Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Specify expected behavior in presence of both cICP and ICC profile information #18

Closed
palemieux opened this issue Mar 16, 2021 · 10 comments
Closed

Specify expected behavior in presence of both cICP and ICC profile information #18

palemieux opened this issue Mar 16, 2021 · 10 comments

Comments

@palemieux
Copy link
Contributor

palemieux commented Mar 16, 2021 •
edited
Loading

A PNG MAY contain both a cICP chunk and an iCCP chunk. If a PNG decoder detects the presence of both a cICP and a iCCP chunk, the behavior is undefined.

The behavior should be defined.
@lrosenthol lrosenthol mentioned this issue Mar 17, 2021
Merged
@ProgramMax
Copy link
Collaborator

I've been thinking about this.

For HDR content, the existing iCCP chunk is insufficient. In that case, we wouldn't want to prioritize iCCP over cICP.
(Is the existing iCCP chunk sufficient for WC?)

However, if we were using ICC v4 profiles (instead of iCCP's v2), maybe it would have been sufficient.
So maybe we want iCC4 (new chunk, can rename) > cICP > iCCP.

What I just described is specific to HDR though. For WC, I can understand that iCCP may be sufficient and is more specific. I think this is where the confusion and divide came from.

I don't think we want a rule like "If the cICP chunk describes a HDR color space, it takes priority. If not, the iCCP chunk takes priority." Even if we carefully defined what counts as HDR, this feels like the wrong approach.

Instead, if the existing iCCP chunk is sufficient for WC (or any other non-HDR color), I think the user/creation program could simply provide only the iCCP chunk and not the cICP chunk. That way it effectively takes priority. They have no need for the cICP chunk so why waste bytes?

I believe the user would only provide the cICP chunk when the iCCP chunk is insufficient. In which case, it should take priority. And later when we have support for ICC profiles that are sufficient for HDR, it can take priority over cICP.

@LarsBrg Do you agree with this? Am I missing anything?

If this looks good, we'll want to think about the iCC4 chunk enough to make sure we aren't making a mistake there.

@LarsBrg
Copy link

LarsBrg commented Mar 30, 2021 via email

@svgeesus
Copy link
Contributor

@ProgramMax wrote:

However, if we were using ICC v4 profiles (instead of iCCP's v2), maybe it would have been sufficient.

There is already a PNG erratum raised by Phil Green to update the PNG spec to reference ICCv4 and iccMAX. The restriction to ICC v.2 is unintentional, happened because that was the latest version at the time, and is not honored in practice. People can and do put ICC v.4 profiles into iCCP so the spec simply needs to be updated to reference the newer specifications and match the implementation reality.

The proposed iCCN tag does need to be a new tag, however, as it also usefully changes the profile name from Latin-1 to UTF-8.

@svgeesus
Copy link
Contributor

svgeesus commented Mar 31, 2021 •
edited
Loading

@ProgramMax wrote:

Instead, if the existing iCCP chunk is sufficient for WC (or any other non-HDR color), I think the user/creation program could simply provide only the iCCP chunk and not the cICP chunk. That way it effectively takes priority. They have no need for the cICP chunk so why waste bytes?

I would put it the other way, if the cICP chunk is sufficient to describe the WCG content (for example, Rec. 2020 content) why waste like 2k for the iCCP?

On the other hand, there are WCG cases where cICP is not sufficient. Content using ProPhoto, or Adobe (1998) RGB, or Display-P3, is not covered by ITU H.273so the options are:

  • embed an ICC profile (currently done, for still images)
  • transcode to a supported colorspace, like DCI-P3 content transcoded to a REC. 2020 container (currently done, for streaming video services)

@ProgramMax
Copy link
Collaborator

Below is Lars's exact email. GitHub did not recognize which parts were quoting me and which parts were new, inline comments. I've reposted it to include that formatting and be easier for everyone to read.

For HDR content, the existing iCCP chunk is insufficient. In that case, we wouldn't want to prioritize iCCP over cICP.
(Is the existing iCCP chunk sufficient for WC?)

WC == Wide color gamut? Yes, ICC V2 handles wide color gamut such as Rec.2020.

Yes, AFAIK HDR requires ICC V4. I make such profiles, and I haven’t seen any ICC V2 profiles made for HDR.

However, if we were using ICC v4 profiles (instead of iCCP's v2), maybe it would have been sufficient.
So maybe we want iCC4 (new chunk, can rename) > cICP > iCCP.

What I just described is specific to HDR though. For WC, I can understand that iCCP may be sufficient and is more specific. I think this is where the confusion and divide came from.

I don't think we want a rule like "If the cICP chunk describes a HDR color space, it takes priority. If not, the iCCP chunk takes priority." Even if we carefully defined what counts as HDR, this feels like the wrong approach.

Yes, too fragile.

It would be hard to come up with a rule that determines if future CICPs are HDR or not.

And very hard to determine if an ICC profile is HDR.

Instead, if the existing iCCP chunk is sufficient for WC (or any other non-HDR color), I think the user/creation program could simply provide only the iCCP chunk and not the cICP chunk. That way it effectively takes priority. They have no need for the cICP chunk so why waste bytes?

Not sure.

For many hardware-supported devices, beyond GPU, CICP may be more useful, as the hardware usually is optimized for the most common CICP cases.

This optimization doesn’t work for ICC, especially not current ICC HDR profiles, as there are near-infinite ways to make such and you’d have to find if it matches your hardware. Like, does this ICC profile encode the PQ curve or not? With OOTF? Also, ICC profiles for HDR are large. HLG to display is very large. CICP is tiny.

I believe the user would only provide the cICP chunk when the iCCP chunk is insufficient. In which case, it should take priority. And later when we have support for ICC profiles that are sufficient for HDR, it can take priority over cICP.

Not sure.

We have HDR ICC profiles today in V4, sufficient for static HDR.

I assume that the ICC profiles we will see here are for consumption of content, not for editing of content.

In that context the ICC profile should be used if reasonable.

But:
The ICC profile might have been picked to render HDR to an SDR display. For an HDR display the CICP could be a better fit.
For image editing, use the CICP to get to the mastering display.
Not a trivial call.

Thanks,

Lars

@ProgramMax
Copy link
Collaborator

I would put it the other way, if the cICP chunk is sufficient to describe the WCG content (for example, Rec. 2020 content) why waste like 2k for the iCCP?

If the PNG decoder doesn't understand cICP, it would assume sRGB without an iCCP chunk.

This might be fine. If a website determines their users are migrated enough they could provide a PNG that has cICP and no iCCP fallback. Or perhaps the website could sniff browser version and serve two different PNGs.

Fundamentally, I do like what you're saying: That if a cICP chunk works for the website, they could use just it and not the iCCP chunk to see a significant size savings.

Talking about only WCG:

  • If it cannot be represented by cICP then I think it makes sense to use just iCCP.
  • If it can be represented by cICP and it is deemed users have sufficient support, it makes sense to use only cICP and not iCCP.
  • If it can be represented by cICP and we're in the middle of a transition, I think it makes sense to provide both cICP and iCCP.

Given this, I think it is okay for either chunk to take precedence.

For HDR content:

  • ICC v2 is insufficient and a cICP chunk without an iCCP chunk makes sense. Although, maybe it is better to have an iCCP chunk to get as close as possible??
  • If decoders are allowing iCCP chunks to store ICC v4 anyway (and there is an erratum), we're in the same situation as WCG I listed above.

I'm coming around to having iCCP take precedence over cICP. I think my original concern may have been wrong.
I think I was the holdout, right? If we agree that iCCP takes precedence over cICP then this becomes resolved? And I think we no longer need the iCCN chunk, either in that case.

@ProgramMax
Copy link
Collaborator

To spell out my change of mind (in case others felt similarly):

Originally, I had thought cICP would be a handy shortcut for decoders to not need to parse and interpret iCCP. And during the transition period, iCCP would provide a fallback. End users would see correct colors until a website owner deems enough users have transitioned and iCCP could be removed. This fallback mentality is why I thought we needed the precedence to match spec order.

But in the cases I listed above, the exact same effect happens without relying on iCCP as a fallback. The website owner can still remove iCCP when they are ready. And honestly, the time spent parsing iCCP isn't so bad that it is worth shipping PNGs that contain both iCCP and cICP. The website owner probably wouldn't want to send extra bytes during the transition.

Realistically, the website owner will likely send either cICP or iCCP, not both. And if they aren't sending both, the precedence shouldn't matter.

We could say that a PNG with both is invalid. I believe that is how we arrived at the undefined behavior from before. But surely someone will create a PNG with both and decoders will choose what to do. I think it might be better to specify a behavior and discourage sending both. I'm happy to specify iCCP taking precedence over cICP given that iCCP supports v4.

@LarsBrg
Copy link

LarsBrg commented Mar 31, 2021 via email

@LarsBrg
Copy link

LarsBrg commented Mar 31, 2021 via email

@ProgramMax
Copy link
Collaborator

This is now spelled out explicitly at https://github.com/w3c/ColorWeb-CG/blob/master/hdr-in-png-requirements.md#decoder

Closing

@palemieux palemieux mentioned this issue Mar 30, 2022
Closed
@butcherg butcherg mentioned this issue Mar 14, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ProgramMax @svgeesus @palemieux @LarsBrg