After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 82882 - Alpha channel affects RGB pixel values when saved as TIFF
Alpha channel affects RGB pixel values when saved as TIFF
Status: RESOLVED NOTABUG
Product: GIMP
Classification: Other
Component: General
1.x
Other Linux
: Normal critical
: ---
Assigned To: GIMP Bugs
Daniel Egger
Depends on:
Blocks:
 
 
Reported: 2002-05-24 14:14 UTC by Cliff Medling
Modified: 2003-12-02 16:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to break tiff support. This will patch on both the 1.3 and 1.2 branches without any changes. (7.41 KB, patch)
2002-05-29 12:59 UTC, Dave Neary
none Details | Review

Description Cliff Medling 2002-05-24 14:14:59 UTC
When opening TIFF and SGI 4-channel images, any areas where alpha is not 
255 are edited.  If the alpha channel has 0-black, the RGB colors are 
completely removed.
Comment 1 Cliff Medling 2002-05-24 14:20:59 UTC
I have added a test file on our FTP server:
wsiftp.wsicorp.com/pub/dmd/cliff/Original.tiff
Comment 2 Dave Neary 2002-05-24 14:28:06 UTC
I'm not sure I see the problem. Isn't this the way alpha channels are
supposed to behave? When you save something that's transparent in a
tiff, it's colour is "transparent", isn't it? I may be missing
something, though...

Dave.
Comment 3 Raphaël Quinet 2002-05-24 14:37:45 UTC
I am not able to test this right now, but could you check if this
could be related to the problem described in bug #77283 ("Out-of-gamut
alpha pixels turn black in TIFF")?  There is a patch included in that
bug report.  You might want to test it as well.

If this bug is not a duplicate of bug #77283, then it would be nice to
describe a bit better what does not work as expected (maybe this is
obvious when loading the test image, but this is not possible for me
for the moment).
Comment 4 Dave Neary 2002-05-24 17:01:34 UTC
This is unrelated to 283 - I've verified at least that there's an
issue. The tiff plug-in seems to be destructive if there's an alpha
layer. We have (in read_16bits and read_8bits) for 3 different
photometrics (PHOTOMETRIC_MINISBLACK, PHOTOMETRIC_MINISWHITE and
PHOTOMETRIC_RGB), there's apparently destructive operations on the RGB
channels - for example, in read_8bits for the PHOTOMETRIC_RGB, we have 
       case PHOTOMETRIC_RGB:
          if (alpha) {
            red_val= *source; source+= 2;
            green_val= *source; source+= 2;
            blue_val= *source; source+= 2;
            alpha_val= *source; source+= 2;
            red_val= MIN(red_val, alpha_val);
            green_val= MIN(green_val, alpha_val);
            blue_val= MIN(blue_val, alpha_val);
            if (alpha_val) {
              *dest++ = (red_val * 255) / alpha_val;
              *dest++ = (green_val * 255) / alpha_val;
              *dest++ = (blue_val * 255) / alpha_val;
            }

In the tiff output code (in save_image) the RGB values are
pre-multiplied by alpha to get the actual RGB values output. Does the
TIFF standard specify that? 

Basically I can confirm that the GIMP stuff doesn't keep the RGB
values of alpha'd TIFFs through a save. The question, I guess, is
whether it should, and if so, how to fix our code.

Dave.
Comment 5 Dave Neary 2002-05-24 17:27:34 UTC
Just looked at the tiff standard, and the relevant part is this...

"In addition, when associated alpha data are included with RGB data,
the RGB components must be stored premultiplied by the associated
alpha component and component values in the range
[0,2**BitsPerSample-1] are implicitly mapped onto the [0,1] interval.
That is, for each pixel (r,g,b) and opacity A, where r, g, b, and A
are in the range [0,1], (A*r,A*g,A*b,A) must be stored in the file. If
A is zero, then the color components should be interpreted as zero."

So it seems like the behaviour of the GIMP is in likne with the TIFF
standard. The original poster said this was for the saving alpha
channels? In that case, there's no problem. The alpha channel on the
loaded image will be exactly the same as the one in the saved image.
The colour information underneath will be different, though.

Dave.
Comment 6 Cliff Medling 2002-05-24 18:40:23 UTC
The problem does seem similar to bug #77283, however, the TIFF format 
I am using is common, and works correctly under other imaging 
software, like photoshop.

To better explain the problem...In photoshop, when I open the image 
mentioned earlier, you will view a complete image (no transparency).  
In the channel menu, there will be all four channels, with the fourth 
being the alpha channel.  In GIMP, the image that is displayed has 
transparency (wherever black in the alpha channel existed), and all 
RGB info is lost in those areas.

To help explain, I have created a JPEG image of a photoshop screen 
opening the "Original.tiff" file.  Both the Original.tiff, and 
the "photoshop_capture.jpg" images are at:
wsiftp.wsicorp.com/pub/dmd/cliff/

Does this help explain the issue?
Comment 7 Dave Neary 2002-05-29 12:57:47 UTC
I'm closing this as NOTABUG, because (1) SGI does what the original
poster wants, (2) the GIMP does what the TIFF standard wants, and (3)
the extra channel for alpha is already in 1.3, and would probably be
too big a change to put in a stable release. 

In any case, I've patched tiff.c for the original submitter to do the
wrong thing. Patch attached after this comment.

Dave.
Comment 8 Dave Neary 2002-05-29 12:59:50 UTC
Created attachment 8815 [details] [review]
Patch to break tiff support. This will patch on both the 1.3 and 1.2 branches without any changes.
Comment 9 Dave Neary 2002-05-29 13:32:54 UTC
One last thing - when I said "the extra channel for alpha is already
in 1.3, and would probably be too big a change to put in a stable
release", I didn't mean that there is no separate alpha channel in
1.2, since there is, but only that there is no separate "Channel" for
alpha in the Channels dialog. Adding that to the Channels dialog in
1.2 would be a big job, and would probably be too big an UI change to
go into a stable release. So that's what I meant :)

Dave.
Comment 10 Dave Neary 2003-12-02 16:53:56 UTC
Changing subject because it took me ages to find this bug.

Dave.