GNOME Bugzilla – Bug 82882
Alpha channel affects RGB pixel values when saved as TIFF
Last modified: 2003-12-02 16:53:56 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.
I have added a test file on our FTP server: wsiftp.wsicorp.com/pub/dmd/cliff/Original.tiff
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.
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).
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.
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.
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?
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.
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.
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.
Changing subject because it took me ages to find this bug. Dave.