Well, there we have it. So, in this case- will a soft clip LUT do the trick? http://www.xdcam-user.com/2014/03/are-you-screwing-up-your-footage-in-resolve/
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
No. A soft clip LUT will only provide a smooth roll-off into clipping for image data which is not already clipped. Since ProRes4444 gets clipped by Resolve when decoded, the super-whites are irrecoverably gone at that point. No LUT will bring them back.Well, there we have it. So, in this case- will a soft clip LUT do the trick? http://www.xdcam-user.com/2014/03/are-you-screwing-up-your-footage-in-resolve/
The issue is with Resolve, not the Odyssey. The Odyssey records everything right up to 109% (and down to -7%) but when Resolve decodes ProRes4444 (and XQ) it clamps at 100%. Resolve also adds extra confusion by treating the clip ranges of ProRes4444 differently to other ProRes variants. With "data" selected it maps the 0 to 100% to it's internal 0-1 range. For other ProRes formats "data" maps -7 to 109% to 0-1.
It is a problem with ProRes4444. Many applications "assume" ProRes444 contains only RGB data in the 0 to 100% range, and clamps to that. Adobe applications also do so. You can see the entire range of the data in a ProRes4444 file if you open it in ScopeBox, for example. Nuke can also read it, although not with the default Read node settings (you need to choose the mov32 decoder and a YCbCr pixel format). Baselight can also do so.
No. As I said, a lot of software clamps ProRes4444. Not just Resolve.Not sure if this issue is just a Resolve issue.
No other software (Premiere, FCP, AE, Scratch, Vegas) that I've tried can recover the data.
I don't know what Sound Devices have done, but it can't be altered by simply changing metadata. It would be necessary to scale the image data to the 0-100% range before writing the ProRes. Convergent Design could consider adding this option to the Odyssey, but it would open up the possibility of people using it in other situations where it would not be appropriate. Currently CD have made the choice of writing unmodified image data to files at all times. Of course when they introduce the option of baking in LUTs to recordings, it will be possible to implement the scaling as a LUT.I believe this is a metadata/tag thing. I believe Sound devices were able to solve it in their recorders.
Premiere and AE clamp, but in my testing FCP (7 and X) can see ProRes4444 image data up to 109%. You can see it on the waveform. Be aware that some filters may clamp to 100%, so you may think you can not bring it into range.No other software (Premiere, FCP, AE, Scratch, Vegas) that I've tried can recover the data.
I'd agree its such an minor visual thing- in the long run for your feature you have to compromise somewhere. I will say for my most recent commercial spot it was definitely satisfying bringing back some specular highlights like car headlights and such- as compressed as it is there's just a nicer roll-off after making the adjustments that Nick Shaw mentioned in Apple Compressor. Will anyone but me notice? No. Do I sleep better at night knowing I got an extra 1/4 stop in the highlights? No. Will I record uncompressed next time? YES!
is it possible to fix this in camera as part of the SDI output. I know hyper gamma can reduce the white range. Is there a setting to bring the camera within 100% while still outputting SLOG.
Indeed there is. In S-Log1, from 100% to 109% is about 0.7 stops. See this table for details.There's more than 1/4 stop up there.
Indeed there is. In S-Log1, from 100% to 109% is about 0.7 stops. See this table for details.
They are clipped by the method Resolve (and most other apps) use to decode the file. So no, nothing can recover it after that.Could setting an input LUT save those highlights before Resolve clips them off? Or are they simply gone with Resolve's processing no matter what you do?
https://github.com/ampas/aces-dev/b...lied/sony/IDT.Sony.SLog1_SGamut_10i.a1.v1.ctlThe SLOG 1 IDT is on the AMPAS github page we've had it for years.