AVS Forum banner

841 - 860 of 1220 Posts

·
Registered
Joined
·
1,479 Posts
Discussion Starter #841
madmeasuredynamicclipping Tool V3.7.7

@Everyone
NEW Version V3.7.7

Download:
Madmeasure Optimizer V3.7.7:
http://projectiondream.com/download/madmeasuredynamicclipping/

MadVR Beta V40:
http://madshi.net/madVRhdrMeasure40.zip

NEW:

1) New dynamic Target nits "ALGO BT2390" :cool:

- Started based on a discussion we had with @madshi some weeks ago: to target for every frame constant FALL after BT2390 is applied

What it basically does is an optimizing process for each frame.
-->Knowing your display real nits (that you have entered), it will look for the target nits which will give you after application of the BT2390 tone mapping on the histogram a FALLBT2390 brightness on your screen.

To put it even more simply, for the same dynamic tuning value (default 100), EVERYBODY will get the same average brightness on screen.
You basically only have to enter you "real display nits" and the algo will look for each frame for the corresponding target nits so that it achieves a hardcoded average brightness.

So, no matter if you have 50 real nits or 200 real nits, you can keep dynamic tuning at 100 and you will perceive the same brightness with your eyes from the screen. :)
Of course, you can tweak this global average tagregt brightness with the dynamic tuning.

- Higher value than 100 dynamic tuning will target a lower average brightness but will strengthen HDR.
- Lower value than 100 dynamic tuning will target a higher average brightness but will lessen HDR.

I expect that Neo-XP will maybe choose something like 50 or even 25 for dynamic tuning to get twice or four time the average brightness than everybody else would have with 100. :D

To put is as a formula to illustrate things:
we are looking for each frames through mutiple optimization iteration for the correct target nits so that:

Average screen brightness = FALLBT2390 * RealNits / Target Nits * Dynaming Tuning /100 converges to
--> Target brightness
- with FALLBT2390 being heavily dependant on the target nits.
- Target brightness is hardcoded to 12.5nits at the moment since it gives me a good brightness on screen.
(it should give the same brightness feeling to evereybody no matter their real nits, as long as they did not lie in the rea display nits filed ;) )

Note: since this is an optimization process and the whole BT2390 tone mapping equations are recalculated each time, the BT2390 algo is slower to calculate as FALL Algo. Up to 30s for us compared to 7s with the FALL algo. We can probably improve the optimization process speed some more in the future.

2) The new BT2390 algo includes a new sub algo to make sure than the 0-100nits is NEVER compressed.
That's for you @Manni01 ;)
What it does is to put the "KneeStart" defined in BT2390 at 100nits, and look what target nits does it needs based on the current frame peak so that 0-100nits stays untouched.
-->This basically makes "No compression Limit" a bit useless since it is much smarter. :)

Here a table we created from BT2390 formulas to illustrate how hich needs to be a target nits for a certain frame peak so that 0-100 stays untouched (Knee start at 100nits).



3) There is a new chapter logic called "sandwich".
What it basically does if you have 3 scenes in a row is to to look is scene 1 and 3 looks alike (similar FALL), if they do and than the "in between" scene number 2 is smaller than the "minimal duration chosen", then 1,2 and 3 becomes a single chapter.
This avoids to have unwanted "target nits" reset when people are talking to each other and the camera keeps changing perspective back and forth. You ideally do not want that one personn is much brighter than the next if they are sitting in the same room. :rolleyes:
-->This will be further improved in the future with multiple in betwwen scenes as long as they are not longer as the "minimal duration":

4) Minimal duration is now only used in 3. It made no sense to just make a scene longer just to meet a length mixing scenes which had no reasons to be together.

5) Since, we now have an algo looking to protected the 0-100nits range from compression no matter what, I advise to use 0 as a "No Compression Limit" in combination with the BT2390 Algo.

6) Also, the target nits for the "BT2390 algo" still is capped at the frame peak.
It is also capped at 2*avgHL*brightness scaling factor with avgHL being the FALL of the pixels 100nits to peak only.
The "Brightness scaling factor" is it itself 1 with 100 "Real display nits", about 0,88 with 50 real nits etc.
It scales with lineartoPQ from "Real display nits" as Madshi proposed in the past.
--> I would say, you probably don't need any hardcoded "Max target nits" anymore. So you can put it at 10000nits now. (Before I had it at 1500nits).

8= Forgot to say that avgHL algo is now gone. So is the "Fix bright spot" option.

7) As conclusion "BT2390" should make life much easier and more intuitive for the user. :)
- "No Compress Limit" can probably be removed in the future: 0 recommended
- "Max target Nits" can probably be removed in the future: 10000 recommended
- Dynamic Tuning now only scales with the brightness/HDR taste of the user and do not need to be increased if you have a higher real nits (it's done internally already)

BT2390 is also now based on "physics": an average brightness target on screen.
In the end, I still get similar results than the FALL algo which is good since everybody liked it a lot.
But it has now a "meaning" and will scale much easier for any kind of real nits on screen.

Further improvement are planned for:
- the sandwich chapter algo
- dynamic clipping with "decompressed strength" calculation based on our new implementation of BT2390 in the code

It now looks like this:




Enjoy,
Anna&Flo :)
 

Attachments

·
Registered
Joined
·
7,964 Posts
That sounds very cool! So this basically means if I change the "real display nits" setting, the image will actually get brighter/darker accordingly? That often wasn't the case with the FALL algo, which I found confusing.
 

·
Premium Member
Joined
·
9,875 Posts
Yes very exciting, looking forward to testing. Thanks for all your hard work Anna and Flo, especially re protecting 0-100nits :)

Question: why do you provide madVR beta V40? Is it the first version that works with your tool, or the best one? Does it not work with the latest betas with the live algo improvements?
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #844
That sounds very cool! So this basically means if I change the "real display nits" setting, the image will actually get brighter/darker accordingly? That often wasn't the case with the FALL algo, which I found confusing.
Yes. :) (but only for the dynamic target nits BT2390 algo).

The goal is that everybody will SEE from the screen the same average brightness no matter what they have for "real display nits" as long as they use the same dynamic tuning.

So, if I have 50 real nits and 100 dynamic tuning, and if Manni01 put 150 real display nits and 100 dynamic tuning, in reality we will both see an picture which is in average equally bright to our eyes.
Only the one from Manni01 with higher real nits will of oucrse use higher target nits in general and have more hdr pop to it that mine.

After that, people can further fine tune their taste to have a a difference brightness on screen than what you get with 100% dynamic tuning.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #845
Yes very exciting, looking forward to testing. Thanks for all your hard work Anna and Flo, especially re protecting 0-100nits :)

Question: why do you provide madVR beta V40? Is it the first version that works with your tool, or the best one? Does it not work with the latest betas with the live algo improvements?
You're welcome. :)

I think this table we created from BT2390 formulas really explains things from a new angle.
We all knew that with 480 target nits, you were certain not to ever compress the 0-100nits range.
As you can see in the table, this is to protect 0-100nits in you case you have a peak of 10000nits.

I was really surprised to see that if your peak in 4000nits, you only need a target nits of 343nits to protect 0-100nits.

I was really surprised to see that if your peak in only 1000nits, you only need a target nits of 214nits to protect 0-100nits.

And even more surprised to see that for a peak of 500nits (and A LOT of content have peak below that), you are even safe with 170 target nits. :D




I just attached V40 so that people don't use an older one. :) In theory any newer one should work just fine as well... but Madshi is very active lately, so I can also happen that a newer beta V70ish breaks something at some point. :D
 

·
Premium Member
Joined
·
9,875 Posts
You're welcome. :)

I think this table we created from BT2390 formulas really explains things from a new angle.
We all knew that with 480 target nits, you were certain not to ever compress the 0-100nits range.
As you can see in the table, this is to protect 0-100nits in you case you have a peak of 10000nits.

I was really surprised to see that if your peak in 4000nits, you only need a target nits of 343nits to protect 0-100nits.

I was really surprised to see that if your peak in only 1000nits, you only need a target nits of 214nits to protect 0-100nits.

And even more surprised to see that for a peak of 500nits (and A LOT of content have peak below that), you are even safe with 170 target nits. :D




I just attached V40 so that people don't use an older one. :) In theory any newer one should work just fine as well... but Madshi is very active lately, so I can also happen that a newer beta V70ish breaks something at some point. :D
Yes, that’s why I insisted on trying to implement this 0-100 protection :)

I had not done the detailed calculations in your table (very useful) but I had roughly in my head that with around 200nits on the display we should be able to tonemap 1000nits content without touching 0-100. That wasn’t too far off :)

Very exciting with this new algo and very much looking forward to trying it :)

Well done!

As Madshi said, the correllation between target peak / dynamic tuning and actual brightness sounds great too.

It was worth the wait :)
 

·
Registered
Joined
·
7,964 Posts
Yes. :) (but only for the dynamic target nits BT2390 algo).

The goal is that everybody will SEE from the screen the same average brightness no matter what they have for "real display nits" as long as they use the same dynamic tuning.

So, if I have 50 real nits and 100 dynamic tuning, and if Manni01 put 150 real display nits and 100 dynamic tuning, in reality we will both see an picture which is in average equally bright to our eyes.
Only the one from Manni01 with higher real nits will of oucrse use higher target nits in general and have more hdr pop to it that mine.

After that, people can further fine tune their taste to have a a difference brightness on screen than what you get with 100% dynamic tuning.
That sounds pretty much perfect to me. It's exactly what we were chatting about, isn't it? And it looks good to your eyes? Won't mid range scenes become (subjectively) too bright, if they are rendered with the exact same FALL as very bright scenes? That was my biggest worry with this approach, although I like the concept a lot!

You still have some limiters in place, though, e.g. IIRC the target nits can't exceed the frame peak, or things like that, right? Couldn't those limiters sometimes result in the somewhat weird situation that changing the real display nits value doesn't result in any visible change?
 

·
Registered
Joined
·
113 Posts
@Soulnight

It still says "madMeasureDynamicClipping V3.7.6" in the upper left corner in the program window.
(The BT2390 Algo is there as it should, so I have the right version)

edit:
For me the dynamic tuning is 75 as default
(To put it even more simply, for the same dynamic tuning value (default 100))
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #849
@Soulnight

It still says "madMeasureDynamicClipping V3.7.6" in the upper left corner in the program window.
(The BT2390 Algo is there as it should, so I have the right version)

edit:
For me the dynamic tuning is 75 as default
(To put it even more simply, for the same dynamic tuning value (default 100))
I have just re-uploaded.

The installer was right ( and I always use that). The exe was the wrong one from a previous build 3.7.6 and with error in there. So if you use directly the exe, please redownload. :)

It needs to be written 3.7.7 :rolleyes:

ps: I did not change the default since I left "FALL algo" as default. So please change dynamic tuning to 100 or whatever brightness you like best on your own. ;)
Also, put no compression limit to 0, and you can try max target nits to 10000nits.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #850 (Edited)
That sounds pretty much perfect to me. It's exactly what we were chatting about, isn't it? And it looks good to your eyes? Won't mid range scenes become (subjectively) too bright, if they are rendered with the exact same FALL as very bright scenes? That was my biggest worry with this approach, although I like the concept a lot!

You still have some limiters in place, though, e.g. IIRC the target nits can't exceed the frame peak, or things like that, right? Couldn't those limiters sometimes result in the somewhat weird situation that changing the real display nits value doesn't result in any visible change?
Yes, this was based on our discussion. However FALL is not enough, you need to scale down or up based on the currently used target nits compared to the "real nits" to have the "real perceived brightness". :)

The results looks very surpringly pretty similar to the experimental based "FALL algo".
So yes, looks fine to me.

Yes limiter are still there.
So yes, you can't go lower than the mininum/real nits (that would be rendered brighter than intended on the 4k bluray anyway).
You also can't go lower than the calculated "Mintargetnits" for a Kneestart at 100 for protecting at all time 0-100nits from any compression.

And I you can't go higher than the peak because that would just throw brightness away.
And not higher than 2*avgHL*brightnessscalefactor either which helps in some cases to not go too high.

So it any of these situations, you don't respect the "target brightnes" calculation but it still looks fine to me. Very similar to the FALL algo. :)

But much more practical from a user point of view.

Edit: however we only did limited testing today. :)
So as everything, it may still evolve...
 

·
Registered
Joined
·
113 Posts
I have just re-uploaded.

The installer was right ( and I always use that).

Great! I have re-downloaded and it is now the correct version.
What are the pros of using the installer as you do, I always find it easier to simply make a shortcut of the "madMeasureDynamicClipping.exe" to the the desktop and start the program that way.
 

·
Registered
Joined
·
2,033 Posts
Hi Soulnight,

I just looked at your release notes briefly. Can you explain your BT.2390 adjustment a little more. For example, I was looking at this line:

- Display Target Nits: 214nits
- Frame Peak: 1000nits
- Knee in nits: 100nits

I have been using a real display nits of about 214nits with the current FALL algo. Does this mean 480nits is always chosen when the frame peak is 1,000 nits? If so, I'm not sure I like that as the previous FALL algo actually seems to make a more intelligent choice of when to raise the target nits that high. In other words, I took your side that using the FALL more than the frame peak results in better perceived brightness and contrast than always attempting to protect 100 nits from compression.

I still don't see why most people need targets above 480nits if their display is outputting 50-150nits. I was waiting for madshi to finish working on correcting scene detection before asking this question.

Tone mapping is desaturating all colors relative to the target display nits. Using crazy targets like 600-1,500 nits on a dim display often creates terribly oversaturated, dark color tones. Even if it might look good to the eye, color accuracy is harmed by using excessively high target nits relative to the actual display brightness. There was a thought that 4,000 nits targets should be used as a point of reference for color accuracy at one point, but BT.2390 is meant to desaturate pixels relative to the loss of luminance.
 

·
Registered
Joined
·
2,033 Posts
I guess I should have added that I was using a dynamic tuning value of 100 with no compression set to 300nits and the target nits limit set to 480nits.

I'd say I was 85-90% happy with the targets of the simple FALL algo, as almost every movie I tested looks good without being washed out. The result is definitely better than using Manni's static profile rules, which use generally higher targets for the majority of the movie. More often than not, there is enough contrast to make HDR work without making the image too dim.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #854 (Edited)
Hi Soulnight,

I just looked at your release notes briefly. Can you explain your BT.2390 adjustment a little more. For example, I was looking at this line:

- Display Target Nits: 214nits
- Frame Peak: 1000nits
- Knee in nits: 100nits

I have been using a real display nits of about 214nits with the current FALL algo. Does this mean 480nits is always chosen when the frame peak is 1,000 nits? If so, I'm not sure I like that as the previous FALL algo actually seems to make a more intelligent choice of when to raise the target nits that high. In other words, I took your side that using the FALL more than the frame peak results in better perceived brightness and contrast than always attempting to protect 100 nits from compression.
1) The new BT2390 algo has for goal "constant brightness on screen". That's the main part.
This is explained in detail in my main post. This is using the FALL after tone mapping to choose the target nits. So this kind of based on FALL.


2) As I said, there is a second algo within (which has nothing to do with the first) for the express purpose to protect 0-100nits from compression. This table shows you what can happen for various peak and what minimum target nits do you need to place the Kneestart at 0-100nits.
If you have a peak of 1000nits, then the target nits minimum value will be 214nits.
This is the minimum target you need for specific peak to protect 0-100 nits.
480 target nits is only needed as a MINIMUM target to protect 0-100nits range IF you peak is 10000nits! That does not happen very often.
-->this 2nd sub algo is only defining a dynamic "No Compression limit" if you prefer. So only defining a minimum target value. Algo 1 is doing the main decision work here.

I still don't see why most people need targets above 480nits if their display is outputting 50-150nits. I was waiting for madshi to finish working on correcting scene detection before asking this question.

Tone mapping is desaturating all colors relative to the target display nits. Using crazy targets like 600-1,500 nits on a dim display often creates terribly oversaturated, dark color tones. Even if it might look good to the eye, color accuracy is harmed by using excessively high target nits relative to the actual display brightness. There was a thought that 4,000 nits targets should be used as a point of reference for color accuracy at one point, but BT.2390 is meant to desaturate pixels relative to the loss of luminance.
Maybe someone else than myself to explain? @Manni01 @Neo-XP? @madshi?
In any case, nobody in forcing you to do something you don't like.
But you should be very careful with your statements saying that everybody else is doing it wrong. ;)


EDIT:
By the way, as it is said in my main release post, all the BT2390 related changed are only for the BT2390 algo.
The FALL algo remains identical.
So everybody can compare both. ;)
 

·
Registered
Joined
·
2,033 Posts
1) The new BT2390 algo has for goal "constant brightness on screen". That's the main part.
This is explained in detail in my main post. This is using the FALL after tone mapping to choose the target nits. So this kind of based on FALL.


2) As I said, there is a second algo within (which has nothing to do with the first) for the express purpose to protect 0-100nits from compression. This table shows you what can happen for various peak and what minimum target nits do you need to place the Kneestart at 0-100nits.
If you have a peak of 1000nits, then the target nits minimum value will be 214nits.
This is the minimum target you need for specific peak to protect 0-100 nits.
480 target nits is only needed as a MINIMUM target to protect 0-100nits range IF you peak is 10000nits! That does not happen very often.
-->this 2nd sub algo is only defining a dynamic "No Compression limit" if you prefer. So only defining a minimum target value. Algo 1 is doing the main decision work here.
I think I'm still somewhat confused by the second algo. Can you give me some example target nits?

If I set the real display nits to 200nits, what targets do I get for the following frame peaks:

- 300 nits
- 600 nits
- 800 nits
- 1000 nits

Is the FALL still factored-in? It looks like some or all of the formula might be there, but I'm not sure if I understand it.

Maybe someone else than myself to explain? @Manni01 @Neo-XP? @madshi?
In any case, nobody in forcing you to do something you don't like.
But you should be very careful with your statements saying that everybody else is doing it wrong. ;)


EDIT:
By the way, as it is said in my main release post, all the BT2390 related changed are only for the BT2390 algo.
The FALL algo remains identical.
So everybody can compare both. ;)
I'm not saying anyone is wrong. It is hard to provide an opinion if it goes against the consensus.

I was arguing that tone mapping science should be given more weight when choosing the target peak nits. Very high target nits create oversaturated colors because color correction in tone mapping is designed to desaturate most colors after (Y) luminance is compressed. This desaturation is meant to match the target display brightness.

I think there should be a better defined limit and reasoning behind using these targets, as they have trade-offs, including creating occasionally unintended dark images. The very high targets are also rarely used by the FALL algo.

I thought 480nits was doing a good job with most very bright scenes, so that is my preference for a practical limit for most displays.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #857
I think I'm still somewhat confused by the second algo. Can you give me some example target nits?

If I set the real display nits to 200nits, what targets do I get for the following frame peaks:

- 300 nits
- 600 nits
- 800 nits
- 1000 nits

Is the FALL still factored-in? It looks like some or all of the formula might be there, but I'm not sure if I understand it.
This minimum target nits is fully independant of your "real display nits".
So the table posted 2 times above already gives you the answer of what minimum target nits will be applied based on the current frame peak so that the KneeStart=100nits.

But that's only a minimum. In most cases, the minimum will not be used because the BT2390 constant brightness algo will ask for a higher target nits than this minimum anyway.

It's not that important. But when needed, it is smarter and more effective than using a fix no compression limit range.

In any case, you don't need to understand it to test it. :)
 

·
Registered
Joined
·
2,033 Posts
This minimum target nits is fully independant of your "real display nits".
So the table posted 2 times above already gives you the answer of what minimum target nits will be applied based on the current frame peak so that the KneeStart=100nits.

But that's only a minimum. In most cases, the minimum will not be used because the BT2390 constant brightness algo will ask for a higher target nits than this minimum anyway.

It's not that important. But when needed, it is smarter and more effective than using a fix no compression limit range.

In any case, you don't need to understand it to test it. :)
Yep, it's still definitely not clear. So "Display Target Nits" is the same thing as target peak nits (target output brightness for tone mapping) in madVR?

How can the knee point be at 100 nits if the target nits is 214 nits? Are you manipulating BT.2390 to have a higher knee point?
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #859
Yep, it's still definitely not clear. So "Display Target Nits" is the same thing as target peak nits (target output brightness for tone mapping) in madVR?

How can the knee point be at 100 nits if the target nits is 214 nits? Are you manipulating BT.2390 to have a higher knee point?
Please have a read there at the BT2390 (page 22). ;) The Kneestart depends mostly on the master peak luminance.
When you work frame based, this becomes your frame peak instead.
Do the math and you will see that with a peak of 1000nits, your Kneestart will be at 100nits with a target nits of 214 nits. (with the assumptions of display and master black = 0nits)

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-5-2018-PDF-E.pdf

As a reminder: this thread is dedicated to our tool: madmeasure dynamicclipping / optimizer.
So people are expected to give feedback to the results.

I only provide more advanced explanations for people who are interested in them and understand them.
For further discussion, you will find mutiple threads in avsforum dedicated to tone mapping discussion.

Thank you,
Happy testing. :)
 

·
Registered
Joined
·
2,033 Posts
Please have a read there at the BT2390 (page 22). ;) The Kneestart depends mostly on the master peak luminance.
When you work frame based, this becomes your frame peak instead.
Do the math and you will see that with a peak of 1000nits, your Kneestart will be at 100nits with a target nits of 214 nits. (with the assumptions of display and master black = 0nits)

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-5-2018-PDF-E.pdf
I don't know why you are being rude to the person who answers madVR-related inquiries everyday. I don't understand all of the math there. That is why I am asking these questions.

Has BT.2390 been using a variable and not fixed knee point all along with frame-based tone mapping by using the measured brightness of each frame? That is what I am now trying to understand. fhoech had always been advocating the use of a fixed 480 nits with BT.2390 because the image was too flat for his tastes. I can also see this in screenshots I take now where 0-100 nits looks compressed at low target nits.

I'd like to know if the detail added at higher target nits is artificial or caused by reduced compression of 0-100nits.

If you understand the math better than me, why can't I ask you, the expert, in this thread? I won't get that information anywhere else.

As a reminder: this thread is dedicated to our tool: madmeasure dynamicclipping / optimizer.
So people are expected to give feedback to the results.

I only provide more advanced explanations for people who are interested in them and understand them.
For further discussion, you will find mutiple threads in avsforum dedicated to tone mapping discussion.

Thank you,
Happy testing. :)
Anything can be improved with constructive feedback. It helps to understand how things work before testing to know what you should be looking for. This is particularly true with screenshots when looking for compression of 0-100 nits.

With the current builds, I think I see compression of 0-100 nits when the frame peak is 600 nits and the target nits is 200 nits. Is this incorrect? If so, do you know why higher target nits manage to add more apparent detail?

You didn't address this question, either

I was arguing that tone mapping science should be given more weight when choosing the target peak nits. Very high target nits create oversaturated colors because color correction in tone mapping is designed to desaturate most colors after (Y) luminance is compressed. This desaturation is meant to match the target display brightness.

I think there should be a better defined limit and reasoning behind using these targets, as they have trade-offs, including creating occasionally unintended dark images. The very high targets are also rarely used by the FALL algo.
Is that not what the formula for chrominance in BT.2390 is doing (desaturation):



The theory comes from a paper that was posted some time ago in the HDR -> SDR tone mapping thread:

Color Correction for Tone Mapping

While many tone mapping algorithms offer sophisticated methods for mapping a real-world luminance range to the luminance range of the output medium, they often cause changes in color appearance. The most common tone manipulation is luminance compression, which usually causes darker tones to appear brighter and distorts contrast relationships. Figure 1B shows an HDR image after compressing luminance contrast by a factor of 0.3 while preserving pixel chrominance values (in terms of the CIE xy chromatic coordinates). When compared to the non-compressed image (exposure adjustment + sRGB display model) in Figure 1A, the colors are strongly over-saturated.
The color distortion caused by using target nits that don't align with the display nits is what I don't agree with.

These are two examples from Blade Runner:

200 target nits:
http://upload.vstanced.com/images/2019/01/13/b8bdf2d1b270aefbe28cc3d5960a27be.png

425 target nits:
http://upload.vstanced.com/images/2019/01/13/d9a4983803a4df4d2d9bc05593735f6f.png

200 target nits:
http://upload.vstanced.com/images/2019/01/13/15a1b063cbcb62f24596f5cb38170d45.png

425 target nits:
http://upload.vstanced.com/images/2019/01/13/96bcf029c5a46cfe21fd573536ba7826.png

The orange hues and brown hues in these images have far less accurate color saturation when the target nits and display nits are badly misaligned.

The end display is basically double tone mapping the result calculated by madVR by reducing the luminance of each calculated value at the display. I think of this as "distorting color relationships."

It is these overdark color tones that I see when comparing images taken at high target peak nits with various reference images on review Websites. The hue is always accurate, but the colors look oversaturated.

I was asking if these high targets nits are worth it at the expense of color accuracy and the possibility of occasional overdark images?

I don't why I would need to be brushed off over that...
 
841 - 860 of 1220 Posts
Top