Re: [PNG] Cancel upcoming meeting?

I know this is a late reply but the details of this has been worked out a while ago: https://github.com/libspng/png-restart-marker

Metadata is added either about the offsets of the IDAT chunks that begin with a restart marker and NONE/SUB filter byte,
or metadata can indicate that each IDAT chunk is encoded to begin with a restart marker and NONE/SUB filter byte.

Everything from backward compatibility to guarding against specially crafted PNG's should be covered by it.

Randy


On Friday, 28 February 2025 at 04:18, John Bowler <john.cunningham.bowler@gmail.com> wrote:

> > > a cracker can use it to defeat a decoder which uses the restart marker
> > 
> > I didn't understand this. Do you mean "There is a restart marker at bit index 200" but there isn't, so the parallel and serial decodes are different?
> 
> 
> No; zlib restart markers work just fine and work now, so far as I can remember. The restart markers allow a decoder to skip forward _by bytes_ (IRC) and find the next restart marker. This allows recovery from a damaged stream (again, IRC) but that isn't relevant in this context. Any PNG encoder can cause restart markers to be introduced into the IDAT (or fdAT) stream and, because they can be found without decoding the stream (just by skipping forward, which is fast) parallel decoding of the whole stream is possible.
> 
> Unfortunately the result is not an image in one of the canonical PNG formats. It's a _filtered_ image and the _filtered_ image cannot be decoded to recover the original data without either decoding all the previous image or having some information about where at least some rows start; if that information leads to a _filtered_ row starting with a NONE or SUB filter byte the image can be decoded ("completely decoded" was the term I used) from then on.
> 
> So to _completely decode_ a PNG in parallel requires more than a zlib restart marker; it requires information which locates a PNG filter byte of NONE or SUB (not the others) somewhere after the restart marker; that is the problem.
> 
> I'm very interested if you have a solution, just so long as you intend to publically disclose it without retaining any patent rights. It seems to me (having considered the problem on and off for around 20 years) that a solution is patentable.
> 
> John Bowler

Received on Thursday, 8 May 2025 14:40:53 UTC