@andy_dill @Ashby et al
I’m putting this out there and prepared to look stupid - I’ve used the built in lin to log and log to lin and see that the round trip loses data. Is there any way to make a perfect round trip without losing data?
@andy_dill @Ashby et al
It looks like you’re feeding it 709. If you feed it log footage, does it still do that? It seems like it shouldn’t matter given that it’s 16fp, but I am not a color scientist!
It’s definitely linear footage. However to my mind it shouldn’t matter what you feed it because the round trip should not be destructive. It’s just maths.
Use Input Transforms in the CM node. The Log to Lin mode is legacy stuff.
Switch to 32b float
I did try the input transforms and got a worse result: ending up with a more saturated output. Didn’t try 32bit though.
32 bit is what you’ll need.
I think that if input transform is making it more saturated then the transform is doing something wrong or your LUT thinks that the image is somthing that it isn’t.
What type of linear are you using? What is your colour management node doing?
The classic vsns are less lossy then the input transforms, and 32 bit will give you less errors than 16. Pretty sure it’s the same in Puke though.
Wouldn’t expect that much diff at 100 gain though.
Thank you Congleton Boys. I’ll give it a look tomorrow. I was using the preset legacy version. Got same with Aces too. Need to try with 32bit.
Congleton boys. Are you kidding me?
Quite right. I always *forget that. I need to get you this t-shirt
How did you manage to piece this information together?
I’ve worked with you both…
I just did a quick test and converting all of it to 32 bit will make the issue go away.
HOWEVER, I’d like to argue that in all cases, nothing, absolutely NOTHING any of us has ever worked on needs that level of precision. You would have to round-trip a thousand times before switching between A and B would be visible.
Instead of using “softness” wind up the gain on the difference. I feel that’s a more human way to interrogate the differences since you have a scale value for how hard you have to push it to see a level of difference.
I stumbled across this in nuke a while back when converting between gamuts. Not exactly your issue here but yea…
also consider the rounding error when you do 32float to 16float conversions
Hi Andy… we totally see 16b float clipping when working on material for feature films… we see some crazy high float values in scene linear camera footage that is not adequately computed when in 16b.
On real world plates? Ive seen this with CG data passes but not personally seen any camera plate that would have higher values than what 16bit float can hold. would be interesting to see a plate like that