Re: [PNG] Cancel upcoming meeting?

I think the hesitation is we wanted to have data to show when it is
good/bad, and by how much.

For example, very wide images will have more data per row. That leaves
fewer places for the new filter & restart marker. And it might mean forcing
none/sub filters has a bigger impact on file size. OR maybe the bigger rows
means the filter was more likely to be none anyway.

And then what about for small / tall / normal images?
And for data, how much speed can we gain for how much file size sacrifice?
Is the speed gain because most of the time is spent in the inflate step? If
we optimize the inflate, does that reduce the reward?

On Thu, May 8, 2025 at 10:39 AM Randy <randy408@protonmail.com> wrote:

> 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
>