//

3D-LUT interpolation pseudo-code

I wrote this presentation two years ago that could be the basis of an annex of the CLF document on 3D-LUT interpolation pseudo-code. Let me know what you think.

JD
AMPAS-CLF-LUT-pseudoCode.pdf (272.2 KB)

1 Like

Thanks JD!

Some comment on your PDF, if you don’t mind:

p. 4: It says “The system (hardware or software) would have to parse through a 4.03 Gigabyte memory for every pixel” but that’s not true. It just needs to look up one color out of the 4 GB table (per pixel). The problem isn’t parsing or scanning of the LUT, it’s just the massive size.

p. 15/16: It seems like the blue dots should be red (since that’s the axis interpolated) and the red dots blue. The green ones are right.

I hadn’t heard of Prism and Pyramid interpolation, just Tetrahedral interpolation (because that’s what OCIO supports). Has anyone ever done quantitative or qualitative comparisons of them? I was told Tetrahedral “looked better” than Trilinear and that’s why it’s used, but I’ve never seen a study. So I’m curious how they all stack up against each other.

///d@

Thank you Dennis for your comments. I’ll look into them.
As for how they compare to one another, I’ll refer you to my paper. You can find it here:
https://www.researchgate.net/publication/328576446_A_survey_on_3D-LUT_performance_in_10-bit_and_12-bit_HDR_BT2100_PQ

JD

Great paper JD, thanks! Based on that, no need to bring prism and pyramid to OCIO or CLF.

I look forward to contributing our branch-free tetrahedral interpolation GPU code to OCIO v2 once Doug’s team’s work is done.

Somewhat related, I’ve found that for any LUT taking linear input the design of the pre-shaper function is critcally important. The AllocationTransform operator in OCIO is barely servicable in this capacity when some negative input range is needed, and I’d love to see CLF (and OCIO v2) improve in this regard.

1 Like

As I think is explained in my slides (if not, I can provide supplemental material), you can pre-process a lot of numbers to speed up the actual calculation. Also, using octree is probably a good idea if you haven’t already. I also ended up slicing the image in order to parallelize the calculation but that goes without saying.