AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
April 1994

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date


The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems

Valid HTML 4.01!


1994.04.07 14:05 "", by Christoph Wissing
1994.04.07 17:50 "6 Bit TIFF", by Niles Ritter
1994.04.08 09:48 "", by Karsten Spang

1994.04.07 17:50 "6 Bit TIFF", by Niles Ritter

Christoph Wissing <> writes,

>  I encountered a problem when reading some grayscale X-Ray-Images:
>  They use 6 Bit per Sample, and I`ve seen in your doc`s:
>      o Class G for grayscale images
>  	SamplesPerPixel = 1
>  	BitsPerSample = 4, 8
>  	Compression = 1 (none) 5 (LZW)
>  	PhotometricInterpretation = 0 (Min-is-White), 1 (Min-is-Black)

While 6-bit TIFF files are technically allowed, they are a bit perverse.
They are strictly ruled out for Baseline TIFF grayscale, which only
supports 4 an 8 bit pixels, and for the general case the Aldus
TIFF specfication manual, page 30, contains the following caveat:

  "If the number of bits per component is not a power of 2, and
  you are willing to give up some space for better performance,
  use the next higer power of 2. For example, if your data can
  be represented in 6 bits, set BitsPerSample to 8 instead of
  6, and then conver the range of values from [0,63] to [0,255].

In any case, you still have to pad the end of a 6-bit pixel row to
8-bit byte alignment anyway, so why not just pad each pixel out
to a byte? If space is an issue, using 8-bit pixels with LZW
will often give better (lossless) compression than just crunching
down the bits.

I realize this doesn't help you if you're dealing with a vast
archive that somebody has already created, with thousands of
this rogue TIFF files lying around, but the point is that the
program that created those files is being very non-standard,
and should probably be fixed, especially if these files are to
be used outside of the lab where they were created. And after
all, the TIFF format was designed to be a data *interchange*
format, meaning that it is supposed to be a little easier for
others to use the data than just having the raw pixels.

I suspect that the X-ray files were originally 6-bit packed raw
data, and to save time, the converter program just took the
data and put a TIFF wrapper around it. If this is the case 
there is the danger that the rows weren't aligned to 8-bit
boundaries, and so the file may actually be invalid,and not
just hostile. This might not be apparent if the files have only
been used internally, as the source code that packed this
data may be the same one that unpacked it in other applications.

Though I can't speak for Sam Leffler, I can't imagine that
installing support for non-power-of-2 pixels is very high
on his list of things-to-do, and I know he's got quite a list.
Anyway, good luck with those files.


Final note: I just hacked together a 6-bit tiff image and
passed it to Adobe Photoshop 2.5.1, and it returned an error message,
"Could not open "6bit.tiff" because the TIFF file uses an
unsupported bit depth". I also tried to open it with NIH Image 1.5
for the Macintosh, and it opened the file, but the bit values
were wrong; I suspect that it ignored the BitsPerSample and
just assumed it was 8-bit. So, the industry doesn't seem to
like 6-bit TIFF very much, either.