GNOME Bugzilla – Bug 306675
Greyscale TGA files are not opened correctly
Last modified: 2008-01-15 12:55:35 UTC
Please describe the problem: I have some greyscale TGA files that display gibberish when opened with GIMP. For reference, same TGA files can be successfully viewed with display (ImageMagick) and Kuickshow (KDE). Steps to reproduce: 1. Email me and I will send you an example file (small size) 2. Start Gimp 3. Click File->Open and select this file. 4. Click OK. Actual results: File is opened, but the graphic data is garbled. Expected results: I would expect to see the image properly, as presented by reference programs (display and Kuickshow) Does this happen every time? yes Other information: no
Could you attach the image(s) to this bug report if possible? Note that everybody will be able to see them, so maybe you prefer to create an example image that shows the same behavior and attach that.
Created attachment 47328 [details] This is an example TGA (public domain) that gives a problem
Created attachment 47329 [details] UPDATED: This is an example TGA (public domain) that gives a problem
Thanks. The behavior in GIMP and ImageMagick is exactly as you described, confirming.
I found what causes it - let's see if I can find the info needed to fix it. The file given is compressed (I hope it is RLE compressed,, and not another algorithm) - but it has the image type "3" in the 3rd byte. GIMP's TGA plugin assume these to be uncompressed (tga.c, line 464 : ) case 3: info.imageType = TGA_TYPE_GRAY; info.imageCompression = TGA_COMP_NONE; break; And assume type "0b" to be RLE compressed: case 11: info.imageType = TGA_TYPE_GRAY; info.imageCompression = TGA_COMP_RLE; break;
Nope - no RLE. I tried to force it open with RLE encoding, and got even more gibberish.
Forget the previous 2 comments. The file, IMO is corrupt. I checked the TGA specs from here: http://www.dca.fee.unicamp.br/~martino/disciplinas/ea978/tgaffs.pdf and the field 5.6 from the header (byte at file offset 17), which contains the alpha bits contains "8" in the lower 4 bits - which indicates 8 bits of alpha information for pixel. But each pixel has 8 bits of information total. When placing 0 in this field, the file opens normally in the GIMP. I'd say the file may have been created with the intention of being used as an alpha mask only, and all the values in there are supposed to be alpha values - in that case, oppening this as grayscale (as other apps do) would be incorrect. But it is either that, or this field contains garbage. The plug-in could be modified so that the GIMP would ignore this value,a nd open the image as a flat grayscale, or even modified so that the gimp creates an all white image, and put the file data in the alpha channel. Either behavior seem strange for me.
Where do these images come from? Do we know anything about their intended use?
This image is a bump map (height map) for its corresponding texture. It's used for rendering a 3D scene.
As I wrote, the file indicates that 8 bits of each 8 bits of information per pixel should be used for transparency. Other apps are just ignoring that, and openning the file as greyscale. The patch to ignore the transparency bits when they are equal to the image depth would be trivial - should it be done, since other apps do that?
IMO it would make sense to change the plug-in that way.
Removing NEEDINFO -- doesn't seem needed anymore.
It doesn't need more information but it definitely needs a patch...
Fixed in HEAD. I will assume it is unnecessary to backport this. 2006-05-19 Bill Skaggs <weskaggs@primate.ucdavis.edu> * plug-ins/common/tga.c: gracefully handle incorrect alpha info in header; fixes bug #306675.