Re: [EXTERNAL] Re: [PNG] Cancel upcoming meeting?

BT.2408 has contextual information that is relevant to the ISO document. The ISO document definitively establishes the dWLm element (not with the same name).

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Chris Blume (ProgramMax) <programmax@gmail.com>
Sent: Thursday, February 27, 2025 9:47:43 PM
To: jbowler@acm.org <jbowler@acm.org>
Cc: Fares Alhassen <falhassen@google.com>; public-png@w3.org <public-png@w3.org>
Subject: [EXTERNAL] Re: [PNG] Cancel upcoming meeting?

What’s the loopback to BT.2408 for?
In the dWLm GitHub issue<https://urldefense.com/v3/__https://github.com/w3c/png/issues/390__;!!PIZeeW5wscynRQ!vn_6GGcdqgtcWow7jRPadCqEjWp4yOEgKwW7ZYb3SD_QGffgU3vTkFe5zhyZA1M_j-zuIRIreGVdPtMhl539$>, Pierre-Anthony asked if there is similarity between BT.2408 and ISO 22028-5, I think.
This sounds like something we discussed in a meeting but forgot to update the GitHub issue with.


(just by skipping forward, which is fast)
Oh, yeah. That makes sense. I hadn't thought about that. Other threads can scan forward.

 It's a _filtered_ image... NONE or SUB filter byte
Right.
§ 9.1 Filter methods and filter types<https://urldefense.com/v3/__https://w3c.github.io/png/*9FtIntro__;Iw!!PIZeeW5wscynRQ!vn_6GGcdqgtcWow7jRPadCqEjWp4yOEgKwW7ZYb3SD_QGffgU3vTkFe5zhyZA1M_j-zuIRIreGVdPiswATFs$> says that
1.) Interlaced images must share one filter, and
2.) Non-interlaced images can have a different filter for each scanline.
You're right that any filter which references previous scanlines won't work.

My understanding is a new chunk can indicate exactly where in the deflate stream the NONE/SUB scanlines with a restart marker start.
This can also mean an encoder intentionally forcing NONE/SUB scanlines to sacrifice a bit of compression efficiency for parallelism.
This means there can be restart markers which are not eligible and not included in the new chunk. Only the ones that intentionally work alongside the filter would be listed.

without retaining any patent rights
Definitely. My personal intention is to make things open and free. There is already public discussion on this, which would invalidate a patent anyway.


On Thu, Feb 27, 2025 at 9:18 PM John Bowler <john.cunningham.bowler@gmail.com<mailto: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