Gamma issues with .mov / colorspace metadata in Quicktimes / NCLC tags

Flame Flame Questions
, ,
21

Hi John,

Definitely not a noob question. Ensuring the metadata in the Quicktime file is correct BEFORE the decisionmakers lay eyes on it is the key here. In Tim’s scenario, I’m assuming clients laid eyes on the Color Correct house’s incorrectly flagged Quicktime and then proclaimed that one was being the “Gold Standard”. At that point, you can fix the Quicktime’s metadata, but it usually won’t change the perspective of the creatives. I believe the only thing to do in that particular scenario is to re-grade the spot to match the look that Quicktime created.

I think the “right” way to go forward is to have the Color Correct house revisit how it has exported its .movs and see if they can manage to flag it correctly for future exports.

As far as Flame artists are concerned, I’ve messed with some export settings and can’t seem to figure out how to export it “wrong” so I think we’re in the clear as far as falling into this issue ourselves.

22

Jeff has said it very succinctly. In fact, the colour house did simply flag it properly and send it out. And I had to replace it in the spots, and the client said it was much better. And of course, anyone who knew anything knew that it was EXACTLY THE SAME. As far as the colour company paying more attention in the future, one of the benefits of working on mostly commercials is that I can keep a years worth of jobs at my fingertips. I looked back through the last 4 or so that they had provided colour for and everything was correct. And I rarely have issues with them. Their people are all very good and their colorists are very talented. They made a mistake. What made this such a frustrating issue was that I couldn’t make anyone understand the issue which I figured out but couldn’t prove. All any of them could do was say “the output of the flame doesn’t match the colour correct.” I will once again thank Jeff for showing me where to find the smoking gun, because it made all the difference.

23

I agree the color house, and especially such a large one I assume, should have been on top of it. That said, we were also caught by this and it has to do with some new features in Baselight which they didn’t seem to really flag to users. Their default tagging for QTs has now moved from the legacy 1-1-1 to trying to, in their eyes, tag it properly in relation to the content/end display.

While it’s for a different topic, here’s some insight from Filmlight if you want to sit through it. The interesting stuff is half way through.

Not trying to defend them, just providing some context. Glad to hear it’s all been resolved and it really sucks when you first run into this and are trying to figure out what the hell is going on.

24

Does anyone know of any utilities that can re-tag an existing file? In years past this was less of an issue because nothing except Quicktime Player X respected the tags and everyone just got used to never trusting it, but I do try to keep an eye on it now. Netflix used to recommend JES Extensifier but it no longer runs on current MacOS :frowning:

I’ve been using a modified version of the BBC one, which is designed specifically for ProRes but will do the job on h264 in a pinch. There’s a Mac build of it here if anyone needs it: https://github.com/lcrs/qtff-parameter-editor/releases

I’ve heard that this thing can do it but haven’t tried yet: http://mogurenko.com/2020/09/14/amcdx-video-patcher-v0-6-0/

25

I think Cinedeck CineXMeta does it:

26

Hi Lewis,

Although I haven’t yet bought this, I’m interested in it:

“QT Edit has a Custom option for color, which allows you to specify the primaries, transfer and matrix individually.”

QT_edit
QT_edit944×573 33.3 KB

To enter this mode, select the video track, go to Encoding Attributes and choose Custom under the Color field. If the Color field isn’t showing, it means the movie doesn’t have a color atom in its structure, so hit the + button to add one.

27

This might be old news now.

I have been following this thread for awhile. I believe that Richard Betts has the best solution for the ‘tagging’ issue. This is to apply a simple Colour Transform to your work when your export a clip for clients to review. This assumes that the clients are viewing the work on a laptop (sRGB), not running it through a TV (rec709). This will fix the whole “the client is seeing it brighter” gamma issue as described by the OP. I wont go into the technical details about why… I’ll just offer up the fix! The Colour Transform re-maps the gamma correctly from 2.4 to 2.2 and tags the clips meta-data as sRGB (1, 13, 1). So when viewed on a a laptop (well at least the 3 macs I tested) it looks very close to the Sony broadcast monitor. The same clip exported with no tagging (1, 1, 1) looks too bright as per the OP’s problem. I cant upload the LUT, so here is a picture of the settings within “Show Advanced Options”!

Remember to “Tag” as sRGB!!

(I cant upload pics!!! ) Trying to… “computer says no”…

PXL_20201124_022320654
PXL_20201124_0223206544032×2268 3.44 MB
PXL_20201124_022335206
PXL_20201124_0223352064032×2268 2.97 MB

28

Yeah. I have really appreciated all of the helpful discussion on this topic. It has been enlightening.

What @justinbromley and I were keen to avoid was double handling the outputs.
You just want to export your ProRes and have it looking correct.
You don’t want to run a command line script or jump on another computer to modify the metadata.

So the solution for client viewing files was for me to apply a slight gamma shift by removing 2.4 gamma and then applying 2.2. You can do this during export as @justinbromley shows above.

As @justinbromley mentioned, Flame should tag this as sRGB display and the colour profile (1-13-1) will display correctly in Quicktime.

However, we still need to deliver broadcast masters and rightly or wrongly ProRes seems to have become our digital standard.

Applying the gamma shift during Flame export is good for client review but it is grading the pixels. No longer broadcast 2.4 gamma.

I’m with @lewis I am hunting for what I can use to bulk convert the metadata on my broadcast masters.

I have been testing using JES Extensifier which I think is excellent. The winning feature for me is the ability to use a preset to convert entire folders of ProRes files. The only problem is that it seems as if development has stopped and it won’t run on OSX Catalina or above.

I have dabbled with AMCDX video patcher but it seems to only work on one file at a time.

I also saw a post about the BBC GitHub but I couldn’t get past the lack of GUI. I am technically curious but GitHub just confuses me.

So I guess I am hoping that we can convince Autodesk to give us a custom gamma option in a future release.
Or someone holds my hand and walks me through GitHub or is there another bulk metadata converter out there.

Thanks for showing me this rabbit hole. It has kept me very busy for over a week.

29

yea this is a HUGE rabbit-hole, and I really think the industry has to change with many deliveries going on the internet nowadays.

Dont even get me started on youtube-vimeo e.t.c re-tagging everything as 1-1-1 (which is gamma 1.96), windows treats those as sRGB as does iOS but macOS does not.

Its currently not even possible to create a single master to fit all viewing conditions, even if people are using the same screen, same surround brightness e.t.c , windows works totally different than macOS, hell even iOS works differently. and tbh macOS with Colorsync is the only one that gets it right imho, if just everything would write proper tags… NOT even FCPX reads or writes the tags… i mean come-on.

Some say the gamma shift from 2.4 to 2.2 is some sort of “Surround compensation” , but I do not believe that anymore, maybe if both screens run at 100NIT, one in dark one in bright surround which imho is a flawed way of thinking, as people just crank up their screens luminance themselves when its too dark due to a bright surround, measure your laptop screen in a normal lit room, that you feel comfortable with I do not think it will be close to 100NIT at all but all the ‘standards’ tell you SDR should be, its just really not 100NIT anywhere in reality.

Also its just not the same 2.4 to 2.2 , what we get when we upload a master to youtube is 2.4 mastered content thats transformed as 1.96 to sRGB… at least on macOS chrome and safari.

We really need to rethink how to master/Finish files in this era of web deliveries. the current way is not working, mastering on BT.1886 2.4 Gamma 100NIT screens in a dark surround is all good and well, but we need to find a way of transporting the creative intend to the viewer in the end, if you just deliver 2.4 gamma encodes to the internet you are not doing the correct thing, in my opinion at least.

For still images its easy, everything is sRGB and you need to create a print-master thats CMYK, same for audio, web master and TV master, guess what video needs the same treatment, you need to finish differently for a instagram vs a youtube ad, depending on whats your main focus group is, in reality the marketing companies would have to dictate that, but they do not care, nobody cares, they just want to “see the same thing everywhere” which just isn’t possible and its honestly breaking my mind how inconsistent this all is and how the industry has not adapted to this, resolve and Baselight are the only tools i have seen that even offer a option to tag stuff during export

just for more fun some infos:

Premiere treats everything that comes in as video as gamma 2.4 no matter the tag but displays it uncorrected, so if you have a sRGB screen it would display it too bright, if you enable Viewer color management it displays it corrected to whatever you set your display as, so same as flame “Colorimetric” or “aces-SDR” just not based on a tag but rather just saying everything is Gamma 2.4
On export it does however tag everything as 1-1-1 which is horrible.

FCPX treats everything as 1-1-1 during import and displays it corrected from 1-1-1 to display and also tags all the output stuff as 1-1-1 ,

Youtube does the same as FCPX unless you upload anything tagged 1-13-1 (sRGB) .

Resolve is fine, it tags the viewer as whatever you set in the timeline and outputs whatever you choose when you enable ‘use mac viewer blah blah’

Flame also does really well in that regard minus the output tagging not working correctly, you can choose broadcast and graphics space and have your stuff auto converted to that profile, its great honestly, the best implementation for a UI/broadcast output system ive seen yet, you could even send HDR to broadcast and use SDR on your graphics display, so cool, so flexible.

firefox is not Colormanaged at all, just pushes pure values to the display so like windows.

Baselight UI seems to work like firefox.

Now all of this only goes for MacOS Catalina, ive seen some additional stuff happening on BigSur… like suddenly VLC is Colormanaged apparently acting like its sRGB…

Its a rolling rollercoaster of complete garbage and even after multiple weeks of late night research and testing I am still not 100% what I would deliver to my clients without sending them a long list of questions to fill out beforehand…

Nothing of this concerns TV broadcast at least…

30

yea a bulk converter would be nice, the BBC tool works but only re-tags the NCLC tag but I have not found a way to write 1-2-1 with a custom gamma to it using it yet, so far AMCDX is the best, they have a command line version that you can script, but yea we really need to have metadata tagging in flame!!

32

AMCDX has a command line version. Seems like we could python hook our way into a solve. It’s just metadata, so I think it’d run quickly after export. Anyone interested in something like that ?

33

Yes, i got a python thing that can change metadata using a script in nuke, should work in flame as well with some mods. Just havent found a way to set the gamma tag to 2.4 as thats not specified

34
35

At the bottom there’s a few examples, I think there’s one in there that’ll do the trick.

36

i honestly would just want flame to have the same simple dropdown as resolve, I thibk there is a feature request for this even? shouldnt be crazy to implement I recon.

38

I wrote a quick Python script (https://www.dropbox.com/s/1rjagdyfg3gbi5v/nclc.py?dl=0) that one can use with/as a post script. AMCDX won’t run on CentOS 7.4 so I had to put it on another machine that had more up-to-date libraries so you’d need this to be kicked off on another machine unfortunately. Should be fine on OS/X though.

Usage:
python nclc.py primaries transfer matrix gamma /path/to/mov

eg

python nclc.py 1 1 1 2.4 /path/to/mov

You need to modify the script to point to the location of AMCDX. Also, if you set gamma to 0 it will remove that tag.

Curious to hear what combination of values and gamma people feel work best for rec709.

40

https://raw.githubusercontent.com/da8eat/VideoEditorInstaller/master/v0.6.1/InstallerAMCDXVideoPatcher.run

this works for me in cent 7.6 at least

41

After some testing … setting the transfer to ‘2’ and then specifying the gamma (2.4) is exactly what Baselight is doing (1-2-1 with a specified gamma of 2.4) with their latest release and what’s been causing a bunch of headaches for people.

I’ll have to agree with them on this one, when I compare it against my broadcast monitor it’s definitely far closer than the old-school 1-1-1 tagging.

I’m working on scripts to run the nclc.py script from the media hub as well as automatically post export. The post export bit is a bit more to chew off though. I’ll post them when I get something working.

43

Thanks for this trick. I’ve been applying an adjustment layer with a Look power setting of 1.2 but your solution is much better.