Same files, only in .zip format:
http://stolen.paul.googlepages.com/gimp-tga.zip , http://stolen.paul.googlepages.com/ps-tga.zip

Ingame shot of the problem:
http://stolen.paul.googlepages.com/shot0000.jpg <= gimp tga-file (yellow shield) vs PS:CS2 original (cyan)

Excerpt from "Creating a starship", explaining how to make a tga-file with a proper alpha channel via PS:CS2:

There are two ways you can use these images (rgb flattened image and alpha channel) in the game. The more common is combining them into one .tga file. It's very simple. Open the RGB image, go to the "Channels" tab and create a new channel. Copy the Alpha image, and paste into this new channel. You now have a 4-channel image that you can save as a 32-bit .tga file (e.g. graphics/ships/ter_asst.tga).

( http://www.digital-eel.com/modguide/ship_example.htm )

If you think that TGA support is important, feel free to improve the TGA file plug-in. Since noone else is actively maintaining the TGA plug-in at the moment, your issues are not likely to get fixed otherwise.

All other apps is slightly exaggerated:

- Inkscape reads the file correctly
- Graphicsmagick reads the file correctly

Also, your shield graphic made in  GIMP is almost opaque already, and you didn't supply the cyan shield graphic for reference.

Created attachment 64730 [details]
Original Shields

Michael Schumacher:
All other apps is slightly exaggerated:
Correct, all other apps is only the case for the applications i use, not
neccesarily everyone else's.
Not even Firefox (ver 1.5.0.3) gets it right in my tests, though.

Also, your shield graphic made in  GIMP is almost opaque already, and you
didn't supply the cyan shield graphic for reference:
Original file attached.

Also note that this file and the contents of the ps-tga archive are picked from
the retail game and should only be used for debug purposes, lest the artist who
made them get irate and furious. :)

Bug 65534 could be releated. BTW, the original shield.tga file is displayed as a blank image in GIMP, GraphicsMagick and Picasa2.

GraphicsMagick identify tells me:

$ gm identify -verbose shield.tga 
Image: shield.tga
  Format: TGA (Truevision Targa image)
  Geometry: 256x128
  Class: DirectClass
  Type: true color with transparency
  Depth: 8 bits-per-pixel component
  Channel Depths:
    Red:      8 bits
    Green:    8 bits
    Blue:     8 bits
    Opacity:  1 bits
  Channel Statistics:
    Red:
      Minimum:                     0
      Maximum:                   255
      Mean:                        7.4194
      Standard Deviation:         30.3741
    Green:
      Minimum:                     0
      Maximum:                   255
      Mean:                        7.3904
      Standard Deviation:         30.7184
    Blue:
      Minimum:                     0
      Maximum:                   255
      Mean:                       15.6633
      Standard Deviation:         39.5969
    Opacity:
      Minimum:                   255
      Maximum:                   255
      Mean:                      255.0000
      Standard Deviation:          0.0000
  Opacity: (  0,  1,  1,255)      #000101FF
  Colors: 2136
  Filesize: 128.0k
  Interlace: None
  Background Color: grey100
  Border Color: #DFDFDF00
  Matte Color: grey74
  Dispose: Undefined
  Iterations: 0
  Compression: 
  Signature: eb559e518e66d5100fdd4123536b844956f5473b2a4361b8fb77e3f0a0d80f87
  Tainted: False
  User Time: 0.000u
  Elapsed Time: 0:01

Paul,

  The bottom line here, as I see it, is that we aren't convinced that GIMP is doing the wrong thing and your other apps the right thing -- given that Inkscape,  imagemagick, and (for me) gthumb all do the same thing as GIMP.  There are some applications around that produce incorrect TGA files, and other applications that have been hacked to be able to deal with those incorrect TGA files.  Firefox relies on plug-ins to handle TGA, so the way it behaves will just be a function of what plug-in you install.  So the net result at this point is that it isn't clear that anything in GIMP should change.  We would need to understand what is going on here better in order to do anything about it.

I'm not about to debate what kind of tga's are "correct", the main problem here is that Gimp cannot write tga's that can be read properly by most applications I use.
The fact that inkscape and imagemagick read these files without issues doesn't help me one bit.

There are no evil TGA's, there are just different kinds of them; See, I would like nothing more than to see Gimp to read and write using the subtly different minority format I seem to have discovered. You, on the other hand, use the first chance you get to slap an 'incorrect' label on it just because it does not conform to the standard your applications use.

Shaaame on you.

You might want to read http://www.catb.org/~esr/faqs/smart-questions.html#answers in order to understand possible comments which were provoked by your comment #8.

Of course, this could also have been an attempt to be funny and/or ironic, but such things usually go terribly wrong if not marked by the proper smilies.

If you are interested in getting help, then "We would need to understand what is going on here better in order to do anything about it." is what you should make easier for us - you could e.g. ask the artist and/or game developer what TGA spec the images used in the game conform to.

Well, I am not offended by comment #8, but I think it is missing the point.  The software community has learned by painful experience that, to avoid chaos, when a file format is created, it needs to have a file format specification written out, describing the rules of exactly what a file needs to contain in excruciating legalistic detail.  Programs that use files should then handle the format as it is described in the specification.  When there is a problem, the program that should be fixed is the one that fails to follow the specification.  If every program feels obligated to support everything that exists, regardless of whether it follows the specification, then you have a recipe for anarchy.  Again, this is a lesson learned from experience.

There have been cases where files that are incorrect in a certain way have been so common that it was more convenient to support them than to be legalistic about it.  But those are exceptions.  As far as we are concerned, if GIMP is following the official TGA specification and some other program is not, then GIMP is right and it is the other program that needs to be changed.

From your point of view as a user, of course, you just want things to work, and don't care about these questions.  But from our point of view as developers, we have to enforce the rule that specifications need to be followed.  So the thing that would convince us that something needs to be changed in GIMP is evidence that  GIMP is not following the TGA specification, and we haven't seen it yet.

If you are interested, you can find a PDF version of the TGA specifications at

www.digitalpreservation.gov/formats/fdd/fdd000179.shtml

As per comment #10, this should probably be NEEDINFO.

Resolving as INCOMPLETE due to lack of response from the bug reporter, who seems to have become disgusted with the whole affair.

Actually, I'd sort of forgotten about it :P
No rush, I use TGAs with partial alpha quite rarely.
Whenever i need one, i'll just get someone with PS CS2 to help out :P

In comp.graphics.apps.gimp, someone encountered a similiar problem recently: http://groups.google.com/group/comp.graphics.apps.gimp/browse_thread/thread/95cf9823a547a7d5