Tone-mapping should be stable when mDCv and cLLi are static

[palemieux]

If present, mDCv and cLLi SHALL completely define the tone mapping algorithm used by the decoder when rendering the image to a display.

mDCv and cLLi SHOULD be set. This is particularly important when drawing a temporal sequence of images. If mDCv and cLLi are not set, the tone mapping algorithm can vary over the sequence, resulting in temporal artifacts.

[ProgramMax]

Just to be clear, I think "...completely define the tone mapping algorithm..." might just mean the decoder's choice of tone mapping is now set, right? IE we aren't defining what tone mapping algorithm the decoder should use. Just that it should be consistent with itself.

(The intention being that the decoder doesn't change which tone mapping algorithm it uses based on the image, for example...just the metadata.)

[fintelia]

Does "SHALL completely define" contradict "Ancillary chunks may be ignored by a decoder."?

[ProgramMax]

It shouldn't.
It's more like when mDCv and cLLI are present, the decoder has everything it needs to make a consistent decision about which tone mapping to use. I think that is the intent of the "shall completely define" phrasing. (And we want to enforce that it will indeed be consistent with itself.)

But those are still ancillary chunks.

[fintelia]

If a decoder sees that mDCv and cLLI are present but ignores them and does tone mapping based on the image contents instead, has it violated the spec?

[palemieux]

If a decoder sees that mDCv and cLLI are present but ignores them and does tone mapping based on the image contents instead, has it violated the spec?

I think it should be strongly discouraged at the very least.

[palemieux]

IE we aren't defining what tone mapping algorithm the decoder should use. Just that it should be consistent with itself.

Yes, the idea is that the HDR metadata, if present, should set all internal parameters of the algorithm, no matter what they are.

[ProgramMax]

It is a little tricky because the HDR metadata in cLLi is itself dependent on the image contents.

I could imagine a scenario where a new tone mapping algorithm is developed and the mDCv and cLLi chunks are not sufficient. So even though they are provided in an image, the decoder might ignore them.

However, that theoretical future decoder will run into the problem that spawned this issue: Two images next to each other or in a sequence like a flipbook might have a jarring, unintentional jump if they use different tone mapping algorithms.

The goal is to make the decoder consistent with itself. It can use the new tone mapping algorithm both times. That's fine. Said another way: So long as the decoder ignores both chunks consistently and always applies its tone mapping algorithm, that is fine.

[palemieux]

Said another way: So long as the decoder ignores both chunks consistently and always applies its tone mapping algorithm, that is fine.

I think it should be a little bit more stringent: it should be possible for the author to strongly hint that multiple images should be tone-mapped ignoring their contents.

[palemieux]

It is a little tricky because the HDR metadata in cLLi is itself dependent on the image contents.

cLLi is for an image sequence, not an individual image.

[svgeesus]

It is a little tricky because the HDR metadata in cLLi is itself dependent on the image contents.

cLLi is for an image sequence, not an individual image.

It's a good thing the PNG spec defines some terms, so that we have the option of using them consistently.

A PNG datastream consists of a static image and, optionally, a frame-based sequence. ( which may or may not include the static image as the first frame).
https://w3c.github.io/PNG-spec/#static-and-animated-images
https://w3c.github.io/PNG-spec/#dfn-frame

cLLi is defined on frames. We don't need the term 'image sequence'.

I just noticed that the casual reader might conclude that a static (non-animatedPNG has no frames and thus, that they can't use cLLI to define the brightest pixel in a static PNG.

The spec is actually clear on that, because the MaxCLL is defined on "the entire playback sequence" but I think we could be a bit more explicit that MaxCLL can indeed be defined on a static PNG.