1994.04.07 14:05 "", by Christoph Wissing

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

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.

  --Niles.

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.