LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2006
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2006.09.16 20:01 "Re: alpha in Grayscale or Palette", by Joris Van Damme
Bob and All,
Bob Friesenhahn wrote:
> > 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.
Right.
In general, these issues in practice I think should be viewed from three
angles.
- the spec
- interchange
- LibTiff
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.
Best regards,
Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html