3d LUT colourspace mapping on a realtime video stream?

Does anyone know if there’s any way to apply 3d lookup table colourspace correction to a video stream in real time? It’d be great to do complex colour mapping on a VVVV renderer output for video/texture processing based stuff. Generally I just render image sequences and do colour processing in photoshop, but it’d be really useful to be able to do something similar live.

Hi,
Ok this is not a vvvv based solution but…
If you don’t need to manipulate your lut table “live”, you can use blackmagic’s HDLink device.
I use this for correcting camera streams during performances.
It works for HDSDI in/out, has no latency, and is the cheapest solution I found for this.
Limitation is that you can’t manipulate the table live, because when you manipulate or upload it it has some freezes.

Mehdi

can be done in a pretty simple shader, have a look here:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter24.html

basically you input a 2D texture (the image you want to modify) and a 3D texture (LUT) into a shader, sample the 2D texture (get color per pixel) and use the result as coordinates to sample the 3D texture. That’s it!

Cheers. Both are interesting solutions, although I’d rather do something in software than hardware.

Unfortunately writing a shader is beyond me at this point, although a shader based solution would be ideal. One day I’ll probably have to learn some shader code.

check 3d-lut-color-grading

@milo @bjoern @unc

:D

That’s super awesome. Thanks so much.

I’ve run into a bit of a stumbling block. The help patch works fine with the included .cube file, but whenever I try to load any others it loads for a while then the graded outputs go black. I’ve tried a few different ones and seem always to get the same result. The valid pin on the parser outputs “1” for the included .cube file and “0” for all of the .cube files I try, so I’m guessing there’s a problem parsing?

Any idea what might be causing this?

Discovered the problem. Looks like all the .cube files I was feeding in have headers that weren’t compatible with what the RegExpr node was checking for in the parser. Seems like I can just manually change the header and things work fine.

…To an extent. Looks like if the cube files are different dimensions it’s not always straightforward to just change the dimension numbers. Might see if I can do some research into how the file format works. If anyone can point me in the right direction you’ll be saving me loads of time. :)

If you post your cube files and some before/after images like the birch it’s more likely someone will be able to help.

The issue seems to have been that the parser doesn’t like to parse anything that isn’t a power of 2 (16^3, 32^3). A lot of .cube files seem to have non ^2 dimensions like 17^3, 21^3 or 33^3, and when that’s the case nothing renders.

I managed to find an application that can analyse and convert formats and dimensions, and after some testing it seems to work pretty well. Could be useful if anyone else has similar needs. https://cameramanben.github.io/LUTCalc/LUTCalc/index.html


There is a ZIP ther with lots of luts
The example one from the patch is 16x16x16
most of the ones on the file are 25x25x25
@eno is it too big resource intensive to expect a realtime video at 25x25x25 lut?

shouldn’t be a problem, the LUT size doesn’t really matter

I shoud tell the render that the data its a 25x25x25 and thats it? or I am missing somehting ?
Im testing the lut files of that zip, it seems to work