Re: [png-mng-implement] How to process IDAT chunk in passes

[John B. <jb...@ac...>]

From: J_C [mailto:ja...@or...] 
>As per my understanding libpng requires whole IDAT to be in memory (read
>from file) at once, before calling inflate to decompress for each row. Is
it
>correct? 

I don't think it does, because in the past PhotoShop has produced massive
PNG files with just one IDAT.  The issue does arise because most of the time
libpng reads a complete chunk, checks the crc then, if the crc is correct,
processes the chunk.  For IDAT unchecked data gets passed to zlib (IRC) and
the crc only gets checked at the end.

>If so, is there any way we can pass partial IDAT in passes to inflate? 

It's certainly possible to change libpng to do this if it doesn't already.

>for example, I found IDAT chunk, i read 200 bytes, call inflate, if require
>i can again read next 200 bytes and call inflate again. likewise.

I think that's what libpng does at present, but I'm not absolutely sure.

>In png file, each zlib block represents scanline ? 

No, neither the IDAT chunks nor the blocks of zlib data are aligned in any
way with the scanline.  Further the zlib blocks forced out by passing a
non-zero value of 'flush' to the deflate API aren't aligned to either byte
boundaries or the boundaries of IDAT chunks.

>Is there a method or way to identify length of each zlib block for png
file?

I assume you do mean the zlib blocks, not the IDAT chunks, because the
length of each IDAT is recorded in 4 bytes at the head of the chunk.  For
the zlib blocks it would be necessary to parse the zlib bit stream that the
IDAT contains.  The result would not be very useful - all you would know (I
think) is that you could get a complete set of the original PNG image data
up to a given byte in the image by passing in a certain number of bits (not
bytes) from the IDAT chunk.

If you have control over the PNG production you can do a lot more.  It is
possible to sync the zlib data and the IDAT to scanlines (for example) so
that each scanline can be read independently.  I do not believe libpng
supports this and relying on this feature in a decoder would make the
decoder non-conformant to the PNG spec.  (I.e. such a decoder would *not* be
a PNG decoder.)

John Bowler <jb...@ac...>