YUV to RGB conversion issues

Yes that is correct. I used the native plugin.

I made a discovery the other day which may help a little. Having sold my X-T3 I am concentrating my efforts on my HC-X1500, which shoots broadcast restricted (MPEG) video. My action camera shoots full range, so I need Cinelerra set to JPEG for that. I always use RGBA-FLOAT.

I found (understandably) that importing MPEG into JPEG colour space leaves it rather flat even after my best efforts. I also found that yes, if I set Cin to MPEG it hard clips, so the waveform monitor 100% is ususally a straight line. However, if I leave Cin set to JPEG and import MPEG clips, then convert it to JPEG using Colour Space, the flatness disappears and so does the hard clipping.

Edit: I forgot to say the HC-X1500 exposure is normally set using 95% zebras, so the waveform monitor should never hit 100% with a raw clip.

Just thought I would mention it in case it helps.

@igorbeg

Thanks again for your input.

I can confirm that formats using bgra seem to match the compositor when using JPEG as the colour model, I can then convert to m4v using Handbrake, and upload that file to YouTube.

Colours seem reasonably consistent in YouTube.

So the issue appears to be in how JPEG colour model YUV files are written by Cinelerra, as the files converted from RGB to YUV by Handbrake are displayed correctly. Is this a separate issue to the clipping of out-of-range values when in MPEG color model?

@glitterball3

It is good webm-gbrp works also for you.
I don't know why You and me are seeing different results in some cases.
May be it depends on my old software versions and my screen.
To compare with te Compositor I am using both VLC and ffplay.
The info about.
- VLC media player version 2.2.2 Weatherwax
- ffplay version 2.8.6
- My screen is calibrated on sRGB with an external probe.

However I can see that if we use a Rendering format with "Pixels: gbrp" (see Render #2 of my previous post) or "Pixels: rgb" and using ffmpeg by command line to convert the CinelerraGG output to h264 yuv420p/yuv422p/yuv444p, the conversion seems good for you and for me. It might be a good but "undesiderable" workaround (strategy).

Another good Render is...

- Render #4:
  File Format: FFMPEG | mkv
  Video Preset
    Compression: user_ffv1.mkv (or ffvhuff)
    Bitrate: 0
    Quality: -1
    Pixels: bgra

Converted by ffmpeg command line to...

ffmpeg -i input.mkv output.mp4

(default pix_fmt will be yuv444p)

or for yuv420p ...

ffmpeg -i input.mkv -pix_fmt yuv420p output.mp4

My ideas are on a dead line, now. Sorry.

@igorbeg

For me, a webm video using your settings looks very similar to the compositor, however the mp4 video does not. The mp4 video suffers from the same dark/more contrast difference as before. Webm is very slow to render!

the Render below is playable in VLC if it has been created from CinelerraGG_20201031,
NOT if it has been created from CinelerraGG_20211231. Is it just my problem?

Works fine for me using CinelerraGG_20211231 (with the usual too dark/too much contrast).

Also, I also tested CinGG-20201031-x86_64-older_distros.AppImage, but didn't see any different results.

Thanks @glitterball3 for the last information.
So your source video file is .MP4 h264 yuvj420p(pc, bt709).
My tests are on .AVI mjpeg yuvj422p(pc, bt470bg) and .MP4 h264 yuv420p files,
using CinGG-20211231-x86_64-older_distros.AppImage and CinGG-20201031.

Below the Render settings that seem to match good VLC vs Compositor
Could you do a test with these Render, please?

- Render #1:
  File Format: FFMPEG | mp4
  Video Preset
    Compression: h264.mp4
    Bitrate: 0
    Quality: -1
    Pixels: yuv422p (ffprobe will show it is changed to yuvj422p)
            yuvj422p

- Render #2:
  File Format: FFMPEG | webm
  Video Preset
    Compression: webm.webm
    Bitrate: 0
    Quality: -1
    Pixels: gbrp

Settings used in CinelerraGG:

- Preferences:
  - Playback A TAB
    - Video Out section
        Play everyframe = unchecked
        Video Driver: X11
                      Use direct x11 render if possible = checked
  - Appearance TAB
    - Color section
        YUV color space: BT709
        YUV color range: JPEG


- Format:
  - Video section
      Frame rate: ---
      Width: ---
      Height: ---
      Color model: RGBA-8bit

It is strange,
the Render below is playable in VLC if it has been created from CinelerraGG_20201031,
NOT if it has been created from CinelerraGG_20211231. Is it just my problem?

- Render #3:
  File Format: FFMPEG | mp4
  Video Preset
    Compression: h264.mp4
    Bitrate: 0
    Quality: -1
    Pixels: yuv444p (ffprobe will show it is changed to yuvj444p)
            yuvj444p

Thanks!

Here's the output of ffprobe for the original video:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55673f3d3ac0] st: 0 edit list: 1 Missing key frame while searching for timestamp: 3600
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55673f3d3ac0] st: 0 edit list 1 Cannot find an index entry before timestamp: 3600.
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '18-surfer-wide.MP4':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp42avc1
    creation_time   : 2021-12-23T17:01:38.000000Z
  Duration: 00:00:22.56, start: 0.000000, bitrate: 92715 kb/s
  Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 92496 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)
    Metadata:
      creation_time   : 2021-12-23T17:01:38.000000Z
      vendor_id       : [0][0][0][0]
  Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 125 kb/s (default)
    Metadata:
      creation_time   : 2021-12-23T17:01:38.000000Z
      vendor_id       : [0][0][0][0]

@glitterball3

Could you do a little test with the settings below to see if the rendering viewed in VLC match with the Compositor, please?

Because it creates a huge file it is better highlight 5-6 seconds in the timeline and using Selection checkbox in the Render window.

- Preferences:
  - Playback A TAB
    - Video Out section
        Play everyframe = unchecked
        Video Driver: X11
                      Use direct x11 render if possible = checked
  - Appearance TAB
    - Color section
        YUV color space: BT709
        YUV color range: JPEG


- Format:
  - Video section
      Frame rate: ---
      Width: ---
      Height: ---
      Color model: RGBA-8bit (also RGBA-FLOAT)


- Render:
  File Format: FFMPEG | qt
  Video Preset
    Compression: png.qt
    Bitrate: 0
    Quality: -1
    Pixels: rgb24 (also rgba64be)

I have to say that things are easier for me now I have changed my main camera.

I was shooting 10-bit 420 full range (full range cannot be changed), 2160p at various compression settings i.e. long-GOP or all-i at anything up to 400mbps, sometimes in F-log, sometimes in Eterna profile, with my X-T3. Now I am shooting 10-bit 422 MPEG long-GOP at 50mbps, using Cine D profile or occasionally F1, with my HC-X1500 and I prefer the image quality slightly, this has made most of my Cin troubles disappear. I am now importing 16-235 rather than the 0-255 I was, I set it to MPEG BT709 and use RGBA-FLOAT, now everything looks good from first import into Cin to the final render. I'm damned if I can see any difference in the outputs between full range in and restricted range in and in any case, output will be restricted range BT709 so no I longer see any logic in importing full range by choice.

@phylsmith2004  & @andreapaz

Thanks for all of the suggestions, however after trying even more things out, it seems that the main problem that I have is that what I see in the compositor is simply not the same as I see in other editors or players unless MPEG is selected as the YUV color range. This comes with the caveat that anything outside the 16-235 range is hard clipped.

Is there any way that this functionality could be changed, or an option added to prevent everything being hard-clipped when using MPEG as the YUV color range? Perhaps only hard-clip the range closer to the output after video effects have been applied?

@glitterball3
To see the rendered video in a player without color problems (I can't tell in other NLEs), it is advisable to write in the wrench options the 3 information about the colors you are using as metadata. They are as follows:
colorspace= ... (color matrix: RGB, YUV,...)
color_trc= ... (transfer characteristic or gamma: sRGB, Rec709, ...)
color_primaries= ... (gamut: sRGB, Rec709, BT2020, ...)
These parameters do not affect the rendering you do in CinGG, but are read as metadata by players (Vlc, mpv, ...) that take them into account to play the video in an optimal way.
https://cinelerra-gg.org/download/CinelerraGG_Manual/Extra_acin_a_Options_Render.html

In case of different and non-uniform assets it is advisable to standardize all sources to the same model color, gamma and gamut (and that coincide with those of the project). So render/Transcode inside CinGG or, even better, externally from terminal with ffmpeg, etc. In any case, as Phyllis said, the rendering is only affected by the Project settings (and wrench parameters).

@glitterball3

Another question that I have is about the pipeline in Cinelerra:

Is the "YUV color range:" setting in Appearance a project-wide setting, something that affects the final rendered output, or just the compositor?

It seems to be a setting that affects how all media is interpreted - so what happens if there are mixed sources?

As far as I know, the "Project Setting" is used for everything.  So if there are mixed sources, it uses the same current Project setting for all sources.  So for advanced usage, it is always best to set up your project settings first.

https://cinelerra-gg.org/download/CinelerraGG_Manual/Automatic_Best_Model_Media_.html

I think that I'm getting closer to understanding the issue - if anyone knows better, then please correct me.

1. My videos are recorded using the 0-255 range.

2. 0-255 corresponds to JPEG in the "YUV color range:" setting, and with this set, I can see the full range of black to white in the compositor.

3. When I render a video with "YUV color range:" set to JPEG, the outputed file is usually interpreted as 16-235 and blacks appear crushed and highlights are clipped - both players such as VLC and even other video editors such as Kdenlive interpret the rendered video as being 16-235. However, if I import the rendered file back into cinelerra it is interpreted as being 0-255 without the crushed blacks and clipped highlights.

4. When I set "YUV color range:" to MPEG, what I see in the compositor is exactly the same as how the rendered video is interpreted by other players, however any values outside 16-235 are clipped by Cinelerra and cannot be recovered using any of the color correction effects.

At present, I can either:

a. Set "YUV color range:" to MPEG and the final output will match what I see in the compositor, with the caveat that I may lose some shadows and highlight information from the source media.

or

b. Set "YUV color range:" to JPEG and accept that the final output will be misinterpreted and that my shadows and highlights will be crushed and clipped.

Another question that I have is about the pipeline in Cinelerra:

Is the "YUV color range:" setting in Appearance a project-wide setting, something that affects the final rendered output, or just the compositor?

It seems to be a setting that affects how all media is interpreted - so what happens if there are mixed sources?

I think that a better way of working would be to allow the values outside of 16-235 to continue to exist (rather than being hard-clipped) in a RGB-FLOAT project with color range set to MPEG. These values would be outside the legal range in the scopes, but at least we could pull them back into range and recover highlights/shadows during colour correction

The easiest way to see the clipping that I am talking about, is to load a video file with some over-exposed highlights, and add a blue banana effect.

Then, switch between RGB-FLOAT and YUV-8 Bit. The mini histogram in the 'value' slider of Blue Banana will show the out-of-range values when in YUV mode, but these will be clipped when in RGB-FLOAT.

Be careful when switching between MPEG and JPEG in the Preferences dialog, as this may change YUV to RGB in the background (if the format dialog window is also open, it will not show the updated value until you close and re-open it).

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 was indeed rendering in ProRes, I will try rendering in DNXHR instead.

Edit: I think that the JPEG vs MPEG YUV color range may well be a factor here - in my camera, I have the range set to 0-255 (the other option is 16-255). However, if I set the YUV color range to JPEG in Cinelerra, the final render does not match what I see in the compositor.

Edit 2: If YUV color range is set to JPEG, then the exported video will be much darker than in the compositor. If I import the rendered video back into cinelerra, then it looks exactly the same in the compositor as the original video. However, the timeline preview will be much darker (just like in VLC)!
So, there's likely a clue there as to why the rendered video looks darker than the original.

Is it possible that MPEG is assumed as the color range in many areas of the software as well as in external video players and tools? If this is the case, is there a way to squeeze that extra range back into the MPEG range in Cinelerra without just discarding it via hard clipping?