[ConnecTEDDD]

RGB Separation Examples

The quality of the pre-calibration of a display/projector will affect the end results.

If we improve the pre-calibration, it will help to provide a better final image.

It will require to use the profile of 'Primary Only' measurements run, as pre-calibration verification to know that the display is ready for comprehensive profiling.

For example, with LGs OLEDs, we know that if we reset the 3x3 matrix, the 2019/2020 TVs have before the LUT's, using DeviceControl and 'Restore Factory Values', and then send a reset 3D LUT (UNITY LUT), set 2.2 gamma from regular TV menu, these settings will provide the native panel response.

We need to confirm that no additional functions are enabled, like power-saving, dynamic processing, the RGB separation chart can help for that confirmation.

I have seen a lot of quick profilings from various models.

Usually, each year/model has a similar RGB separation shape, but I have seen issues also.

I believe the variations have to do with the panel calibration saved to the TCON chip.

About CX models, I have seen some issues, where they will affect the final calibration, but using RGB Separation and some adjustments to Contrast or Color control of TV, during pre-calibration, it can improve better pre-calibration and provide insane improvement to the final results (like all green points 1000p verification).

It will take one day to find all the info to post the example I have to understand the power of the RGB separation chart so that I will post another day.

Using the RGB Separation chart, it can reveal active processing or a power-saving, if its clipping luminance to one color channel or has less luminance to one color channel.

All these problems can appear even when the user has confirmed that he has no clipping to Contrast or Color Clipping Flashing Bars.

When the user takes multiple 'primary only' measurements testing different Contrast settings (-2, -1, 0) or Color (- or +), after comparing all the measurements looking RGB Separation chart, you will see how they improved.

Below we have a display with some form of a problem; it needs some attention to the settings to find out if it can be improved.

Below we have a display with some form of a clipping to top end. Check if my reducing Contrast or Color can resolve the problem:

Here we have probably a major power-saving function enabled or very high luminance level, where the panel can't reproduce any color at that high nits levels:

Here, it needs some check of the settings, but it looks that the color management system is designed like that, so it can be fixed after profiling.

Need the user to check different device settings, other picture modes when he is not sure which picture mode or colorspace option provides less color processing:

Below is an OLED, not at best factory calibration, an older generation of panels may have that shape, its OK to start profiling.

Below is an OLED with much better factory panel calibration, ideal RGB Separation to start profiling.

Below is a shape of RGB Separation I have seen to some CX models, that kind of shape it was not available to any other 2019/2018 measurements I have seen again.

It will require some adjustments of Contrast of Color slider to improve that, so in such 'special case', the Contrast 85 and Color 50 are not ideal as default settings.

Something related in panel variation (or factory calibration) is not such good.

However, all these above examples may have perfect grayscale, so without the RGB Separation chart, it is not possible to find out what is wrong... or which adjustments improve or not the panel pre-calibration.

 

[ConnecTEDDD]

Correct me if I'm wrong but on RGB seperation the closer it is to the black line the better it is, or is it the opposite?

R,G,B lines closer to the White line of ColourSpace (or black line in LightSpace) define a good RGB Separation.

The post-calibration will have a great RGB Separation also.

Note that the RGB lines will not go above the White/Black line.

 

[ConnecTEDDD]

Just a quick question, Do you have to do a manual calibration to get the 100 ire patch the least error before doing a cube profile? I did an uncalibrated Benq ht9060 projector with no manual adjustments and I think I lost some pop in the picture (not that much though)? I am using the radiance pro to load the LUT

It will require more info to see what is happening to your setup.

Pre-Calibration Primary only, Profiling, Post-Calibration Primary only.

Please export these three measurement data files, attach and send me here, to take a look. Explain to me all other details, meter settings, and every other detail to help me understand.

Pre-Calibration is very important before starting large profiling.

Black/White evaluation using Contrast/Brightness, Color Clipping patterns, Peak White RGB balance pre-calibration to set your peak output levels.

All these steps required are from all users, with any display/projector, or LUT box model.

Native gamut colorspace coverage also.

The measured triangle to be larger from the target colorspace triangle when you look at the CIE chart.

Also, the pattern generator for the brightness and contrast patterns do not show up using the radiance pro as the External tpg. The other patterns on the drop down patterns also do not show in the display.

These patterns will be displayed when you are using the software iTPG of ColourSpace.

 

[ConnecTEDDD]

Manages Colour Spaces Video

An overview of the ColourSpace Manage Spaces library menu, and how different color spaces can be generated and utilized.

 

[ConnecTEDDD]

Peak White Pre-Calibration Tip - Before Starting the 3D LUT profiling

When we want to set the peak output and pre-calibrate the White balance, it will require to use RGB-Gain/High controls of the display/projector for that procedure.

Please use only RGB-Gain/High controls to fix RGB balance errors while handle peak output levels with OLED Light or Iris aperture with projectors.

For that example, I will use an LG OLED.

The internal LUT of the TV has Video Legal Extended Range (up to 255....when we have the Contrast @ 85).

It means that we need to pre-calibrate the 109% White of the TV.

I will use the REC.709 with gamma 2.4 as an example for our target colorspace.

If we want to get 100 nits to our 100% White in the post-calibration, we need to pre-calibrate the TV
using a 109% White patch for 124 nits as a target luminance.

RGB Triplet 235.235.235 is the 100% Reference White in a TV video legal level signaling.

RGB Triplet 255.255.255 is the 109% Super White in a TV video legal level signaling.

We can set ColourSpace that we need 124 nits as a fixed target.

When we need a specific nit level output, the user can use the Settings -> Luma Target and enter the luminance (nits) level manually using the keyboard.

It will simplify the graph's calculation.

Disable the 'AUTO' radio button, since you don't want the software to recalculate the Target Luma target after every 255.255.255 patch measurement.

We will disable AUTO as we need to have a fixed Luminance target.

We can enable AUTO after the end of the pre-calibration.

Then go to Manual Measure page:

For the users who found the RGB widget small to decide what adjustments to apply, they can select the RGB Balance Chart and use the zoom of the graph to focus on the 109% White only (1.0 to the chart).

According to the RGB balance pre-calibration procedure we suggest, the users will have to use the Service Menu and the RGB-High controls to pre-calibrate the 109% White RGB balance.

The RGB-High value of 192.192,192 in SM will provide the maximum dynamic range of the panel.

We will aim to keep the highest possible dynamic range of the panel, so we will have to keep one of the RGB-High values to 192 and reduce only the other two channels to minimize the RGB Balance errors.

Set RGB-High @ 192.192.192 and take the first measurement.

Then look at the RGB balance chart; the White line is the perfect RGB balance indicator.

R,G,B lines will show us if we have more or less luminance to each color channel.

We will keep untouched (so 192 value) the color channel we will see to have less luminance than others.

LG OLEDs native panel response will have a 10-11K color temperature, so the blue channel and green will have more luminance compared to red.

As you see to the chart, red has a lower luminance compared to the other two color channels, so we will keep the Red channel at 192 value and reduce the other two channels only.

The same logic will work with any other display/projector. We keep to the default value (0, for example) the color with lower luminance.

When you look at the RGB widget, the RGB bars have a negative direction as our peak output is lower from the target.

If you want to exclude Y error from RGB Widget, you can enable 'Chroma only.'

Now it will be easier to handle RGB balance errors using the GB-High controls, while the Gray bar, which has a negative direction, can be used as an indicator to increase OLED Light to increase the light output, as we have only 100.8 nits.

 

[Rolls-Royce]

Excellent write-up, Ted!

 

[ConnecTEDDD]

ColourSpace Hardware Menu

An overview of the ColourSpace Hardware Integration menu, and how different hardware can be managed.

 

[ConnecTEDDD]

ColourSpace Patch Sequences

The unique Patch Set capabilities of ColourSpace, showing some of the possibilities for automated and manual profiling when used for display calibration.

 

[ConnecTEDDD]

ColourSpace Overview

An overview of ColourSpace color management and calibration system. ColourSpace enables unprecedented and previously unachievable levels of accuracy and data reporting for display calibration, color management, and color workflows within the professional Film, Post-Production, & Broadcast industries, as well as for Display Manufacturers and Home Cinema enthusiasts.

 

[stama]

Hi, I have a quick question. I want to use the TV as a display monitor, sending it full 8 bit RGB.

What is the best way to profile the TV, in order to create a 3D LUT that will be uploaded to the TV using DeviceControl:
1. TV Black Level = High, TV Contrast = 85, and have ColourSpace display 0-255 patches in its patch display window, or
2. TV Black Level Low, TV Contrast = 85, and have ColourSpace display 16-255 patches in its patch display window, but switch the TV Black Level to High after that when using the TV as display monitor for full range RGB input (like it's done with Calman)?

I think I read that DeviceControl can't upload 3D LUTs which are full range, which would imply I have to pick the second choice, but I'm not sure I have not misunderstood what was said.

 

[ConnecTEDDD]

Hi, I have a quick question. I want to use the TV as a display monitor, sending it full 8 bit RGB.

What is the best way to profile the TV, in order to create a 3D LUT that will be uploaded to the TV using DeviceControl:
1. TV Black Level = High, TV Contrast = 85, and have ColourSpace display 0-255 patches in its patch display window, or
2. TV Black Level Low, TV Contrast = 85, and have ColourSpace display 16-255 patches in its patch display window, but switch the TV Black Level to High after that when using the TV as display monitor for full range RGB input (like it's done with Calman)?

I think I read that DeviceControl can't upload 3D LUTs which are full range, which would imply I have to pick the second choice, but I'm not sure I have not misunderstood what was said.

Hi,

LG TVs are not suitable to work correct and accurate with a PC 8-bit full range signal as the TV's whole internal processing is performed using YCbCr.

The LG templates of Device Control doesn't have any limitation.

The method of profiling with 16-255 with HDMI Black Low and after the end of the calibration to switch to HDMI-Low, is not recommended.

The TV will never work correctly with the RGB-Full range signal, and it doesn't matter if you send any LUT or not send anything.

When you send an 8-bit Full Range, you will see immediately banding as the panel will work in an 8-bit mode. (with PC icon enabled). It will add some issues to the low end also.

If you want to use the LG only to watch movies from your PC and your video player can playback the movie as Video Levels (not expand it to PC level), then set your GPU to RGB-PC Levels and the LG to HDMI Black Low.

Profile with 16-255 pattern.

In that case, only the movie from your player will have correct levels, and your desktop will have incorrect levels.

If you want the LG to work globally for your PC, then set GPU to YCbCr and profile the TV with 16-235 patterns.

Apply Videoscale sub-black filter.

Don't name any LG HDMI input as a PC.

 

[stama]

Thanks for your reply. My intent is for the calibration to work globally, indeed.

Visible banding when encoding image data using only 8 bits is normal for a BT.1866-like EOTF, as those 8 bits are not enough to keep differences between the encoded values above the visual difference threshold. Even using 12 bits starts to show banding above 60 nits for such a EOTF. This is based on the Barten formula for contrast sensitivity function, and there are some nice graphs at pages 18-19 in the ITU-R BT.2390-8 report that illustrate it.

The reason why this is not visible with TV broadcast content, or mastered movie content, is because that content already has noise baked in which hides this banding. The output of a PC graphics card however usually does no dithering when the output is RGB, which is why a display that does no extra processing to hide it will display banding. In this respect, the LG OLED TVs are behaving as expected when using RGB and setting the HDMI as PC input. Display monitors do internal processing to hide banding in fact, many professional-grade display monitors that have 8-bit panels are driven using just 7 bits and FRC instead for this reason.

In contrast to the RGB output case, a nvidia graphics card will always dither its YCbCr output, which hides banding. The TV will do extra processing on top of that, introducing additional noise that helps hiding that banding even more. The fact that the LG OLED TVs use such tricks can be made shown with some 12-bit grayscale gradient patterns, which will show a smooth gradient when displayed alone, but as soon as you put the window of some program on top of the grayscale ramp, the nice smooth gradient of the grayscale breaks apart. There were already tests carried out and results shared in the CX threads on this topic.

So, while I can't argue whether the LG OLED TVs perform internal processing in a YCbCr pipeline or RGB pipeline (but I'm sure some conversions from one to another do happen as some picture controls imply transformations on YCbCr data), having banding visible in PC mode with 8 bit and even 12 bit RGB in SDR is not a "fault" in the TV, it's the expected result from a display device that does not try to mask the inherent banding of the content by using dithering. I personally prefer to use RGB output and have the content faithfully represented with banding (visible banding doesn't happen that often, anyway), than incur the loss of half the chroma spatial resolution by using YCbCr 4:2:2. It's not just text that looks bad, the colors of fine details are affected too. The banding is visible when using YCbCr 4:4:4 as well, so using YCbCr is not a cure for this issue as long as one wants to preserve full chroma resolution.

Considering this, can I profile the display using the first choice in my previous email or some other way, or is there no way to use ColorSpace and DeviceControl to create and upload 3D LUTs to the TV for full RGB input signals (pretty much the same issue that exists with Calman)?

 

[ConnecTEDDD]

Thanks for your reply. My intent is for the calibration to work globally, indeed.

Considering this, can I profile the display using the first choice in my previous email or some other way, or is there no way to use ColorSpace and DeviceControl to create and upload 3D LUTs to the TV for full RGB input sinals (pretty much the same issue that exists with Calman)?

LG OLED's specifically can't initialize full-range 3D LUT because of the issue as explained above. It doesn't matter what software you will use.

Using ColourSpace/LightSpace, you can generate whatever levels you like; the TV cannot process a full range of 3D LUT.

TV needs a 0-1023 LUT, but the 64 is mapped to 0 of that LUT.

When you measure using 64-1023 patterns, the software will send 0-1023 LUT to TV. (64 mapped to 0 of the LUT)

The TV has 0-1023 LUT, but the black is mapped to 64 with HDMI Black Low.

So the only way to use RGB-Full range profiling (with any LUT software, it doesn't matter which you will use) is to profile with 16-255 and HDMI Low and change to HDMI High after calibration.

So the TV will map your LUT to 0.

If you verify, you will see other errors added, and your picture will not look as good.

TV processing will add banding and problem to near black; you can verify and see the issue.

You can also measure the added errors if you load your correction as active LUT in ColourSpace (not to internally to the TV .measure 1000 colors) and then upload the LUT to TV and measure 1000 colors.

Then compare these two measurements to understand how much more errors are added using that method.

 

[Nanekiu]

LG OLED's specifically can't initialize full-range 3D LUT because of the issue as explained above. It doesn't matter what software you will use.

Using ColourSpace/LightSpace, you can generate whatever levels you like; the TV cannot process a full range of 3D LUT.

Hmm i'm also curious about this as i run a HTPC/entertainment setup, so that means that GPU RGB FULL > HDMI level high is not possible, what about calibrating with contrast at 100, i think i read somewhere that changes how the LUT is handled, or alternatively would sending RGB Limited be okay, as it seems the conversion to YCbCr from NVIDIA is sub-standard somehow as it shouldn't really lower the available color gamut around 3-5% right?

 

[ConnecTEDDD]

Hmm i'm also curious about this as i run a HTPC/entertainment setup, so that means that GPU RGB FULL > HDMI level high is not possible, what about calibrating with contrast at 100, i think i read somewhere that changes how the LUT is handled, or alternatively would sending RGB Limited be okay, as it seems the conversion to YCbCr from NVIDIA is sub-standard somehow as it shouldn't really lower the available color gamut around 3-5% right?

When TV is working in with HDMI-High, it will add banding and problem in near black.

Option 1: Calibrate with 16-255 HDMI-Low and after the calibration set HDMI-High (but you will have banding)...with GPU RGB-Data.

Option 2: Calibrate with patterns generated from ColourSpace 0-255, set GPU YCbCr 10bit, Contrast 85, HDMI-Low, and apply Videoscale sub-black before exporting for DeviceContro.

Option 3: Calibration with patterns generated from ColourSpace 0-255, set GPU RGB-Limited, Contrast 100, HDMI-Low, and no need to apply any videoscale filter.

Options 2+3 will not have the additional banding/issues like Option 1.

Your gamut will have no problem as you measure with patches generated from your GPU, so your whole video signal chain is calibrated.

 

[stama]

Thanks Ted for your reply.

My experience with Calman is as you hinted to: a verification performed with the TV in Black Level = High after profiling the TV with Black Level = Low and uploading to it the 3D LUT created after profiling shows the calibration is not as good as when the TV had its Black Level = Low. So this is not the perfect way to calibrate the TV for full range input.

However, there must be more to it.

I've been using for the past 6 months a 3D LUT created with DisplayCal/argyll and uploaded to the TV using the aiopylgtv utility. The profiling was done for RGB 8 bit full range input with the TV in Black Level = High mode and the HDMI input set as PC, the 3D LUT (which is not in DeviceControl format, but just a IRIDAS cube file) was created and was uploaded to the TV, and everything was fine.

The developer which added this capability to the aiopylgtv utility has a thread on this forum (@theMule), but most of the details are found in the thread on the DisplayCal forum.

He has investigated what Calman does and I think he said the range of the 3D LUT data in a Calman 3D LUT file can be specified in the header of that file. I don't remember if the data is then uploaded to the TV as is, or whether Calman does by itself level mapping before uploading that data to the TV.

I did not have a look at the aiopylgtv source code, but I believe it does not do full range to limited range mapping of the data points before uploading them to the TV, either. In this case either aiopylgtv does this wrong, or the 3D LUT inside the LG TV is full range.

There were several other tests carried out, and he noticed that a full range RGB 10 bit input signal of 0-1023 is mapped to the entire 3D LUT range of 0-4092, though that mapping is not quite perfect - it has some clipping and the alignment is not perfect.

Maybe @theMule can give more info, maybe some of the things I wrote here were misunderstood by me, but it seems the 3D LUT in the TV is indeed full range, with perhaps some scaling applied to it, or maybe it's just a different rounding convention than the one we expect.


Oh yes, and I wanted to say that I did not experience "banding" in games - which are a real source of full RGB content - (except on very very few occasions with a blue gradient sky), or problems near black while I used the 3D LUT created for full range, so the 3D LUT must have corrected for that. The banding which is visible on test patterns is the expected one for 8 bit SDR signals, as I wrote above. The appearance of no banding with YCbCr is because the GPU is doing its best to hide it by dithering its output, then the TV is doing its best to hide it by adding noise and dithering, and finally because the YCbCr TV broadcast/movie content a TV displays had noise added to it in the production chain (see the ITU report I mentioned) that masks banding, not to mention it might have also been created from a higher resolution content by dithering to 8 bit too.

 

[stama]

I posted a new reply instead of editing the previous one.
Please delete this...

 

[ConnecTEDDD]

The header is not used from the TV, and you don't send a header to the TV.

The thread is dedicated to ColourSpace here.

If you want to find out what CalMAN or DisplayCAL is doing or post your experience by using them, you can post that feedback/questions to other threads.

We want that thread to be clean from issues not related to ColourSpace.

I used 10-bit values to simplify the example, 3D LUT stored in 12-bit.

 

[stama]

Sure, I understand that this thread is about ColourSpace.

The issue discussed is not other software packages but the TV 3D LUT range. This range seems to be full range not limited range. If I don't bring any evidence then I have no grounds to prove my claim. And this evidence lies in what other software does.

Thank you for the three choices you mentioned, I'll try and see what results I get.

 

[ConnecTEDDD]

The data are 0-1023 but black, the video black you measure it's mapped to 0 of the LUT data, all these explained before some years, I have available that info to my site also, from 2018.

The problem is located about how TV handles the LUT, and how it's designed internally.