Re: [PNG] June 13th, 2022 Meeting Topics

> UTF-8
Chris Lilley will probably be able to provide a better answer than I will.
My understanding is UTF-8 wasn't a hard requirement but rather a clean-up.
And Leonard had a great suggestion
<https://github.com/w3c/PNG-spec/issues/95#issuecomment-1084653432> where we
could introduce a UTF-8 BOM in order to gain UTF-8 support with the
existing iCCP chunk.

> Priorities
I think you're right. I think I misspoke.
(This was the thing I neglected to update.)
You had documented the result of a Color Web meeting from 3-31-2021
<https://github.com/w3c/ColorWeb-CG/pull/19#issuecomment-811487208> where
cICP has priority unless the code point is unsupported on that
display/surface. When unsupported, iCCN should be used. The way we worded
it is that iCCN gets priority.

But really, the priority isn't changing. It's more of a fall-through.

The recommendation as-is matches that priority. It just doesn't have any
wording about how to handle an unsupported cICP code point.

That is the pull request I'll send your way shortly.

On Fri, Jun 10, 2022 at 7:31 PM Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> > We agreed on that (and documented as such) in a Color Web meeting but I
> never updated the recommendation.
>
> The requirements stated that cICP had priority [1].
>
> I think this is always preferable if the decoder understands the color
> space specified in cICP.
>
> [1]
> https://github.com/w3c/ColorWeb-CG/blob/master/hdr-in-png-requirements.md
>
>
> On Fri, Jun 10, 2022 at 4:30 PM Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
> >
> > > Happy to hear other thoughts, of course.
> >
> > To confirm, `iCCP::profile name` being limited to Latin-1 is not a
> problem?
> >
> > [ed.: it is not for me, but just checking :)]
> >
> > On Fri, Jun 10, 2022 at 4:25 PM Chris Blume (ProgramMax)
> > <programmax@gmail.com> wrote:
> > >
> > > Correct.
> > > Happy to hear other thoughts, of course.
> > >
> > > One thing to note:
> > > The priorities of the chunks proposed SHOULD put iCCN first, then
> cICP, then iCCP. We agreed on that (and documented as such) in a Color Web
> meeting but I never updated the recommendation.
> > >
> > > This could mean that the existing iCCP chunk (if repurposed) gets
> priority over the cICP chunk. I think this is okay?
> > >
> > > On Fri, Jun 10, 2022 at 7:23 PM Pierre-Anthony Lemieux <
> pal@sandflow.com> wrote:
> > >>
> > >> Hi Chris,
> > >>
> > >> Thanks for the detailed investigation.
> > >>
> > >> To summarize, you recommend:
> > >>
> > >> - store ICC v4 in the existing iCCP chunk and thus not introduce a
> > >> separate iCCN chunk
> > >> - not support iccMAX (in this new edition)
> > >>
> > >> Did I get this right?'
> > >>
> > >> Best,
> > >>
> > >> -- Pierre
> > >>
> > >> On Fri, Jun 10, 2022 at 3:49 PM Chris Blume (ProgramMax)
> > >> <programmax@gmail.com> wrote:
> > >> >
> > >> > Hello everyone,
> > >> >
> > >> > Sorry about such late notice on the meeting topics for this coming
> Monday's meeting.
> > >> > I realize I did not give you all time to consider the topics, which
> reduces the value of the meeting. However, they are topics we have
> discussed before. I think we can now resolve some of the discussion and
> will find value in the meeting.
> > >> >
> > >> > Previously, we were unsure if we needed a separate iCCN chunk or if
> we could reuse the existing iCCP chunk (making it ICC v4).
> > >> > We also discussed potentially adding an iCCM chunk for iccMAX.
> > >> >
> > >> >
> > >> > I dug deep into all of the Color on the Web Community Group history
> I could think of. I have attached the results of my investigation. Here is
> the result of my investigation:
> > >> >
> > >> >
> > >> >
> > >> > "At no point was there mention for or against repurposing the iCCP
> chunk to be ICC v4. However, there is clear acknowledgement that the
> existing iCCP chunk effectively already is ICC v4 (May 6, 2021,
> https://github.com/w3c/ColorWeb-CG/commit/c0d909ec716a997ff345a49e9773d620c0c6b747).
> This indicates a separate iCCN chunk is not needed and iCCP can indeed be
> ICC v4.
> > >> >
> > >> > There were also several mentions of iccMAX being desirable.
> However, there were also concerns about security and limited support. The
> security concern comes from a scripting language included in iccMAX.
> Although the scripting language is designed to be safe, it is not yet
> widely adopted and thus not trustworthy.
> > >> >
> > >> > We do not want to risk contentious items in the new PNG spec.
> Including an iccMAX chunk (iCCM) would endanger the other changes we want
> to land. I think it is best for us to delay the iCCM chunk for the next PNG
> spec edition. This reduces the number of changes and buys time for iccMAX
> to gain both adoption and trustworthiness."
> > >> >
> > >> >
> > >> > Please review my investigation and let me know if I've missed
> anything.
> > >> >
> > >> > I'll see you on June 13th, 2022!
>