LibTiff Mailing List

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

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.

> 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


AWARE [SYSTEMS]		Imaging expertise for the Delphi developer
		TIFF and LibTiff Mailing List Archive
	LibTiff Mailing List TIFF and LibTiff Mailing List Archive June 2006 Previous Thread Next Thread Previous by Thread Next by Thread Previous by Date Next by Date Contact The TIFF Mailing List Homepage This list is run by Frank Warmerdam Archive maintained by AWare Systems	Thread 2006.06.23 04:45 "TIFF JBIG", by Charles Auer 2006.06.23 09:52 "Re: TIFF JBIG", by Joris Van Damme 2006.06.23 15:38 "Re: TIFF JBIG", by Charles Auer 2006.06.23 15:38 "Re: 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). > > 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. > 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

LibTiff Mailing List

Thread

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