What's new

Resolve v9.1 clipping

Gray Marshall

Gray Marshall





Above is a short "rant" on where I found Resolve v9.1 likes to clip.

I have to apologize that I sound like I drank 3 cups of espresso and am being chased by a rabid badger. I'll try to slow it down for the next one.

This was done using YRGB/Rec709 settings in Resolve 9.1, not ACES.
My GPU is a GTX580 3GB, modified by MacVidCards for Mac OSX 10 (10.8.2 in my particular case)
My GUI card is the GT640 2GB

Paul has pointed out that he wasn't able to replicate the same effect (except in ACES), so I'm inclined to think that it might be hardware config specific. He also notes that the LUT application in any individual node comes as the last step, so you CAN pregrade before the LUT in the same node. Noted, Paul & thanks.

Run your own tests & find if your system clips in the same way.
If your experience is different, please comment below. I'd really like to know.
 
I'm seeing the clipping, too, in both Resolve 9.1.0171, and in 9.1.1.013 on 10.8.2 using a GT640 and GTX690.

When I first ran through the test, I used a 10 bit gradient I had rendered out in Final Cut, and didn't see the issue. I was kind of relieved, but then I tried some Alexa footage, and the clipping appeared. And, Gray's right.... any adjustment, no matter how small puts it way out of whack.

So, I created a new gradient in After Effects using 32bpc rendered out to Pro Res 4444 at the highest settings, and clipping appears with that now, too.

Here is the gradient file I used: Gradient-PR4444.mov.zip
(13.3MB un-zipped)

One thing that's similar between our machines is that we are both running the GT640 on 10.8.2, so it would be interesting to see the results on different hardware. If you're on Windows, you'll probably need to test with RED or Alexa footage, or render out the gradient as DPX. I'm not sure if even DNxHD 444 would work as it's still only 10 bit.

AE project to render out a gradient: Gradient 32bpc.aep.zip
Resolve 9 Gradient Test: Gradient Clipping Test.drp.zip

Here are my results....

Resolve-Clipping.jpg


Larger Screenshots:
Resolve Clipping Issue Pt1.zip
Resolve Clipping Issue Pt2.zip
 

Attachments

  • Gradient-PR4444.mov.zip
    96.2 KB · Views: 12
  • Gradient 32bpc.aep.zip
    3.8 KB · Views: 2
  • Resolve Clipping Issue Pt1.zip
    431.8 KB · Views: 2
  • Resolve Clipping Issue Pt2.zip
    291.3 KB · Views: 2
  • Gradient Clipping Test.drp.zip
    23.6 KB · Views: 2
I've now tested (briefly, due to good questions) live test footage of R3D and Alexa LogC ProRes4444, as well as the linear ramp in a DPX format. All gave me the now expected clipping.

Oh, yeah, I'm running Resolve 9.1.1.013
 
Gray Marshall said:
Above is a short "rant" on where I found Resolve v9.1 likes to clip.

I have to apologize that I sound like I drank 3 cups of espresso and am being chased by a rabid badger. I'll try to slow it down for the next one.

This was done using YRGB/Rec709 settings in Resolve 9.1, not ACES.
My GPU is a GTX580 3GB, modified by MacVidCards for Mac OSX 10 (10.8.2 in my particular case)
My GUI card is the GT640 2GB

Paul has pointed out that he wasn't able to replicate the same effect (except in ACES), so I'm inclined to think that it might be hardware config specific. He also notes that the LUT application in any individual node comes as the last step, so you CAN pregrade before the LUT in the same node. Noted, Paul & thanks.

Run your own tests & find if your system clips in the same way.
If your experience is different, please comment below. I'd really like to know.
Click to expand...

Only the Hue-curves work like this, and it has always been like this. All other tools should not clip, unless you are intentionally trying to clip using Soft Clip.

Regards,
Rohit
 
After a conservation with Juan and Gray tonight I think I have a better idea of what's going on. Resolve processes in 32-bit float, but some of the tools are more limited, and that's what's causing the clipping. It also seems to be exacerbated a bit by Gray's test, which stretches the luma before and after the test node causing the clipping to become more pronouced. The tools in Resolve seem to process data like this....

32-Bit Float:
LOG Controls
Lift/Gamma/Gain
Custom Curves
Qualifiers

Not 32-Bit Float:
Hue vs Hue
Hue vs Sat
Hue vs Lum
Lum vs Sat
Soft Clip

The curves (with the exception of Custom Curves) each operate a lot like a variable LUT, taking inputs (Hue, Sat, Lum) from any changes you make and applying them to the signal. LUTs by design are meant to shape a signal, and therefore cannot operate with floating point accuracy. They work at something less, possibly 16 or 12-bit integer. Still very good, just not floating point. This is also why applying a LUT to the test node creates a similar result, because whether it's a Hue/Sat/Luma Curve or an actual LUT, they both process the signal in a similar fashion.

What Gray's test seems to have demonstrated is that when these non-FP tools are activated, they are inserted into the signal path, and even before any adjustments are applied, their very presence changes the range within which the signal is processed. By stretching the contrast before and after the test node, the clipping caused by this becomes even more apparent.

This also brought up a lot of discussion about order-of-operations, and how by using the 32-bit float tools early in your signal path, you allow the non-floating point tools to perform better by keeping them within a safe operating range that avoids clipping. If I remember correctly, something like this should work well....

LOG Controls -> Camera LUT -> Lift/Gamma/Gain -> Custom Curves -> Hue/Sat/Lum Curves -> Soft Clip

Anyway, this processing difference between controls is also what a lot of people are seeing with the Resolve ACES workflow. The controls that do not behave correctly in ACES (Hue/Sat/Lum Curves, Soft Clip) seem to be incapable of the math required by the ACES color pipeline, and will probably need to be completely re-written in order work correctly.
 
Jason Myres said:
The curves (with the exception of Custom Curves) each operate a lot like a variable LUT, taking inputs (Hue, Sat, Lum) from any changes you make and applying them to the signal. LUTs by design are meant to shape a signal, and therefore cannot operate with floating point accuracy. They work at something less, possibly 16 or 12-bit integer. Still very good, just not floating point.
Click to expand...


One small point of clarification.

I believe the processing and result is still 32-bit float. It's just that those functions, due to the way they operate (inherently in the case of the soft clips), do not pass over and under information. The content in the visible spectrum, the defined range is still treated in 32-bit float, but the brights above white, and blacks below black, aren't passed through. They're clipped. Which is the behavior that Gray illustrated. Basically it's best to limit those functions to the end of the line processing, and do your highlight and shadow recover operations at the beginning of the line.

This strikes me as a sort of common sense approach anyway.
 
That the soft curves and LUTs clip out-of-bounds data is not a surprise, though it'd be nice if manually zeroed out controls suspended clipping rather then requiring a reset. However, that the Hue Curves clip out-of-bounds data is not something I'd actually noticed before.

Probably because, as Juan suggests, I've gotten into the long term habit of using node 1 to pull all of the visible detail into the 0-100 percent range as part of my primary grade (I don't like starting out a grade with out-of-bounds data), and then for organizational purposes I tend to put my Hue curve adjustments into node 2, where they're only working on within-bounds values. I only started doing that to keep track of where my curves are, and to make it easy to turn them off for clients, but happily it's kept them from doing anything untoward to the signal. I find I like to keep all my data where I can see it on the scopes unless I'm compressing or chopping it at the top or bottom end for effect.

As with others, I've also gotten into the habit of sticking soft clip and LUT application at the end of the node tree as my last operation, unless I'm deliberately trying to clip out-of-bounds data that I don't want coming back (such as when I create a flat color field for effect). I try to keep my operations orderly as I don't like surprises.
 
Jason Myres said:
32-Bit Float:
LOG Controls
Lift/Gamma/Gain
Custom Curves
Qualifiers

Not 32-Bit Float:
Hue vs Hue
Hue vs Sat
Hue vs Lum
Lum vs Sat
Soft Clip
Click to expand...

This is not correct. All the tools are 32-bit float, it's the only hue-curves where we don't handle sub-black, and super-white data. Don't mix precision with data range, different things.

The Soft Clip is designed to clip for technical or creative effects.
 
Great discussion & very educational for me.
Thank you, Jason, for suggesting that I move it here from Vimeo.

Yes, I agree and understand that the LUT & Clip controls SHOULD clip, and that the fact that even zero'd clip controls are still clipping makes sense if you view it as an "activated process" which is not turned off until reset. The Hue vs. bugs me, though.

I think the points that Jason, Juan & Alexis made about proper work flow not running into this problem (much) are the best take aways from all this.

In my tip, I wanted to point out "here be dragons" for the less-experienced and people who might not have experienced or thought about clipping before. To get helpful working process tips is a bonus. Thanks.

By the nature of Internet demonstration & compression, I did design my tests to be very explicit & clear, and no doubt beyond "normal use" limits. It did make its point.
 
Thanks for the discussion. I need to re-think my order of nodes which I've been meaning to do anyways.

By the way, has anyone noticed that the Hue vs's cause color cast on clipped highlight area? I used to like to have a series of parerell nodes above the second node reserved for my Hue vs's adjustments, and they'd cast some funky colors onto the clipped highlight area. This color cast would still remain even after I "base-mem" on the nodes. So I had to change my habbit.
 
You must log in or register to reply here.
Back
Top