Re: [PNG] Upcoming meeting topics

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
>