Jump to content


Photo

Problem With Alexav3logc Macro / White Clip After Returning To Log-c


  • Please log in to reply
20 replies to this topic

#1 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 11:24 AM

Hi there,

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)

http://s26.postimg.o...7j4aux/clip.jpg

Thanks
Holger

#2 xmare

xmare

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 723 posts

Posted 27 February 2014 - 11:31 AM

If it's a macro You can edit the .setting file, change "macro operator" into "group operator" in the headline (or sth like that) using notepad (or sth like that)...
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 ;)

#3 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 27 February 2014 - 11:37 AM

Do you have Fusion 6.4? It has native logC support in its logarithmic conversion tool.

#4 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 11:48 AM

Yes, I have fusion 6.4, but the conversion with the gamut tool to BT.709 was so different to what we had seen in the rushes which where converted to BT.709 by Arri, that it simply seemed wrong.


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.

#5 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 11:55 AM

Below the line my problem is, that I have finalized EXR 32bit sequences that I have to convert to DPX 10bit Log-C which would be suitable for the grading suite.

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).

#6 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 27 February 2014 - 01:46 PM

I've recently set up a color workflow for an Alexa logC project, so I hope this helps:

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.

#7 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 02:04 PM

Thanks, Tilt, At the moment, it looks like this:

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)

Thanks

#8 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 27 February 2014 - 04:24 PM

Your end result looks very much like a logC image, except for the clipped highlights. That would be the correct format to write to a DPX. In the Saver, you have to bypass the lin-to-log conversion though (because the image already is logarithmic).
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.

#9 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 04:49 PM

Hi
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.

Thanks again.

#10 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 05:29 PM

Interesting,
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.

#11 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 05:34 PM

Nope, same effect with 32 bit exrs.

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.

#12 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 27 February 2014 - 05:55 PM

If you have used ARRI's LUT you get a soft rolloff of the superwhites to fit everything into the 0 to 1 range. That's what I meant with "one way street".

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).

#13 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 06:02 PM

Yes, tested exactly like you said (cineonlog,gamut,gamut, cineonlog),

clipped highlights in float 32 bit flow

#14 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 06:10 PM

Ok I think I found something: When I go into the first cineonlog after the loader of the Log-C-mov, and change the bitdepth from keep to 32bit float, i get the highlights back.

shit, that means I have to rerender all the comps.

#15 holgerneuhaeuser

holgerneuhaeuser

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 101 posts

Posted 27 February 2014 - 06:15 PM

Last question: DPX Output as 10bit / logtype bypass/ data is linear checked.

or

10bit/ arrilogC ?




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users