Incorrect offset for the next block (DEFLATE/PNG)?

Question

EDIT: This refers to the actual datastream block within IDAT (and the only IDAT chunk at that). I successfully navigate through the relevant critical chunks, from IHDR to IEND -- the problem is in the navigation between actual blocks.

So, I'm working on a little pet project out of curiosity, writing a PNG loader and experimenting first with uncompressed files to actually get the gist of it. For compression type 00 (no compression), it should be the size of 2^16 - 1, 65535 or less if the final block is in question.

So, I load the first block properly and try to add an offset of the last block's length, (which is variable, 65535 or less if last). So, I'd expect that the offset to the 65535th should land right on the next block's first byte, since the last one was read from 0 to non-inclusive 65535 or 65534th byte being the last byte of the first block. But for some strange reason, my uncompressed PNG file (output with Photoshop) reads bogus data on what should be the second block pass (it marks it as compressed and final with dynamic huffman codes, and therefore the variant of LZ77 compression algorithm, on a different image it outputs 77 for compression type etc., at the 100k byte mark from a 1MB file).

So, I must be landing on the wrong byte, perhaps? It should be really trivial, but I can't see where I'm failing, here's the relevant bit:

unsigned int accumulatedOffset = 0;
CBlock cblock; // initializes length to 0

do {

    accumulatedOffset += cblock.length; // Adds 65535 on second pass

    // Extract block header
    unsigned char bheader = IDATChunk[Description::BlockHeaderOffset + accumulatedOffset];

    // The second pass reads from the wrong byte, it seems.

} while(...)

Am I missing something in between for the second pass?

Answer 1

Ah, thank you for the edit. So you are talking about deflate blocks.

If you have all stored deflate blocks, the format will be:

00 rs pq ~rs ~pq [ pqrs bytes ] ... same thing repeated ... 01 rs pq ~rs ~pq [ pqrs bytes ]

where ~ means the inverse, or one's complement.

Note that this will follow a zlib header and be followed by a zlib trailer. See RFC 1950.