[rascas]

I dont know much about how the raspberry pi manages this and also Kodi on it but I know that it is the only way to change it on the Raspberry Pi. Or changing the Kodi source code, I never had a look at the code about it. Maybe @popcornmix can explain you this better.
What gives the best image quality I think it is the default if the edid is correct, but you can always force another mode and see if it looks better for you.

[wesk05]

But, given that it does that, my previous question stands: wouldn't we get better output by setting the Pi to output RGB full rather than RGB limited? (And if not, why not?) 

 If Kodi is using the Y'CbCr to R'G'B' matrix conversions given in the code that @FernetMenta linked to in the other thread, then it is converting it to RGB Limited. I would think that it would scale/remap only when the output pixel encoding is set to RGB Full.

I personally am of the opinion that RGB output should not be used for video because most displays apply sRGB gamma to RGB input instead of BT.1886 gamma. There is also the additional issue with BT.601 color space that I mentioned in the other thread. A while back, I had looked at the bit accuracy of RPi2 YCbCr output and there were some insignificant rounding errors . I am not seeing that now. Because the final output of a display is RGB and a YCbCr input will bring in additional conversion some folks recommend RGB input, but that rationale doesn't really hold because most display processors work in the YCbCr domain. Lumagen does suggest RGB input (their CMS works in linear RGB) and YCbCr 4:2:2 output. So, in your case RGB output should be OK, but keep in mind that you may have issues with upscaled NTSC content.

[User 309201]

Not all displays are RGB. Mine is an LG OLED TV, and the sub-pixel structure is RGBW, not RGB, so there isn't necessarily a conversion to RGB before the signal hits the pixels. And the signal sent from the Lumagen to the screen pretty much has to be YCbCr 4:2:2 (because the TV can't fully resolve 4:4:4 - or at least it sort of can, but not without disabling some rather vital image processing).

Converting between component and RGB (or vice versa) should be more or less lossless, though I suppose there could be rounding errors - I'm slightly more inclined to trust the Lumagen to convert from RGB to component than the Pi - but I doubt it makes that much difference.

The things I want to avoid are A: doing more transformations than are necessary, and B: (particularly important) to avoid doing any unnecessary mapping between limited-range and full-range (or vice versa) - that's where the significant errors are going to creep in.

(I'm a bit dubious about BT.1886 gamma. How many things are really mastered with a gamma of 2.4? I think almost everything is actually mastered at 2.22.)

One thing that's still bothering me is: if the Pi is working internally with limited-range RGB, and also outputting that, why do below-black and above-white get clipped?

[rascas]

Who said that the Pi is "working internally with limited-range RGB" ? I never saw that in the documentation...

[wesk05]

Not all displays are RGB. Mine is an LG OLED TV, and the sub-pixel structure is RGBW, not RGB, so there isn't necessarily a conversion to RGB before the signal hits the pixels. And the signal sent from the Lumagen to the screen pretty much has to be YCbCr 4:2:2 (because the TV can't fully resolve 4:4:4 - or at least it sort of can, but not without disabling some rather vital image processing).

Converting between component and RGB (or vice versa) should be more or less lossless, though I suppose there could be rounding errors - I'm slightly more inclined to trust the Lumagen to convert from RGB to component than the Pi - but I doubt it makes that much difference.

The things I want to avoid are A: doing more transformations than are necessary, and B: (particularly important) to avoid doing any unnecessary mapping between limited-range and full-range (or vice versa) - that's where the significant errors are going to creep in.

(I'm a bit dubious about BT.1886 gamma. How many things are really mastered with a gamma of 2.4? I think almost everything is actually mastered at 2.22.)

One thing that's still bothering me is: if the Pi is working internally with limited-range RGB, and also outputting that, why do below-black and above-white get clipped?

Pixel substructure of a panel is not relevant here. As for the issue with RGBW, it is my understanding that it doesn't affect the LG OLEDs. It only affects the LG LCD/LEDs which has a substituted & shared white sub-pixel for every fourth pixel. OLEDs have independent white sub-pixel for all pixels.

BT.1886 has a technical gamma of 2.4 (the exponent used), but an effective gamma of about 2.2. It is not a pure power function. Professional studios are to follow BT.2035 recommendation that expects the master displays to be calibrated for BT.1886 gamma.

Pi hard clips 16-235. This is why you don't get super white/black.

I checked my old notes and tested again today. YCbCr output is a non-starter for the Pi2. I had mentioned about these errors long time ago (https://forum.kodi.tv/showthread.php?tid...pid2023415), but I never checked the errors in detail. It appears that the Pi2 actually uses BT.601 matrix to convert from RGB to YCbCr. I am kind of surprised that this error has gone un-noticed this long. Also, Pi2 sets the colorimetry bit in the AVI InfoFrame to BT.709 even when the content is BT.601.

[rascas]

Pi hard clips 16-235. This is why you don't get super white/black.

Still didn't get any proof of this... You can select RGB Limited, RGB Full, etc output in config.txt. If it is accurate on a professional level, that I don't know.
On my TVs I generally find the default setting (generally RGB Limited) to work the best but I have a Pi connected to a monitor which gives me better whites and blacks if I select RGB Full compared to limited.

[wesk05]

Still didn't get any proof of this... You can select RGB Limited, RGB Full, etc output in config.txt. If it is accurate on a professional level, that I don't know.
On my TVs I generally find the default setting (generally RGB Limited) to work the best but I have a Pi connected to a monitor which gives me better whites and blacks if I select RGB Full compared to limited. 

I use HDMI analyzers to verify these things, but you can easily verify it yourself using an appropriate test pattern. Try this test pattern (Black & White Steps) and check whether you can see any of the squares below 16 or above 235 flash.

[rascas]

Well I just tested that file on a RPi 3 with a cheap ASUS vp228h monitor, without any color calibration, and I can see the diference in 14 to 25 (blacks) and from 230 to 236 (whites), more or less. This is with RGB Full, by default the Pi sets this monitor as RGB Limited. With RGB Limited I notice a little less blacks and whites (almost no difference), but RGB Full gives a better overall image quality in this case in my opinion.
I have to test it on another Pi connected to a better LG TV and also on my PC.

[rascas]

Well, I just tested this on a better LG TV and it is about the same as the Asus monitor, so you are most likely correct about the Pi clipping <16 and >235.
What is curious is that I also tested it on a x86 Intel PC with a Nvidia 5xx series graphics card running Ubuntu 16.04 connected to a Samsung monitor also via HDMI and the result is also about the same  . I have to get more information about this 

[wesk05]

It is a fact that super black & white are clipped on the Pi if the video range flag is limited (which would be the case with almost all commercial/broadcast videos). It is possible that it will not clip if the video range flag is set to full. I haven't checked that. Here is the same test pattern with a full range flag in the VUI: Black & White Steps Full Range I do have to say that this is really a problem only if want to use the Pi as a source for calibrating your display.

[Soli]

Well, I just tested this on a better LG TV and it is about the same as the Asus monitor, so you are most likely correct about the Pi clipping <16 and >235.
What is curious is that I also tested it on a x86 Intel PC with a Nvidia 5xx series graphics card running Ubuntu 16.04 connected to a Samsung monitor also via HDMI and the result is also about the same  . I have to get more information about this 

If you set nvidia to limited it does double scaling in the gpu in the last step before it's sent to the display.. Kodi will always "see" the full range. This is what all the GPUs do it. (Team red/blue/green)