TIFF and LibTiff Mail List Archive


2006.06.23 04:45 "[Tiff] TIFF JBIG", by Charles Auer
2006.06.23 09:52 "Re: [Tiff] TIFF JBIG", by Joris Van Damme
2006.06.23 15:38 "Re: [Tiff] TIFF JBIG", by Charles Auer

2006.06.23 09:52 "Re: [Tiff] TIFF JBIG", by Joris Van Damme


Of course, the problem with stand-alone, multi-plane JBIG files has always been that there is no standardized way to encode information such as the meaning of the various bit planes, causing the compression of color images to be plagued with ambiguity. However, this ambiguity disappears when we incorporate JBIG into TIFF, thanks to basic tags such as photometric interpretation, bits per sample, and samples per pixel. In a manner of speaking, multi-plane JBIG compression finds a happy home inside TIFF files.

One might envision a scheme where every strip or tile of a grayscale or color image is a n-plane JBIG image, where n is the number of bits per pixel (PLANARCONFIG_CONTIG) or n is the number of bits per sample (PLANARCONFIG_SEPARATE).

I'm not sure I follow you on that last part. In planarconfig separate images, the number of planes equals the number of samples, not the number of bits in a single sample. Otherwise, we have a compression-dependent non-standard interpretation.

On the other hand, I feel it is important (even if not strictly required) that things can 'flow' in and out of compressors and decompressors. If we need n different subsequent blocks in a strip/tile, where n equals the number of bits in the sample or pixel, then the compressor/decompressor needs a buffer size of the uncompressed strip/tile, and needs to fully traverse that buffer n or n-1 times. I think that is clumsy and non-scalable, at best, and I much prefer requiring compression of individual strips/tiles to 'stream through'.

Things similar to the trick with the 'Indexed' tag come to my mind, and/or adding a new photometric PHOTOMETRIC_BITPLANES... But all such options have serious drawbacks.

Does anyone know if Photoshop CS2 writes these multi-bit JBIG things? If so, it may be worth looking at. If not, we ought to be very interested on how Chris Cox feels about this.

> rewritten tif_ojpeg.c file... I did think

that the warning handler message was a little wordy.

Feel free to suggest something. Note that we do need to properly use any opportunity to get the message through, though. Adobe hosts the spec supplements together with the original spec, but those are forever marked 'draft' and there is no indication of update in the TIFF 6.0 spec PDF itself. Also, people often link directly to the TIFF 6.0 PDF instead of the Adobe page with the supplements, and/or host a copy of the TIFF 6.0 PDF themselves. It is thus not surprising some vendors don't get the message, and we need shout hard about it.

Joris Van Damme
Download your free TIFF tag viewer for windows here: