Just to check Mr. Boyle, the ARRI LUTs includes the video to full conversion?
This is because LogC in signals are Video Legal only and IDT expect full?
So, if you are working with regular IDTs inside Resolve or another system, all Alexa clips must be interpreted as Video Data Levels? (to perform the right contrast expansion, since IDT is Full but LogC uses just legal range)
Other IDTs expects full range and to define Full Data Levels is the correct way (and inside the LUT the fix was not necessary)
Thanks for help me to understand better.
@ediwalger, you make an important point about being aware of the differences in range scaling between different log signals over SDI and e.g in Resolve.
@cmlgeoff will have to answer as to what he has done with the latest round of LUTs, but I can confirm that when I made the set of LUTs linked in the first post on this thread I took account of the differences in data range of the various log formats “on the wire”. And as described in the first post, the LUTs are each created in two versions, one (EE) for LUT devices which perform a legal to full scale before applying the LUT and a full to legal scale afterwards, and another (LL) for LUT devices which apply the LUT directly to the unscaled incoming SDI code values and also send the LUT output unscaled to their SDI output. And the table I posted shows which version should be used in various LUT boxes.
Your review of LUT Hardware is very welcomed, thank you again! Do you confirm that the Prores clips made from ARRI cameras all are video range? (And must be interpreted as video data levels in resolve and in other sytems too). Is this the only exception about Log, and the rest of manufacturers writes full range in each propietary Log encodings? Thanks in advance Nick Shaw.
Sadly it’s not that simple!
ProRes recordings from ARRI, RED and Blackmagic cameras all map their log curves to “video” range, as do their SDI outputs. This means they need to be interpreted as “Video” in Resolve. Many other systems include a “hidden” legal to full scale in their ProRes decodes, so you need to verify the behaviour. Baselight’s handling of ProRes has varied with different versions. Currently Baselight 5.2 decodes ProRes to legal range (un-scaled normalised code values) but adds a legal to full scaler to the input layer, which you have the option to switch off.
Canon, Panasonic and Sony cameras scale their baked video recordings to “video” range, but do not scale their log recordings.
Thus to get a match in Resolve between a ProRes recording from an ARRI, Blackmagic or RED camera and a Raw recording you can leave the Clip Attributes set to the default Auto, which for ProRes is “Video”. For Canon, Panasonic and Sony ProRes recordings, the Clip Attributes need to be set to “Full” to match a Raw recording with log ProRes, but should be left on “Auto” or “Video” for a baked video recording.
Thanks for clarify! Very useful information again.
This behavior today is the same if the camera records in another video codec like DNxHR? I know that the best is to test, but maybe you have an answer to that…
As you say, best to test.
I do not know about DNxHR, but I believe DNxHD is internally a Y’CbCr codec like ProRes, and therefore inherently “legal range”. So its behaviour is generally similar to that of ProRes. However, like ProRes there may be hidden range scales in an application, and these will be set to behave in whatever way the developers thought would be “most intuitive for users”. This may well not be the same for DNxHD as ProRes, as ProRes is native to QuickTime, which has always applied a hidden scale, whereas DNxHD is native to Avid, which historically has not.
Nuke, for example, applies a hidden legal to full scale when decoding ProRes, which cannot be bypassed. With DNxHD there is a “Source Range” drop-down, although some consider that behaves in a counterintuitive manner.
Hi. i have a question.
Can I use this LUT,S in camera?, I am working on a RED Scarlet- W
Uno, thanks for your first post!
Steve T
ACES Adoption Lead
Thanks.
I hope you can help me here
I has been searching around Scarlet W camera.
I notice that I can turn on ACES PROXY on the image pipeline menu of the camera.
it is this the right way to see what is going to happen when I take the footage to editing room?.
I made a test, but footage doesn´t look exactly the same as I see it on camera´s monitor.
It. looks close, but in camera it looks a little less saturated.
I am seeing the image in my computer through a DeckLink mini monitor 4K card, my monitor it is an EIZO which has its own calibration pipe so I asume it is calibrated, I set it to gamma: Rec 709, and colors Gamma to 709 too.
it is normal? I will never see the exact color or luminance in both devices?
i am goin to color grade a project and we expect it will make its course to a theatrical presentation, should I set my ACES ODT and Monitor to P3 DCI instead of REC 709?.
I hope my doubts have been clear.
Thanks in advance
ACESproxy is not intended as a direct preview of ACES output. It is an integer version of ACEScc, intended so that the same ASC CDL grade applied to it can be matched when applied to ACEScc. But it still needs an ACES Output Transform applied downstream of that.
I’m afraid I don’t know whether this is possible internally in a Scarlet W, or how you would set it up if it is, but what you need to do is turn off all IPP2 processing, so the camera is producing a Log3G10 / RED Wide Gamut signal, and then apply the appropriate LUT from the ACES set linked in the first post here.
ok, thanks for your answer. One last thin please.
scarlet - W doesn’t have ipp2 in camera, so, as you say I produce Log3g10/ RED WideGamut Signal, my question it is, where do I apply The Lut? in a external monitor? or do I have to convert this LUT to 16x16 somehow and try to put in camera via “look LUT”?
Whichever you want. You might prefer to apply it in-camera if possible, because then you will see the same look on the EVF/LCD and external monitoring. Or you may prefer to apply it in a monitor or external LUT box, so you can easily toggle it on and off to check the exposure on the log signal.
Hi Geoff,
I’m assuming for the BMD Lut you are using Blackmagic Film as the IDT?
I was also wondering if another Lut needs to be generated for each base ISO if the camera has Dual native ISO.
Thanks
Yes, BMD film is the base. ISO variations differ from camera to camera, some work with the “standard” LUT others need something else.
What a wonderful world of standards
Thank you for all this information. I am eager to try these LUTs.
Hey @nick , im shooting XOCN ST, and running ACEScct in resolve. Are you suggesting using Full levels in resolve? Instead of video? Im using full in legal out in livegrade.
You need to use LiveGrade like that because S-Log3 is full range on the SDI output of the camera. In Resolve, XOCN is (I believe) decoded directly to ACES, so input range is not relevant. You should see no effect if you change the clip attributes between Video and Full.
Correct, i see no. difference in the clip attributes toggling. Only on the video monitoring out option does it change.
The correct setting for video monitoring is related what your monitor is expecting, and is unrelated to the source. If your monitor expects Video levels (most do by default) then Resolve’s SDI output should be set to Video.