SMPTE 240M discussion

[sekrit-twc]

No description provided.

[dwbuiten]

I would like to note NLEs and QuickTime both match the reverted zimg behavior on ctual 240M files (and I have shared at last one, but I have many). There was a huge uptick in complains from users when the original commit went into prod. I suspect Michael Bradshaw on that thread probably experienced similar. I have a lot of files from a lot of software, all of which disagree with the pre-revert behavior of zimg.

You can maybe argue the behavior pre-revert was "most correct" based on docs, but it does not match how any software or files act in the real world, and thus is defacto wrong, in my opinion. It is not useful to say "but this is technically correct" if it doesn't match anything else in the real world. There is plenty of evidence in how standard NLEs and players render 240M, an how they create files. I have thus far seen zero evidence that the pre-revert behavior was correct, other than arguing technical semantics based on docs.

[dwbuiten]

QuickTime does not even support BT.1886, so who cares what it does

Almost everybody working in profesional (and amateur) video editing cares what QuickTime does.

As for NLEs (I doubt any NLE supports this old and deprecated transfer)

You would be surprised.

Why those users even use that transfer??

I do not read minds.

Also, Youtube does not support this transfer,

I would be surprised if they did not support it for ingest.

BTW, why is Youtube using zimg? Also, not like Youtube even supports sYCC and stuff.

They're not AFAIK, but the experience wrt 240m source files is relevant.

Please give at least mediainfo of those files. Does it use ffmpeg and/or zimg

I've provided some to @sekrit-twc, but I'm not clear to provide user files or info in the open. I have plenty that are not made by FFmpeg or zimg.

In any case, I don't think I will be spending any more of my time Arguing On The Internet with someone who appears quite angry. If the revert is reverted, then fine, I can work around it on my end manually. I merely reported the feedback.

[kodawah]

I don't think we should break user files for the sake of being technically correct on an old and deprecated format, as it could be argued that the the current zimg implementation (post revert) is the behavior needed by this de-facto standard.

if a stricter implementation is required maybe a custom option could be added to support this specific use case. jm2c

[sekrit-twc]

My two cents: it can never be correct to apply inverse 240M OETF followed by 1886 EOTF to do a gamma conversion, because 601, 709, and all other CRT-based transfer functrions imply an end-to-end 1.2 gamma boost. It is not clear to me that 240M is different from 601 and 709, but if it were, it would still be incorrect to convert to 709 by applying 1886 on top of 240M, as that would add a second layer of gamma boost.

[sekrit-twc]

Updating this issue with some additional context.

ValZapod wrote:

since most use Chromium/Chrome to watch it, as a dev of Chrome, I can say

Contributor A wrote:

I missed ValZapod being a Googler.
A nice quote from chromium's bug tracker:

If it makes you feel any better, you're absolutely correct in principle, and we're objectively wrong. We simply made this decision by allowing more than that objective principle to affect our decision, and we know how and why we're wrong, and I think we're all still pretty much okay with that decision.

Yeah, Val is not a Project Member :)

Contributor B wrote:

and as a dev of Chrome, I can say

I can find no evidence of this.

Contributor A wrote:

I can find no evidence of this.

At most, he posted a rejected patch. He does not have Project Member badge on the Chromium issue tracker.

[mirh]

So.. I don't want to disturb you gentlemen (even because this is not my field, and I couldn't find the last 1999 spec anywhere)
Though I just wanted to point out 170M has a lot of "ifs" and "buts" between what the datasheets say, and what the thing in the real world ended up being.

[John-Greg]

Just a newbie here. I don't know if this is helpful, interesting, or totally irrelevant:
---I was preparing to capture footage from an early 1990's Betacam SP master. As I studied about these colorimetry/SMPTE standards, there was this comment on Wikipedia (https://en.wikipedia.org/wiki/NTSC):
"Japanese NTSC never changed primaries and whitepoint to SMPTE "C", continuing to use the 1953 [470m?] NTSC primaries and whitepoint."--which I felt was relevant to me, since this is a Japanese Betacam master tape.

[John-Greg]

Thank you. You guys are amazing!