IM not detecting alpha on compressed TGA's

[brianw]

Hey everyone,
Ok, so I'm working with images that are used in an existing program. Some of the images, like this one:

actual file here: http://invisiblecarrot.com/images/im/odouls.tga

are regular uncompressed TGA's that IM detects with an alpha channel. Now, if I convert straight to PNG, I get this:


But that's ok, I use these commands (and the Ruby equivilent) to get the correct PNG:
convert odouls.tga -alpha off odouls_alpha_off.png
convert odouls.tga odouls_inverse_alpha.png
composite -compose minus odouls_alpha_off.png odouls_inverse_alpha.png output.png

Now, some TGA's are run across are compressed, like this one:
http://invisiblecarrot.com/images/im/package.tga

The program I'm messing with sees the TGA above as this:


So the app is detecting an alpha channel. But If I pull an "indentify -verbose package.tga" IM doesn't detect an alpha channel. If I convert it to a png, the supposedly transparent sections are blacked out. The only images I've come across like this are the compressed TGA's. Photoshop doesn't see the alpha in the compressed TGA's either.

So is whatever app the person is using to produce the TGA's doing something weird? I initially thought that the app was using a color-key or something like that, but it specifically mentions the image having transparency info in it's "diagnose" section:
Bitmap image loaded successfully.
Bitmap contains transparency information.
13.1% of the image's pixels are transparent.

Anyway to get IM to see the alpha channel in these TGA's? Thanks for your help!

EDIT:
I'm using ImageMagick 6.5.6-8 2009-10-03 Q8 OpenMP.

[fmw42]

IM 6.6.3.10 Q16 (HDRI)

IM verbose info shows your odouls.tga image to have transparency. Mac Preview, IM display, GraphicConvert (on my Mac) all display your odouls.tga image the same as you show after it is converted to PNG (mostly transparent with some white). Only Photoshop shows it the way you display it above. That is because in PS it has an alpha transparency channel (mask), which photoshop does not show by default (it only shows background transparency). This alpha channel mask gets read into IM as alpha data. So as far as I can tell that image is fine. It has alpha data which all these other tools are using to display where it is transparent.

IM (verbose info) shows that your package.tga image has no transparency. PS does not see either background transparency or alpha transparency. None of my tools show transparency anywhere. So I am not sure where your transparency is coming from in that image. Perhaps in some other proprietary tag?

What viewer and platform are you on?

[brianw]

Perhaps in some other proprietary tag?

You're probably right. The app (Space Planning Pro) that's viewing it correctly is a really industry specific tool (retail space management) so there may be some proprietary stuff going on in there. But SPP doesn't actually create those TGA's, they're brought in from other sources. So it's possible that whoever is making those pics, they're using some weird program to write the TGA's.

But one thing I do know is that SPP uses LeadTools(http://www.leadtools.com/) to do it's imaging work. I don't know if that matters, but it seems atleast LeadTools can see the alpha channel on those somehow.

What viewer and platform are you on?

SPP is a Windows only program. But I've played with the images on OSX and Vista.

[fmw42]

Perhaps you may find more information about your file's transparency with exiftool.

Actually exiftool is mystified by your image:


exiftool -s -ee -g1 -u -n -D package.tga
---- ExifTool ----
- ExifToolVersion : 8.24
- Error : Unknown file type
---- System ----
- FileName : package.tga
- Directory : .
- FileSize : 50854
- FileModifyDate : 2010:09:01 11:36:20-07:00
- FilePermissions : 644

[Drarakel]

Exiftool doesn't support TGA. But the TGA files here don't have metadata anyway.

Now, some TGA's are run across are compressed, like this one:
http://invisiblecarrot.com/images/im/package.tga

I see two problems with that file:
1) It's an uncompressed (!) 16bit per pixel TGA file with binary transparency. The red, green and blue samples are stored with 5 bits, and the alpha component has 1 bit. It seems that not many imaging tools can use the transparency in 16bit TGA files. (I'm not even sure what the official TGA specs say about this. Though at least at fileformat.info, it's suggested that '16-bit pixel with overlay bit' is a normal format.)
The TGA decoder in ImageMagick can only generate transparency for 32bit per pixel TGAs at the moment.
2) Additionally, the header could be slightly wrong. In 'package.tga', the byte for the alpha channel depth is set to 0. Should be 1 perhaps. (The byte for the overall pixel depth can be 15 or 16. Currently, that is set to 16.)
The program that you were using probably always expects alpha (in the most significant bit) in the 16 bit values - regardless of the additional header bytes.

With a modified header, at least Gimp can use the transparency in your file and gives that output:

[brianw]

Sorry for not replying!

@fmw42: Thanks for your time.

@Drarakel: Awesome work! Do you happen to have the fixed header TGA lying around still? I'd like to compare that with the original.
So is only Gimp able to read 16-bit TGA's with an alpha channel? Or can IM read the TGA correctly if the header is fixed?

[Drarakel]

Here you are:
package_2.tga (Link deleted)
But it's really only one byte that's important here. It's byte 0x11 that stores the 'alpha channel' depth in TGA (according to the specs, only the lower four bits). Has to be set to 0x01 in your 16bit per pixel TGA file.

So is only Gimp able to read 16-bit TGA's with an alpha channel? Or can IM read the TGA correctly if the header is fixed?

On my system, only Gimp worked. Perhaps Photoshop can read it, too (didn't test that). ImageMagick can't read the alpha values in 16-bit TGAs (but only in 32-bit TGAs).

[magick]

We have a patch for this problem. Look for it in ImageMagick 6.6.4-3 Beta by sometime tomorrow. Thanks.

[brianw]

Excellent, thanks everybody.

[brianw]

The 6.6.4-3 Beta works great on my fixed header 16-bit TGA files. Thanks to everyone that helped me.

To book end my saga(lol), I'd like to share some code in case anyone ever runs across anything like this again. First, if anyone gets 'damaged' TGA's like I got, here's some Ruby to patch the header:

Code: Select all

#Big ups to Drarakel for the help!
if IO.read(bad_tga_file, 2, 16).unpack("H*")[0] == "1000"
  puts "It's bad, let's fix it..."
  io = File.new(tga_path, 'r+b')
  n = [15, 01]
  io.pos = 16
  io.write n.pack("cc")
  io.close 
end

In my case, all of my damaged TGA's had the same incorrect pixel depth (offset: 0x10) and the same incorrect ImageDescriptor (offset: 0x11). They all had the same incorrect values, so if anyone uses this you may want to just check for an incorrect ImageDescriptor as you may not have the same data as I did.

Second, I found a better way to deal with my 'inverted' alpha channels I was getting on some of the non-broke TGA's. Instead of:

Code: Select all

convert odouls.tga -alpha off odouls_alpha_off.png
convert odouls.tga odouls_inverse_alpha.png
composite -compose minus odouls_alpha_off.png odouls_inverse_alpha.png output.png

The better Ruby-equivalent would be:

Code: Select all

image = Image.read(tga_path).first
mask = image.copy
	
if mask.alpha?
  mask.alpha(DeactivateAlphaChannel)
  image = image.composite(mask, CenterGravity, XorCompositeOp)
end  

Instead of using minus, XOR was the way to go.
Thanks again everybody!