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 65534 - targa (TGA) importer alpha support broken
targa (TGA) importer alpha support broken
Status: RESOLVED NOTABUG
Product: GIMP
Classification: Other
Component: Plugins
1.x
Other All
: Normal enhancement
: Future
Assigned To: GIMP Bugs
GIMP Bugs
: 86652 134988 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-11-27 20:12 UTC by Jakub Steiner
Modified: 2007-05-09 13:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
TGA file with alpha channel (generated by blender) (32.62 KB, image/tga)
2001-11-27 20:13 UTC, Jakub Steiner
Details
RGBA TGA, rendered in blender and correctly imported in GIMP (1.26 KB, image/targa)
2007-05-09 13:53 UTC, Jakub Steiner
Details

Description Jakub Steiner 2001-11-27 20:12:15 UTC
I don't know if the alpha channel support is actually there, but opening
TGA files generated with blender results in lack of the alpha channel.
Imagemagic handles those fine. I can `convert blender.tga blender.png` and
open in GIMP with alpha fine.
Comment 1 Jakub Steiner 2001-11-27 20:13:40 UTC
Created attachment 6098 [details]
TGA file with alpha channel (generated by blender)
Comment 2 Raphaël Quinet 2001-11-28 18:20:39 UTC
This shouldn't be too hard to fix and it would be nice to fix it in
1.2.3 (or 1.2.x) because I assume that you are not the only one who
would like to use files generated by Blender.  I will try to have a
look at the TGA plug-in during the week-end and submit a patch if I
find a good solution.
Comment 3 Raphaël Quinet 2001-12-03 17:57:39 UTC
Hmmm...  I looked at this problem and I can provide an easy fix but I
do not know if this is a good solution.  In summary, here is what I
found:
- This image (blender.tga) has 32 bits per pixel (field 5.5 "Pixel
  Depth" according to the TGA specs), but the attributes of the image
  (field 5.6 "Image Descriptor") say that the number of alpha bits
  is 0.  According to the TGA specs, this should be set to 8.  This is
  probably a bug in Blender.
- The Gimp relies only on the number of alpha bits to decide if the
  image has an alpha channel or not.
- ImageMagick relies only on the number of bits per pixel to decide
  if the image has an alpha channel or not (24 = no, 32 = yes).
- Both the Gimp and ImageMagick ignore the contents of field 24
  "Attributes Type" in the (optional) extension area, which is
  supposed to tell the decoding software if the alpha channel should
  be discarded or if it is standard alpha or pre-multiplied alpha.

The easy fix would be to set the number of alpha bits to 8 if bpp==32
and maybe display a warning to the user.  A slightly better fix would
be to issue a warning to the user if bpp == 32 and alphabits != 8.
And then maybe ask the user if the alpha channel should be used or
not.  According to the TGA specs, it is allowed to have an image with
bpp == 32 without alpha channel (i.e., the fourth byte contains
garbage).

Anyway, it looks like Blender, the Gimp and ImageMagic are all wrong
in this case:
- Blender is wrong because it does not set the number of alpha bits
  correctly in the TGA header.
- ImageMagick is wrong because it relies only on the number of bits
  per pixel and does not check the number of alpha bits.  In addition,
  it does not check the extension field.
- The Gimp is wrong (but less than the others) because it does not
  check the extension field.  Maybe it is also wrong because it
  follows the TGA specs more closely than the others and does not
  allow for what could be a common mistake (de facto standard?).

Any suggestions for the best way to handle this?
Comment 4 Sven Neumann 2001-12-03 22:22:29 UTC
I'd suggest to send a mail to the TGA plug-in maintainer Nick Lamb
<njl195@zepler.org.uk>. From my experience he has solid knowlegde about
the file format and its use and will come up with a reasonable fix
pretty soon. 
Comment 5 Nick Lamb 2001-12-06 12:14:54 UTC
Martin Weber asked that this be changed in bug #52728 and it was done
by Stanislav Brabec in branch and HEAD some time later along with
other changes that Martin requested.

So it used to do what the reporter wants (with a warning), and now it
doesn't. This is arguably correct behaviour. In fact pretty much
anything is arguably correct behaviour for TGA. If someone finds a
definitive reference that says we should do something else, I'll
change it and undo this part of Martin's changes.

I am loathe to harass the user with a dialog every time they open a
valid file which "might" contain alpha data, although if someone comes
up with an algorithm that can determine for any file whether Gimp
should or should not read alpha data from it then I'm happy with that.

The CORRECT fix to the reporter's problems is to get the Blender team
to write valid image files. If someone gives me a contact within the
Blender team that is empowered to do that I will work with them to
explain what is needed (amazingly it seems that many 3D people know
almost nothing about 2D image formats)

Note that Raphael mentions in passing the "to pre-multiply or not to
pre-multiply" dilemma for TGA, which Blender should also fix but this
DOES require work on Gimp. The effect of this is that transparency
doesn't look quite right if we ignore the TGA2 trailer. If we get that
far I'll fix it :)
Comment 6 Raphaël Quinet 2001-12-06 13:34:42 UTC
I'd like to have the warning back, please.  ;-)

If possible, it should be something like "TGA: possibly incorrect
alpha in [file].  Do you want to use this alpha channel?" and some
yes/no buttons.  Solving the problem on the Blender side would
probably help, but Blender is not the only application that generates
incorrect TGA files (incorrect meaning "not according to the specs",
but the specs do not seem to be followed very closely by many apps).
Besides, what would the users do with the existing files that were
created before the culprits were punished?  I think that we should
follow the principle "be tolerant in what you read and strict in what
you write" so the TGA plug-in should accept these broken TGA files
and warn the user about them.

We could even add some propaganda in the warning message, such as:
"This TGA file seems to have been written by an application that does
not follow the TGA specifications, version 2.0.  Please complain to
the developers."
Comment 7 Raphaël Quinet 2002-06-28 07:38:07 UTC
*** Bug 86652 has been marked as a duplicate of this bug. ***
Comment 8 Michael Natterer 2003-03-13 22:28:26 UTC
Added (TGA) to the desc. so it doesn't take half an hour to
find this bug next time :)
Comment 9 Sven Neumann 2003-06-11 10:24:03 UTC
Is bug #114913 related (or even the same problem) ?
Comment 10 Alan Horkan 2003-07-23 18:37:18 UTC
Changes at the request of Dave Neary on the developer mailing list.  
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone.  Hope that is acceptable.  
Comment 11 Dave Neary 2003-07-24 10:32:47 UTC
Seems to me that this is more a bug in the TGA handling than a feature
enhancement. It would be nice to have some action on this before 2.0.
Resetting milestone accordingly.

Cheers,
Dave.
Comment 12 Dave Neary 2004-01-13 14:35:28 UTC
Is there any reason we don't read the alpha channel if it's there (a
la ImageMagick), taking account of alpha-bits if it's non-zero? That
seems like it would be an easy fix.

Dave.
Comment 13 Raphaël Quinet 2004-01-13 17:31:27 UTC
Another solution (which would be similar to what we need for TIFF): if
the TGA image contains an extension field specifying a number of alpha
bits, load this as a mask, not an alpha channel.  This seems to be how
most apps use these alpha bits for.  If the TGA image does not specify
a number of bits for alpha but it has 32 bits per pixel instead of 24,
then load the extra data as an alpha channel.  Use the same logic when
saving: if the layer has a mask, declare alpha bits in the TGA file.
If there is no mask but the layer has alpha, then save 32 bits per
pixel.  This would allow the GIMP to load and save images in a way that
would be closer to the current practice for TGA files (although not
strictly in line with the specs, but these specs are not very good
anyway).
Comment 14 Dave Neary 2004-02-24 20:54:05 UTC
*** Bug 134988 has been marked as a duplicate of this bug. ***
Comment 15 Dave Neary 2004-03-10 10:48:40 UTC
Bumping a bunch of bugs which won't block the 2.0 release to 2.0.1.

Dave.
Comment 16 Sven Neumann 2004-04-03 10:55:19 UTC
Bumping to the 2.2 milestone since noone seems to be actively working on this
problem and it shouldn't block a 2.0.x release.
Comment 17 weskaggs 2004-12-11 22:33:54 UTC
My take on this bug report is that it would be easy to change the TGA plug-in to
do any of the things suggested, but there is no consensus on which of those
things it ought to do.  If Sven says "I approve of this suggestion" for any of
the comments above, or any new comment, I will undertake to implement it. 
Meanwhile, based on comment #5 I am going to reclassify this as an Enhancement
until it is clear that there is a definite bug here that ought to be fixed.
Comment 18 Sven Neumann 2007-05-07 16:45:05 UTC
It would help if someone could write a short summary of this bug report and give an update on the situation with respect to files written from Blender.
Comment 19 Raphaël Quinet 2007-05-08 18:51:11 UTC
I hope that jimmac (or someone else who uses Blender more actively than I do) can provide an update regarding Blender.

As for the solution, I think that what I suggested in comment #13 could be still applied: if the TGA image contains 32 bits per pixel, then load the extra bits into a layer mask regardless of what is specified in the number of alpha bits.  Using a layer mask instead of an alpha channel makes it easier for the user to discard this extra information in case it contains garbage, so maybe we do not need a warning in this case.
Comment 20 Sven Neumann 2007-05-08 19:17:53 UTC
Only few users know what layer masks are and how to handle them. I don't think using a mask is a good idea.
Comment 21 Jakub Steiner 2007-05-09 13:52:21 UTC
I exported a render as RGBA TGA file from a recent blender and opened it fine in GIMP. 

I guess it was fixed on the blender side as the attached image above still has the issue. Marking as NOTABUG even though other gnome apps such as eog seems to open it correctly showing alpha.
Comment 22 Jakub Steiner 2007-05-09 13:53:45 UTC
Created attachment 87877 [details]
RGBA TGA, rendered in blender and correctly imported in GIMP