search

w3c / ttml2

Timed Text Markup Language 2 (TTML2)
https://w3c.github.io/ttml2/
Other
41 stars 16 forks source link

Gamma approximation in luminance gain. #1070

Open cconcolato opened 5 years ago

cconcolato commented 5 years ago

From a discussion with @joedrago:

a minor note about SRGB's transfer function. SRGB's transfer function approximates much closer to a gamma of 2.2, despite the value of 2.4 being present in the only exponent of the function. Here is a reference from color.org indicating its approximation: http://www.color.org/srgb.pdf And here is a Desmos graph showing 2.2, 2.4, and SRGB: https://www.desmos.com/calculator/az6xrrvj8v

palemieux commented 5 years ago

A key question IMHO is: what gamma is applied to the subtitles when authoring against a Rec. 709 video program? According to ITU Rec. BT.1886, a gamma of 2.4 will be applied to the Rec. 709 video program. Will a different gamma be applied to the subtitles?

joedrago commented 5 years ago

The TTML standard's Q.1 and Q.2 sections specifically cite the source color profile as SRGB (IEC 61966-2-1). If the source color is not SRGB, but instead BT.709 + BT.1886, the TTML standard should specify that as the source instead, or Q1/Q2 should use something that better approximates sRGB's EOTF.

I think it is perfectly reasonable to leave the 2.4 alone and instead replace all references to SRGB from the Q section with some other specification for the source color profile.

palemieux commented 5 years ago

@joedrago My question was more operational: do you expect authoring to be done using BT.1886 EOTF or sRGB EOTF?

joedrago commented 5 years ago

I am not involved with video or subtitle authoring, so I honestly have no idea. I don't really have a strong direct stake in this implementation. I recognize that the end result will be very similar regardless of 2.2 or 2.4 here.

I'm just noting what feels like mildly-incorrect advice for converting from SRGB to BT.2020 PQ. If you have a standard that people rely on for a source of truth math-wise, and it has a step labeled "Linearize using the SRGB EOTF", the math provided there should be a reasonable approximation of that label, which I don't think it is.

If your goal here is to mimic video authoring, so be it. If that is the case, I think the wording in the standard here is misleading by either citing SRGB or using a poor approximation for its EOTF.

palemieux commented 5 years ago

If you have a standard that people rely on for a source of truth math-wise, and it has a step labeled "Linearize using the SRGB EOTF", the math provided there should be a reasonable approximation of that label, which I don't think it is.

Understood. Perhaps the minimal modification is then to state Linearize using the BT.1886 EOTF instead of Linearize using the SRGB EOTF?

Would that work?

joedrago commented 5 years ago

Yes, that would be a good change (amongst other similar changes throughout Q.1 / Q.2), but only if you effectively abandon using references to SRGB. If you want to still cite things like the CSS standard (which uses SRGB) when talking about colors, it might be much easier to just correct the gamma instead of upending lots of indirect ties to SRGB in the standard.

palemieux commented 5 years ago

it might be much easier to just correct the gamma instead of upending lots of indirect ties to SRGB in the standard.

Well, unless the sRGB EOTF is not used in practice when compositing sRGB onto Rec. 709 content, right? Q.1 is purely informative and intended to reflect common practice.

joedrago commented 5 years ago

I feel like this discussion is ultimately coming down to what SRGB actually means in its standard vs how people loosely use the term when they describe a color and how they perform math on it. I'm sure people are much more likely to use a basic gamma (be it 2.2 or 2.4) instead of the proper SRGB EOTF, just as I'm sure people are accustomed to seeing blends in nonlinear space, despite it being "wrong."

There exists a standards-accurate formula to get from SRGB (IEC 61966-2-1) to BT.2020 PQ, and there exists friendlier/simpler/less-accurate means to get almost the same result (depending on bit depth / rounding). I'm all for simplicity, and I think using a simple exponent here is an easy win, but after seeing the SRGB recommendation on color.org and graphing it for ourselves (as shown above), we internally use a 2.2 gamma when rendering/converting our SRGB content to HDR.

If the goal of Q.1 and Q.2 is just to be informative and give someone a rough idea of the kind of conversion pipeline they're signing up for, and you expect people to implement it how they see fit, okay. I hadn't caught on to the "Non-normative" wording in the header title, so I recognize (now) that this isn't intended to be prescriptive. That said, I do think that people that aren't accustomed to this kind of pipeline are likely to just copy/paste these kinds of sections into their code and it can become a sort-of "de facto normative". I have similar (but more serious) reservations about the luminanceGain of 2.0 (say) implicitly meaning "precisely 160 nits" vs "twice as bright as normal", but that falls under the same non-normative umbrella.

Based on the "non-normative" in the Q title alone, feel free to ignore my suggestion(s). As I mentioned before, I don't really have a huge stake in the outcome, the 2.4 just caught my eye, so I figured I'd mention it. Sorry for the swirl.

skynavga commented 5 years ago

As a reminder, TTML[123] define SRGB as meaning whatever GB IEC 61966-2-1:1999/AMD1:2003, "Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB," says it means, and nothing more or less.

On Wed, May 1, 2019 at 4:07 PM Joe Drago notifications@github.com wrote:

I feel like this discussion is ultimately coming down to what SRGB actually means in its standard vs how people loosely use the term when they describe a color and how they perform math on it. I'm sure people are much more likely to use a basic gamma (be it 2.2 or 2.4) instead of the proper SRGB EOTF, just as I'm sure people are accustomed to seeing blends in nonlinear space, despite it being "wrong."

There exists a standards-accurate formula to get from SRGB (IEC 61966-2-1) to BT.2020 PQ, and there exists friendlier/simpler/less-accurate means to get almost the same result (depending on bit depth / rounding). I'm all for simplicity, and I think using a simple exponent here is an easy win, but after seeing the SRGB recommendation on color.org and graphing it for ourselves (as shown above), we internally use a 2.2 gamma when rendering/converting our SRGB content to HDR.

If the goal of Q.1 and Q.2 is just to be informative and give someone a rough idea of the kind of conversion pipeline they're signing up for, and you expect people to implement it how they see fit, okay. I hadn't caught on to the "Non-normative" wording in the header title, so I recognize (now) that this isn't intended to be prescriptive. That said, I do think that people that aren't accustomed to this kind of pipeline are likely to just copy/paste these kinds of sections into their code and it can become a sort-of "de facto normative". I have similar (but more serious) reservations about the luminanceGain implicitly meaning "precisely 160 nits" vs "twice as bright as normal", but that falls under the same non-normative umbrella.

Based on the "non-normative" in the Q title alone, feel free to ignore my suggestion(s). As I mentioned before, I don't really have a huge stake in the outcome, the 2.4 just caught my eye, so I figured I'd mention it. Sorry for the swirl.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/ttml2/issues/1070#issuecomment-488450099, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC4E37BEOLT5GH3CGZOJ33PTIICRANCNFSM4HHTNEPQ .

nigelmegitt commented 5 years ago

@joedrago thanks for bringing this up - your link and graph are very persuasive to me that we should change the linearisation exponent from 2.4 to 2.2. The colour space of TTML is SRGB so it would not seem appropriate to me to adjust the EOTF reference to BT.709 + BT.1886.

@palemieux @cconcolato have you got any assessment of the impact (on implementations, for example) of adjusting the formula in Q.1 step 4 in this way?

palemieux commented 5 years ago

I am comfortable making the change from 2.4 gamma to 2.2 gamma in the Linearize using the [SRGB] EOTF step since:

The change should be accompanied by an informative note highlighting that the annex is merely an example, and that the actual mapping will depend on the rendering system.

P.S.: This does not address the fact that subtitles are commonly authored on broadcast monitors that have a gamma of 2.4 (per BT.709 + BT.1886), regardless of whether the color is encoded as sRGB, and that televisions might apply a gamma of 2.4 to all SDR RGB pixels. This issue goes beyond the specification however.

palemieux commented 5 years ago

@joedrago See https://github.com/w3c/ttml2/pull/1072

joedrago commented 5 years ago

The change to Q.1 looks great(!), although a similar discrepancy exists in Q.2 as well.

palemieux commented 5 years ago

@nigelmegitt You were the primary proponent for Q.2. Any opinion on https://github.com/w3c/ttml2/issues/1070#issuecomment-488739513 ?

@joedrago Thanks for the review!

nigelmegitt commented 5 years ago

The discrepancy in Q.2 is deliberate - there's a note at the bottom of the section explaining it.

palemieux commented 5 years ago

The discrepancy in Q.2 is deliberate - there's a note at the bottom of the section explaining it.

@nigelmegitt The comment remains valid: "Linearize using the [SRGB] EOTF" is not accurate since the sRGB EOTF is definitely not 2.0. This could be addressed by stating "Linearize using the SDR EOTF" instead.

nigelmegitt commented 5 years ago

@palemieux I'm not sure any change is really needed - I suppose it could be reworded to something like:

Linearize using the an approximation to the [SRGB] EOTF without the viewing environment psychovisual rendering adjustment (see note below).

though I'm not sure it is an overall improvement or is helpful.

@simontwork any thoughts on this?

palemieux commented 5 years ago

though I'm not sure it is an overall improvement or is helpful.

Yes.

Similarly, regarding Annex Q.1, I have received feedback that the proposed PR, while technically accurate, might not match practice, e.g. https://github.com/w3c/IMSC-1.1_Text_TestContent. Even if only informative, it would be unfortunate to have a misleading example.

I am therefore leaning towards not closing the PR until we can really sort this out.

[edit: a critical not was missing :(]

nigelmegitt commented 5 years ago

while technically accurate, might not match practice

Isn't the whole point of the change to direct practitioners to make updates? By your logic here we would never make the change but would always want to.

If there's a plan afoot to update the test content with the revised gamma in the near future, I'm happy to hold off merging until the new test content is available. Otherwise I think we should go ahead and make the change anyway. The arguments in favour seem compelling.

palemieux commented 5 years ago

@nigelmegitt To be specific, there are two options on the table:

It is not clear to me at this point which one is the most representative of reality.

simontWork commented 5 years ago

The solution for TTML rendering needs to be workable in the integrated receiving devices in use. This is the reason that a simplified version was developed which could be transformed in a TV graphics plane. If we wanted a more accurate system then a 3D LUT could be used, but this is not possible in reality.

The gamma should be kept as 2.0 for HLG. HLG is a scene-referred system and therefore needs a scene referred transform - we apply a simplified inverse OETF, not an EOTF. http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2087-0-201510-I!!PDF-E.pdf

I can try and find a reference to the simplified inverse OETF being 2.0. I'm sure my colleagues have one.

svgeesus commented 4 years ago

I see this discussion, and the resolution to change the sRGB gamma to the 2.2 approximation, and the merged pull request to do that.

However, the published Recommendation still has 2.4, and the errata list is empty. Shouldn't this change be listed in the errata?

skynavga commented 4 years ago

See the new 2nd Edition CR [1] which has been updated. We have not placed an obsoletion warning in the existing REC at this time since it has not yet been replaced by the 2nd Ed which has not yet reached REC. However, you raise an interesting point about its errata page. Perhaps we should simply place a link in its errata page pointing to the new 2nd Edition CR (as well as pointing to the changes document for the 2nd Edition CR [2], which I note currently only lists substantive changes, and so does not yet list this non-substantive change related to Appendix Q).

[1] https://www.w3.org/TR/2020/CR-ttml2-20200128/#hdr-compositing [2] https://www.w3.org/TR/2020/CR-ttml2-20200128/ttml2-changes.html