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 134988 - TGA Image Descriptor Byte not checked for correctness in header when loading
TGA Image Descriptor Byte not checked for correctness in header when loading
Status: RESOLVED DUPLICATE of bug 65534
Product: GIMP
Classification: Other
Component: Plugins
1.x
Other Windows
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2004-02-20 20:15 UTC by ju92kqj02
Modified: 2004-02-24 20:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description ju92kqj02 2004-02-20 20:16:23 UTC
Hello,

The TGA "Image Descriptor Byte" is not checked for correctness in header
when loading.

To replicate this bug repeat these steps.

Find an invalid tga, or create your own as follows:
save 24bit (no alpha channel) tga, byte17 will have the following in the
lower bits:

===============
Bits 3-0 - number of attribute bits associated with each
pixel.  For the Targa 16, this would be 0 or 1.  For the Targa 24, it
should be 0.  For Targa 32, it should be 8.  
================

In my replicatable bug, I was given a tga with 0x28 for 24bit tga, instead
of 0x20 as it should have been.
GIMP loaded the file, and did not detect the inconsistency in the header.
GIMP obviously read the 0x28 and flagged the texture as 32bit because the
blue channel was duplicated in the channel window and listed as an "alpha
channel".

Could a consistency check be made on the tga headers when loading?  and if
the depth byte 16 is 24bit this should be regarded as the bitdepth indicator.

Kind regards





I replicated this bug with:
gimp-2.0-pre2-i686-setup.zip
gtk+-2.2.4-setup-2.zip
Comment 1 Raphaël Quinet 2004-02-20 20:58:32 UTC
Is this a real problem?  If the TGA image is incorrect but some parts of
it can be loaded despite some errors in the file format, then I think
that it is reasonable for the GIMP to try and load the file anyway.  The
GIMP should handle correct files in the right way and try a best-effort
approach for the incorrect files.  What you get from an incorrect file
may not always be good, but this is fine from my point of view as long
as the GIMP does not crash.  Nobody should be surprised by the principle
"garbage in, garbage out".
Comment 2 ju92kqj02 2004-02-24 20:08:35 UTC
Hello quinet@gamers.org,

You raised some good points.

So when the GIMP reads a TGA with conflicting information (depth is
24bit, image descriptor byte is 32bit) I think there are several
courses of action GIMP could take:

1. The GIMP could detect there was conflicting depth info.   Display
an error dialog, ask if user would like to continue and GIMP will "do
its best" get the image loaded.  Then GIMP calculates the larger depth
against the x/y resolution and sees if the file size is big enough? 
if so, use that data.  Otherwise use the lower resolution.

2.  The GIMP could default to just load at the lowest certified
resolution.

3. Present, assume the TGA is the larger of the two conflicting
depths.  Do not report an error, and use the blue channel if not
enough bytes to have an alpha channel.

I think method (1) is best,  what do you think?  If GIMP can make
"best efforts" to deal with the broken TGA file this is great.  Also I
think the user should be notified by a dialog error about this problem
so they are aware.  (Presently I noticed the blue channel was
identical to the "alpha")


Kind regards
Comment 3 Dave Neary 2004-02-24 20:54:06 UTC
This looks like a duplicate of bug # 65534, which also talks about
discrepancies between the TGA header and contents.

Dave.

*** This bug has been marked as a duplicate of 65534 ***