PNG-spec
PNG-spec copied to clipboard
w3c
Testing `cICP`
This can be tested in WPT by converting full-range sRGB values to one of the common encodings (such as 2100 PQ, 2100 HLG, Display P3, linear sRGB) and making a PNG with those values and the appropriate cICP chunk. A pass displays the same colors as an sRGB reference image.
For non-browser support, detecting and correctly decoding the chunk demonstrates support.
TweakPNG may add support for cICP:
- https://github.com/jsummers/tweakpng/issues/11#issuecomment-1537449629
Chromium has cICP support for PNG (and also supports CICP in AVIF):
What you described is nearly exactly what is already being tested here: https://wpt.fyi/results/png/cicp-chunk.html?label=master&label=experimental&aligned
There is a cICP chunk which marks the image as Display P3.
The image is painted into a canvas and its color value read and compared to what it would be when converted to sRGB.
Does that mean we can close this?
We could, although I would prefer to see more than one test; and I want to track non-browser implementations like TweakPNG too. So I prefer to keep it open.
FWIW, darktable implemented support* for cICP chunk some time ago (though only a subset of possible color spaces are actually built in and recognized by the input color profile "colorin" pipeline module).
* for import only, export uses iCCP
Thanks for the heads-up! Yes I see it in the darktable 4.2.0 announcement:
Attempt to obtain the color-space for PNG files from the cICP chunk. This was added in a recent revision of the PNG spec, so we take advantage of it, if present.
At the 8 Jan 2024 PNG WG meeting it was concluded that cICP has now met the W3C minimum support criteria (two independent implementations) so removing that tag.
Leaving the issue open to collect latest implementation status, for the implementation report.
I have a PR for a test that combines APNG and cICP to check that all frames inherit the colorspace information, not just the static image.
https://github.com/web-platform-tests/wpt/pull/43980
I have a PR for a test that combines APNG and cICP to check that all frames inherit the colorspace information, not just the static image.
PR is now merged, as hoped Chrome (and Edge) pass while Firefox and Safari do not
From the documentation for oxipng, an optimizer written in rust:
--strip
<mode>Strip metadata chunks, where<mode>is one of:safe => Strip all non-critical chunks, except for the following: cICP, iCCP, sRGB, pHYs, acTL, fcTL, fdAT all => Strip all non-critical chunks <list> => Strip chunks in the comma-separated list, e.g. 'bKGD,cHRM'
So clearly, it supports cICP and knows that stripping it will affect the rendered image.
CSS Color 4, in the section Color Space of Tagged Images, now includes the test results for the PNG cICP tests.
I added a WPT PR to test that
cICPwins overiCCP
This is now merged. Chrome 123 on Linux 20, and Edge 123 on Win 10 both pass. Safari TP 188 on macOS 13.6 is reported as failing, because it needs macOS 14 for CICP support. Firefox 125 on Linux 20 fails because they don't implement cICP yet, see bug
libavif has an open issue
@svgeesus Chris: The libavif issue https://github.com/AOMediaCodec/libavif/issues/1421 that you mentioned in https://github.com/w3c/PNG-spec/issues/312#issuecomment-1979051651 covers conversion of AVIF to both PNG and JPEG. The PNG part of that libavif issue is already fixed. So for PNG that issue should be considered closed.
So should PixelMator/Photomator. They enabled the MacOS API support in one day after requesting it :-)
Get Outlook for iOShttps://aka.ms/o0ukef
From: Chris Lilley @.>
Sent: Wednesday, March 27, 2024 1:12:55 AM
To: w3c/PNG-spec @.>
Cc: Subscribed @.***>
Subject: [EXTERNAL] Re: [w3c/PNG-spec] Testing cICP (Issue #312)
Affinity 2.4 supports cICP in PNGhttps://urldefense.com/v3/__https://forum.affinity.serif.com/index.php?*topic*196692-32-bit-hdr-png-support-added*__;Ly8v!!PIZeeW5wscynRQ!otyqRX3QaRGte8sihzbhxkuJW6BicTwlua1KKGSD8H-u4q9pj5bILl1NkGLKGTJKuXdPObVo2yyOiGCkVmPi7qNkPg$ including narrow and full range.
— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/w3c/PNG-spec/issues/312*issuecomment-2021948597__;Iw!!PIZeeW5wscynRQ!otyqRX3QaRGte8sihzbhxkuJW6BicTwlua1KKGSD8H-u4q9pj5bILl1NkGLKGTJKuXdPObVo2yyOiGCkVmPGoYt4tQ$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AANIO6BVD76ONAZJT3M7ZKLY2JINPAVCNFSM6AAAAAAX2K2NIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRRHE2DQNJZG4__;!!PIZeeW5wscynRQ!otyqRX3QaRGte8sihzbhxkuJW6BicTwlua1KKGSD8H-u4q9pj5bILl1NkGLKGTJKuXdPObVo2yyOiGCkVmP9el5hSQ$. You are receiving this because you are subscribed to this thread.Message ID: @.***>
I tested the Video Full Range Flag in both Chrome and Safari. Neither one seems to respect it: pixel values were the same regardless of whether it was set to zero or one
(Firefox was the same... but that's expected since it doesn't have cICP support yet.)
I see several Chrome CICP bugs one of which relates to Full-Range AVIF. Probably best to open a separate issue for PNG Full/Narrow range CICP.
That’s been true of most applications (even for video wrapped movies).
This feels like a tricky one. For typical computer use cases today, all images will be full range. In fact, I think even an (non-broadcast) expert would need to work very hard to find even 1 real world narrow range image. As a result, I can understand not wanting to spend engineering time solving a non-problem. Chrome considered it explicitly and closed as won't-fix because there was no interest.
However, that then forces the question "Then should it be part of the spec?"
For legacy broadcast, it does seem important. That's why it is part of H.273 in the first place. For broadcast experts, I could see PNG test images that use this flag being very useful. Any software along the pipeline which reads CICP data will want it.
To me, the tradeoff is "Almost all users don't need this, so we should drop it..." vs. "...but then we're not using real CICP / H.273."
Perhaps we could still reference H.273 for all CICP values and just drop that field. (To that end, perhaps we can also drop the one that says the color model is RGB, since we likely will always have a standard RGB PNG available even if we later add extra channels.) But I feel like the cost of 2 bytes which are unenforced is worth it to keep H.273 in tact. What if later H.273 changes from 4 bytes to 2 bit version flag, 6bits, 12bits, 4 bits, 8 bits? We'll have wished we kept all 32 bits.
So maybe the key is for us to make it a note and reference H.273 but to not require strict enforcement on the values?
The difference between a cICP chunk taking 16 bytes versus 14 bytes (once counting the chunk header and CRC) doesn't really seem like enough justification to diverge from the base specification.
I'd say that the spec should only require that decoders support full-range images, given that that's what major implementations are planning on doing. Leaving the text as-is would likely create pointless engineering work for implementers who don't realize quite how rare narrow-range images are. Though I'm not quite sure how to word it in the spec so that web browsers which ignore the flag as well as legacy broadcast folks' software can both be considered conformant.
If we say that narrow-range images are poorly supported and should not be created, we effectively require creation/conversion tools to convert narrow-range images to full range, which is lossy due to quantization error.
The definition of reference image is a full-range image (although it does not explicitly use that term, and probably should): it clearly maps 0, not 16, to black for example.