GNOME Bugzilla – Bug 77283
Out-of-gamut alpha pixels turn black in TIFF
Last modified: 2009-08-15 18:40:50 UTC
I have a TIFF file with alpha that does not display correctly in Gimp, but works fine in all other applications I have tested. When I load the image, and pixel who's alpha value is not 255 gets displayed as a black pixel. This only happens with TIFF, not other formats. I have example files that I would like to send, but I don't see any way to add attachments here. What should I do?
Please attach the image file(s) to this bug report. This is easy to do: after you submit your bug report, you have a link "Create a new attachment", which does exactly what it says...
Created attachment 7515 [details] This is the image that causes problems. Note the "hole" that appears at (205,277) to (206,276) where the alpha is 254.
Created attachment 7516 [details] Here is that same image converted to png. It looks fine in gimp.
Argh, Entropy! More 3D industry software. Look at that "TimeStamp" present in both files. Which year is 0102? The cretins that wrote _this_ piece of 3D software decided to store ExtraSample associated alpha that is not pre-multiplied, in contravention of the TIFF specification (Adobe TIFF R6.0 final). I'm going to assume that this particular bit of random 3D software is expensive, and that therefore you can call them up and personally shout at the people responsible until they fix it. If I'm wrong about that then you probably need to email them and hope for a fix in some later version. This is NOTABUG in The GIMP. Thanks for telling us about this, if you need someone to speak verrry sloowly to your vendor until they understand then give them my email address.
Summary changed to match the problem, now that I know what's wrong. Apparently I can't mark this NOTABUG. Someone please do so and change the summary to "Entropy creates invalid TIFFs" so that other users can find it easily.
Ok. Thanks for the info.
I think that it is more appropriate to mark this as NOTGNOME instead of NOTABUG. According to the description of the Resolution field, NOTABUG is for something that is intended to work as described, while NOTGNOME is for something that is really a bug, but not in our software (in this case, not in the GIMP). So I am changing the status accordingly. By the way, some software that is not transparency-aware (e.g., xv) displays the TIFF image correctly (without transparency, but without a black spot like the GIMP does). So some users might think that the GIMP is broken, even if the error comes from Entropy.
OK, apparently I'm the one who needed to be spoken to "verrry sloowly" and the PNG attached to this bug is incorrect, not the TIFF. CVS Gimp 1.2 is fixed and I will take care of applying a similar fix to CVS HEAD soon. Sorry for the inconvenience Greg, I will add a patch to this bug which contains the CVS changes, this should apply fairly cleanly to any recent version that you're using and resolve this issue with TIFFs from Entropy and similar software for you.
Created attachment 7830 [details] [review] Patch for tiff.c from Gimp 1.2.x
This patch appears to fix the bug for us. Thanks.
Fix applied to CVS 1.3 too. Updated and re-resolved. A little bird tells me that Gimp 1.2.4 will be out 'soon' and will therefore roll up this fix for the general public.
For the record, the png file attached here was created from the tiff file with ImageMagick, like this: convert -quality 100 myfile.tiff myfile.png (Nick Lamb had asked, but my emails to him are bouncing).
The fix is part of the stable release 1.2.4. Closing this bug.