Scripts to change QT NCLC tag within Flame

Flame Python
,
1

With all the discussion lately over Quicktimes and NCLC tags lately I wanted to be able to change the color tags within Flame as a stopgap measure until ADSK gives us the ability to do so. I hope some of you find it helpful.

There are two scripts:

  • nclc.py (Acts as the middleman to send things to AMCDX)
  • nclc_mediahub_tag.py (Media Hub Hook)

How To Install:

  • Download AMCDX Video Patcher for Mac or Linux

  • Modify nclc.py to point to the correct location of where AMCDX is located. You shouldn’t have to touch this if you’re on a Mac. On Linux, the AMCDX link is the program itself so no need to “install” it per-se, just copy it somewhere like /opt/amcdx

  • Modify nclc_mediahub_tag.py to point to where nclc.py is

  • Move nclc_mediahub_tag.py to where ever you keep your python hooks or the default /opt/Autodesk/shared/python

How To Use:
In Media Hub right-click on any .mov and you’ll see a new menu called “QT NCLC Tagging”. There are two options.

Rec 709, 2.4 Gamma (1-2-1)
This is the way FilmLight is exporting Rec709 QTs now. The difference is telling QT to use our gamma of 2.4 as the transfer as opposed to 1.85 which is what happens in the legacy way.

Rec 709, Legacy (1-1-1)
If you want to revert back to how Flame exports QTs.

I know ADSK is working on a fix for all this very soon but in the meantime, here’s a way to do it. Let me know if something doesn’t work. I’ve only tested the media hub script on CentOS 7.4 but it ought to work on 7.6 and OS/X fine.

Why It’s Needed

Short Answer:
QuickTime on OS/X doesn’t display rec709 videos using a gamma of 2.4. This fixes that by telling it to.

Long answer:
QuickTimes have always looked slightly different on a normal laptop/computer monitor when compared to a broadcast monitor. Apple has tried to address this by using color tags within QTs and having their own version of color management called ColorSync. Basically it does what Flame does: What is this file & what is my display and I’m going to make it look right.

Historically all the apps we author content with have exported QTs with 1-1-1 tagging which is Rec709 across the broad. The problem is the gamma isn’t defined as 2.4 in this implimentation so there’s always been a shift.

I’m unsure why, but FilmLight seems to be the first to implement a better way to approach this issue which is tagging the video as 1-2-1 with a gamma of 2.4. The key here is the 2nd digit, 2, which tells ColorSync “Use the specified gamma as the transfer function”. In this case, 2.4 which is correct. ColorSync then knows to map this to whatever your client’s super awesome P3 Retina display is.

This video posted by Jean-antoine Lacolle does a great job explaining everything and showing the differences.

The sad fact is once it leaves us, it’s still throwing darts at a board. Some applications recognize ColorSync, some don’t. Vimeo, YT, etc…not at the moment, but maybe they will all the sudden. Oh, and of course this is only applicable for anything Apple. It sort of makes the argument of having online deliveries where you convert the gamma from 2.4 to 2.2 but that’s a whole different story.

20 Likes
2

Pretty incredible work man. Well done :+1:t2:

3 Likes
3

This is amazing. @kyleobley, would you terribly mind amending your post to include why this is so important? We have a lot of new users and they may not have been around when that epically long discussion on Quicktime having flags and it responding differently in different applications, different browsers, different operating systems, etc.

2 Likes
4

Maybe we can link that discussion @randy?

1 Like
5

I can, totally @cnoellert…I was thinking the original topic was pretty blackbelt and perhaps a bit too geek for some to wade through. Waddya think…am I overthinking it?

1 Like
6

I was just thinking that a link means it lives in one place. That’s all…

1 Like
7

yeah im overthinking it…you’re right. .lemme think about the best way to do this…I may merge…lemme think about it.

8

I’m more than happy to include a link or maybe a short summary. I was hoping to keep things clean and not go too into the details as it’s a lot to explain.

I think the video posted on FB recently does a great job breaking it down with visuals to support.

Glad you guys like it the scripts though. ADSK has said a solution is in the works on their end and we should expect it soon but as not everyone uses the latest and greatest, this will hopefully still serve a purpose.

3 Likes
9

@kyleobley…would you be okay if I combined the 2 posts?

10

Your call, I’m fine with that. I sort of thought as they’re Python scripts they belong in that category but I completely understand that this is a solution to an issue brought up in a previous thread. I’m easy so whatever you think is best.

11

@kyleobley this is BEAUTIFUL.

12

I don’t know how I’ve dodged this bullet up til now, but these scripts just saved me from an immense amount of troubleshooting and fruitless explanation. So easy to implement on a Mac. Thank you @kyleobley, and everyone on this and the other thread for the brilliant sleuthing. :clap: :pray:

2 Likes
13

@kyleobley this is so amazing. Thanks for all you do and as a small gesture of appreciation please accept this promotion to 16bit member.

1 Like
14

Thanks for that. I’m just happy it’s helpful to some and getting people out of jams.

1 Like
15

btw I cant get it to run on CentOS 7.7 and 7.8 either (AMCDX that is) not allowed to run 7.6 or older due to security issues. the GLIBCXX_3.4.22 is needed which none of those provide , I dont think thats included in 7.6 either , I asked the maker if he could compile it with the older GLIB that we have in centos…

using centOS feels like using windows XP… ffs .

16

Thanks for reporting back. I can modify the code if needed for the remote exemption. Right now it checks if it’s OS/X or if CentOS is above 7.4. If either are met, then it’ll run locally. If not, then it’ll run remote.

I can’t recall who, but someone reported it worked fine on 7.6 hence the cut-off.

I’ve also wrapped everything into a .app where you can drag files from the finder onto that. You can download that here. You’ll need to have AMCDX installed and nclc.py saved in /usr/local/bin.

1 Like
17

cool, yea I didnt even try your tool on centos as I know I cant even get AMCDX to work at all , I am working on getting this automatically done by ftrack/pipeline but ive got 7.6 at home and will try that later as well.

18

Ah, got it.

In the previous thread someone had an example of how to change the tags directly via Python without any other application but it didn’t include the gamma tag which is needed. If someone could figure that bit out then it’d be a straight Python which would be great.

19

Yea totally I think that was henrik proosas doing in the nuke forum IIRC , there also is the BBC tool which has the same limitation

20

I just had a quick look at file specs for Quicktimes and came across this:

The 'colr' extension supersedes the previously defined 'gama' Image Description extension. Writers of QuickTime files should never write both into an Image Description, and readers of QuickTime files should ignore 'gama' if 'colr' is present.

I guess that means that what we’re doing here is something we shouldn’t be doing…yet it seems to be the only way at the moment to get a rec709 QT to display properly on a Mac.