Re: [PNG] Upcoming meeting topics

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