Re: [PNG] Upcoming meeting topics

I agree with Chris – as proposed, this is a breaking change and not one I think we want to persue.

Why not just put the ACES stuff in a chunk of its own?

Leonard

From: Chris Blume (ProgramMax) <programmax@gmail.com>
Date: Wednesday, November 20, 2024 at 8:56 PM
To: jbowler@acm.org <jbowler@acm.org>
Cc: Portable Network Graphics (PNG) Working Group <public-png@w3.org>
Subject: Re: [PNG] Upcoming meeting topics

EXTERNAL: Use caution when clicking on links or opening attachments.


Thinking about this more, any existing PNG decoder which understands cHRM as unsigned will see a huge number for ACES AP0.
Effectively, the change only works if an ACES AP0 image is never loaded into an older PNG decoder. But that's sorta the definition of breaking backwards compatibility.
We could make the change if ACES AP0 is never actually used. But then there is no benefit to making the change.

Still very worth a discussion. But the Working Group charter requires that we do not break existing PNG editors/viewers. So this might be a difficult change to sell.

On Wed, Nov 20, 2024 at 8:56 PM Chris Blume (ProgramMax) <programmax@gmail.com<mailto:programmax@gmail.com>> wrote:

I'll add it to the discussion.
It could *theoretically* break existing PNGs.
No visible color space needs all those bits, right? But maybe some NASA space image does.

That said, I like the idea.
ACES AP0 is not a display color space. It is more for processing. But it would be nice to be able to save mid-process work with the correct color space.

I can also try to request an update to CICP which includes ACES AP0. I am not part of that group so I'll need to make introductions.

On Wed, Nov 20, 2024, 8:34 PM John Bowler <john.cunningham.bowler@gmail.com<mailto:john.cunningham.bowler@gmail.com>> wrote:
I would also like to see some discussion of the issue raised by the now well established ACES AP0 profile.  It is described here: https://acescentral.com/knowledge-base-2/aces-working-spaces.  Because one of the AP0 end-points has a negative y the colour space can't be represented in cHRM.  There is also no support in cICP (fixing this raises a boatload of issues.)

The specification of the cHRM chunk is, currently, that it only allows unsigned values for the 4 chromaticities however the encoding supports signed values as well (the encoding is a 32 bit encoding, unsigned values only use 31 bits).  As I've said simply extending the definition to allow signed values; changing the word "unsigned" to "signed" at the relevant place in the cHRM specification, does not invalidate any existing PNG cHRM chunks and, while initially only applicable to ACES and other, similar, workflows is easy to accommodate in all PNG implementations that I've seen (perhaps some already do through lack of checking!)

John Bowler <jbowler@acm.org<mailto:jbowler@acm.org>>
PO BOX 3151
KERBY OR 97531-3151
USA