Washed out blacks -- Edit: solved for content but bars still grey

Help and Support Vero 4K / Vero 4K +
1

Hi from Australia!

I just received my Vero 4K+.
I’ve done a lot of research on this issue in this forum and suggested links, but I’m still stuck.

I am getting washed out (grey) blacks on both the content of the videos and the letterbox bars. Even the black background of a test pattern PNG file is washed out. It’s happening both on my Christie HD6K projector and a small Eyoyo monitor. With my previous media player, a cheap Wintal model, all the above-mentioned black levels were always true black.

I read and understood the article Video levels and color space.

I’m aware of the significance of the option:
“Use limited colour range (16-235)”
The blacks remain identically washed out whether or not I enable it, which is strange.
I would have expected some difference.

[Edit: This is not correct. There actually is a difference. With Limited, the content now shows true blacks, but the letterbox bars remain washed out.]

The above setting is for KODI. Then there’s the GPU.
Is it possible that the GPU is set to Limited?
The article I linked to above says to set the GPU to output Full.
They say to use the xrandr command, but I see that this is not available.

Questions:
Is the GPU set to Limited or Full by default?
If it’s set to Limited, how can I set it to Full?
Can anyone suggest the next steps I should take?

Thanks,
Richard

2

Yes, there should be a difference. The article you linked does a good job of explaining limited vs full, but it’s based on a different architecture. We take the value set in Kodi and apply that to the GPU. You also need to know that if you send a YUV signal to a display, chances are it will ignore the flag which says ‘this is full range’.

Can we get a better idea where you are starting from? Logs will show us, with mediainfo for the content you are trying to play:

To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.

Depending on the used skin you have to set the settings-level to standard or higher, in summary:

  • enable debug logging at settings->system->logging

  • reboot the OSMC device twice(!)

  • reproduce the issue

  • upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A

  • publish the provided URL from the log set upload, here

Thanks for your understanding. We hope that we can help you get up and running again shortly.

OSMC skin screenshot:

image
image957×540 224 KB

3

Thanks. The log is here:
https://paste.osmc.tv/ewitopiluy

I can confirm that I am seeing the washed-out blacks on all content that I test, including:

  • Blacks within videos
  • Letterbox bars
  • Test pattern PNG images containing black

By the way, the grey level seen in the letterbox bars is identical to the grey level of “blacks” in the content. For example, when the content fades to “black” for the credits, it becomes the exact same grey as the letterbox bars.

With my old Wintal media player and the Vero 4K+ connected to a receiver amp, and with the identical media file playing on both, I can flick between them using the amp’s input selector, and the difference between the WIntal’s black and the Vero’s grey is very obvious. Similarly, the amp’s internally-generated black (such as the amp’s menus) is clearly more black than the Vero’s grey.

I’ve also taken the receiver amp out of the loop, and compared both players when each is connected directly to my small field monitor, and have seen the same difference in the blacks.

The fact that the blacks remain identically washed-out whether or not I enable “Use limited colour range (16-235)” does seem like a clue. Could there be something stopping this setting from working?

[Edit: This is not correct. There actually is a difference. With Limited, the content now shows true blacks, but the letterbox bars remain washed out.]

Thanks in advance for any clues.
Richard

4

I’m not sure why, but the full-range setting in Kodi isn’t getting through. You will have to set it directly. Instead of xrandr, you can try this:

echo fullnow | sudo tee /sys/class/amhdmitx/amhdmitx0/attr

I can’t tell which display you had on when taking the logs, but from the symptoms it looks like both your monitor and PJ don’t do limited range. We can therefore make the change permanent.

To do that, if the above command fixes things, you can put a line into /etc/rc.local, just before exit 0.

echo 2 > /sys/module/am_vecm/parameters/range_control

5

Thanks. The log was taken while connected to the small field monitor. I have now done additional tests described below. (This is prior to any modifications like the ones you suggested.)

I tested with yet another display, this time an ordinary Teac TV which surely expects 16-235 (limited). This still shows the same washed-out blacks.

To summarise, I have tested with all these displays:

  • Christie projector
  • Eyoyo field monitor
  • Teac television

With all the above displays, I get true blacks when supplied by these sources:

  • Wintal media player
  • Samsung Blu-ray player
  • Denon receiver amp’s menu screens

So I don’t think it’s a case of all my displays expecting 0-255 because, apart from that being unlikely in itself, it would mean that all 3 sources would need to be supplying 0-255 to achieve those true blacks, which seems unlikely.

With all these displays, I get washed-out blacks when supplied by the Vero.

The odd one out is the Vero. It suggests that it’s compressing the range even more than the 16-235 that the displays are surely expecting, like the Limited-Limited-Limited scenario mentioned in the article that I linked.

Based on this, do you still recommend that I perform the modifications in your last post?

Regarding your first suggestion:
echo fullnow | sudo tee /sys/class/amhdmitx/amhdmitx0/attr
Am I right in thinking that this is non-permanent and will be negated upon reboot?

Richard

6

I can’t comment on that without knowing your display settings. If you set output to YUV and limited it should just work with a bog-standard TV. If it doesn’t, please post logs again.

Yes.

Monitors typically don’t support limited range. Yours definitely doesn’t. Your PJ has only a DVI input (unless you have the add-on HDMI board) which hints that it doesn’t support limited range. Logs with the PJ connected would confirm that.

Update: I’ve been testing a vero with the same set-up as yours. One thing that isn’t obvious (the on-screen help text got mixed up in a recent Kodi update) is that to change from RGB to YUV and vice-versa you need to reboot. That is not necessary with changing from full to limited and back.

Leafing through the HD6K manual (it’s not HD6K-M??) it seems possible it supports only RGB (not entirely clear). There’s a black level adjustment but no mention of ‘limited’ or ‘full’ range. It seems to have been designed when analogue video was king and digital was a new thing, at least for the professional uses it’s targetting.

7

Thanks. I need to update my comment about the symptoms.

I had been using a test pattern PNG image when I did those further tests showing the blacks remaining washed out with the various sources/displays no matter the setting of “Use limited colour range”. However, it seems I should have been using a video source, because I can now report:

Setup:
Vero => Denon AVR1713 amp => splitter => TV
MP4 video with high aspect ratio 2.76:1 resulting in letterbox steps top and bottom.
Force RGB output: OFF for both tests below. (I noted your point about reboot needed.)

Use limited colour range: OFF
Result: True black in content, washed-out black on letterbox bars
Log: https://paste.osmc.tv/figewanivi

Use limited colour range: ON
Result: Washed-out black in letterbox bars AND content
Log: https://paste.osmc.tv/tiharutaho

The command line hack you suggested:
echo fullnow | sudo tee /sys/class/amhdmitx/amhdmitx0/attr
did not have any effect, and the “Use limited colour range” continued to have the results described above.

Now, I don’t know the effect of passing the signal through an AVR and splitter, but I naturally tend to think “What about testing with the Vero directly connected to the TV?”
Well, I tried this, and after powering on the Vero, I get the blue splash screen on the TV, followed by blackness forever.

Also, if I type kodi at the command prompt, I again get blackness forever.

I have idea what is going on but maybe that is a clue?

(I got myself able to see the above-mentioned command prompt by starting with Vero => amp => splitter => TV so I have a picture, switching to the CLI, then plugging Vero directly into TV.)

About the projector…

Yes, HD6K (not -M).
It has DVI input and I’m using an HDMI to DVI adaptor plug (passive).
The manual shows the specs for the DVI-I input, and says signal types it supports are:

  • RGB (Analog or Digital
  • YPbPr (Analog)
  • YCbCr (Digital)

I did some tests with the projector.
Same result… Letterbox bars washed out even with full range (limited: OFF) as shown below.

Setup:
Vero => Denon AVR1713 amp => splitter => Christie HD6K projector (DVI input)
MP4 video with high aspect ratio 2.76:1 resulting in letterbox steps top and bottom.
Force RGB output: OFF for both tests below.

Use limited colour range: OFF
Result: True black in content, washed-out black on letterbox bars
Log: https://paste.osmc.tv/ziqetuqoca

Use limited colour range: ON
Result: Washed-out black in letterbox bars AND content
Log: https://paste.osmc.tv/nenuzuhisa

So at the moment, with Use limited colour range: OFF, I can get good blacks in the video content, but the letterbox bars are washed out. And so are the blacks in images (at least the PNG I tested with known 0,0,0 black).
The issue is seen on both the ordinary Teac TV and the projector.
I note also that the command line interface has a washed-out black for the background, in case this is a clue.

Is there anything I can do about the washed-out blacks in letterbox bars of videos… and in still images?

I see there are some other discussions about this:
Black bande are grey
Grey bars when watching video that doesn’t match screen size

Richard

8

Well you do have a unique setup, the details of which are gradually coming out. Thanks for the testing and logs, but the presence of the splitter could be crucial. These things don’t always pass through the information about the displays (EDID) that the source needs to decide what signal to send.

If you haven’t despaired yet, can you get a log with the vero plugged into the projector directly and then with it plugged into the TV. If you don’t get a picture you can ssh in and issue grab-logs -A. That will give us the EDIDs and indicate why you get a black screen. What’s the model of the TEAC?

Something else I discovered yesterday is if you change full to limited or v-v the change doesn’t take effect until you play a video. So displaying a PNG immediately after that change won’t show a difference.

I’ll look at your logs later and see if I can reproduce what you are seeing - just going out now.

9

Thanks again.

<BTW on the separate topic of PNG image files, I confirm PNG image shows washed-out blacks even after playing a video to force the change to “Use limited colour range: OFF”. This is with “Force RGB output: OFF”. And it’s also happening with Vero connected directly to projector.>

Here we go with the direct-to-projector test:

Setup:
Vero => Christie HD6K projector (DVI input)
MP4 video with high aspect ratio 2.76:1 resulting in letterbox bars top and bottom.
Force RGB output: OFF
Use limited colour range: OFF

Result:
True black in content, but washed-out black on letterbox bars.
Log: https://paste.osmc.tv/eyozesejat

So the grey bars are even happening when direct from Vero to projector.

As for the TV, I only brought it up from the kitchen for an additional data point to add to the projector and Eyoyo field monitor results. It’s a TEAC and the model is LCDV3255HD. It’s pretty crappy and I have no plans to use it with the Vero. Is there any point doing a log with it, considering I won’t be using it and we seem to have an answer from the projector test? But I will if you still would like me to do it.

I’ll be interested in any info you can glean from the log connected to the projector and would love to know what part of the log you are looking at to tell you what’s happening.

Do you think we can rule out the splitter, since the grey bars are happening with Vero–projector directly?

Thanks,
Richard

10

OK. The bad news is your projector isn’t telling the world it can can’t handle YCC video and it can’t recognise limited range input. The good news is:

  1. We don’t care about RGB/YCC - vero is still sending YCC falling back to RGB and the projector is happy with that
    2. Your projector can display full range video using either RGB or YCC (as I say many TVs don’t do YCC full range) You can therefore choose either - I recommend YCC as it avoids an extra conversion step in Vero.
  2. The splitter isn’t affecting things for the projector (it may be for the TV but as you say that’s irrelevant)

I’m not sure what was going on with your first set of tests - the log showed you had limited range set.

The remaining problem - letterbox mattes being the wrong colour is down to Vero. I can reproduce that. I’m not sure why this has never been fixed but 99.9% of users are watching on TVs or projectors that accept ‘standard’ limited-range video so we don’t get many reports. I was supposed to be following up on one of those threads you found :roll_eyes:. The problem is fixed in the new version of OSMC we about to roll out but I’ll see if there’s a hack you can use in the meantime.

11

Thanks for your quick support with all of this. It’s been a steep learning curve and now I know heaps more than I did in my early posts which had some premature conclusions! I also discovered with embarrassment that the blacks in the PNG image were (16,16,16) not (0,0,0) :open_mouth:

I’m not sure what was going on with your first set of tests - the log showed you had limited range set.

This may have been because I didn’t realise until later that you need to power cycle to get rid of old log data, so there may have been multiple video playbacks included in the log including the relevant one occurring just prior to upload. Just a theory.

Out of curiosity:
I looked at the EDID part of the latest log with projector connected (pasted below). I see text saying “YCC support”. But you mentioned that the projector is not broadcasting its YCC capabilities. Can you explain your thinking here?

====================== EDID =================== wE0go885
Rx Brand Name: CDG
Rx Product Name: CHRISTIE
Manufacture Week: 1
Manufacture Year: 2006
Physical size(cm): 0 x 0
EDID Version: 1.3
EDID block number: 0x1
blk0 chksum: 0xba
Source Physical Address[a.b.c.d]: 0.0.0.0
YCC support 0x00, VIC (native 32):
ColorDeepSupport 0x00 10/12/16/Y444 0/0/0/0
1 2 3 4 5 16 17 18 19 20 31 32 33 34 39 41 42 43 47 48 49
Audio {format, channel, freq, cce}
Speaker Allocation: 0x00
Vendor: 0x000c03
MaxTMDSClock1 210 MHz
SCDC: 0
RR_Cap: 0
LTE_340M_Scramble: 0

checkvalue: 0xba740000

---------------------- EDID END ---------------

Thanks again and I look forward to the update. I’m very impressed with the support here! On a side note, I imported the Christie projector to AU from London, so it and the Vero have something in common!

Cheers,
Richard

12

I would assume 0x00 means not supported.
Mine reads YCC support 0x03

Most likely just a formatting of our log parser, should read YCC support : 0x00

13

To rephrase it better: YCC support status.

0x00 means not supported

14

OK thanks :+1:
But Graham said that he thinks my projector actually accepts YCC but just doesn’t announce that. If so, what does “not supported” mean? Maybe it just means announcing is not supported?

From the log, can we say for sure that it is using YCC? (I am too dumb to make sense of the log.) I had Force RGB set to OFF but presumably the devices could still agree to RGB.

17

I’m glad we got it sorted. A learning curve for both of us - that Christie looks like a beast! Does it really do 4k or is that just the -M version? No sign of that resolution in the EDID.

The line YCC support just reports the (hex) value in the EDID. 0 means RGB only, 1 means 4:4:4, 2 4:2:2, 3 both 4:4:4 and 4:2:2.

BTW, the line about Deep colour ‘ColorDeepSupport’ works the same way: 0x00 means only 8 bits, not the 10 or 12 twelve bits you would need to minimise banding.

Now you ask, I was wrong - we are not sending YCC at all but sending RGB in all cases - there’s an automatic fallback so even if Kodi is set to YCC we won’t send it if the display doesn’t support it

Mar 02 14:54:38 osmc kernel: hdmitx: video: Bit depth: 8-bit, Colour range RGB: full, YCC: full, Colourspace: RGB

I’ve edited my previous post.

18

Thanks, everything makes sense now.

I look forward to the OSMC update with true black letterbox bars when sending full 0-255 to displays like mine that need that mode.

To answer your question about my Christie HD6K projector:
It’s HD 1920x1080.
It has 3 huge 0.95" DLP chips (red, green and blue).
The 6K in the name refers to 6000 lumens.
It weighs about 40kg and is indeed a beast!

19

Quick question:

When do we think the next OSMC update will be released?

20

See Kodi v19 Matrix is here. Here's what you need to know - OSMC

21

Thanks Sam!