Following the recent Optimize Playback thread, I seem to have opened Pandora's box when it comes to Color Model in Cinelerra.
I work mostly with 8 bit YUV footage from Panasonic and DJI cameras. Up until now, I have always set the color model to RGB-FLOAT for my projects, and this, combined with setting YUV color space to BT709 and YUV color range to MPEG has meant that what I see in the compositor looks the same as my final rendered video.
However, I have noticed that if I set the color model to YUV-8 Bit, then my footage has far more dynamic range (highlights are hard-clipped when set to RGB-FLOAT), and is more saturated. In fact, when set to YUV 8 Bit, the footage looks the same as it does in VLC player.
On the other hand, if I use YUV-8 Bit as the color model, the final rendered video does not look the same in VLC player as it does in the Cinelerra compositor - it is a bit de-saturated compared to the compositor.
What I would like to achieve is to retain the vibrant colour and highlights that I see in the compositor when the color range is set to YUV-8 Bit in my final rendered video. Can anyone point me in the right direction?
If it's of any help, what I have found is;
If shooting restricted range video as most camcorders do, the colour range needs to be set to MPEG. If shooting full range video as many mirrorless cameras do, it needs to be set to JPEG. Analogy: Putting restricted range video into JPEG colour range is like trying to fill a bucket with a single glass full of water and trying to put full range into MPEG is like trying to get the bucket full into the glass. JPEG into MPEG clips at both ends, losing detail, MPEG into JPEG needs stretching, causing distortion. Assuming, of course, the video scopes are being used as a guide.
I always use RGBA-FLOAT whether shooting 10-bit full range or 8-bit restricted range. I get the impression (correct me if I am wrong!) that the plugins work in RGB, so it is better to set the timeline to RGB at the start to avoid converting YUV to RGB for processing and then back to YUV again.
I use BT709 colour space, even for UHD video, as I output 1080p which will become BT709 on export anyway.
In case you use it, I find there is a problem with ProRes in Cin, I started a thread about it a couple of years ago, whereby rendering loses highlight detail no matter what variation of ProRes I use. I got round it by using DNXHR instead.
"In case you use it, I find there is a problem with ProRes in Cin, I started a thread about it a couple of years ago, whereby rendering loses highlight detail no matter what variation of ProRes I use. I got round it by using DNXHR instead."
I also finally logged a BugTracker ticket #606 so it can be fixed when a "pro" (pun intended) comes along.
In theory RGB-FLOAT should be the only mode that does not create clipping, so I'm more and more confused...
Anyway, if you can find some certainty about CinGG's behavior with colors, let us know and we'll put it in the manual.
EDIT:
The only note to make is to use RGB-FLOAT with BT2020 and not RC709.
What we see in the Compositor depends also on the color space of the monitor.
@
In my little experience after rendering for 3 weeks to get the compositor color.
RGB-8 Bit > Colors equal to the original video.
YUV-8 Bit > Limited colors (saturated). different rendering than compositor.
JPEG > full color
MPEG > limited colors
You can try using Shotcut to do your color tests.
YUV-8 Bit + MPEG looks beautiful in the compositor but that's because the compositor uses X11 and X11 is RGB.
I could be wrong.
Using RGB + JPEG will have colors equal to the compositor.
The YUV of the compositor is not the same as the YUV of the render.
@sparkill Your observations are mostly the same as mine - having looked at it again, I would say that in YUV mode, the compositor looks more saturated than it does in VLC player.
However, RGB + JPEG, definitely does not show the same colours as the original video in the compositor for me - the image becomes quite washed-out looking. Also RGB+JPEG when rendered, does not look the same as it did compositor either - it looks similar to the results from RGB+MPEG (close to the original).
Is there any way to prevent the RGB-FLOAT conversion from clipping the highlights?
