More progress. The sample image now displays correctly.
- fixed
- flipped the flags, so it now displays black on white like ImageMagick shows, but why is 'blackIsZero' == 1?
- fixed, although not verified on a .tif with height and/or width not a multiple of 8 (for bi-level)
- still discarding alpha until confirm that all images are handled correctly (sample file all alpha are 1 = opaque)
- no further work on this yet
- will need some real non-bi-level .tif images, with real alpha channel (not just full opaque/transparent) to check this
'fillOrder' on this .tif is 1... I'll have to look and see if fillOrder and planarConfiguration have any effect. What I'm worried about is either a sample order that's not GA or RGBA, or bit orders within samples are reversed. Also, if a strip does not fill a whole number of pixels (i.e., there's some bits left over in the strip's last byte), I fear that it will get out of sync with the data by not discarding that last bit of junk -- or does Graphics::TIFF hide this from me somehow?
If I read the TIFF spec correctly, it is possible to have different sized (bits per sample) samples, and not necessarily 2^N size, e.g. 5 bit Red, 8 bit Green, 2 bit Blue, and 4 bit Alpha. However, Graphics::TIFF seems to return all samples the same size -- is this an error, or are they resampled to all be the same size and possibly all 2^N size?
At some point, with some real-world experience under my belt with this, it may turn out that the pure Perl code to split out the image and alpha from the buffer (as well as un-pre-multiplying the image) is too slow, an we'll have to approach the Graphics::TIFF author about adding an XS code (C) splitter, as was done in Image::PNG::Libpng for PNG support.
Cary, I can't go much further without someone with a selection of real .tif files of various types seeing if they work with the revised TIFF_GT.pm. As your request for TIFF+alpha support is driving this work, I'd like to ask for your help on this.