2006.06.23 15:38 "Re: [Tiff] TIFF JBIG", by Charles Auer

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).

Joris Van Damme wrote:

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.

Actually we are talking about 2 different sets of planes here. I was referring to the number of bit planes required to code the series of samples for each strip/tile; that is the number of bits in each sample. I think you are referring to the number of sample planes, for example 3 for RGB, 4 for CMYK, etc.

Joris Van Damme wrote:

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.

Well, we do need a buffer as you describe. As we read or write each successive JBIG bit plane, we set or retrieve the appropriate bits in the buffer. There's not really any easy way around it; that's how bit plane coding works.

Charles