As it happens, I was poking around in Vero’s code today. All the classic colour adjustments - brightness, contrast, hue and saturation are done in the YCC colourspace. The maths is easier.
1 Like
There are displays with panels that have multi-primary color subpixel structure. The subpixels can be PenTile matrix (RGBG - Samsung AMOLED), M+ (RGBW - LG), Quattron (RGBY - Sharp) or RGBYC (Genoa Color).
By nature of my work, I often come across proprietary data. The statement that I made is based on the information that I am privy to. I don’t have access to unlimited information. So, I could be very well wrong on this. I will gladly correct myself when contrary information is provided 
2 Likes
This is a fascinating thread - hope there is a conclusion!
@direx , I have given up my PC/RPi3 combo in favour of the Vero 4K+. It has a decent CPU performance (although not i5 territory but good enough to run TitanMOD skin), the ease, silence, always on mode of RPi3. Couple that with 4K HDR playback, cool & neat look and nigh on perfect calibration, it’s unbeatable.
NB, i have tried external players with my Kodi PC but i can’t do without the OSD/usability of the Kodi player 
Mind you, I am playing with an S905x TV box flashed with LibreElec but more just cuz i like tinkering than anything else. It looks very much like the Vero 4K complete with blue light 
PS bought another Vero 4K+ for my son in the sale.
Wildly off-topic, but have you tried CoreELEC?
I was going to comment on this, but Wesk05 beat me to it. Yes, the assumption that display panels are RGB is a decidedly outdated one. In particular, pretty much all OLED TVs these days use LG-manufactured panels which, as Wesk05 says, have an RGBW sub-pixel structure.
Many TVs are also not capable of fully resolving 4:4:4 chroma information at native resolution.
I think the majority of consumer AV devices nowadays (blu ray players, set top boxes, media players) output YCbCr as standard. RGB has only ever been popular in the computer/PC space (unless you go all the way back to RGB SCART). That’s what TVs expect to receive.
Plus, of course, 8-bit video is generally encoded as black=16, white=235; so, remapping to full-range RGB (black=0, white=255) will cost you accuracy. (The limited/full/limited business is specifically designed to avoid that conversion).
OK, that might explain the color issues I have with my JPEG pictures. The Vero 4K+ is literally the only device where some of my photos show color banding on my TV.
I was not talking about the actual panel technology, just the panel interface. Older panels might have something like an LVDS interface, which is RGB only. Don’t know about OLEDs and other kinds of stuff. It’s probably a proprietary interface these days, I doubt they’ll use eDP for this (LVDS is probably completely out of discussion these days).
That’s what Kodi Dsplayer gives you. Full Kodi controls (even within the player), combined with the power of MadVR. But yeah, that’s off-topic.
Depends on the bit depth. YCbCr 4:4:4 at 4K/60Hz is only possible with 8 bits (HDMI bandwidth limitation). If you need 4K/60Hz and 10/12 bit at the same time, you need to use 4:2:2. RGB is not possible at all with 10/12bit at 60Hz.
Since mainstream 4K material is only available at 24p, this is not really an issue. You’ll get the 4:4:4 at 10/12/bit up to 30Hz. The same applies for Full RGB. That’s why I run my PC Kodi at 4K and 30Hz at 10 bit.
The 16/235 thing should not be an issue, if you keep the Full RGB chain all the way to the display (which is still in discussion here). What is more problematic is “downgrading” JPEG images with Full RGB to the “limited” YCbCr colorspace. That’s where you’ll actually lose information.
If the panel is RGBW then the interface can’t possibly be RGB. Something has to tell the white sub-pixels what to do.
No, it doesn’t. I’m not talking about what signal format the TV can receive, I’m talking about what you actually see on the screen. Even TVs which are capable of accepting a 4K 8-bit 4:4:4 signal aren’t necessarily capable of actually physically displaying all of that chroma information.
Ahh, that makes sense. I thought you ware talking about the signals you can feed to the display, which is what this thread was originally about.
I thought the white LED is just for improved brightness and a “better” white. You could get that out of an RGB signal, depending on how “intelligent” the panel is. But you are right that this would probably not make sense in this case, as it should be cheaper to make the panel as “dumb” as possible. In this case the panel probably has a proprietary connector, which does not know anything about RGB/YCbCr signals.
Which leads us back to the original discussion, how the signal is processed by the display. Or let’s say, which kind of signal can be handled better. The Panasonic support did not send me a reply yet
Meanwhile, back on topic, I have found what we need to do to get videos output in RGB full. Slightly complicated because we deliberately made Vero ignore the incoming video metadata. This was because limited range videos tagged in error with full range in the metadata was showing up and we suspected is quite common.
The problem now is not how to fix it but what controls to bring out into the GUI interface. There will a limited/full range switch as on other platforms, but full range will mean ‘this is full range and we are signalling it as such in HDMI’ and limited will mean ‘this is how the signal came in and we are signalling it as limited range’
The OSD will also output full-range when the setting is on full-range. That, together with setting the GUI to 4k should be as good as it gets without more love from the Kodi devs.
1 Like
Just to add, it won’t screw up YCbCR right? Given that we now know video content is perfectly preserved all the way up the chain with YCbCr.
Only asking as i know Kodi player for Wintel always messes up with changes. There was a time when colour and grayscale ramp calibration was fixed and now it’s messed up again
The OP has submitted a return request, but the conversation is still valid.
It is my understanding that this request needs more thorough discussion in terms of how we handle things through UI.
I’d like to release the final v17 update with potential improvements just before Christmas and release test builds for v18 over the Christmas period.
I think the ideas here warrant further discussion and testing. We don’t want to break anything.
Cheers
Sam
1 Like
Yes, it’s quite common those bad tagged video files specially in HDR rips. I just remove those files as soon as I get one. You can’t expect a consistent behaviour among different players with those ones.
If you change the player behaviour due to “popular”, but bad tagged, files you are, indirectly, breaking “well tagged ones”.
I mean, to make development decisions about default colour spaces, limited vs full, etc… forks inside the code, I think you should stick with realiable/well tagged files. Mainly only full remuxes/rips or well-known sources/demo files.
Get a trustable collection of those files to perform reliable decisions.
No. Not changing that.
It’s a balance to get the maximum number of videos to ‘just play’. It’s been like that since the middle of this year and no-one has complained that their well tagged full-range vidoes aren’t rendering properly. Meanwhile, we get ‘this (badly tagged) video plays all right on other platforms’. Hence the default behaviour is to ignore the tag and have a setting (already available on the commandline) to say ‘yes, this really is full-range’.
I have to admit that a solution from the “players” perspective could be good due to the amount of those files out there.
I’m starting to think that a specific menu to allow users to enable/disable on-the-fly could be a good idea. And maybe a chance to add other options to make your player more versatile and friendly: subtitles, audio tracks 
,. forcing output colour/spaces, range. Default Kodi options doesn’t seem enough to deal with these new demands.
Why not just re-tag them in this case?
If you are referring to my original request I think you got this wrong. Here’s the situation:
- My TV expects Full RGB or YCbCr on HDMI 4 (where the AVR is connected)
- Vero’s default YCbCr output is okay (not more than that). On some images I get color banding. Even in the default Kodi theme (Estuary) there is color banding.
- When I set the Vero to “Force RGB” it correctly switches to RGB. This now looks odd on my TV, because the Vero outputs Limited RGB. Again, the TV expects Full RGB. I could set the TV to Limited RGB, but this will cause issues with the other devices connected through the same HDMI port (through AVR). And Limited RGB is not ideal for watching photos.
- When I use the command line to force “full” RGB, nothing really changes. Things are still looking wrong (including the Kodi UI being too bright). So if you refer to that command you’ve provided above, I must say that it does not really change anything for me right now.
I think this has nothing to do with improperly tagged videos in my case. I would not expect OSMC to handle such broken videos.
Agreed. I understand your use case case perfectly.