Hi Logik pros,
Watching through the ACES Made Easy videos from Randy on logikacademypro.com I thought I had a good grasp on dealing with tagging. But I was just tossed some files that I was told was shot “Panaviaion DXL2 Log3G10 R3D” and given a .cube show lut along with a reference. But everything is coming in crushed when I tag it upon import as - camera/ RED/ Log3G10 / REDWideGamutRGB. It looks much closer to the reference when I tag it as Scene-linear / REDWideGamutRGB. Then when I apply the .cube file the whole shot gets crushed again. Curious if any pros out there could take a look at the files to see if things are just whacky on my end or if the info I have is just not jiving. Much appreciated in advance.
Cheers,
-Chris
A few thoughts -
When someone tells you a file ‘XYZ’ always take it with a grain of salt. People get this information wrong a lot. Also, was it the camera original file, or did someone transcode it? What happened to the file since it left the camera?
Regarding the .cube file - important to understand that LUTs are color space specific. They need to be applied to footage that is in the same color space was in when the LUT was created. Apply it in the wrong place of the chain, and things will get wonky.
Lastly, some people (IMHO wrongly) bake the camera color space transform into the show LUT. A show LUT should be based on the scene color space, not the camera color space. Otherwise you risk a double transform and cannot separate the two for proper color management.
Sounds like your LUT file has the camera transform baked in.
So I would ask the person to double check the statement. As your experiment shows it most likely was incorrect information and the files are in scene linear.
Regarding your show LUT, you could ask them and see if the can provide a new one? Probably won’t.
The fix maybe - tag your footage as unknown. Insert a ColourTransform that goes from SceneLinear to 3Log10 (gamma only, no change to color primaries). Then apply your .cube file and it likely will look as expected. Though might find more bodies buried there.
2 Likes
Do you know how the LUT was made?
Quite often a LUT will allow for the colour transform within it so could be doing the colour transform twice.
What file type is the camera source? Is it a RAW camera file, as in r3d? Or has it been transcoded to something like an exr? r3d will be debayered into what ever colour space you tell it to. So if you are debayering within flame you will have to check in the colour format settings what colour space you are debayering into. Once again, if someone else has done that step, they need to tell you what they have done. You could also check in the metadata of the file but I’ve seen places tag things wrong too.
I get what you are saying here and mostly agree. However, if you do not know the colour science intended to finish the project in, just as people often don’t know what colour space things were shot in, then it isn’t quite so easy. On a lot of features, the vendor whom is processing the rushes could be different to the vendor doing post production who is different again to the vendor/s doing visual effects. If the process is ACES then you’d take a different approach than someone self managing colour science or even using RCM. Sometime camera department might want alf4 files back or something different which you also need to allow for.
Unfortunately, there isn’t a one solution fits all process so often we find we are juggling a solution that makes it easiest for production which may not make it as easy for post. However, if you have someone onto it that knows what they are doing then it makes all the difference.
Unfortunately, I think you need to “shoot the messenger.”
Am I out of the loop here? But this doesn’t make sense to me.
“Panaviaion DXL2 Log3G10 R3D”
Isn’t this like saying it was shot in Alexa Red Sony space? As in? Verbal contradictions?
EDIT: I am out of the loop. Panavision DXL2 does have a Red sensor. So don’t shoot the messenger , but definitely clarify some things. Check to see if you were working on the original camera negative. If you aren’t, and someone transcodes it, then you need to understand that process as well. In the meantime, you can tag it with whatever looks good to you and look do your work and worry about any kind of rendering or output for editorial and/or WIPs that include the show/cube lut later.
2 Likes
@ad
That is totally fair. Reality is often more complex.
One way to address this is to make your show LUT as CDL rather than LUT. That is mostly color space independent and still captures the key elements of the intended color treatment. Rarely is the show LUT the last word in color, is it?
It’s meant as a temporary stand-in to judge color direction, not final grade. Though just as people ship log footage as final, my guess is show LUTs may have found their ways into deliverables as well.
CDL support is a lot more common these days.
Allklier, Adam, Randy all the info is much appreciated – thank you so much!
For context this is for episodic television, a couple of seasons in, and I’m walking into a pre-established workflow receiving files matching the way things are distributed to other facilities and the finishing house. Working with 3840x2160 EXR files transcoded from the camera originals. I’ll reach out to them today to better understand the transcode process.
Generally with episodics in the past I could apply the “show lut” and then the clip specific cdl, and if the resulting image in rec709 matches the reference then I’m off to the races. But this time I’m tripping over my own feet.
Here’s some of the info found when looking at the metadata:
OpenEXR 3.1.11
Under “Attributes”
3d_lut – BASE_LUT.cube
(I think maybe this means the “show lut” has already been applied in the dailies process??? … something I’ll ask when I reach out for more info).
CameraFormat – RED
Codec – REDcode 8:1
ColorSpace – ImageColorREDWideGamutRGB
GammaCurve – ImageGammaLog3G10
ResultColorSpace – REDWideGamutRGB_Linear
Camera_model – Panavision DXL
Sensor_name – MONSTRO 8K VV
I’ll tag it however looks best for now to get some work done while awaiting some more info … thank you for that tidbit Randy that helps a lot.
Allklier at risk of sounding completely green could I ask how best to go from SceneLinear to 3Log10 gamma only with no change to the primaries? I add a color management node. For mode I have it set to “color transform” and then I’m getting a little lost on the next step.
Thank you again for all of the information!!
I’ll report back when I hear back from the facilities.
Sorry to send you off on a wild goose chase there…
When I wrote this I was thinking a bit more about the CST effect as it exists in Resolve, where you can just pick source and destination for gamma and gamut spearately.
In Flame the configuration is a bit more complicated, but the one worth trying would be this one (inside ColourMgmt node):
This would in fact affect both gamma and color primaries, but essentially invert what likely was applied in the transcode, and then you could try the show LUT on top of that (you might even be add it as another layer right underneath).
This is a bit of a shot in the dark, as we don’t have enough data. But it’s a quick test worth trying.
PS: In your follow-up you posted that these are EXR files. That may come into play here, as EXR files are always in linear gamma. So ‘linear’ behavior may actually not have been their LUT, but just the fact that the EXR render will linearize the gamma.
1 Like
Thank you Jan!
And thanks on the EXR linear info - that makes a lot of sense.
-Cheers
Your exr files could be in any colour space. They could even be log. @allklier is correct that they should be in linear (as using log in exr format is destructive due to log rounding issues) but it could be any flavour. They may have given you ACES 2065-1 or ACEScg or RWG/Scene Linear or even AWG/Scene-linear if they had used Alexa previously.
The workflow in VFX may include a transform into a different colour space prior to applying any CDL or LUT. This is actually a fairly common way of working.
I’m sure whoever is doing the pulls to exr will have some kind of workflow document they are willing (probably expected) to share which should outline the colour workflow.
1 Like
CDLs are more often used for colour balancing on a shot by shot basis whilst the LUT is used to give the overall show look to rushes/dailies. Then in VFX you need to provide editorial media back to editorial that matches the previous dailies. Essentially the VFX shot needs a version that matches the plate but then a version without any CDL or LUT bake should go back to DI in the expected colour space which will usually same as supplied (in this case, whatever the exr is).
If we’re getting right into it, for vfx you will likely have count sheets that include CDL SOP values and which LUT was used. You may get a separate CDL or an edl with CDL SOP values embedded.
As above, colour workflows can vary greatly so you can never guess. There usually will be a colour workflow document of some kind created that should cover the processes of the show.
2 Likes
@AdamArcher is right.
The peculiar thing about the subject ask is that the origination is a Panavision device.
It’s unusual that such a unit would be part of an undefined, uncontrolled workflow.
It’s unusual but it does happen!
A part of my role is creating colour workflows and documentation and I have to say that there are plenty of vendors who need to be talked through it and the order of operations so there is no reason to feel like you’re the only one not getting something. If anything it shows professionalism asking to be talked through the colour workflow on a project.
The workflow can differ quite a lot depending on how the DOP, DIT/Dailies vendor, editorial, DI facility and Colourist want to work. It’s rarely a copy & paste workflow.
1 Like
@AdamArcher - I’m not disputing that it’s a good idea to ask your peers for help and information, god knows there are only 11 people on the planet using flame, and we’ll be extinct by next February…
It’s unusual that a Panavision unit is contributing to an undocumented workflow, and that @Ketchikan_Chris is having to ask for help.
If it had been a Red MOnstro out in the wild - well there are plenty of those and privateers do what they want all the time.
Panavision activity is usually bonded, which requires auditing before, during and after shooting.
2 Likes
Thank you all - here’s the latest update,
Reached out to dailies company and got this info:
No LUT is baked into the EXR frames but they are linearized for placement into EXR float as Linear/REDWideGamutRGB. So it would be correct to read them as linear but all dailies color operations such as creating review quicktimes would be applied in the typical Log3G10/REDWideGamutRGB space.
After a couple more querries I received this follow up:
I’ll defer to the finishing facility for delivery specs but if they are requesting EXR frames I would leave them in linear space as Linear/RedWideGamutRGB. If they instead request DPX that would be Log3G10/RedWideGamutRGB.
For the review quicktimes here is a quick breakdown on the color pipeline:
Plate → Linear to Log3G10 → CDL → ZEUS.cube
Thank you Jan for the scene-linear to Log3G10 transform diagram. When I followed the pipeline things ended up being really close. Colors seem correct but the end result is a bit darker than the reference. Thinking maybe they just brightened the shot in editorial before sending the reference. 
I completed a shot and exported EXR files, then confirmed the finals match the original, so I think I’m good on that front.
Next step is to send reference review files to the client and a round-robin test to the finishing house to make sure everything is copacetic.
Thank you so much … when short on information and time - this forum is absolutely invaluable! Thank you
6 Likes
The other thing to check in terms of your transforms matching the reference is is your reference at full/data levels or Legal/video levels. That may cause it to be darker if you’re reading the reference file as legal when it is full then comparing the two.
2 Likes