16bit TGA with transparency

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
elperepat
Posts: 1
Joined: 2015-04-28T06:47:49-07:00
Authentication code: 6789

16bit TGA with transparency

Post by elperepat »

Hi!

I'm doing some embedded (arduino + color LCD) projects and was looking for a file format that has transparency and low bit count. Arduinos have little processing power and little memory, so jpeg and png decoding was ruled out. I wanted to use BMP files but imagemagick does not support 16bpp with transparency. I chose TGA as my format of choice.

I saw that since 6.9.0, 16 bit TGA files were supported. However, I had a lot of problems with transparency.

First, the TGA writing was wrong about "and-ing" 80 to the 16 bits to do alpha channel. It should have been 0x80. (The MSB of the byte)

But then struck another problem. Not a lot of viewer are able to parse 16 bits TGA with transparency properly. The only one working about right is gimp. But the files were still incorrectly displayed. Based on a specification sheet of TGA ( http://www.fileformat.info/format/tga/egff.htm ), and the fact that with 32bpp files, a fully transparent pixel is one with 0 value in the attribute byte, I extrapoled that the attribute bit would be the same in 16bpp files and 1 for a fully opaque pixel. So, the current implementation was reversed.

That where the < midpoint change to > midpoint comes from.

Also, the header also did not specified the number of attribute bits when using 16bpp files, as it did when using 32bpp.

So I added a little logic to put a 1 in the "Image Descriptor Byte".


Lastly, when inputing the resulting file back into IM, the transparency was inverted.

This is the reasong the ternary operation being inverted.


With all this, the 16bpp files created with IM can now succesfully be read with gimp and a file created with it can succesfully be converted back to an other format with IM.



The patch is here:
http://pastebin.com/suC6vV6W


Thanks

Patrick


References:
http://www.fileformat.info/format/tga/egff.htm
http://www.paulbourke.net/dataformats/tga/
https://rt.cpan.org/Public/Bug/Display.html?id=32926
https://bugzilla.gnome.org/show_bug.cgi?id=114913

User avatar
dlemstra
Posts: 1596
Joined: 2013-05-04T15:28:54-07:00
Authentication code: 6789
Contact:

Re: 16bit TGA with transparency

Post by dlemstra »

Thanks for all the detailed information. I will take a look at it this weekend.
.NET + ImageMagick = Magick.NET https://github.com/dlemstra/Magick.NET, @MagickNET, Donate

User avatar
dlemstra
Posts: 1596
Joined: 2013-05-04T15:28:54-07:00
Authentication code: 6789
Contact:

Re: 16bit TGA with transparency

Post by dlemstra »

I found the following in the documentation:
Alpha channel is a nondescript name that indicates the degree of transparency of a displayed pixel. Alpha channel and overlay values are used when one image is overlaid onto another image or onto a live video picture. A single overlay bit (as in the Targa 16) can only indicate that the pixel is visible or invisible. Eight bits of precision can vary the visibility of a pixel from completely transparent (0) to completely opaque (255).
I think it is safe to assume that 0 means transparent/invisible and 1 means opaque/visible even though this is not clearly stated in the documentation. I just applied your patches to our SVN repository so this will be fixed in the next release of ImageMagick (6.9.0-3). I had to make another fix that you missed, it should be '< midpoint' instead of '> midpoint' in the last block that you patched.
.NET + ImageMagick = Magick.NET https://github.com/dlemstra/Magick.NET, @MagickNET, Donate

Post Reply