Created attachment 6098 [details]
TGA file with alpha channel (generated by blender)

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.

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?

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. 

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 :)

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."

*** Bug 86652 has been marked as a duplicate of this bug. ***

Added (TGA) to the desc. so it doesn't take half an hour to
find this bug next time :)

Is bug #114913 related (or even the same problem) ?

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.  

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.

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.

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).

*** Bug 134988 has been marked as a duplicate of this bug. ***

Bumping a bunch of bugs which won't block the 2.0 release to 2.0.1.

Dave.

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.

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.

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.

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.

Only few users know what layer masks are and how to handle them. I don't think using a mask is a good idea.

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.

Created attachment 87877 [details]
RGBA TGA, rendered in blender and correctly imported in GIMP