Re: [PNG] Upcoming meeting topics

ACES AP0 cannot be represented in PNG, currently. So in a way, you are
right that there is no backwards compatibility to break.
However, the cHRM chunk does work in PNG currently. And redefining it to
allow ACES AP0 *would* break backwards compatibility with existing PNG
decoders that know cHRM.

If we could add ACES AP0 support without changing cHRM, things would be
fine. And CICP gives us an option to do that. We just need to add ACES AP0
to the CICP list.


The forwards compatibility story isn't perfectly clear to me. My take on it
is "the user can tell what it is but might not get the best experience".
For example, a PNG decoder which doesn't recognize cHRM could decode
assuming the color values are all sRGB. But the skipped cHRM chunk
likely indicates they aren't.
The colors will be wrong. But the user will still be able to tell it is a
picture of a red apple.
Your CICP example is similar to this, I think.

Going back to ACES AP0 + cHRM + forward compatibility: One of the primaries
being negative but read as a large positive value would mean purples and
blues wouldn't be reproduced, right? In fact, since AP0 includes all the
visible colors, the large y primary would force all of the colors to be
outside the visible color spectrum.
A red apple would no longer look like a red apple, I think.

On Thu, Nov 21, 2024 at 8:38 AM Leo Barnes <lbarnes@apple.com> wrote:

>
>
> On 21 Nov 2024, at 14:20, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
> 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.
>
>
> Not sure I understand this argument.
>
> Does ACES AP0 currently work correctly in PNG? If no, how is it breaking
> backwards compatibility?
> How is this any different than CICP? If I add CICP with a linear transfer
> curve to a PNG file, that file will look pretty weird with a parser that
> has not added CICP support.
>
> Cheers,
> //Leo
>
>
> 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> 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> 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>
> PO BOX 3151
> KERBY OR 97531-3151
> USA
>
>
>