A-HA! (No, not the band.) Got it! Each scanline is being presented in its own deflate block. So you have to add 4 bytes (LEN and NLEN) to each one. It becomes 3 (for flags) + (width+5)*height + 4 (for adler) => (width+5)*height + 7. Again, that does not include the IDAT label, size and CRC, which represent a further 12 bytes (right?).

Your comment on the scanline separator was what got me the solution.

I think I missed a couple of bytes somewhere, but I'm not sure.

PNG Specification: Deflate/Inflate Compression
RFC 1950 (rfc1950) - ZLIB Compressed Data Format Specification version 3.3
RFC 1951 (rfc1951) - DEFLATE Compressed Data Format Specification version

Cool, now I can sleep tonight.

Cheers!

If the above is correct (not having reviewed your references in depth) then neither GIMP's nor pngout's uncompressed PNG format is "correct". The IDAT chunks have wrong sizes.

test case:
width:144
height: 43

Shold be: (width+1+2+2)*height+4+3+4+4 = 6422
GIMP uncompressed IDAT: 6246
PngOut uncompressed IDAT: 6456

Let me stop you right there. Correctness is defined by whether it can be correctly read by a compliant parser. Like, there are several different ways for me to say this to you, and none of them are more "correct" than the others (although the correct ones probably don't start with "like").

Specifically, you can split the data in deflate blocks wherever you want, as long as they're all within the 32k boundary. PNGOut is splitting them at each scanline -- probably due to lazyness more than anything else, since he thought nobody would use the uncompressed format. GIMP is splitting it in a different way. But they are both "correct". So there.

So long, and until the next mistery...!

Cheers!

PS: Thanks for the puzzle. Please do post other questions like yours, it's very interesting stuff.

i totally agree. I had hoped that the quotes around correct in my last post indicated that I'm aware that the correctness of any format relies on the interpreters in question.



Will do. Thanks for the feedback