Re: [libpng:feature-requests] #32 Modern compressor

It's also debatable whether anything does significantly better than LZW.

In fact LZ77/deflate is very fast and very memory efficient on
decompression; it just needs the window allocated in memory, the overhead
for the tables is actually fixed and small.  This isn't as good as LZW/GIF,
which only needs a 4096 entry table for either compression or
decompression, but that assumes a 12-bit encoding; 16 bits requires a 65536
entry table and the entries are somewhat larger.

The main problem with PNG compression is failure to identify the code set;
LZ77 compresses bytes, LZW compresses an arbitrary sized code which is in
practice limited to 8 or so bits, but the codes in PNG data are between
1-bit and 64-bits in size.

Adoption of a new PNG format would not happen any faster than adoption of
JPEG2000 and probably a lot slower (like, "never").  It would require a lot
better justification than compression speed.

One obvious improvement is better encoding of higher dynamic range data; at
present really expensive digital cameras just exceed the range of 24-bit
RGB (Sony A7S; the 12MP version which has lower noise) and the output
devices in development exceed 24-bit RGB by a long way.

There's a need to carry around data without additional lossy compression
before the final compression happens and this can be done with 64-bit PNG
(16-bit gamma encodinged R/G/B channels) however 64-bit RGB compresses
really badly with LZ77.  However it doesn't make sense just to change the
compression; the problem is that the 64-bit gamma encoding more than
doubles the size of the original data!

There are other significant problems with PNG in many uses.  One of these
is the inability to extract the data in tiles; it always comes out in rows
(at best).  A tile format is better and takes advantage of the 2-D locality
that happens in image brightness; a single tile will normally have a much
lower brightness range than the complete image.

>From the performance point of view the lack of support for 16-bit floating
point is an obvious issue, however realistically 16-bit FP has all the same
problems as 16-bit gamma (they can both represent about the same dynamic
range with sufficient accuracy) and 16-bit FP support can easily
(trivially) be implemented for PNG.

Apart from 16-bit FP at the end of the day I don't think the result would
actually be called "PNG"; however apparently minor the change it is a new
file format and it will have different applications.

John Bowler
​

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc