[Zlib-devel] Re: FYI: lossy compression

[Ed Avis]

On Wed, 4 Sep 2002 Zlib-devel-request at zlib.org wrote:

>My main question is not answered by your page
>http://membled.com/work/apps/lossy_png/ :
>
>  Comparison with JPEG
>  I don't know how well this approach compares with JPEG lossy compression.
>
>That would have been the first thing to do! JPEG was designed for lossy
>compression, zlib was not.

On the other hand: JPEG works well for photographic images but not so
well for cartoons or screenshots.  It blurs text and leaves rings
round solid objects.  PNG is good for these images and I want to get
sharply defined text while throwing away enough information to save
disk space.

>I took me less than one minute to do the experiment on your file
>dartmoor01.png. The JPEG version at quality level 75% has a size of
>11512 bytes, about half your "lossy PNG" version dartmoor01.1000.png
>and of comparable image quality.

The Dartmoor photograph is something I picked to experiment on, but
the other example, the Dilbert cartoon, is closer to what I aim to
compress.  It has four colours (not a continous grey scale) and a
'mottled' background.  I would like to tune the matching so that the
background can be altered a lot, while the foreground features stay
more or less unchanged.  As you can see from the web page, I haven't
succeeded in that so far.

The current implementation is rather crude and as mentioned on the web
page there are many enhancements which I hope would give better image
quality for the same space.  In particular, a combination of colour
reduction with lossy compression.

If you said that this was vapourware then you'd be right.  I put up
the web page slightly sooner than planned to generate interest after
there was that JPEG patent scare.  If JPEG did become unusable (which
now seems unlikely) then lossy-PNG would have the advantage over other
formats of not needing any new decompression software.

FWIW, I think that an image containing a mixture of text and
photographic data might be a good demonstration of the current code
against JPEG.  For example a screenshot with a photograph as
background.  I will have a look and see how well these compress.

>>In the long term I would like some way to plug in a lossy matcher to
>>zlib
>
>But that would no longer conform to RFC1951!

The zlib output would still conform to the RFC.  Imagine a mail
server which discards spam automatically (and sends no
notification back to the spammer).  It would not conform to the RFCs,
but would still be a useful piece of software.

Anyway, I thought that zlib, gzip and Info-ZIP defined the RFCs, not
the other way around :-).

>zlib is _by definition_ a lossless compressor.

Suppose I rephrase it in these terms: add a new API whereby zlib sends
status messages back to the application, saying 'I'm about to compress
this bit of data', and the application has the opportunity to modify
the data to get better compression.

It would always be the application which decides what changes to make
to the data being compressed, not zlib.  That is the reason to have a
callback.

>Your idea was interesting but I'm afraid I'm not convinced.

If you're not convinced that it is useful (rather than a bizarre
toy) then on the current evidence I would have to agree.  However, one
of the libmng developers reports good results using the modified zlib
to compress animations.  I'll see if I can get him to produce a web
page with his results.

If you're not convinced that the additional interface to zlib is worth
the complication... hmm.  I think it would be just one additional
function set_matcher() which normal users could just ignore.

-- 
Ed Avis <ed at membled.com>