Problem With Alexav3logc Macro / White Clip After Returning To Log-c
Posted 27 February 2014 - 11:24 AM
need some help please.
I have a loader with an original prores Alexa file. First I convert the image to BT.709 with the AlexaV3Logc Macro.
Now I apply the AlexV3LogC Macro again an revert the image back to Logc. (I took out any imagemanipulation inbetween to see whats the problem between the conversions)
Result: All looks like before the conversion, as it should, except the highlights. The superwhite glints on a car in the image are clipped.
What can I do to avoid this?? Or how to workaround ?
(Flow is 32 bit float)
(Please have a look at the image , left as it should be, right clipped)
Posted 27 February 2014 - 11:31 AM
then import it - then You should have a group - and You can see by Yourself which node is doing what ... if it's a macro
Posted 27 February 2014 - 11:37 AM
Posted 27 February 2014 - 11:48 AM
The AlexaV3LogC Macro was very very close to what we had seen all the time, so we decided to go with the macro for conversion, and so we didn´t use the gamut tool.
Basically we would be completely screwed if we had to rework all our comps with the gamut tool, so I need something to work around that problem.
Posted 27 February 2014 - 11:55 AM
Any idea how to do that properly. All my attempts with the various dpx options lead to more or less slightly different results compared to the original log-c videoclips (the unaltered footage).
Posted 27 February 2014 - 01:46 PM
logC dpx files that are converted to rec709 by a grading suite or by ARRI (or via mov) don't just have a log-to-lin conversion. They are done by applying ARRI's 3D LUT that you can download from their site. It does three things: logC to linear, gamut conversion from Alexa wide gamut to sRGB gamut and then apply a curve that's part gamma-correction and part soft shoulder for the highlights. You can't rebuild all steps yourself so if a client wants rec709 you need to apply ARRI's 3D LUT. Since it requires a logC input you need to convert your linear EXRs to logC first which can be done using Fusion's CineonLog tool.
Do you have linear EXRs or do they have sRGB or rec709 gamma baked in? That's important to know before I tell you about things that don't apply in your situation.
edit: on our project we deliver dpx and since we get dpx in the beginning it's easy to compare our results to the source plates.
Posted 27 February 2014 - 02:04 PM
If I save my exr sequences to dpx cineon, I get the same look back that I had in my exrs . So far so good, except that they are not logC. Basically this could be a working solution, cause we pregraded the comps with the DoP. So we are basically were we want to be.
I´m just trying to understand, why I can´t reconvert properly to log-c. I tried the arri Lut generator already and got a lut that worked pretty much exactly like the AlexaV3LogC Macro that we were using for comping on the incoming side.
But I couldn´t generate a proper lut back to Log-c. All attempts that I tried with the arri lut generator were to saturated, although no clipping in the whites.
My exrs are linear. At least I think so, cause if I open them in pd Player or after effects I have to apply srgb to view them correctly.
All of my clients in the last years wanted 10 bit dnxhd 185 files or 32 bit tifs, so I never had to care about reaplying logs. (Just to excuse my tumbling around with this issue)
Posted 27 February 2014 - 04:24 PM
The question is, why are the highlights clipped. And I can only imagine that this is due to some bit depth issue. Even if the flow is float, the mov Loader will certainly be 8 or 16 bit integer by default which will clip highlights if you've used the macro.
The macro is not that important anymore with Fusion 6.4. If you want to recreate its inner workings, try a CineonLog tool (logC -> linear) followed by a Gamut tool (target BT.709 + add gamma). You can do the same steps in reverse, and if you're in float16 or float32 there can't be any clipping.
Even those two tools in combination won't give you exactly the result that ARRI did using their 3D LUT. Their LUT is a one-way street. You can't invert it and it's not possible to rebuild it with any combination of grading tools.
Did you pre-grade the mov on the left side of your screenshot directly? As in: without gamut and log-to-lin conversion? That would be wrong.
Posted 27 February 2014 - 04:49 PM
and thanks a lot for the Infos, makes sense now.
No I didn´t grade directly into the log-c mov. I first converted it with the AlexaV3LogC Macro to BT.709. Which looks nearly exactly like using the Lut I generated on Arri´s website with fusions lut loader. So I think thats correct.
There seems to be a problem in the math that the macro does when converting back to log-c. But its just the clipping of the highlights. (I deconstructed the macro, and shuted the tools down one by one. The error comes with an expression tool, that does a lot of complicated math.
To much math for me...
Good to know that the Arri Luts are a one way street, that makes tracking down the problem a bit easier.
I´ll try your conversion tips using on board tools.
Posted 27 February 2014 - 05:29 PM
I did as you proposed:
Coming from my 16bit float EXRs (sorry I mentioned before they were 32bit, which is not the case), I added a gamut tool (source space Arri ITU BT709 / remove gamma checked) an then a cineonlogtool (Mode lin to log / Logtype Arri LogC / Version 3)
The result looks exactly like the original LogC-mov but: the highlights get clipped exactly the same amount like in the AlexaV3LogC Macro.
So in other words: the workflow you proposed to convert back to LogC results in the same image like the Macro with clipped superwhites.
I have no other idea at the moment than saving a sequence as exr 32 bit istead of 16 but to see if that might change anything in the end.
Posted 27 February 2014 - 05:34 PM
It looks like arri does some manipulation with the rolloff in the whites that can not be recreated in tne conversion back to log C in fusion.
Posted 27 February 2014 - 05:55 PM
But you haven't created your exrs by applying the LUT, have you? Do they have super white values? If they got clipped somewhere, it doesn't matter how many bits they have.
Can you try this process with your original movs?
Loader (mov and bit depth set to float) -> CineonLog (logC to linear) -> Gamut with target BT.709 (ARRI, scene or display-referred shouldn't matter) and add gamma -> Gamut with source BT.709 and remove gamma -> CineonLog (linear to logC).
Posted 27 February 2014 - 06:02 PM
clipped highlights in float 32 bit flow
Posted 27 February 2014 - 06:10 PM
shit, that means I have to rerender all the comps.
Posted 27 February 2014 - 06:15 PM
10bit/ arrilogC ?
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users