Re: [PNG] Cancel upcoming meeting?

>
> 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 Friday, 28 February 2025 02:18:51 UTC