Black clips at 85 for Dolby Vision output only **SOLVED**

With VS10 SDR 10-bit remains - that depends on the content and you don't "lose" Rec.2020 but it is mapped into Rec.709 and if you can tell the difference you're better than me - even with test patterns!

But in simple terms, if your display is competent at HDR, then I'd say stick with HDR - certainly with a flatscreen. Projectors are a bit more complicated...

 

Hi Mark,

Did you have a chance to look at my observation on my setup?

http://forum.zidoo.tv/index.php?thr...put-only-realtek-soc.94541/page-3#post-179503

Cheers

K

 

If so, what is the need for a VS10 for DV only setting if you still get the VS10 engine DV on Auto? Also, why does the image gets dimmer on this particular setting compared to Auto I wonder?

 

Hi Mark, If at all possible, may I humbly request that you please put together another "idiot's guide" PDF for JVC projectors and your current setup (including gamma file if necessary). Our projectors are nearly identical and we're both using the same year's DENON tech.

There was a time in my life when I would actively hate on such a request for spoonfeeding in a tech forum. A head injury a couple of years ago conspired with a few rugby and hockey traumas in my past to render me a bit rubbish with understanding how all of these variables fit together...but I can still follow instructions and think that, between my son and I, I can setup another preset and return back to your LLDV setup with the existing PDF.

 

It's to allow non-DV displays to process only DV with VS10.

There is no need for it with a DV display - in that case, it does the same job as HDR > Auto.

Once again, by definition, Dolby Vision has to use VS10.

 

I'm going to do that at some point but there is currently an issue where an internal SDR EDID does not perform the same as an external SDR EDID (for example with an HDFury device).

The problem is that in both cases, after loading an SDR EDID the colours are a bit dull and muted in VS10 SDR.

With an external EDID, a box reboot fixes this and the colours return to their correct vibrancy, but with an internal EDID, for some reason they do not and I don't know why, nor can I find a workaround...

 

So, I guess I'm on the naughty step?

 

Thanks so much for your work on this. Truth be told, I am very happy using your PDF for LLDV with your custom gamma. It is the best that my system has ever looked in terms of colour , contrast and shadow detail and I love the cutdown of sync times... but from time to time, there are titles where I feel that blacks maybe a bit crushed and I wonder if it's not time for a new bulb even though I have only 850 hours on the present OEM one... I'm sure it's the individual titles, but I will await your findings and idiot's guide to test!

 

Sorry - I sometimes miss posts when I'm not quoted or atted because then I get notifications...

Checking now... Stand by

 

Thanks, that makes sense! Though not sure what accounts for dimmer picture on my DV capable display with this particular setting - this is the reason why I keep things on Auto and not use VS10 on DV Only setting - the difference is quiet noticeable, enough that I almost returned the device immediately b/c of the dimmer picture quality thinking this was the preferred setting.

 

I checked earlier just to make sure I wasn't going mad and there is no difference between Auto and VS10 for DV content here with a DV EDID.

The correct setting would however be Auto - In reality, for a DV display the option to choose VS10 for DV content shouldn't be there at all so it's possible there's something wrong in the code causing some issue or other - but as I say, they should be the same and here they both perform the same.

 

Odd behaviour - can you send your EDID so I can make sure we're both singing from the same hymn sheet when I test this?

Sorry - just realised that was a stupid request

 

This is using the Non-DV but HDR EDID that you posted to force DV to use VS10 to HDR - 600MHz BT2020 HDR10+.bin

Can you check that EDID, or do you need me to re-upload that EDID?

EDIT - here it is anyway:

 

@Markswift2003 this isn't related to this thread but not sure where to post - I only discovered it by forcing all content to VS10 HDR - it also converts 3D to VS10 but of course the display devices don't have an HDR mode for 3D so it all looks wrong. Could you mention to Realtek? Thanks

 

Ok, so here's what's happening:

A lot of what we were doing the last couple of weeks was making sure that the compatibility layers for Profiles 4, 7 and 8 were being used correctly - in other words for an HDR10(+) EDID like this one, when HDR is set to "Auto" the base layer only is used and VS10 is only used with the full DV metadata if VS10 is invoked.

When VS10 for all content is chosen, all profiles are converted by VS10 to HDR10 and the RPU is used.

However, it seems that in other cases, VS10 for DV content for example, the base layer only is being used and in other cases, VS10 for DV & HDR for example, VS10 is used.

Well spotted!!

There's a flaw in the logic here so I'll have to figure out how I explain this to the devs....

As far as the clipping goes, I'm still seeing VS10 DV > HDR (VS10 for all content) clipping at 71/72 not 76.

 

**edit** - Just to note that this issue has now been fixed from v6.3.37 onwards

Bloody hell you opened a can of worms!

Good catch!

So having checked all the VS10 DV modes with HDR and SDR EDIDs, here are the results:

With HDR10 EDID:

With HDR set to "Auto"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - HDR10 base layer is used (correct)
Profile 8 - HDR10 base layer is used (correct)

With HDR set to "VS10 for all content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - VS10 & RPU is used (correct)
Profile 8 - VS10 & RPU is used (correct)

With HDR set to "VS10 for DV content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - HDR10 base layer is used (incorrect)
Profile 8 - HDR10 base layer is used (incorrect)

With HDR set to "VS10 for SDR, DV content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - HDR10 base layer is used (incorrect)
Profile 8 - HDR10 base layer is used (incorrect)

With HDR set to "VS10 for HDR, DV content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - VS10 is used (correct), but RPU is not used (incorrect)
Profile 8 - VS10 is used (correct), but RPU is not used (incorrect)

With HDR set to "VS10 for SDR, HDR, DV content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - VS10 is used (correct), but RPU is not used (incorrect)
Profile 8 - VS10 is used (correct), but RPU is not used (incorrect)


With SDR EDID:

With HDR set to "Auto"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - Realtek engine converts HDR10 base layer to SDR (correct)
Profile 8 - Realtek engine converts HDR10 base layer to SDR (correct)

With HDR set to "VS10 for all content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - VS10 & RPU is used (correct)
Profile 8 - VS10 & RPU is used (correct)

With HDR set to "VS10 for DV content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - Realtek engine converts HDR10 base layer to SDR (incorrect)
Profile 8 - Realtek engine converts HDR10 base layer to SDR (incorrect)

With HDR set to "VS10 for SDR, DV content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - Realtek engine converts HDR10 base layer to SDR (incorrect)
Profile 8 - Realtek engine converts HDR10 base layer to SDR (incorrect)

With HDR set to "VS10 for HDR, DV content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - VS10 is used (correct), but RPU is not used (incorrect)
Profile 8 - VS10 is used (correct), but RPU is not used (incorrect)

With HDR set to "VS10 for SDR, HDR, DV content"
Profile 5 - VS10 & RPU is used (correct)
Profile 7 - VS10 is used (correct), but RPU is not used (incorrect)
Profile 8 - VS10 is used (correct), but RPU is not used (incorrect)

 

Thanks Mark, just like you, here for the community.

 

Forgot to ask, did you get different clipping levels depending on the mode used on the clipping test file I referenced?

Checked again in a dark room, and I get:

VS10 for HDR and DV only = 68
VS10 for all = 76

I guess all panels have variations, but I guess the important point should be that there should be no clipping difference between the two modes?

 

I can resolve down to 70ish with VS10 for all - maybe its the tonemapping that making your display darker in the VS10 for all mode? I can also confirm that the RPU is being used in the VS10 for all mode. What I need is a 'VS10 for all mode except 3D'.

 

The panel doesn't make a difference - it's the source clipping in this case and to see the source clip point you should turn brightness on the panel to full to negate panel calibration. We want to see what's coming out the box and not what the display is doing to it.

In your case above the reason for the discrepancy is that (from your can of worms!) DV conversion for VS10 for all content is different from VS10 for HDR, DV content.

At the moment VS10 for all content is the only mode that handles the conversion correctly and the devs are looking into this so hopefully will be sorted next week. So only the VS10 for all content value is valid.

So in my table we're looking at the VS10 DV>HDR line which I get to 69

You have 76, but you're looking at a pattern with less resolution - the next grade down is 72 then 68.

When I'm quoting the clip point, it's the point at which black first appears, not the last "flashing" bar so in this case 76 is flashing obviously but if you turn brightness up, you can also see 72 flashing slightly so the clip point to the resolution of this pattern is 68, but we can really only say it's between 68 and 71.

The Spears and Munsil pattern is more accurate because it resolves to individual 10-bit quantisation levels - so with that one, 70 flashes, but 69 doesn't.

One thing I will say is that I noticed some discrepancies and artifacting in the purchased Medialight S&M patterns. I'm not sure if this is down to poor MP4 conversion, but I suspect it's something Medialight have done and not S&M.

Also the HDR10 and DV Medialight patterns shown a Mastering Display of 10,000nits in both HDR10 metadata and RPU. Shouldn't make a difference, but 1000nits sits more comfortably with me - it's more the norm.

So what I did for my tests was to rip the 1000nit HDR10 and Rec.709 SDR clipping patterns directly from the S&M UHD Benchmark BluRay and then attached a 1000nit RPU to the HDR10 pattern. This RPU is the same as the one attached to the Medialight file but I changed the mastering monitor to 1000nits to match the base layer by converting to json and editing. This RPU does very little - no tone mapping because obviously there's absolutely no need at this level - it just sets the basics - MaxCLL, MaxFALL, MDL etc.

This now gives me 3 patterns, SDR, HDR and DV with a more reasonable RPU and no artifacts.