I’m trying to create a 1D LUT that converts linear to DaVinci Intermediate with LUTCalc. I get slightly lower exposure and the shadows and highlights are clipped. Anyone know what the right settings are to use?
I notice that you have input and output range set to 109%. Try 100% and you may well find it solves your issue.
(Note this is speculation on my part, not tested)
Edit: Although thinking further, this will still clip input above diffuse white. I think you may need to make the LUT in a different way, which supports a wider input dynamic range, if you want to support linear input.
You could do it with Colour Science for Python, for example.
>>> import colour
>>> LUT = colour.LUT1D(size=16384, domain=[0.0, 100.0])
>>> LUT.table = colour.models.oetf_DaVinciIntermediate(LUT.table)
>>> colour.write_LUT(LUT, 'lin_to_DaVinciIntermediate.spi1d')
True
2 Likes
Thanks Nick,
Yea the screenshot was accidentally taken from the other test seeing if 109% made a difference, but it made it worse 
.
I was afraid something like that might be the case.
Sounds like a great idea but I’m not familiar with any Python stuff, just a simple artist. Would be grateful if you could do it whenever you have the time. 
There’s no rush to it.
Initially I was looking for a way to use Resolve’s Fusion page with the viewLUT in the viewer with Resolve Color Managed DWG/Intermediate active. Because it auto linearizes in Fusion it needs to be reverted and then the DaVinciDRT applied but this is impossible with the built in tools.
I found a way to do it with going from linear to LogC instead with the built in VFX IO LUTs. Then a second LUT doing the display transform from there. For clarity/sanity sake I’d rather have the 1D LUT go back to Intermediate instead.
lin_to_DaVinciIntermediate.txt (176.1 KB)
You will need to rename the file, as ACES Central does not accept uploads of .spi1d files.
Thanks! This version does seem to fix the exposure difference judging visually but the darks and brights still don’t map nicely.
(Left yours, right LUTCalc)
vs colorspace transform
Not sure what else can be done to get the right results. At least I have a workaround for now.
Instead of lin-to-log LUT apply the following log-to-lin LUT in reverse direction, if you can.
Davinci_Intermediate_to_Linear.spi1d.txt (134.3 KB)
That was a good idea! Still the same result unfortunately…
@priikone makes a very good point. If inversion is available, a log to lin LUT applied in reverse gives higher precision, with a smaller table, than a lin to log LUT.
I only did a brief test, but the result of my LUT appears to match that of Resolve’s Color Space Transform. So I think the issue you are seeing is somewhere else in your pipeline.
I don’t know Fusion well, and have not fully wrapped my head around its colour pipeline. So I don’t have any other suggestions, I’m afraid.
1 Like
Hey, thanks for that clue Nick! I did a test with the OCIOFileTransform in the node tree and compared with the viewer’s OCIOFileTransform. It looks like the viewer version of OCIOFileTransfom is not applied in float? I’ll ask on the BMD forums about this. Seems really impractical. The Lin to Log version did work in the node tree too but that loglin reverse is indeed more efficient with half the LUT size.
Pekka’s DaVinci_Intermediate_to_Linear.spi1d on both viewer left, node tree right.
One more update…
I was curious why the built in VFX IO LUTs were working as intended. I noticed they were .cube files with 1D LUT data stored inside. I transferred the Linear to Intermediate spi1d data to that format and it worked flawlessly in the viewer! So the LUTs loaded directly work fine with linear data but the ResolveFusion viewer only supports .cube format for them.
Posting the LUT here should anyone ever come by this thread with the same challenges.
Linear_to_DaVinci_Intermediate.cube.txt (624.1 KB)
One caveat is that the DaVinci Intermediate 0-1 range maps to 0.0-100.0 linear. That is the range the LUT covers. But if the image data contains negative linear values, these would need to be represented by negative DaVinci Intermediate values, and those are outside the LUT range.
In a display pipeline this may not matter. But it is something to be aware of.
1 Like
@nick Sorry to bother you again! Do you think you can make one for Linear to ACEScct as well? I’d like to do the same for ACES since loading an OCIOColorSpace in Fusion’s viewer also suffers from issues.
I would not recommend doing a linear to ACEScct conversion as a forward 1D LUT. The range covered makes it necessary to use a 65536 sized table (which can cause problems on some systems) to maintain reasonable accuracy in a round-trip.
I think I’ve posted here before illustrating the issue. I’'ll add a link if I can find the post.
ACEScct log-to-lin LUT is part of ACES OCIO config (named ACEScct_to_linear.spi1d).
True. But OCIO uses the log to lin LUT in reverse to do the lin to log (as you described previously). I believe @Shebbe’s pipeline requires using a .cube LUT in the forward direction. This risks introducing significant error.
(4096 sized LUTs used to make the errors more obvious)
With a 4096 entry 1D LUT, covering the entire ACEScct 0-1 range, the first entry in the table is 0.0 and the second is ~0.3. So every ACEScct value between 0.0 and 0.3 is derived by linear interpolation of logarithmically spaced values, resulting in the bend you see at the bottom of the plot.
2 Likes
Ah, yes that looks quite nasty. Was afraid it’s range could potentially be problematic. Right now the only solid functioning method for Fusion’s viewer is .cube LUTs as OCIO configs or file transforms don’t display accurately.
BMD should either make the OCIO tools in the viewer support float with some performance cost (or just project wide OCIO like Nuke). Or start supporting spi1d/spi3d LUTs as direct LUT loading in the software including invert options. For ResolveFusion it would be even better to just sync the Color page managed viewer to Fusion page. There are plenty of solutions but no progress has been made ever.
If you have any other ideas happy to try but it’s going to be on BMD now to address it
I’ve always thought it would be simpler if Resolve gave you the option to easily use the colour page (including all appropriate colour management) as a view transform for the Fusion page. It seems logical, so hopefully one day it will happen.
Of course when using it as part of a display transform, you don’t need all of the range of ACEScct. You could work out a combination which used only as much range as necessary in the shaper.
I don’t claim to know Fusion in detail, but I have found (and maybe it’s just me being a control freak!) that I prefer to have a separate branch in the node tree that applies whatever transforms are needed for viewing, and pipe that to the monitor, while a ‘clean feed’ is sent to the output node. That way I don’t use Fusion’s VLUT options at all.
I get your point. A similar approach in ReFusion is to place the view out behind the MediaOUT node. It becomes annoying if you want to preview nodes including the view transform or measure values whilst still looking through the view transform.
The more I dive in to this stuff the more annoyed I get 
I’m also not a Fusion artist, just exploring workflows. I checked the manual and found this.
Which means we can setup a custom output. Sounds great on paper but having it only limited to CPU seems to mean that it’s incompatible with ColorSpaceTransform and ACES Transform. I created a node setup for them and nothing happens when they load in the viewer. All the OCIO nodes do work because they run on CPU according to the Fusion GPU Accelerated Tools pdf.
To make it worse, even they don’t do anything in ReFusion, it only works in Fusion Standalone.
So we can at least fix the view for ACES workflows in Fusion Standalone.
Going into the viewer LUT menu and selecting [Edit…] crashes both ReFusion and Fusion Standalone when you have such a LUT applied… 
Wake me up in 2 years if anything changed haha.