AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2001.03.28 14:50 "Bit depth", by Andrew Jarvis
2001.03.28 16:32 "Re: Bit depth", by Joe Dumoulin
2001.03.29 08:02 "Re: Bit depth", by Andrew Jarvis
2001.03.29 11:03 "Re: Bit depth", by Martí Maria
2001.03.29 11:14 "Re: Bit depth", by Andrew Jarvis
2001.03.29 11:44 "Re: Bit depth", by Martí Maria
2001.03.29 16:57 "Re: Bit depth", by Chris 'Xenon' Hanson
2001.03.29 18:23 "Re: Bit depth", by Andreas R. Kleinert
2001.03.29 18:10 "Re: Bit depth", by Martí Maria
2001.03.29 17:02 "Re[2]: Bit depth", by Rainer Wiesenfarth
2001.03.28 18:07 "Re: Bit depth", by Frank Warmerdam
2001.03.28 18:52 "RE: Bit depth", by Max Martinez

2001.03.29 18:10 "Re: Bit depth", by Martí Maria

Hi,

One also could do:

    in8   = 2047;
    out16 = (in8 << 5) | (in8 >> 6);

This is equal to 2047*32 + 2047/64 and gives 65535 as well.

Yes, this is an valid approximation, since (32+1/64) = 32.015625 and 65535/2047 = 32.01514411. Also the only way to get reasonably speed ;)

If I'm not mistaken, 12 bit TIFFs are really valid (don't remember, whether they did contain triplets of byte nibbles or 16 bit values with only 12 bits used).

I have seen some of these, as separate planes. But decoding them is a mess since are packed together as bitstreams. 16 bits are fine for most purposes, and if any entropy compression is used (LZW or Deflate) the space savings are even bigger.

But why not just convert the 10/12 bit values and store them as real 16/24 bit ones. Most readers won't be able to handle anything except 1,4,8,15/16,24.

Probably the best choice. Most doesn't understant nothing but 1, 8, 24

Regards,

Martí.