LUTs loss of information - shadows cutoff

Hi, recently I've been working with shadows recovery, all good until I want to generate a LUT from a simple contrast adjustment to share across different platforms, no matter what I do the LUTS are incapable of reproducing a simple contrast adjustment [attached image]. This is not specific of Davinci Resolve, it happens across all editors I work like Final Cut, Color Finale, Lattice, Catalyst Browse and even Photoshop.

I had issues before about this shadows cutoff when creating slog LUTs in lowlight but now I'm working with a GoPro 9 at -2 stops to protect highlights so the shadows recovery is more critical than ever.

I found weird that a simple contrast adjustment can't be shared across different platforms, with all the color science probably you all have knowledge of this issue so any advice would be really helpful.

ScreenShot.jpg (989.23 KiB) Viewed 1846 times

From what I know is that a lut can only work within a 0-1 range so if there is any data originally outside of that it will be clipped on reapplying.

My question in your case would be why not shoot in log so you can expand contrast instead of reduce?

The other way to go about it would be to not create a lut for it but just grade it. Any reason it needs to be a lut?

LUTs are destructive by nature.

From what I know is that a lut can only work within a 0-1 range so if there is any data originally outside of that it will be clipped on reapplying.
My question in your case would be why not shoot in log so you can expand contrast instead of reduce?

Thanks for the info but as I mentioned this happens also in s-log (no data under 0-1 range) when making LUTs for lowlight the LUT result is washed out instead of a real blacks (and above 0 luminance). And if I remember well something similar happened trying as workaround to bake the s-log adjustments exporting a Prores file ( in Catalyst Browse), the result was also washed blacks. Note: the cutoff happens too with highlights if I remember well.

The other way to go about it would be to not create a lut for it but just grade it. Any reason it needs to be a lut?

Manual grading a contrast adjustment is as simple as it gets but as I expose in the post this limits to work from scratch only within one platform instead of working with LUTs that all editors can translate.

LUTs are destructive by nature.

I don't think color scientists just decided to create LUTs destroying the work that are paid for in millionaire production movies.

Thanks for the info but as I mentioned this happens also in s-log (no data under 0-1 range) when making LUTs for lowlight the LUT result is washed out instead of a real blacks (and above 0 luminance).

Sorry, read over that part.
Maybe it is a bug then with your current version? Have you tried other Resolve versions?
I created a lut today and didn't see any issues there.

With "destructive by nature" I'm referring to the fact that you can't get anything back that has been shifted into crushed blacks or clipped highlights by a LUT. Any LUT.

With Resolve, you can over- or underexpose in one node and pull back in the next and it's all still there. A true grading program is far more flexible than a LUT.

A LUT is good if e.g. you need a quick solution to show dailies to a client after shooting log, which would look 'meh' to lay people. Even then you may want to design your own one, adapted to the lighting situation and the intended style. DR is great for preparing such a LUT too.

Sorry, read over that part.
Maybe it is a bug then with your current version? Have you tried other Resolve versions?

As I mentioned this issue happens across all platforms, been working with s-log and Davinci for years and that cutoff already existed

I created a lut today and didn't see any issues there.

Really? If you'd like to share the powergrade & LUT would be very interesting!

With "destructive by nature" I'm referring to the fact that you can't get anything back that has been shifted into crushed blacks or clipped highlights by a LUT. Any LUT.

I'm aware of the "irreversible" properties of LUTs. You can check in the image posted that the LUT generated was actually from a single contrast adjustment to protect shadows&highlights from clipping, which by the way in reality aren't clipped but it's Davinci Resolve that transforms the input gamma expanding the luminance beyond 0-100.

A LUT is good if e.g. you need a quick solution to show dailies to a client after shooting log, which would look 'meh' to lay people. Even then you may want to design your own one, adapted to the lighting situation and the intended style. DR is great for preparing such a LUT too.

Yeah, I know, not that I'm an audiovisual technician but LUTs are used for many applications such as thermographic cameras, false color, etc. That's why I think there's something missing here.

I'm thinking you're confusing a LUT with a Grabbed Still.

The latter will apply the exact same adjustment and produce the desired result. A LUT can't do that.

I don't think you can save that adjustment for use in other software and have it function identically.

LUTs are destructive by nature.

So a lut that maps 0.0-1.0 range to 0.0-1.0 range destroys what exactly?

LUTs are destructive in some cases, depends on LUT and data. And how relevant the destruction is in practice is another topic. 12bit prores encoding is destructive by nature too, so based on this info should we remove it from all ”pro” pipelines?

Every time there is an urge to state that ”luts are destructive m’kay”, I’d suggest taking a moment and explain to oneself what exactly a LUT is and how it is applied to color data (the math).

I'm thinking you're confusing a LUT with a Grabbed Still.

Maybe it is confusing for you, that's why I uploaded an image for better understanding.

The latter will apply the exact same adjustment and produce the desired result. A LUT can't do that.

Nobody said nothing about grabbed stills. Actually, if you export a grabbed still in .tiff format you'll learn there's already a cutoff information happening. But this isn't the core of the matter here.

I don't think you can save that adjustment for use in other software and have it function identically.

LUTs do function identically with luma&chroma for any software, the matter here is that doesn't function with the same software that is creating it.

Found a workaround and the partial explanation of what is happening:

Found that Final Cut doesn't transform the gamma when video is imported so I export them as Prores and now Davinci works properly when generating LUTs.

I was working with Prores files transcoded with Apple Compressor, Compressor seems to apply the same gamma (or whatever the correct term is) transformation as Davinci: when importing the video gamma is scaled beyond 0-100 luminance, no information loss but then comes all the other problems with LUTs.

I'm going to keep this post updated as I gather more information.

Alright so finally the mistery it's been solved:

The cause: In this case the video editor misinterpretation of the video contrast levels is because the video itself lacks of the appropriate "color space tagging" [see example in attached image]

Generic Solution 1: to make Davinci Resolve apply LUTS as if the contrast levels where normal, just make a node with the contrast correction and then generate a new compound clip from this, afterwards any LUT applied will respect the corrected contrast. Note: make sure to deactivate the s-curve option from the projects settings.

Generic Solution 2: find a way of tagging the video file to its real color space ( HD 1-1-1 equals a 709 space), I'm currently searching how to do this one.

Specific Mac OS Solution: I updated to the last OS version and this solved the problems with GoPro, weird as you can see in the attached image GoPro does in fact tag correctly the color space of their videos.

Screen Shot.jpg (384.25 KiB) Viewed 1469 times