1993.10.05 22:32 "Re: regarding 16 bit components in tiff", by Dan McCoy

We have an application that would like to use tiff format to store images with 16 bits per component, sometimes also 4 components/pixel. Some interesting questions arise, which don't appear to be covered either in the docmentation or in common practice.

1. what endian order should be used to store 16 bit components?

The native order of the writer.

There was some debate about whether the reader had to check or not. In the lastest librib, the library will byte-swap the data if necessary, so the reader get's it in his native order from the library.

In other words, you shouldn't need to care.

1. Is this affected by the endian order used to store the header.

Yes, it should match.

2. what component order should be used for 4 component x 16 bit images?

No different from the order of 8 bit components.

If it's rgba, alpha is defined by the ExtraSamples tag, extra samples come after the normal samples covered by the Photometric.

2. Likewise, should this be affected by the endian ordering of the header.

Emphatically, No!

3. how will 16 bit components interact with various supported compression schemes?

LZW will compress the byte stream, since it is a byte-string compressor, two-byte colors are just two byte strings. It doesn't do as good of a job as it does on an 8-bit image, but there is a lot more information there.

The horizontal differencing predictor used with LZW knows enough to do the difference on the 16-bit values rather than just bytes. (This is one of the reasons why the library has to do the swap.)

PackBits just deals with the byte-stream and will probably do a pretty lousy job on all but the simplest images. However it already does a

lousy job on all but simple images anyway, the range of good images just shrinks a lot when you go to 16 bits.

You can improve compression in the usual way, throwing away information. 12-bits is very often enough for image data.

You can shift 12-bit data up 4 bits, write it to TIFF and shift it down when you read it. You get 4 extra bits of information over 8 bit data and the file is compatible with full 16 bit applications. The extra zero bits should make lzw a little happier, since the shifted out bits tend toward high frequencies.

4. are there any real world applications that support 16 bit components now?

RenderMan has supported 16-bit channels in TIFF for years now.

4. Are there any sample images available for validation purposes?

A while ago I sent Sam a couple to help testing.

I could provide more if they're needed.

Your return address says triple-i.com, I believe you folks have RenderMan there.

To get 16-bit TIFF files, just use the following in a rib file:

Quantize "rgba" 65535 0 65535 0.5
 and
Display "filename" "tiff" "rgb"
 or
Display "filename" "tiff" "rgba"

If you need to play with details like compression or horizontal differencing let me know, I'd be glad to help.

Dan McCoy mccoy@pixar.com