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
December 1999

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



Valid HTML 4.01!



Thread

1999.12.07 09:06 "Re: ZIP/Deflate", by Ivo Penzar
1999.12.07 09:19 "Re: ZIP/Deflate (2)", by Ivo Penzar
1999.12.07 14:53 "Re Deflate - Patch for libtiff", by Ivo Penzar
1999.12.07 17:17 "Re Deflate - Patch for libtiff", by Michael L Welles
1999.12.07 15:07 "Re: ZIP/Deflate (2)", by Tom Kacvinsky
1999.12.07 17:33 "Re: ZIP/Deflate (2)", by Ivo Penzar
1999.12.08 07:15 "Re: ZIP/Deflate (2)", by Tom Lane

1999.12.08 07:15 "Re: ZIP/Deflate (2)", by Tom Lane

"Ivo Penzar" <ivo.penzar@infolink-software.com> writes:
> 1) Apparently, Corel's Draw and Photo Paint read and write WI images
> (Wavelet compressed format). Interestingly, WI images created by Draw or
> Photo Paint, WEB Photo Paint (claimed to be built on the same technology)
> refuses to open, explaining that these are corrupt WI files.

> As expected, this lossy compression provides much better results than JPEG.

I'll manfully resist the temptation to rise to that bait ;-).

> 2) Except for ImageMagick and similar open-source products, I didn't find a
> widely used commercial product (at least those ubiquitous by Corel and
> Adobe) to support JBIG format. What is actually the past, present and future
> of the JBIG format and what are its main characteristics? As far as I
> understand (I didn't look into the open-sourced libjbig code), JBIG is by
> definition restricted to bilevel images, and uses some sort of arithmetic
> coding compression (as patented by IBM).

JBIG is a bilevel method in essence, but it has never been restricted to
purely bilevel images: the spec explains how to apply it to images of
any depth you like by JBIG-ing each bitplane independently.  (Actually,
the spec recommends converting the samples to Gray coding before
applying the bitplane trick, in order to reduce the frequency of
transitions in the higher bitplanes.  See any standard
information-theory textbook if you've never heard of Gray codes.)
It's not that great a method for deep images, but up to five or so
bits per sample it works very well.

The only reason you don't see JBIG in every nook and cranny today is
that they defined it to use a patented variant of arithmetic coding ---
in fact, the very same variant that's used by arithmetic-coded JPEG,
which is also extinct in the wild.  Unfortunately JBIG didn't have a
patent-free variant to fall back on, so it never went anywhere.

You'd think the standards committees would have learned something from
the spectacular failures of JBIG and A/C JPEG ... to wit, patented
specs won't fly ... but I'm not sure the lesson has been absorbed fully.

			regards, tom lane
			organizer, Independent JPEG Group