Improving Madvr HDR to SDR mapping for projector - Page 2 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 4786Likes
Reply
 
Thread Tools
post #31 of 6081 Old 02-05-2018, 04:06 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Manni01 View Post
You don't change the hard clip, your change the soft clip start point (and possibly the shape of the curve) according to the actual highlights in each frame. [...] But the hard clip point doesn't need to change, or you're changing the relative brightness of the shots too much
That doesn't make much sense to me. IMHO changing the soft clip will probably affect the relative brightness of the shots more than changing the hard clip. I see no reason why we shouldn't change the hard clip.

Quote:
Originally Posted by Manni01 View Post
I'm not sure you make a difference between nits in the content and nits in the output. For example, when you process (not convert) and output metadata, you indicate for max_brightness the peakY value we specify in the parameters (say 125nits for me). This is completely wrong. The peakY value we specify is the max output nits. It has nothing to do with the max content nits. As when you process and don't convert you're expecting the display to use an ST2084 calibration, you should report the content max_brightness, not the output max_brightness, otherwise the display will surely get it wrong if it uses the metadata to do its own tone-mapping?
If you activate "processing", the usual goal would be to replace the display's internal tone mapping with our own. So our aim would be to try to disable the display's tone mapping. If we just report the original metadata to the display, it will definitely activate tone mapping and compress our pixels even more than they already are. So when you activate "processing", madVR reports to the TV the "format" it has tone mapped the video to, in the hope that the display might be clever enough to understand that the content is now within the native capabilities of the display, and might disable the internal tone mapping as a result.

To be honest, I don't know if anybody uses the "processing" options at all, so I'd rather not bother discussing this now and here.
madshi is offline  
Sponsored Links
Advertisement
 
post #32 of 6081 Old 02-05-2018, 04:21 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,011
Mentioned: 307 Post(s)
Tagged: 0 Thread(s)
Quoted: 5360 Post(s)
Liked: 5412
Three pictures with MadVR:

First two pictures with Pixel Shader HDR to SDR conversion (along with the parameters used), using a SDR BT2020 calibration (with null 3D LUT).

The compression causes ugly posterization (and/or clipping if there is no highlights compression). It's not super visible in a picture (especially with my crappy iphone and variable exposure), but it's very visible with motion.

Have you tried watching the clip on your projector with a peakY of 125nits, or are you watching the clip on your monitor?

Last picture in passthrough with a HDR BT2020 custom curve calibration clipping at 4,000nits (identical to what the UB900 does). No posterization (don't pay attention to the change in brightness, it's the iPhone auto-exposure).
Attached Thumbnails
Click image for larger version

Name:	IMG_3322.JPG
Views:	264
Size:	572.3 KB
ID:	2356426   Click image for larger version

Name:	IMG_3323.JPG
Views:	216
Size:	572.2 KB
ID:	2356428   Click image for larger version

Name:	IMG_3326.JPG
Views:	199
Size:	495.6 KB
ID:	2356430  

JVC Autocal Software V11 Calibration for 2019 Models (Google)
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 02-05-2018 at 04:38 AM.
Manni01 is online now  
post #33 of 6081 Old 02-05-2018, 04:29 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,011
Mentioned: 307 Post(s)
Tagged: 0 Thread(s)
Quoted: 5360 Post(s)
Liked: 5412
Quote:
Originally Posted by madshi View Post
That doesn't make much sense to me. IMHO changing the soft clip will probably affect the relative brightness of the shots more than changing the hard clip. I see no reason why we shouldn't change the hard clip.


If you activate "processing", the usual goal would be to replace the display's internal tone mapping with our own. So our aim would be to try to disable the display's tone mapping. If we just report the original metadata to the display, it will definitely activate tone mapping and compress our pixels even more than they already are. So when you activate "processing", madVR reports to the TV the "format" it has tone mapped the video to, in the hope that the display might be clever enough to understand that the content is now within the native capabilities of the display, and might disable the internal tone mapping as a result.

To be honest, I don't know if anybody uses the "processing" options at all, so I'd rather not bother discussing this now and here.
Changing the soft start doesn't need to be huge, that would indeed cause a lot of visible variation. Changing the shape of the curve (more flat as the soft point goes up to have more gradations in the highlights) would make more of a (positive) difference. Anyway, let's move on, your method is fine and doesn't need improving. I'll stick to pointing at issues in the picture and I'll leave it to you to resolve them.

I don't care/use the processing option, it won't work with the JVCs as you can't disable the internal tonemapping (whether factory or custom curve) AND keep any kind of HDR ability. It's a very dumb, static implementation that simply changes the shape of the gamma curve. I'm not aware of any display that would work like what you're hoping for, so I agree we shouldn't waste time on this.

JVC Autocal Software V11 Calibration for 2019 Models (Google)
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 02-05-2018 at 04:40 AM.
Manni01 is online now  
Sponsored Links
Advertisement
 
post #34 of 6081 Old 02-05-2018, 04:38 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Manni01 View Post
Three pictures with MadVR:

First two pictures with Pixel Shader HDR to SDR conversion (along with the parameters used), using a SDR BT2020 calibration (with null 3D LUT).

The compression causes ugly posterization (and/or clipping if there is no highlights compression). It's not super visible in a picture (especially with my crappy iphone and variable exposure), but it's very visible with motion.

Have you tried watching the clip on your projector with a peakY of 125nits, or are you watching the clip on your monitor?

Last picture in passthrough with a HDR BT2020 custom curve calibration (identical to what the UB900 does). No posterization.
Hmmmm... With posterization do you mean banding? Or do you mean something else? I'm not sure I see what you're seeing. I've tried on my 4K LCD TV, with peakY 125nits.

What happens if you make a screenshot with your media player (e.g. Alt+I in MPC-HC, I think)? Is the posterization visible in that?
madshi is offline  
post #35 of 6081 Old 02-05-2018, 04:58 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,011
Mentioned: 307 Post(s)
Tagged: 0 Thread(s)
Quoted: 5360 Post(s)
Liked: 5412
Quote:
Originally Posted by madshi View Post
Hmmmm... With posterization do you mean banding? Or do you mean something else? I'm not sure I see what you're seeing. I've tried on my 4K LCD TV, with peakY 125nits.

What happens if you make a screenshot with your media player (e.g. Alt+I in MPC-HC, I think)? Is the posterization visible in that?
What I see is a smooth transition with passthrough and very visible blotches of red with pixel shader conversion. It could be banding.

Screenshots don't help because they don't take the different calibration (HDR BT2020 or SDR BT2020) into effect.

If you look at the clip on your projector with 125nits peakY and don't see any difference (as in unwanted very visible artifacts) between passthrough and pixel shader, let's drop this.

If I'm the only one to see this, let's drop this too.

I'm happy with passthrough and custom curves selected automatically with the Vertex, and until MadVR is able to send the SDR BT2020 info in the HDMI stream I won't use pixel shader, so let's revisit if 1) you or others can see this issue and 2) I'm likely to be able to use pixel shader in practice because I don't have to switch calibration manually.

JVC Autocal Software V11 Calibration for 2019 Models (Google)
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #36 of 6081 Old 02-05-2018, 06:12 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Manni01 View Post
I'm happy with passthrough and custom curves selected automatically with the Vertex, and until MadVR is able to send the SDR BT2020 info in the HDMI stream I won't use pixel shader, so let's revisit if 1) you or others can see this issue and 2) I'm likely to be able to use pixel shader in practice because I don't have to switch calibration manually.
What about profile activation command lines? I thought you already switched calibrations that way?
madshi is offline  
post #37 of 6081 Old 02-05-2018, 06:32 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,011
Mentioned: 307 Post(s)
Tagged: 0 Thread(s)
Quoted: 5360 Post(s)
Liked: 5412
Quote:
Originally Posted by madshi View Post
What about profile activation command lines? I thought you already switched calibrations that way?
External command on profile activation is still unreliable in its current implementation (I'm also not sure that the hdr flag is always correct) and that doesn't solve the fact that the only way we can select a calibration with an external command is with IP control (using Arve's code). This isn't compatible with iRule, which also uses IP control to control the PJ. The Vertex uses RS-232 to control the PJ when it selects a calibration, so it's perfectly compatible with iRule.

So as I'm not going to let go of iRule to control all my devices or of the Vertex to switch to the correct calibration irrespective of the source (I, like many here, do not use only a HTPC, we also have a streaming device, a UHD Bluray player, a satellite box for HDTV, etc), I simply won't personally use pixel shader until MadVR can report the correct SDR BT2020 info in the HDMI stream so that the Vertex can do its job and select the correct calibation (SDR Rec-709 or SDR BT2020 depending on the content that MadVR is playing if using pixel shader for the HDR to SDR conversion).

I don't have the time at the moment to help with things that I'm not going to use personally, given the way this discussion is going. Let's save both my time and yours and concentrate on what matters for each of us. If others notice the same performance or usability issues I do with pixel shader, they will report them and it will get fixed. If they don't then we both win

JVC Autocal Software V11 Calibration for 2019 Models (Google)
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #38 of 6081 Old 02-05-2018, 07:37 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,011
Mentioned: 307 Post(s)
Tagged: 0 Thread(s)
Quoted: 5360 Post(s)
Liked: 5412
@madshi

Re the above, one thing that would really help, instead of the selection of calibration on profile enable using batch files, would be to associate a baseline calibration to each the 3D LUTs, using a calibration number (1 to 6) to select USER1-USER6 depending on the LUT enabled, similar to what you already do for the lens memory to change aspect ratio. Ideally, we'd like to support all the user modes, not just the six presets, but that would mean more work in the interface and isn't entirely necessary.

As there is already JVC support for IP control in MadVR for lens memories (I helped you to implement that if you remember), it would be nice (and super easy for you) to extend this to user mode for calibration purposes. It would work much better than with the external command and it would be simpler/easier. It would still be IP based, so not ideal, but if it was more reliable that external command it would already be a big step.

Let me know if you need the IP commands for the six JVC user modes, they are implemented in the Vertex and work very well (although 5/6 only work with some models, so you might want to display a warning for that if you were to decide to support this).

JVC Autocal Software V11 Calibration for 2019 Models (Google)
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #39 of 6081 Old 02-05-2018, 11:40 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Manni01 View Post
Three pictures with MadVR:

First two pictures with Pixel Shader HDR to SDR conversion (along with the parameters used), using a SDR BT2020 calibration (with null 3D LUT).

The compression causes ugly posterization (and/or clipping if there is no highlights compression). It's not super visible in a picture (especially with my crappy iphone and variable exposure), but it's very visible with motion.

Have you tried watching the clip on your projector with a peakY of 125nits, or are you watching the clip on your monitor?

Last picture in passthrough with a HDR BT2020 custom curve calibration clipping at 4,000nits (identical to what the UB900 does). No posterization (don't pay attention to the change in brightness, it's the iPhone auto-exposure).
I've tried again, both on my PC monitor and my 4K TV, and I can't seem to see any obvious artifacts with exactly the HDR settings from your screenshots (except clipping when turning off compression, of course). The video looks quite different when comparing my tone mapping to that of the Sony TV in HDR passthrough mode, but that's mostly colors and luminance. Can't seem to see much of a difference in artifacts.

So I wonder if my eyes simply don't see the issue you're talking about, or maybe the issue is specific to your setup?

If you're interested in getting to the root of this problem, I'd suggest the following tests, which should all be pretty quick & easy to do. I know you will be tempted to already rule out some of these tests without even trying because you're sure they're useless, but I'd like to encourage you to try nevertheless, because double checking is always the safer choice.

With madVR configured to reproduce the artifacts, but set to "already calibrated", so no 3DLUT is involved at all (just to remove one potential trouble maker):
1) Is the issue specific to any JVC calibration slot / user mode? E.g. I suppose you may have one for BT.709? Does the issue show there, too?
2) Does setting your GPU control panel to RGB *Full* vs YCbCr change anything?
3) Does setting your GPU control panel to 8bit vs 12bit change anything?
4) Does disabling the custom resolution (I think the Nvidia control panel allows you to temporarily disable it without deleting it?) change anything?
5) If you do a screenshot, does the issue occur in the screenshot, when watched on your computer/laptop monitor?
6) If you do a screenshot, and then open it e.g. with MS Paint on your projector, is the issue visible?
7) If you set madVR's display bitdepth to 8bit, does that change anything?
8) When playing the movie on a normal monitor, but configured the same way as your projector, does the issue occur? (Obviously, the colors will be wrong, but still.)

I think once we have the test results, we should be able to draw some conclusions. The problem could be in madVR, in the GPU drivers, in the projector, or in the calibration.

Quote:
Originally Posted by Manni01 View Post
Screenshots don't help because they don't take the different calibration (HDR BT2020 or SDR BT2020) into effect.
Which calibration? The madVR (3DLUT) calibration? Or the one in your projector? I guess the one in the projector, because you already said that the issue didn't depend on using a 3DLUT, right? If so, if the issue only occurs when running through the projector's BT.2020 calibration, but not when running through the projector's BT.709 calibration, wouldn't that point to the BT.2020 calibration being a possible cause of the issue? An interesting test would be to make a screenshot and show it in MS Paint on your projector. In theory it should show the same problem when shown on your projector. If it does, and if it does not show on a normal computer monitor, then that would suggest that if the screenshot image itself does not seem to have artifacts, but your projector shows artifacts when displaying the screenshot, then madVR is unlikely to be at fault?

Quote:
Originally Posted by Manni01 View Post
If you look at the clip on your projector with 125nits peakY and don't see any difference (as in unwanted very visible artifacts) between passthrough and pixel shader, let's drop this.

If I'm the only one to see this, let's drop this too.
Why drop it then? Are you only interested in discussing the issue if it's caused by madVR, but you're not interested in solving it if the issue is outside of madVR?

Quote:
Originally Posted by Manni01 View Post
I simply won't personally use pixel shader until MadVR can report the correct SDR BT2020 info in the HDMI stream
Quote:
Originally Posted by Manni01 View Post
the only way we can select a calibration with an external command is with IP control (using Arve's code). This isn't compatible with iRule, which also uses IP control to control the PJ.
Quote:
Originally Posted by Manni01 View Post
Re the above, one thing that would really help, instead of the selection of calibration on profile enable using batch files, would be to associate a baseline calibration to each the 3D LUTs, using a calibration number (1 to 6) to select USER1-USER6 depending on the LUT enabled, similar to what you already do for the lens memory to change aspect ratio. Ideally, we'd like to support all the user modes, not just the six presets, but that would mean more work in the interface and isn't entirely necessary.

As there is already JVC support for IP control in MadVR for lens memories (I helped you to implement that if you remember), it would be nice (and super easy for you) to extend this to user mode for calibration purposes. It would work much better than with the external command and it would be simpler/easier. It would still be IP based, so not ideal, but if it was more reliable that external command it would already be a big step.
You're giving me somewhat mixed signals. First you said you needed the 3DLUT info in the OSD in order to continue with madVR tone mapping. So I added it. Then suddenly that's not enough and you also need madVR to add HDMI stream signals, otherwise you can't use madVR tone mapping. You mentioned HDMI stream signals before, but IIRC you didn't say it was a requirement until now. And then you said that madVR's command line execution using IP control is incompatible with iRule, but now you're asking for madVR doing even more IP control? How does that fit together?

Of course it would be possible to add more IP control to madVR, but I think it would be wiser to work on making command line execution reliable, because that's a much more flexible concept. If I add more IP control to madVR, it will be very specific, and it would leave command line execution in its current state.
madshi is offline  
post #40 of 6081 Old 02-05-2018, 12:18 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,011
Mentioned: 307 Post(s)
Tagged: 0 Thread(s)
Quoted: 5360 Post(s)
Liked: 5412
@madshi

Sorry but I don't have the time for this. There are too many issues at this stage, for me, to spend days getting the pixel shader conversion to work in my set-up.

As I said if it's just me experiencing the performance and usability issues I've reported, then there is no reason to waste your time. If no one else reports similar issues, then you'll know it's just me and you can forget about it.

I did ask you to add the 3D LUT indicator in the OSD because I wanted to rule out the calibration before starting this discussion. As soon as you added this, I was able to rule out the wrong 3D LUT being selected as being the cause, so I reported so.

I have no issue with any of my calibrations, with or without MadVR. I use 3D LUTs all the time. I have the issue with a null 3D LUT (which you have checked) and when I select "this display is already calibrated", only with the pixel shader conversion. If I use passthrough with an HDR calibration, there is no issue. If I use another source (such as the UB900) with my SDR BT2020 calibration, there is no issue. So as far as I'm concerned, it's an issue with the pixel shader conversion.

You are not interested in improving the way the conversion is designed because you think it's fine as it is, and I'm not interested in debating this with you for hours because I have custom curves that are selected automatically by the Vertex that work great with MadVR in passthrough mode.

I mentioned the idea of adding IP support to select the correct baseline calibration because you have already implemented JVC support and it seems like an easy thing to do. I don't need it for myself, I just thought it might help others (those without a Vertex).

At the end of the day, you're not making this fun. I collaborate with many developers of hardware and software, and for some reason it's always difficult with you, it must be a personality thing, it just feels like we're always starting from the beginning and I'm just tired of it. I love MadVR, I plan to use it in passthrough mode and I'll revisit the HDR to SDR conversion if/when it changes, provided I have a way to use it that makes it possible for me to select automatically the correct baseline calibration. I've spent hours trying to get the external commands to work and they simply don't. If I knew that I could get better results with a perfect calibration thanks to the 3D LUT and an excellent conversion, that might motivate me to spend the time, and similarly if I knew that I could select the correct calibration baseline accurately that might motivate me to try to resolve the pixel shader issue. At the end of the day, it's just too many things to debug for a feature (HDR to SDR conversion) that I'm not even sure I'll be able to use one day. I have a working solution with the custom curves and the Vertex, and given the limited amount of time I have at the moment, I'll just keep using that for now.

I have told you about the need to find a way to report SDR BT2020 a few times, in the end I've just decided that until that happens I'm not going to use the HDR to SDR conversion simply because it's not practical for my use, especially if I can't get a more accurate calibration using a 3D LUT. I want to be able to use iRule to control the PJ and all my devices. It's not possible to do so with the HDR to SDR conversion in its current state, so yes I'm giving up. My time (like yours) is not unlimited, so I don't want to waste yours or mine.

When I have the time, and when people are nice, I don't mind trying to help. When I don't have the time, and when people are not nice, I just concentrate on what I need personally. Is it such a bad thing?

Keep up the good work, I don't have anything against MadVR, again I use it all the time and I love it. I just don't think the HDR to SDR conversion is for me in its current state, but I'll happily revisit later, when/if it looks like something I could use in my set-up.

JVC Autocal Software V11 Calibration for 2019 Models (Google)
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #41 of 6081 Old 02-05-2018, 01:50 PM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,279
Mentioned: 194 Post(s)
Tagged: 0 Thread(s)
Quoted: 941 Post(s)
Liked: 1384
Quote:
Originally Posted by madshi View Post

Can you do some more comparisons between 300|100 vs 150|50?
Hi Madshi,

I just did that. They are again almost identical. (using the linear one). So I do not see any advantage yet to use 150 target, 50nits diffuse white instead of my original 300 target, 100 diffuse white.
The spline one as always can look nice on on dark scenes but not on a mixed scene where the dark are then washed out.

-->"Maybe" for projector owners, EVEN if it does modify the original brightness distribution through the movie (what the spline already does), it would still be good to use a variable target display nits depending on the rolling average peakY/or a better representative variable.
I believe it would do exacty what we look for:
- keep hdr strength for picture with mixed scenes higher highlights and HDR pop without washing out the dark parts like the spline would do
- keep a lot of details in the overly dark scenes like the spline would do:
I guess we should specify first a range where it is acceptable to vary like: 120nits to 400nits display target nits.


I played some more on the movie Mad max with 50% sat 50% brightness VS 100% sat 0% brightness. Clear winner is 50/50 to keep some details in the various fires/explosions in the storm in desert. (no great pic quality /smartphone + whatsapp -- I reduced the camera brightness to capture the fire properly)

50/50:


100 sat /0 brightness:


I looked for posterization like Manni mentioned but could not really find something except one shot which looked suspicious with basically banding within a fire. I am not sure it should look like that (looked the same with or without 3dlut)
A close-up picture (300 target nits, 100 diffuse white, 50%sat, 50%brightness).



But to keep things fair: I am still every day impressed with the quality I get with HDR content on my projector Epson LS10000 thanks to Madvr HDR to SDR Mapping.
Always wondering if it can get any better ;-)
Attached Thumbnails
Click image for larger version

Name:	banding.jpg
Views:	1467
Size:	46.6 KB
ID:	2356646   Click image for larger version

Name:	100 0.jpg
Views:	1484
Size:	26.4 KB
ID:	2356648   Click image for larger version

Name:	50 50.jpg
Views:	1459
Size:	25.4 KB
ID:	2356650  
Tom Bley and Manni01 like this.

Last edited by Soulnight; 02-05-2018 at 01:59 PM.
Soulnight is online now  
post #42 of 6081 Old 02-05-2018, 02:50 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Manni01 View Post
You are not interested in improving the way the conversion is designed [...]
v0.92.12, released yesterday:
* added experimental "diffuse white" HDR option (mainly for projector owners)
* improved non-hue-preserving HDR tone mapping



Quote:
Originally Posted by Manni01 View Post
At the end of the day, you're not making this fun. I collaborate with many developers of hardware and software, and for some reason it's always difficult with you, it must be a personality thing
You know, there are reasons why you find working with me difficult, and why I find working with you difficult, as well. And the reason isn't just my personality, it is your's, as well. It's not a one-way street. But unless you're interested in discussing this on a friendly basis, we should stop here.
nathanddrews and vjforum like this.
madshi is offline  
post #43 of 6081 Old 02-05-2018, 02:59 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,011
Mentioned: 307 Post(s)
Tagged: 0 Thread(s)
Quoted: 5360 Post(s)
Liked: 5412
Quote:
Originally Posted by madshi View Post
You know, there are reasons why you find working with me difficult, and why I find working with you difficult, as well. And the reason isn't just my personality, it is your's, as well. It's not a one-way street. But unless you're interested in discussing this on a friendly basis, we should stop here.
Absolutely, I never meant or implied only your personality was involved. And it's precisely because it's a two-way street that I'm stepping out.
Always friendly, just better to stop here. I have too many things going on in both my personal and working life at the moment to dedicate more time to this.

JVC Autocal Software V11 Calibration for 2019 Models (Google)
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 02-06-2018 at 03:33 AM.
Manni01 is online now  
post #44 of 6081 Old 02-05-2018, 03:02 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Soulnight View Post
I just did that. They are again almost identical. (using the linear one). So I do not see any advantage yet to use 150 target, 50nits diffuse white instead of my original 300 target, 100 diffuse white.
FWIW, the math really is different, and I did see some differences in my tests. But I'll do some more tests here, too, when I find more time.

Quote:
Originally Posted by Soulnight View Post
-->"Maybe" for projector owners, EVEN if it does modify the original brightness distribution through the movie (what the spline already does), it would still be good to use a variable target display nits depending on the rolling average peakY/or a better representative variable.
I believe it would do exacty what we look for:
- keep hdr strength for picture with mixed scenes higher highlights and HDR pop without washing out the dark parts like the spline would do
- keep a lot of details in the overly dark scenes like the spline would do:
I guess we should specify first a range where it is acceptable to vary like: 120nits to 400nits display target nits.
I'm already using the rolling average to fine tune the tone mapping parameters. I'm not sure if using the same rolling average to modify the target display nits makes sense? I fear if using the same value to adjust to different tone mapping parameters might influence each other negatively.

Ideally, I'd really prefer if we didn't have to "lie" to madVR about the display peak luminance capability. I'm not happy that we currently have to do that. Maybe adding another 25 Nits setting to the "diffuse white" option (as suggested by Manni) would be a good idea to stop the "lying". But then, if it looks nearly the same as using 4*display peak and 100 nits diffuse white, then what's the point? <sigh>

Quote:
Originally Posted by Soulnight View Post
I played some more on the movie Mad max with 50% sat 50% brightness VS 100% sat 0% brightness. Clear winner is 50/50 to keep some details in the various fires/explosions in the storm in desert. (no great pic quality /smartphone + whatsapp -- I reduced the camera brightness to capture the fire properly)
Did you try 30/70? I'm wondering if I shouldn't use 30/70 instead of 50/50 as default, see my screenshot comparison earlier in this thread.

Quote:
Originally Posted by Soulnight View Post
I looked for posterization like Manni mentioned but could not really find something except one shot which looked suspicious with basically banding within a fire.
That looks pretty bad. Is that a blue color within the flames? A couple weeks ago another user sent me a Mad Max sample where a car had a blue pixel in it. After analyzing the underlying YCbCr data from the UHD movie, I found that the pixel was actually encoded as blue, which didn't really make sense.

Quote:
Originally Posted by Soulnight View Post
But to keep things fair: I am still every day impressed with the quality I get with HDR content on my projector Epson LS10000 thanks to Madvr HDR to SDR Mapping.
Always wondering if it can get any better ;-)
Thanks! Well, let's work on making it better! Unfortunately you're the only user so far who's really given any real feedback about the new "diffuse white" option, and basically you're saying it's more or less useless. Ouch.
madshi is offline  
post #45 of 6081 Old 02-05-2018, 03:27 PM
AVS Forum Special Member
 
Javs's Avatar
 
Join Date: Dec 2012
Location: Sydney
Posts: 7,849
Mentioned: 475 Post(s)
Tagged: 0 Thread(s)
Quoted: 6791 Post(s)
Liked: 6418
@madshi I just want to add that I am interested in further troubleshooting/improving upon this with you, I greatly appreciate how generally open you are to making changes. I have just been very busy in the past couple days to really sit down with you and go though a couple more things.

I was able to locate a shot which I believe showed undue amounts of clipping which does not appear to be in the source which I think correlated partially with one of the things Manni was seeing. I didnt personally see anything wrong with the timestamp of 3:30 or so the sunset there. But I did see an issue on this shot

If you look at the highlight on the trunk of the car...

Original log frame:



MadVR



I also agree that spline looks too aggressive, although if you added a 25nit ref white option (which is closer to what we use on our actual HDR curves) then Spline will probably be much more useful here, or better yet if you would allow us to enter a custom value for ref white:

100nit Peak / 50 nit ref.

Linear:



Spline:



30/70 is looking pretty good, but its still making the colour test patterns look very wrong, and the highlights turning more white than they should be, there must be something we are not thinking of here...

I believe that the correct setting and method here will also make those test patterns display as they should.

For eg, this shot which I took earlier, the approx level of saturation we are seeing at 1000nits, that's more like how the 10,000nits level should be displaying and everything in between should be a tone mapped gradient from the knee point leading up to that right?



This is what the original file should look like in HDR, it would never approach white or desaturation at the clipping point:



Here is what happens if the title is 1000nits, the tone mapping should be adjusting this so the mastering level would be full saturation saturation. Now this pattern would never display like this in MadVR, but the tone mapping should be dynamically adjusting this saturation based on the measurements its doing in the frame, now I understand this is tough even with a rolling average because when you have a very dim scene for some minutes, i imagine the saturation is going to fly up to unnatural levels to compensate.



Since the HDR curves we use on projectors already do this, we get the proper highlight saturations in the content which should make this fire highlight look more like this, its actually more yellow than white:


JVC X9500 (RS620) | 120" 16:9 | Marantz AV7702 MkII | Emotiva XPA-7 | DIY Modular Towers | DIY TPL-150 Surrounds | DIY Atmos | DIY 18" Subs
-
MadVR Settings | UHD Waveform Analysis | Arve Tool Instructions + V3 Javs Curves

Last edited by Javs; 02-05-2018 at 03:43 PM.
Javs is offline  
post #46 of 6081 Old 02-05-2018, 11:48 PM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,279
Mentioned: 194 Post(s)
Tagged: 0 Thread(s)
Quoted: 941 Post(s)
Liked: 1384
Quote:
Originally Posted by madshi View Post
FWIW, the math really is different, and I did see some differences in my tests. But I'll do some more tests here, too, when I find more time.
I believe you that the math is different. When I go back and forth through the shortscuts, I see sometimes a very slight variation on some part of the picture.
Try to do some tests on real content: passengers for example.

Quote:
Originally Posted by madshi View Post
I'm already using the rolling average to fine tune the tone mapping parameters. I'm not sure if using the same rolling average to modify the target display nits makes sense? I fear if using the same value to adjust to different tone mapping parameters might influence each other negatively.
You probably mean you are using to change the max value dynamically for the highlights right now. This is already very good.
But for projectors with low brightness, you really need need the whole mathematic to change dynamically to better use the low lumens output.
It's basically a similar idea as what the current dynamic iris implementation in projector is doing to increase in picture contrast. If a dark inage is detected: the projector close-down an mechanical iris, reducing brightness in order to improve black levels but reduce dynamically the gamma value so that the rest of the pixels between white and black still keep the same brightness.

I really believe if we would use Madvr real time analysis of every frame to improve through 2 different mechanisms which would NOT be used at the same time:
- the highlights (max peakY): for pictures which have a peakY higher than the user chosen "This display target nits". The target display nits remains here unchanged. Madvr only works out the highlights dynamically.
- the whole picture for "dark scenes": if you have a peakY lower than the chosen "this display target nits". Here you lower this display target nits to the real peakY. There is no highlights anymore. Nothing is compressed. You just get a brighter, more "redeable" picture with excellent shadow details. (the scene after the fire in Deadpool" where deadpool raises from the ashes at night is an excellent test).
-->and thanks to your rolling average method, there should be no flickering whatsoever and always best optimize for low brightness display like our projectors.

Quote:
Originally Posted by madshi View Post
Ideally, I'd really prefer if we didn't have to "lie" to madVR about the display peak luminance capability. I'm not happy that we currently have to do that. Maybe adding another 25 Nits setting to the "diffuse white" option (as suggested by Manni) would be a good idea to stop the "lying". But then, if it looks nearly the same as using 4*display peak and 100 nits diffuse white, then what's the point? <sigh>
I don't see it as lying. I just know that this is darker than intended on my projector when I use 300nits target with 100nits diffuse white with my projector having only 75cd/m2. But everythings get scaled down so it does not matter. Using the real 100 diffuse white, tells me however real information on what display target nits I am using. I know that above 300nits, everything gets compressed and I can relate that to the rolling average peakY info measured in Ctrl+Y.

Quote:
Originally Posted by madshi View Post
Did you try 30/70? I'm wondering if I shouldn't use 30/70 instead of 50/50 as default, see my screenshot comparison earlier in this thread.
Not yet, will do. But I do love nice saturated colors...

Quote:
Originally Posted by madshi View Post
That looks pretty bad. Is that a blue color within the flames? A couple weeks ago another user sent me a Mad Max sample where a car had a blue pixel in it. After analyzing the underlying YCbCr data from the UHD movie, I found that the pixel was actually encoded as blue, which didn't really make sense.
Not sure whats it is... Maybe manni or Javs or any other user can look at this shot as well?
FYI: I am outputing 8bits from madvr (with dithering), with a Full, Full, Full chain and RGB output

Quote:
Originally Posted by madshi View Post
Thanks! Well, let's work on making it better! Unfortunately you're the only user so far who's really given any real feedback about the new "diffuse white" option, and basically you're saying it's more or less useless. Ouch.
You're welcome!
I am sorry that Isee almost no difference even I tried very hard with a lot of back and forth through shortcuts.
I get the only advantage is for people used to JVC Arve Tool way of working to have a better feeling about the "target nits", but that's it. :-)
And I think here the best process is learning by doing/trying.
So let's continue trying and we will continue testing and report back.
Soulnight is online now  
post #47 of 6081 Old 02-06-2018, 03:55 AM
AVS Forum Addicted Member
 
stanger89's Avatar
 
Join Date: Nov 2002
Location: Marion, IA
Posts: 23,130
Mentioned: 34 Post(s)
Tagged: 0 Thread(s)
Quoted: 4156 Post(s)
Liked: 2384
Quote:
Originally Posted by Javs View Post
For eg, this shot which I took earlier, the approx level of saturation we are seeing at 1000nits, that's more like how the 10,000nits level should be displaying and everything in between should be a tone mapped gradient from the knee point leading up to that right?

This is what the original file should look like in HDR, it would never approach white or desaturation at the clipping point:

Here is what happens if the title is 1000nits, the tone mapping should be adjusting this so the mastering level would be full saturation saturation. Now this pattern would never display like this in MadVR, but the tone mapping should be dynamically adjusting this saturation based on the measurements its doing in the frame, now I understand this is tough even with a rolling average because when you have a very dim scene for some minutes, i imagine the saturation is going to fly up to unnatural levels to compensate.

Since the HDR curves we use on projectors already do this, we get the proper highlight saturations in the content which should make this fire highlight look more like this, its actually more yellow than white:
One thing I think you're missing is that it's that we just can't use test patterns to evaluate what madVR is doing, especially not in comparison to what our custom curves do. The reason is that madVR has a fundamentally different approach to the tone mapping. Our custom curves are dumb, dumb in that they do not have any knowledge of the content that they are processing, this means we manually define them to just clip/clamp at a certain level. When a 1000 nit custom curve sees a 4000 nit pixel, it just blindly sets it to 100%, clamping it off, along with everything else over 1000 nits. All the detail is gone, but that's OK because we manually picked an appropriate curve, and when we throw a 10,000 nit test pattern at a custom curve, it doesn't care, it just clamps it off, but we know what we're looking for.

madVR is fundamentally different, it's not just clamping off at a set max nits, it's evaluating every frame, trying to fit all the detail all the information down into the range we told it our display can support. So when madVR sees that Masciola test pattern, it sees a frame with information up to 10,000 nits, and it dutifully tries to compress all that information, and as madshi's explained, when you do that, something's got to give.

I think it's a distraction and a waste of time to try and get madVR to reproduce the Masciola test patterns the same way as custom curves, it's just not going to happen, and it shouldn't.
stanger89 is offline  
post #48 of 6081 Old 02-06-2018, 04:02 AM
AVS Forum Special Member
 
Javs's Avatar
 
Join Date: Dec 2012
Location: Sydney
Posts: 7,849
Mentioned: 475 Post(s)
Tagged: 0 Thread(s)
Quoted: 6791 Post(s)
Liked: 6418
Quote:
Originally Posted by stanger89 View Post
One thing I think you're missing is that it's that we just can't use test patterns to evaluate what madVR is doing, especially not in comparison to what our custom curves do. The reason is that madVR has a fundamentally different approach to the tone mapping. Our custom curves are dumb, dumb in that they do not have any knowledge of the content that they are processing, this means we manually define them to just clip/clamp at a certain level. When a 1000 nit custom curve sees a 4000 nit pixel, it just blindly sets it to 100%, clamping it off, along with everything else over 1000 nits. All the detail is gone, but that's OK because we manually picked an appropriate curve, and when we throw a 10,000 nit test pattern at a custom curve, it doesn't care, it just clamps it off, but we know what we're looking for.

madVR is fundamentally different, it's not just clamping off at a set max nits, it's evaluating every frame, trying to fit all the detail all the information down into the range we told it our display can support. So when madVR sees that Masciola test pattern, it sees a frame with information up to 10,000 nits, and it dutifully tries to compress all that information, and as madshi's explained, when you do that, something's got to give.

I think it's a distraction and a waste of time to try and get madVR to reproduce the Masciola test patterns the same way as custom curves, it's just not going to happen, and it shouldn't.
I somewhat disagree with you.

That pattern shows 100% red saturation, MadVR turns it and other colours white, it never even gets to 100% saturation, since its turning it white, it also means a by product of that is the actual possible gamut is reduced with it... that's not the desired outcome no matter how we swing it.

Its also linked to the issue (the one I actually care about - not the patterns) of the MadMax explosions also turning white and losing all colour saturation in the highlights. Its just not supposed to look like that. Even on my 1400+nit capable Samsung UHD TV it does not look like that in real HDR not with a 'dumb' curve, so why is tone mapping doing that?.

I would like to know what the Oppo and Lumagen do to that pattern. I wager they are rendering it with full saturation. Kris Deering says the Lumagen is using linear light also same as MadVR, so it would be interesting to know.

JVC X9500 (RS620) | 120" 16:9 | Marantz AV7702 MkII | Emotiva XPA-7 | DIY Modular Towers | DIY TPL-150 Surrounds | DIY Atmos | DIY 18" Subs
-
MadVR Settings | UHD Waveform Analysis | Arve Tool Instructions + V3 Javs Curves
Javs is offline  
post #49 of 6081 Old 02-06-2018, 05:08 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
@Javs , this is a complicated topic. But let me try to guide you through the scientific jungle, by starting with a relatively simple question:

Imagine our dream comes true and we get a true 10,000nits projector. Now imagine you use a full frame white test image, max brightness, and you measure the Nits with a meter. If the projector is perfect, you'd get a 10,000 Nits measurement result, do you agree? Now imagine you use a full frame pure *blue* test image instead, max brightness, 100% saturation, and you measure the brightness you get with that. How many Nits do you think you would get this time?
madshi is offline  
post #50 of 6081 Old 02-06-2018, 05:45 AM
AVS Forum Special Member
 
Javs's Avatar
 
Join Date: Dec 2012
Location: Sydney
Posts: 7,849
Mentioned: 475 Post(s)
Tagged: 0 Thread(s)
Quoted: 6791 Post(s)
Liked: 6418
Quote:
Originally Posted by madshi View Post
@Javs , this is a complicated topic. But let me try to guide you through the scientific jungle, by starting with a relatively simple question:

Imagine our dream comes true and we get a true 10,000nits projector. Now imagine you use a full frame white test image, max brightness, and you measure the Nits with a meter. If the projector is perfect, you'd get a 10,000 Nits measurement result, do you agree? Now imagine you use a full frame pure *blue* test image instead, max brightness, 100% saturation, and you measure the brightness you get with that. How many Nits do you think you would get this time?
Let's focus on 1000nits since I have a display that can actually do that... Yet we still lose saturation in the tone mapping.

As for the nits value of blue? I don't know. I speak colour grading language though. I can colour grade content to peak at 1000nits red green or blue just like those clipping patterns, but it seems madvr is turning them white ? Why is that?

JVC X9500 (RS620) | 120" 16:9 | Marantz AV7702 MkII | Emotiva XPA-7 | DIY Modular Towers | DIY TPL-150 Surrounds | DIY Atmos | DIY 18" Subs
-
MadVR Settings | UHD Waveform Analysis | Arve Tool Instructions + V3 Javs Curves
Javs is offline  
post #51 of 6081 Old 02-06-2018, 06:09 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Javs View Post
Let's focus on 1000nits since I have a display that can actually do that... Yet we still lose saturation in the tone mapping.

As for the nits value of blue? I don't know. I speak colour grading language though. I can colour grade content to peak at 1000nits red green or blue just like those clipping patterns, but it seems madvr is turning them white ? Why is that?
The answer is very complicated. That's why I'm trying to walk you through it. But that won't work if you don't follow my lead. If you want to understand the answer, then please humour me and try to answer the question from my previous comment:

Do you think the blue full frame would measure as 10,000 Nits, same as the white full frame? Or do you think it would be slightly brighter, or much brighter than white? Or slightly darker or much darker than white? I don't need you to guess exact numbers, but it's absolutely *crucial* for you to understand how a full frame blue frame measures (in terms of brightness / Nits) compared to a full white frame.
madshi is offline  
post #52 of 6081 Old 02-06-2018, 06:12 AM
AVS Forum Special Member
 
Javs's Avatar
 
Join Date: Dec 2012
Location: Sydney
Posts: 7,849
Mentioned: 475 Post(s)
Tagged: 0 Thread(s)
Quoted: 6791 Post(s)
Liked: 6418
Quote:
Originally Posted by madshi View Post
The answer is very complicated. That's why I'm trying to walk you through it. But that won't work if you don't follow my lead. If you want to understand the answer, then please humour me and try to answer the question from my previous comment:

Do you think the blue full frame would measure as 10,000 Nits, same as the white full frame? Or do you think it would be slightly brighter, or much brighter than white? Or slightly darker or much darker than white? I don't need you to guess exact numbers, but it's absolutely *crucial* for you to understand how a full frame blue frame measures (in terms of brightness / Nits) compared to a full white frame.
I am not sure in true brightness on the screen, less I guess.

But on a waveform they would be equally 1000nits peak signals.

JVC X9500 (RS620) | 120" 16:9 | Marantz AV7702 MkII | Emotiva XPA-7 | DIY Modular Towers | DIY TPL-150 Surrounds | DIY Atmos | DIY 18" Subs
-
MadVR Settings | UHD Waveform Analysis | Arve Tool Instructions + V3 Javs Curves
Javs is offline  
post #53 of 6081 Old 02-06-2018, 06:15 AM
AVS Forum Special Member
 
markmon1's Avatar
 
Join Date: Dec 2006
Posts: 5,502
Mentioned: 102 Post(s)
Tagged: 0 Thread(s)
Quoted: 4638 Post(s)
Liked: 2943
Quote:
Originally Posted by madshi View Post
The answer is very complicated. That's why I'm trying to walk you through it. But that won't work if you don't follow my lead. If you want to understand the answer, then please humour me and try to answer the question from my previous comment:

Do you think the blue full frame would measure as 10,000 Nits, same as the white full frame? Or do you think it would be slightly brighter, or much brighter than white? Or slightly darker or much darker than white? I don't need you to guess exact numbers, but it's absolutely *crucial* for you to understand how a full frame blue frame measures (in terms of brightness / Nits) compared to a full white frame.
I'm going to throw a guess out there. I am guessing that if a display can do 10,000 Nits on a full white frame, that on a blue frame we'd be looking at around 1/3 that say 3333 nits. I'd expect those white frames to be made up of 3333 red + 3333 green + 3333 blue for 10000 nits white. Maybe this thinking is wrong?

Video: JVC RS4500 135" screen in pure black room no light, htpc nvidia 1080ti.
Audio: Anthem mrx720 running 7.1.4, McIntosh MC-303, MC-152, B&W 802d3 LR, B&W HTM1D3 center, B&W 805d3 surround, B&W 702S2 rear, B&W 706s2 x 4 shelf mounted for atmos, 2 sub arrays both infinite baffle: 4x15 fi audio running on behringer ep4000 + 4x12 fi audio running on 2nd ep4000.
markmon1 is offline  
post #54 of 6081 Old 02-06-2018, 06:20 AM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,279
Mentioned: 194 Post(s)
Tagged: 0 Thread(s)
Quoted: 941 Post(s)
Liked: 1384
An hint ;-) Have a look at the Y values.

Soulnight is online now  
post #55 of 6081 Old 02-06-2018, 06:20 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Javs View Post
I am not sure in true brightness on the screen, less I guess.
Yes. Actually, a perfect 10,000 projector which displays a pure 100% saturated blue pixel would max out at 593 Nits for blue!!! Can you believe that?? But it's true - at least if I did my math correctly.

Now considering that even a perfect 10,000 Nits projector maxes out at 593 Nits for a pure 100% saturated blue, what should that projector ideally do, if the video contains blue pixels with 1000 nits, 2000 nits, 3000 nits, ..., 10000 nits? There are 3 things the projector can do in this situation. I'll give you option 1:

1) The projector could simply draw all those pixels the best it can do, with 593 Nits, with pure 100% saturation. So all blue pixels above 593 Nits would look the same, but at least they'd all have perfect 100% saturation. Obvious disadvantage with this approach is that you'd completely lose any highlight details in blue areas. Advantage of this solution is perfect saturation. Agreed?

Now there are 2 more things a perfect 10,000 projector could do to draw 1000 nits, 2000 nits etc pure blue pixels. Can you think of what those 2 more solutions could be?

2) ?
3) ?
madshi is offline  
post #56 of 6081 Old 02-06-2018, 06:24 AM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,279
Mentioned: 194 Post(s)
Tagged: 0 Thread(s)
Quoted: 941 Post(s)
Liked: 1384
D65 looks actually like this.
Our eyes are not linear to the different color brightness.

Soulnight is online now  
post #57 of 6081 Old 02-06-2018, 06:30 AM
AVS Forum Special Member
 
Javs's Avatar
 
Join Date: Dec 2012
Location: Sydney
Posts: 7,849
Mentioned: 475 Post(s)
Tagged: 0 Thread(s)
Quoted: 6791 Post(s)
Liked: 6418
Quote:
Originally Posted by madshi View Post
Yes. Actually, a perfect 10,000 projector which displays a pure 100% saturated blue pixel would max out at 593 Nits for blue!!! Can you believe that?? But it's true - at least if I did my math correctly.

Now considering that even a perfect 10,000 Nits projector maxes out at 593 Nits for a pure 100% saturated blue, what should that projector ideally do, if the video contains blue pixels with 1000 nits, 2000 nits, 3000 nits, ..., 10000 nits? There are 3 things the projector can do in this situation. I'll give you option 1:

1) The projector could simply draw all those pixels the best it can do, with 593 Nits, with pure 100% saturation. So all blue pixels above 593 Nits would look the same, but at least they'd all have perfect 100% saturation. Obvious disadvantage with this approach is that you'd completely lose any highlight details in blue areas. Advantage of this solution is perfect saturation. Agreed?

Now there are 2 more things a perfect 10,000 projector could do to draw 1000 nits, 2000 nits etc pure blue pixels. Can you think of what those 2 more solutions could be?

2) ?
3) ?
If you give white a value of 1 for the measured brightness rolling average can you do the same for colours? But scale the known max luminance of that colour, so 593 nits blue in the case of 10,000nits encoded blue becomes 1?

I know you are going to say to achieve the encoded brightness you need to add white, but that's clearly vastly deviating from what the real content is supposed to look like.

JVC X9500 (RS620) | 120" 16:9 | Marantz AV7702 MkII | Emotiva XPA-7 | DIY Modular Towers | DIY TPL-150 Surrounds | DIY Atmos | DIY 18" Subs
-
MadVR Settings | UHD Waveform Analysis | Arve Tool Instructions + V3 Javs Curves
Javs is offline  
post #58 of 6081 Old 02-06-2018, 06:31 AM
AVS Forum Special Member
 
Javs's Avatar
 
Join Date: Dec 2012
Location: Sydney
Posts: 7,849
Mentioned: 475 Post(s)
Tagged: 0 Thread(s)
Quoted: 6791 Post(s)
Liked: 6418
Quote:
Originally Posted by Soulnight View Post
D65 looks actually like this.
Our eyes are not linear to the different color brightness.

I don't really care about that though, and yes I am well aware of it, blue still looks like the correct blue in that image, get my meaning?

JVC X9500 (RS620) | 120" 16:9 | Marantz AV7702 MkII | Emotiva XPA-7 | DIY Modular Towers | DIY TPL-150 Surrounds | DIY Atmos | DIY 18" Subs
-
MadVR Settings | UHD Waveform Analysis | Arve Tool Instructions + V3 Javs Curves
Javs is offline  
post #59 of 6081 Old 02-06-2018, 06:35 AM
AVS Forum Special Member
 
Javs's Avatar
 
Join Date: Dec 2012
Location: Sydney
Posts: 7,849
Mentioned: 475 Post(s)
Tagged: 0 Thread(s)
Quoted: 6791 Post(s)
Liked: 6418
How is madvr drawing blue in SDR then? Since blue only accounts for roughly 8% at full saturation yet if I encoded blue at 100 nits on a colour grade and export it, what is madvr doing to the other 92 nits of encoded brightness?

JVC X9500 (RS620) | 120" 16:9 | Marantz AV7702 MkII | Emotiva XPA-7 | DIY Modular Towers | DIY TPL-150 Surrounds | DIY Atmos | DIY 18" Subs
-
MadVR Settings | UHD Waveform Analysis | Arve Tool Instructions + V3 Javs Curves
Javs is offline  
post #60 of 6081 Old 02-06-2018, 09:45 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,573
Mentioned: 458 Post(s)
Tagged: 0 Thread(s)
Quoted: 2338 Post(s)
Liked: 3039
Quote:
Originally Posted by Javs View Post
I know you are going to say to achieve the encoded brightness you need to add white, but that's clearly vastly deviating from what the real content is supposed to look like.
Yes. So we have 2 options now:

1) Clipping: Draw a 2000Nits blue pixel the same way as a 593Nits blue pixel, namely with 593Nits pure blue.
2) Desaturation: Add a little bit of "white" to make a 2000Nits blue pixel brighter than a 593Nits blue pixel.
3) ?

Quote:
Originally Posted by Javs View Post
If you give white a value of 1 for the measured brightness rolling average can you do the same for colours? But scale the known max luminance of that colour, so 593 nits blue in the case of 10,000nits encoded blue becomes 1?
You mean we would map 10,000nits blue to 593Nits, and 9,000nits blue to a bit less than 593Nits? And 8,000nits blue to yet another bit less? Etc?

What would we do with the Red and Green channels then? Would we apply exactly the same mapping? So 10,000nits green would become 593Nits, too? Or would we map 10,000nits green to the max the projector can do for green, which is respectable 6,780nits?

Quote:
Originally Posted by Javs View Post
How is madvr drawing blue in SDR then? Since blue only accounts for roughly 8% at full saturation yet if I encoded blue at 100 nits on a colour grade and export it, what is madvr doing to the other 92 nits of encoded brightness?
That's actually a very good question. And it shows that you start to understand the real technical problems. Fact is, SDR is encoded in YCbCr with a gamma (BT.709) transfer function. Gamma doesn't assign specific nits values to specific Y values, but usually SDR diffuse white is considered to be 100nits, so let's say that an Y value of 235 (8bit) means 100 nits. Theoretically you could encode a pure blue pixel with 100% saturation to have an Y value of 235. However, if you do that, after YCbCr -> RGB conversion that pixel would get a HUGE number for the blue channel, which would *far* exceed the max allowed RGB value of 235 (in TV levels). So no display would know what to do with such a pixel. As a result, most SDR videos actually contain white(ish) skies instead of blue skies (!!), simply because SDR is not technically able to encode a bright blue highly saturated sky in such a way that an SDR display can actually draw it.

When HDR was introduced, I remember that some experts said that the biggest advantage of HDR is not actually HDR in itself, but the technical ability to encode highly saturated blue skies at 100nits+ brightness, which was simply not possible in SDR at all.

Now we still have a similar problem in HDR: We cannot really use 10,000nits blue pixels, because even a perfect 10,000nits display can't draw them properly. However, the problem has moved up to a much higher nits level. SDR had problems with pure blue at 100nits. Now HDR has problem with pure blue at 10,000nits. Same problem, but much less dramatic for real life content. But basically the same problem in test patterns.
stef2 likes this.
madshi is offline  
Sponsored Links
Advertisement
 
Reply Digital Hi-End Projectors - $3,000+ USD MSRP

Tags
dynamic tone mapping , hdr , madvr , sdr , ton mapping

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off