François Zaïdi wrote:there a way to recover the right colors in post, using an NLE or resolve ?

If it has been matrixed, maybe not. But if the components are still intact, maybe there is a way of re-assigning them with a channel switcher. Y =>R, U=G, V=B, like Jello 1-2-3. You might even be able to do it in resolve with a splitter/combiner node and swap the patching.

This won't work. RGB doesn't map to YUV just like that. It's a proper math and conversion, so swapping/mapping YUV channels is not a solution at all. In your case it's not easy to fix, maybe even impossible. This is a task for people at doom9 forum and avisynth.

François Zaïdi wrote: I searched for Jello 123, but to no avail. Can you point me in the right direction ?

Sorry, that isn't a literal reference, I was referring to a gelatin dessert that used to be popular, but its spokesperson has fallen into disrepute, among other things. I was really just trying to be picturesque -- maybe like a cafe latte with the coffee on the bottom, a layer of steamed milk and then foam. Hard to separate them after the drink has been made, and as Andrew correctly points out, some math has been done on them - my reference to the "matrix" processing.

Many VFX applications have channel splitters and "swap channels" behaviour or nodes. Your challenge is to try to get the system to "get some eggs out of an omelette." In the ideal situation, it would work like ProRes 4:4:4, which at least conceptually carries either Red or Luminance in Channel 1, Green or B-Y in Channel 2, and Blue or R-Y in the third channel.(if the order was Y', U, V). At the very least, though if you were capturing in a 4:2:2 format, the original material probably has been bandwidth limited (low-pass filter in chrominance), re-ranged and gamma-indexed. All bad for RGB recovery or re-coding.

It has nothing to do with this. It's not about RGB<->YUV conversion at all.RGB signal was recorded as YUV, so things are totally messed up and probably unrecoverable. This recording may not have any usable information at all.

Andrew Kolakowski wrote:It has nothing to do with this. It's not about RGB<->YUV conversion at all.RGB signal was recorded as YUV, so things are totally messed up and probably unrecoverable. This recording may not have any usable information at all.

I STAND CORRECTLY.

nuke can convert a colour space from YUV to RGB with the same matrice and you can use a lut for it.

You can build complex 3D LUTs in Fusion just as you can in Nuke, but without the watermark. The Custom Tool in Fusion does the same task as the Expression Node in Nuke. Fusion only offers ALUT3, ITX, and 3DL as LUT options, but the ITX version is identical to that which Resolve exports, you just need to change the extension from '.itx' to '.cube' and Resolve will recognise it.

Sometimes a YUV signal is processed in the order of UYV, as is the case internally with some Eizo monitors. If that signal was then read as RGB, it would naturally lead to an image with a heavy green cast. This may or may not have something to do with the problem at hand, but worth considering nonetheless. My post from a few days ago has a link which partially addresses the issue.

Paul Dore wrote:Sometimes a YUV signal is processed in the order of UYV, as is the case internally with some Eizo monitors. If that signal was then read as RGB, it would naturally lead to an image with a heavy green cast. This may or may not have something to do with the problem at hand, but worth considering nonetheless. My post from a few days ago has a link which partially addresses the issue.

i thought about that and in my nuke test i swapped the green and the red channel, still does not look like Yuv...