[quote=“shadow, post:1, topic:1115, full:true”]I do have expert settings level set. On my XBMCbuntu system the correct option is
system > video output > use limited colour range
I need that off on OSMC but can’t find it[/quote]
I just found this quote in an old topic.
Why is this option missing?
Has anyone checked Kodi 17 on RPi to see if the option is available there?
So I tried a Kodi 17 test build and… “use limited color range” is also missing!
Can we please get that option added back in?
You need to set it in config.txt. Then you can verify it with tvservice
I did that. The RPi hardware is set correctly. Kodi must be interfering. That’s why there should be that option in the settings.
Just to proof that RPi is set correctly. But Kodi still scales from 16-235 to 0-255. If the Video has BtB (0-15) and/or WtW (236-255) that information is lost.
Having the same issue here. The missing option within kodi itself is different from setting the actual gpu of the pi
Both the gpu and and tv are setup correctly, but because of this missing setting its crushing blacks really bad.
Would be a big help to get this option back. Or some hint as to where we could change this manually.
EDIT:
Tried changing this setting in kodi’s settings file manually, but it seems it it overwritten at start, so my guess is that it is done by osmc for some reason.
Did you stop Kodi before making the edit? This is necessary.
I did not before, thanks for the warning, but it did not work.
This is what i did:
sudo systemctl stop mediacenter
Then i changed:
<limitedrange default="true">false</limitedrange> -> <limitedrange default="true">true</limitedrange>
in the guisettings.xml
But upon reboot, it changed it back. Am i doing it wrong?
It is meant to be. 0-15 and 236-255 values in a limited range signal are illegal and should be clamped.
Why would non-Raspberry Kodi have the option “use limited color range” then?
I want Kodi Limited → RPi Full → TV Limited like described here: http://kodi.wiki/view/Video_levels_and_color_space
P.S.: I tried LibreELEC Kodi 16 and Kodi 17 and the option is missing on both of them too.
Another P.S.: Got an explanation here LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
Hi,
To calibrate properly a HDTV with à HD calibration disc it’s importants that TV could “see and show” blacker than black and whiter than white colors.
In order to do that, the full chain from reader (OSMC Kodi), GPU, TV must be setup correctly.
The correct setup should be done as explain in : http://kodi.wiki/view/Video_levels_and_color_space.
The only problem that make it impossible with OSMC is that (like Korrigan said) the option : system > video output > use limited colour range , dos not exist on the GUI.
I can understand that for some reasons developpers don’t want to put this option on the GUI but :
Is there a way for people who want to test this option to do it ?
Even if we have to edit guisettings.xml or any other settings files at our own risk?
After stop the mediacenter with :
sudo systemctl stop mediacenter
I tried to modify the guisetings.xml like this
<limitedrange default="true">true</limitedrange>
but It cames back after reboot to :
<limitedrange default="true">false</limitedrange>
So I tried :
<limitedrange>true</limitedrange>
It stays after reboot but it seems that it’s not working.
Is this the right method?
Do I have to write somethings in advanced settings ?
Or is it simply impossible to do ?
Ok after more time searching and trying to understand I think I hundersand (not sure 
)…
No need to set anything to full, TV is done for limited, that’s the point.
But : to calibrate TV’s brightness, some blurays or files contain BtB and WtW, and I read on : RGB: Full vs. Limited – ReferenceHT
What about Superwhite mode on a PS3 or PS4?
A: Superwhite enables YCbCr values over 235 (or 240 in the case of Y)
to be displayed < … >It doesn’t expand the dynamic range, it just allows
values greater than the usual peak to pass through.
popcornmix said :
It is meant to be. 0-15 and 236-255 values in a limited range signal are illegal and should be clamped.
Is there a way not to clamp them with a “Superwhite and superblack OSMC mode” 
?
If I understand correctly he meant that OSMC looks at the video information (it should say if it has superwhite/black or not) and then sets the range accordingly.
I’m still not sure why the option to set it manually was ever removed though… (because I and some others would want to use it it seems)
I tried to read à mkv file that contain superwhite/black information on my TV:
_ once with OMSC (not displaying BtB and WtW)
_ once with my computer Kodi and “limited color range” unselected (not displaying BTB and WTW)
_ once with my computer Kodi and “limited color range” selected (displaying BTB and WTW)
So I think some videos can inform that they are limited (because done for TV) but contains anyway colors in 0-15 and 236-255 (like blurays).
But if OSMC reads in the video informations that it is limited it automaticaly clamps 0-15 and 236-255.
In fact I think this “limited color range” is not realy what we need in OSMC, wath we need is that OSMC does not clamp this information, even if it should “normally” not exist.
1 Like
Are there any news on this topic? I also want to set the player in osmc to limited as I already set the gpu to RGB full (checked with tvservice -s) and my projector to limited. But in white and blsck clipping test patterns I still dont see btb or wtw. If I play the patterns on my bluray player with same projector settings btb and wtw are displayed 
If I set raspi gpu to RGB full my projector defaults to RGB full, too. As wtw and btb are clipped I assume player is set to RGB full as well. So full, full, full.
If I set raspi gpu to RGB lim my projector defaults to RGB lim, too. As wtw and btb are again clipped my assumption is that player is still in RGB full. So full, lim, lim.
I cant get the osmc player to display in lim, so I am not able to display wtw that way.
That’s what we are all asking on this thread…
But I think it’s not a priority for developpers because the signal given by OSMC is “correct” even if it is not allowing correct calibration for our devices…
Too bad that there is not even a workaround… would save us some single (full, full, full) and even double (full, lim, lim) scaling 
Hope we get a solution sooner or later.