Add iCCN support

[ProgramMax]

A description for the new iCCN chunk needs to be added, similar to the new cICP chunk [1]. It should be basically the same as the existing iCCP chunk [2], except that profile names are UTF-8 and it should explicitly be ICC profiles v4.

This contributes to a parent meta-issue #23

[1] https://w3c.github.io/PNG-spec/#11cICP
[2] https://w3c.github.io/PNG-spec/#11iCCP

[svgeesus]

Note that iCCP has already been corrected to allow ICC profiles (2,4 and 5):

the image samples conform to the colour space represented by the embedded ICC profile as defined by the International Color Consortium [ICC][ISO 15076-1] or [ICC-2][ISO 20677-1].

[svgeesus]

Maybe we should have some discussion on whether the iCCN chunk should still be added.

To my mind, the main value of iCCN when proposed, was that it allows ICC beyond v.2 while iCCP in the PNG second edition spec was limited to the (then current) v2. But in practice, implementations allowed any version ICC profile in iCCP; the defect had already been reported as an erratum and in the current 3rd edition editors draft, iCCP allows ICC profiles (2,4 and 5).

The secondary advantage of iCCN is that UTF-8 rather than 8859-1 is the encoding for the Profile name. For a new chunk, UTF-8 is the obviously correct choice. However, I don't see much utility in a name, here; PNG is limited to a single ICC profile and thus, it is not as if the user could be presented with a choice of which profile to use (where these names would make sense).

The downside of iCCN is that it is a new chunk whose functionality (apart from profile name) is now identical to the already-established iCCP. We would need to push for implementations to start generating iCCN and for viewers, in particular browsers, to start using it. And implementations would continue to need to support iCCP.

So I am calling for discussion on whether we should, after all, still add iCCN.

[svgeesus]

@lrosenthol @digitaltvguy thoughts?

[ProgramMax]

I haven't thought enough about the ramifications of the standard updating an existing chunk's meaning. In principle, I like the idea since many viewers already do this. But it could mean we're breaking an existing viewer. A separate chunk allows us to maintain backward compatibility.

This same thought applies to using an unversioned reference to ITU-T H.273 for the cICP chunk. A viewer could be completely correct and then H.273 receives an update which invalidates the viewer.

A part of me thinks this is fine. But I'm not sure.
Maybe someone could say "PNG 3rd edition, referencing H.273 v1". It's a mouthful though. I suspect that won't catch on. Further, what if we start referencing more unversioned specs? This could compound.

The benefit to referencing unversioned specs is being forward compatible.
Maybe we should reference an unversioned ICC Profile spec?

[palemieux]

See discussion at w3c/ColorWeb-CG#18

[lrosenthol]

I would think that with the change to the language on iCCP to support v4 (and possibly even v5) profiles, the need for iCCN goes away. In the same vein, I would bet that most implementations treat the name as UTF-8 anyway and not exactly 8859-1 - but we COULD make it explicit in the same way we did it for PDF, which is to require that a UTF-8 BOM (https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8) proceed such values. That would therefore maintain backwards compatibility and provide UTF-8 into the future - worse case is an older processor would display something strange for UTF-8.

[palemieux]

Requirements put together by the Color CG:

https://github.com/w3c/ColorWeb-CG/blob/master/hdr-in-png-requirements.md

[palemieux]

Meeting notes relevant to the discussion:

https://docs.google.com/document/d/1-YhccaT2MxSZahRYv4rDB79GVMyghrdtU8S-Y6OyGi4/edit

[palemieux]

The Color CG had discussed this topic at length and concluded that two distinct chunks were needed: iCCP and iCCN. I do not think we should remove the iCCN chunk without providing evidence that the conclusion was incorrect.

[ProgramMax]

Slight derailment but worth resolving:

1.) Are we happy with the name iCCN? Is there a better name? I think we were using it as a placeholder (where the "N" means "next").
2.) Should we consider iccMAX? It looks like it addresses some issues with ICC v4.

For 2, we're really adding the iCCN chunk as a response to major PNG viewers which already treat the iCCP chunk as v4, right? I could imagine us adding a third chunk for iccMAX in the future.

My opinion on 2 is we'll cross that bridge when we get there. W3C prefers that we only add things that people want. The demand should come first. (IE don't speculate about what people want.)
Also, it looks like there might be a way to embed iccMAX profiles in ICC v4 profiles.

[svgeesus]

For 2, we're really adding the iCCN chunk as a response to major PNG viewers which already treat the iCCP chunk as v4, right? I could imagine us adding a third chunk for iccMAX in the future.

If major PNG viewers already treat the iCCP chunk as v4, which they do, and which the spec already allows because of a long-standing errata item, then I can't see any utility in telling them "STOP! Put it in this new unsupported chunk instead, thus breaking a decade or two of interop"

Should we consider iccMAX? It looks like it addresses some issues with ICC v4.

The erratum already added support for ICC.2 (iccMAX) but in fact, given zero support for that (that I could find) in image viewers, it might make sense to pave the cowpaths by saying that:

• iCCP is for ICC.1 v2 and v4, which is existing practice
• iCCN is for ICC.2 (iccMAX) in which case maybe rename it to iCCM with the M for MAX?

This would also allow a PNG image to embed an iccMAX profile, and also embed an ICC.1 profile as a better-supported fallback

[svgeesus]

I do not think we should remove the iCCN chunk without providing evidence that the conclusion was incorrect.

The conclusion assumes that ICC v4 profiles are not supported in iCCP and thus iCCN is needed to do that. This conclusion is demonstrably incorrect.

I made some tests of the iCCP chunk. The test files and a readme with explanation of how the tests were created are on GitHub and I also put the test files and an html document to let you run all the tests in a browser, here.

All tests consist of two overlaid images, the upper one is sRGB and has holes to let the lower (test) image show through, and a pass is when you can't see the holes because they are the same color, thus proving the ICC profile was applied. See the readme for further information

I tested four browsers:

• Firefox Nightly 100.0a1 (2022-03-29) (64-bit) on Windows 10 gfx.color_management.mode was set to 1 (full color management)
• Chrome Canary Version 102.0.4999.0 (Official Build) canary (64-bit) on Windows 10
• Microsoft Edge Version 100.0.1185.39 (Official build) (64-bit) on Windows 10
• Safari Technology Preview release 143 (Safari 15.4, WebKit 17614.1.7.7) on OS X Monterrey 12.2.1

All browsers passed all tests, which means that all current browsers accept and apply both ICC.1 v2 and ICC.1 v4 profiles in the iCCP chunk.

[ProgramMax]

I think I agree with iCCP being ICC.1 (v2 and v4) and iCCM being ICC.2.

I won't have this ready in time for our meeting tomorrow, but I'll start digging through past conversations hunting for both:

• Is there a blocker we previously acknowledged which prevents iCCP being v4? And
• Did we simply not consider this option?

I think we didn't consider it because iCCP has a Latin-1 profile name and the only way to support UTF-8 would be a new chunk. Since that would be a clean break, it is also a clean spot to support ICC v4. But my gut tells me we didn't consider how desperately we need UTF-8 profile names and whether that justifies a new chunk. (As a reminder, W3C prefers when user demand drives features. If no one wants UTF-8 profile names, it might not be necessary.)

If we change the definition of an existing chunk (iCCP) we're breaking currently-valid viewers. But I think the path forward there is to say it is 2nd Edition Valid and not 3rd Edition Valid. I'll double check what the 2nd Edition spec says for handling unrecognizable iCCP chunks.

That said, do we know if there is user demand for iCCM? I have not yet caught myself up on ICC specs. My intuition is there is a broad user demand for accurate color representation, rather than a specific method of getting there. Having seen how ICC.2 fixes problems with ICC.1, I think the demand and new chunk make sense.

[ProgramMax]

I should mention, technically a new chunk isn't the only way to support a UTF-8 profile name. We could have a UTF-8 BOM. But that would still leave existing viewers in a situation where they don't work the way they expected.

This is similar to the 2nd Edition Valid / Not 3rd Edition Valid idea.

IIRC, at the time we didn't want to allow breaking changes like this. So at the time, a new chunk was the only option.

[svgeesus]

technically a new chunk isn't the only way to support a UTF-8 profile name. We could have a UTF-8 BOM. But that would still leave existing viewers in a situation where they don't work the way they expected.

Right. That option was already mentioned by @lrosenthol :

I would bet that most implementations treat the name as UTF-8 anyway and not exactly 8859-1 - but we COULD make it explicit in the same way we did it for PDF, which is to require that a UTF-8 BOM (https://en.wikipedia.org/wiki/Byte_order_mark#UTF-8) proceed such values. That would therefore maintain backwards compatibility and provide UTF-8 into the future - worse case is an older processor would display something strange for UTF-8.

There is an existing issue for that, Clarify Latin-1 encoding requirements of text chunks because clearly, if we want to update text-containing chunks we should do it consistently not on a chunk-by chunk basis.

For new chunks, naturally UTF-8 would be the correct choice.