Odyssey firmware 2016.06

I have discovered that Apple Compressor can read super-whites in a ProRes4444 movie. You can process files through that, with a Brightness And Contrast effect applied to do a full to legal scale. The values needed are approximately Brightness = +4.5, Contrast = -63. These are rough values found experimentally (the exact maths of Compressor's Brightness And Contrast filter is not published) but they should bring the super-whites down so that rendering a new ProRes4444 file like this will give a close match in Resolve to the results from a DPX.
 
Last edited:
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.

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 believe this is a metadata/tag thing. I believe Sound devices were able to solve it in their recorders.
 
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.
No. As I said, a lot of software clamps ProRes4444. Not just Resolve.

Have you tried Compressor?

I believe this is a metadata/tag thing. I believe Sound devices were able to solve it in their recorders.
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.
 
No other software (Premiere, FCP, AE, Scratch, Vegas) that I've tried can recover the data.
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.

This all goes to support my opinion that Sony's (and Canon's) decision to continue to use the range above 100% is a risky one. It is so easily clamped in many workflows. ARRI chose to limit themselves to the 0-100% range, "wasting code values" in the process, for exactly this reason. I personally agree with their decision.

Media Composer can also see up to 109% in ProRes4444.
 
Last edited:
Nick, your technique in Apple compressor worked great. Now the waveform on my Flanders actually matches Resolve's software scopes- before the conversion my grading monitor would show data up to 109% that wasn't there and clipped. I'll be recording ProRes decisively infrequently from now on but good to have this in my back pocket when I need it.
 
I know it's a pain to lose that top end of the highlights, but it's only the brightest of brightest highlights that you're losing, and they're from the most heavily compressed part of the gamma curve. So it's really not a hell of a lot you're giving up with them.

Card transfer speeds, and the speed of the drives we're backing up to, have just forced us off shooting uncompressed on this feature I'm currently shooting. We literally couldn't get the data backed up quickly enough - even with enough SSDs for two-days of full shooting on two cameras, and plenty of storage space for the uncompressed footage. It's the time required to push all that data around that's bit us in the arse, so it's back down to ProResXQ for the rest of the shoot.

I had moved back to 2016.01 to facilitate 50p in ProResHQ, but we're shooting so little high speed, that I've decided to go back to 2016.06 for the greater stability, and will just use .dpx for highspeed stuff (and transcode it to ProResXQ afterwards).
 
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.
 
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!

There's more than 1/4 stop up there.
 
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.

You could in theory edit the SLog curve on the Sony editor so that it doesn't go over 100IRE...
 
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?
They are clipped by the method Resolve (and most other apps) use to decode the file. So no, nothing can recover it after that.
 
Bugger. Though I did notice that on that table (which is SUPER helpful by the way, so thanks!), that it says the values were derived from the manufacturers ACES IDTs. To date our little F35 community has been totally unable to get hold of the formal SLOG1 ACES IDT, do you still have access to it Nick? And if so, could you upload it for us please?

Cheers,

Mark
 
Back
Top