- From: John Bowler <john.cunningham.bowler@gmail.com>
- Date: Wed, 20 Nov 2024 17:33:47 -0800
- To: "Portable Network Graphics (PNG) Working Group" <public-png@w3.org>
Received on Thursday, 21 November 2024 01:34:02 UTC
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
Received on Thursday, 21 November 2024 01:34:02 UTC