2006.09.16 20:01 "Re: [Tiff] is there alpha component present in GrayscaleorPalettecolor image", by Joris
Bob and All,
What I am thinking is an extra data plane, not an extra column in the color table.
Right. An interesting issue is that libtiff requires that all samples be the same size so Pallete images using a small bits per sample for the index impose the same bits per sample restriction on the alpha channel. For an 8 bits per sample image, this is not usually a restriction, but it becomes more so for 2 or 4 bits per sample.
In general, these issues in practice I think should be viewed from three angles.
- the spec
As to the spec, I think the specification should largely be viewed as defining a good subset of what's possible in TIFF. Things that aren't specifically mentioned in the specification, but that are a logical and unambigious extension thereof, should be regarded as valid. For instance, when it comes to grayscale images, the spec mentions bitdepths 4 and 8. But the exact wording ("Allowable values for Baseline TIFF grayscale images are 4 and 8") as well as the location in the spec (it's all part of "Part I Baseline TIFF") indicates any other bitdepth can be perfectly valid too. The fact that we all agree 16bit grayscale is perfectly possible, and common practice, is consistent with this.
This is especially important given the age of the specification. It's clear the spec is written with the technology and practice of a decade ago in mind. If we were to restrict ourselves to what's explicitely mentioned in the spec, we would be missing out a lot that is in fact regarded very common practice today, and is certainly much needed too.
This is one of the reasons why I dislike dividing TIFFs in classes like 'class F' and 'class P'... It may make some sense if you restrict yourself to what is explicitely defined in the specification and as such is part of baseline TIFF. It stops making much sense though if you start interpolating the baseline, and such an interpolating action is necessary to cover today's common practice anyway. And it totally makes no sense at all if you interpolate the whole way and view the total of what's possible in TIFF. All you can say at that point, is that everything pretty much combines with everything as long as it doesn't stop making sense, and all border lines between 'TIFF classes' get crossed in continuous manner...
That point of view opens up a shere unlimited number of possibilities, but people that aim for good interchange should bear in mind not all these possibilities are widely supported by TIFF readers out there. For example, you'd have no problem with 16bit grayscale in most readers, but most would likely give up and present the user with a (possibly meaningless or downright incorrect) error message when you try to feed them a 5bit or 20bit grayscale image. Whether or not this is important, depends on what you're aiming for. In a TIFF writer that ends up with on everage end-user desktop, you may want to consider this and not give the user the option to write 5bit grayscale, or either at the very least accompany this option with a warning that most readers are likely to choke on it. In a closed system where your own code is the only code that reads the files back, this issue should not be important, and stuff like 5bit or 20bit grayscale should likely not be considered a problem at all. It certainly is valid.
The third point of view, in practice, is equally important. If your codec can't write it, any discussion about validity is in practice somewhat moat. For many people, that means in practice LibTiff does define what's possible in TIFF.
When it comes to palette images, the issue is not simple. Interpolating the spec, certainly the number of channels/samples is unlimited in all cases, and accompanying the palette index channel/sample with an alpha channel/sample should thus be perfectly legit.
Also, through the use of the Indexed tag defined in one of the specification supplements, it may or may not be possible to actually have an RGBA palette, or a palette in any other color mode that includes alpha, but I'm not quite clear on that, I'm not even sure it's unambigious and certainly it may not be worth further investigation as nobody every adopted support for the Indexed tag anyway.
As to interchange, I think you'll find broad support exists only for single channel 8bit palette images. If you need to write palette images, and you need to write them such that most other readers have no problem dealing with them, single channel 8bit palette images, without any form of alpha or other extra channel, is the single only way to go (for now... chickens and their eggs are related and so some bravery may sometimes be a good thing, as like when Bob unleashed his all-sorts-of-bitdepths palette images on the world).
Finally, as you say Bob, LibTiff support may be another limiting factor, and while I'm no expert on that part it certainly does seem the restriction of using a single bitdepth for all channels does have major implications in this case.
Associated alpha makes no sense since Pallete entries are not related to pixel position but associated alpha is related to pixel position.
I'd agree, but you should note PNG thinks otherwise. If I remember correctly, PNG does support alpha in palette color specification. They call it 'poor man's transparency', though I've never understood why that name should apply as you need to be a very rich man to find the time to think through all implications and fully integrate the concept into your image processing library.
I certainly agree it is safe to say this type of usage of alpha is weird, at the very least, for the exact reason you mention.
Joris Van Damme
Download your free TIFF tag viewer for windows here: