Bug (by design) on lut generating

I was doing a complicate transform with 5 nodes, one of them was the resolve color space transformation ofx.

Once I'm happy, i generated the lut to send in the set for dailies.

But... the actual color space transform is completely missing from the transform/lut.

I understand that might be desirable not allow user "steal" the math with a lut, but in the other end we cannot do proper jobs because of this hidden gem.

Please, fix it..

I was doing a complicate transform with 5 nodes, one of them was the resolve color space transformation ofx.

As was explained to me by the Tech color science department, the math inside a LUT is relatively simple, and I don't think it can necessarily handle color space conversion. I think there's a similar thing going on with a CDL being unable to handle Y-only adjustments. I suspect the only way this could be fixed would be if they were to come up with a completely new kind of LUT that could contain the additional math.

Marc, what i was doing can be describe with a lut (that i have to pass to editorial).

If i switch the ofx for the equivalent lut (generated by Joseph in nuke), it works.

Really, BM, nobody is going to steal your math that is available already in other places.

Sent from my SM-N920T using Tapatalk

Yes I have had to go into Mac, create the transform Lut with Lattice then bring the Lut back into windows resolve. Kind of a pita

Ofx probably breaks the chain because Resolve has no means to capture color expressions from an oxf plugin, it is a black box for Resolve. Nuke overcomes this by explicitly applying all changes on a generated test image and LUT is directly based on resulting pixel values.

A 3D LUT does not contain any math, it is just a lookup table, so it is able to store all color transforms, within its range and precision limits ofcourse. CDL is a set of parameters for a fixed expression and as such is rather limited, but it has the upside of having more precision than LUT because actual calculation is done for each input value while LUT stores results for only a limited set of values and inbetweens are interpolated.

Hendrik, that is not the point. What i need to so simply cannot express with a CDL. I know intimately how a lut work and the math behind it.

I don't think resolve cannot do the calculation, simply BM does not want to.

if you get a chart from nuke and pass it through it will work workout issues. Just extremely inconvenient.

Sent from my SM-N920T using Tapatalk

What i need to so simply cannot express with a CDL.

I know, that's what I meant by saying CDL is rather limited.

Most probably the current logic of baking lut does not fit with plugins, they should change the way lut creation works in Resolve. Not a huge change but a change nevertheless.

[Rohit Gupta]

Hendrik, that is not the point. What i need to so simply cannot express with a CDL. I know intimately how a lut work and the math behind it.

I don't think resolve cannot do the calculation, simply BM does not want to.

if you get a chart from nuke and pass it through it will work workout issues. Just extremely inconvenient.

Sent from my SM-N920T using Tapatalk

We made a change recently to exclude all spatial operations from the LUT generation. Given we don't know what an OpenFX might do, we are excluding that as well. However, for Resolve FX, we can allow some of them which are pixel based processing only. We'll fix it as soon as we can.

Hendrik, that is not the point. What i need to so simply cannot express with a CDL. I know intimately how a lut work and the math behind it.

I don't think resolve cannot do the calculation, simply BM does not want to.

if you get a chart from nuke and pass it through it will work workout issues. Just extremely inconvenient.

Sent from my SM-N920T using Tapatalk

We made a change recently to exclude all spatial operations from the LUT generation. Given we don't know what an OpenFX might do, we are excluding that as well. However, for Resolve FX, we can allow some of them which are pixel based processing only. We'll fix it as soon as we can.

Thanks!

Sent from my SM-N920T using Tapatalk

as a simple temporary workaround you could use Hald 3D test patterns to generate the LUTs. this is a very simple solution, that works on any image/video processing software by analyzing the color changes applied to images showing a specific test patterns. the generated LUTs can also easily translated to more common 3d LUT formats later.

but i'm quite sure, you already know all this tricks.

http://www.quelsolaar.com/technology/clut.html

The 'old' method still appears to work (at least in Resolve 12.5.5.026 on Windows)

Import the trim_lut0.dpx (in the support folder), apply the grade including the OFX plugin and use 'Generate lut from the current grade' in the Project settings>Color Management panel (not from the timeline). It must be the trim_lut0.dpx to work and remember this will still clip values outside of the 0-1 domain i.e. the precision in a 33x cube lut still isn't anywhere near enough for non-linear colorspace transforms but should be fine for an inline transform to a display-referred 'look' lut.

yes -- the old manual trim_lut0.dpx based approach is just doing the same. and it's in fact very handy and comfortable to use within resolve. this other [more complicated] alternative may only be useful, if you want to archive a different precision resp. number of LUT reference points.

I use nuke, generate pattern, pass through, read back, dump lut

Sent from my SM-N920T using Tapatalk