AVS Forum banner

3921 - 3940 of 12911 Posts

·
Registered
Joined
·
5,524 Posts
Just watched Dark Knight Rises with 27. I had one small scene that I need to look at tomorrow but otherwise it looks fantastic. The one scene got noticeably bright for an instant and adjusted itself back to normal almost immediately. Was just a weird brightness jump I guess. I'll try to find the scene tomorrow and see if that's consistent. Really loving these latest features for actual movie watching. I realize you want testing but sometimes it's good to just sit and watch a whole movie uninterrupted and see how it looks in the real world. :)
 
  • Like
Reactions: Manni01

·
Registered
Joined
·
498 Posts
Ok, since we are doing this I have noticed one scene in Skyscraper right at the beginning of the movie after the man sets off the bomb strapped to him and it goes to complete white. Right, when it cuts to the hospital it gets a little brighter and then goes back to correct brightness.
 

·
Registered
Joined
·
54 Posts

Attachments

·
Registered
Joined
·
794 Posts
@pandm1967
great job :) I cannot test it at the moment, but I find your tool very handy. I've used it today to copy your data in spreadsheet to come up with 90%, 99% 99.99% averages. I hope you can incorporate them into our tool, I believe it is under construction :)


I'm off to do some testing with new build with my nits target profiles slightly adjusted based on some new calculation. ;)
 

·
Registered
Joined
·
498 Posts
@madshi


I'm trying v27, is 100 the lowest target peak nits I can set to? I apologize if that was already covered, and if it is indeed the limit I will stick to 100. :)
I am using 100 because it is giving me the same amount of detail as in a basic HD source in UHD quality. I really don't want to go lower until it's too dark where it missing major detail in dark scenes. Then in dark scenes it just feels way too dark and that's another reason I have settled on 100 nits for now.

Also, I just watched Matrix Revolutions with this new build and holy smokes does it look good.
 

·
Registered
Joined
·
794 Posts
I am using 100 because it is giving me the same amount of detail as in a basic HD source in UHD quality. I really don't want to go lower until it's too dark where it missing major detail in dark scenes. Then in dark scenes it just feels way too dark and that's another reason I have settled on 100 nits for now.

Also, I just watched Matrix Revolutions with this new build and holy smokes does it look good.

I'm using @Manni01 HDR profiles:


Measured Target (based on 100 nits screen)
 

·
Registered
Joined
·
771 Posts
Just so you know, I posted on doom9 in the MKVToolNix thread to let the author(s) know that there might be a problem with remuxes of seamless branched titles, at least with madMeasureHDR. It's just a hook, I'm not gonna investigate any further and I already switched (back) to MakeMKV.

As for the HTPC control tool, is it normal that the progress is not displayed while measuring (%)? Sorry if it has been asked before.

I'm expecting 13 days in order to measure everything, at this point I'm limited by NAS read speeds. Hope the measurement file format does not change ;-) Have a good day.
 

·
Registered
Joined
·
794 Posts
Just so you know, I posted on doom9 in the MKVToolNix thread to let the author(s) know that there might be a problem with remuxes of seamless branched titles, at least with madMeasureHDR. It's just a hook, I'm not gonna investigate any further and I already switched (back) to MakeMKV.

As for the HTPC control tool, is it normal that the progress is not displayed while measuring (%)? Sorry if it has been asked before.

I'm expecting 13 days in order to measure everything, at this point I'm limited by NAS read speeds. Hope the measurement file format does not change ;-) Have a good day.

Do you know (or anyone) if I can fix/remux already "affected" files? (Thank you for telling the author about it !!! :D)



AFAIK HTPC control tool doesn't show progress (I wish it had though ;)).


Yeah it is a long process, it is quiet long process, perhaps wait for @madshi to finalize it (if that is even possible during development/testing stage, he might still have to change the format). I would just measure the files of tv shows/movies you are currently watching and do the rest of them later. (Just my $0.05 ;)).
 

·
Registered
Joined
·
794 Posts
New test build:

http://madshi.net/madVRhdrMeasure27.zip

1) Added some workarounds/improvements for incomplete measurement files. Will not solve all problems! But maybe some.
2) Incomplete measurements files are still created, but now get the file name extension ".measurements.incomplete", and are ignored by madVR.
3) madVR no longer stores/remembers measurements during playback, because those were often incomplete, anyway.
4) Simplified settings dialog.
5) Dynamic intra-scene optimizations are now always active, if a (complete) measurement file is available.
6) Dynamic intra-scene optimizations now vary between min 4% and max 20%, depending on the situation.
7) Dynamic intra-scene optimizations are now carefully post processed / smoothed.
8) Dynamic intra-scene optimizations are now only done for 4+ second scenes. Shorter scenes are tone mapped to the scene's peak.
9) Fixed problem with histogram adding up to 106.67% instead of 100%.
10) Live algo: Added 3rd percentage value to histogram "flicker risk".

@Everyone , could you please double check that the dynamic intra-scene optimizations are working well? Basically, they should be relatively fast (up to 20%) for most scenes, but slow enough (4%) for flicker risky scenes like the Matrix 2 scene we tested with. Obviously we want full fast dynamic reaction, but there should be no luminance fluctuations/instabilities, and no visible brightness changes in the middle of a scene.

When you are talking about trying dynamic intra-scene optimizations in "%", you are talking about 20sec / 4sec in "brightness reaction time"? I just wanted to make sure. ;)
 

Attachments

·
Registered
Joined
·
771 Posts
Do you know (or anyone) if I can fix/remux already "affected" files? (Thank you for telling the author about it !!! :D)



AFAIK HTPC control tool doesn't show progress (I wish it had though ;)).


Yeah it is a long process, it is quiet long process, perhaps wait for @madshi to finalize it (if that is even possible during development/testing stage, he might still have to change the format). I would just measure the files of tv shows/movies you are currently watching and do the rest of them later. (Just my $0.05 ;)).


No I don’t know how to fix problematic remuxes afterwards. madshi implemented some kind of error handling in v27 but I still got some errors with some files so I’m slowly starting to redo the problematic remuxes with MakeMKV. So far MakeMKV have been able to produce clean remuxes. I think seamless branched titles are kinda rare with UHD titles so it’s not too much of a hassle.

It’s not a problem if measurement file format change in the future. I’m also doing it in order to check if there could be other problems so madshi could fix it as soon as possible if it’s on the madVR side. But so far madMeasureHDR looks reliable to me.
 

·
Registered
Joined
·
2,033 Posts
The only thing I've noticed, somehow now my Kodi (whit dsplayer / madVR) is kicking my JVC RS420 into HDR picture mode when playing HDR movie. I don't remember seeing this behavior before but I could be wrong. The "output video in HDR format" is unchecked. I would think this would kick my projector into HDR picture mode. Maybe someone with JVC projector can confirm.
Does the OSD still say HDR -> SDR using pixel shaders? You might have a ghost checkbox in the control panel if the media player is sending HDR PQ rather than SDR gamma.
 

·
Registered
Joined
·
794 Posts
No I don’t know how to fix problematic remuxes afterwards. madshi implemented some kind of error handling in v27 but I still got some errors with some files so I’m slowly starting to redo the problematic remuxes with MakeMKV. So far MakeMKV have been able to produce clean remuxes. I think seamless branched titles are kinda rare with UHD titles so it’s not too much of a hassle.

It’s not a problem if measurement file format change in the future. I’m also doing it in order to check if there could be other problems so madshi could fix it as soon as possible if it’s on the madVR side. But so far madMeasureHDR looks reliable to me.

Thank you for the info.


Does the OSD still say HDR -> SDR using pixel shaders? You might have a ghost checkbox in the control panel if the media player is sending HDR PQ rather than SDR gamma.

Thank you, I will double check tonight. I'm sure it is something in my setup (win10 1803, 399.xx nvidia drivers, kodi with dsplayer). I might try previous build (v26) to make sure it is not v27. What is weird even after correcting the JVC's picture setting from HDR to BT2020 SDR during the playback which fixes the problem; the JVC projector goes back to HDR after stopping the playback. Like I said, more likely it is my setup, nothing to do with madVR. Also I would like to say thank you one more time for all your help to get me going (your HTPC madVR thread is very helpful and informative !!! ;))
 

·
Registered
Joined
·
101 Posts
Hi Guys,
Is there a step by step guide to set and starting using this feature of madvr?

Thank you

Inviato dal mio SM-N960F utilizzando Tapatalk
 

·
Registered
Joined
·
8,229 Posts
Why clipping anything? Maybe the adaptation speed is too slow?
I'm not a fan of the idea of clipping, to be honest. If we could reliably detect that there are some overbright pixels we could safely discard without a humanly visible loss in image quality, then I'd be all for that, but I don't think we can.

V26 was really much much better for the Xmen scene. Hope you can restore that to V27.
Alright. I've modified the algo slightly, and I've increased the minimum speed from 3% to 7%, based on votes by various users. That brings this scene back roughly to where it was before.

So I have looked at the "Mother Lamp" scene.
With 0,1% of the pixels clipped for this scene, you would end up clipping at 78nits (or your target nits which is higher).
You loose details in the lamp.

With 0,05%%, clipping at 205nits: basically the same as before if your target nits is 200nits...

With 0,02%, the exact nit clipping will be somewhere between 504 and 679nits ( I cannot say in more details because of the big histogram steps). In any case, this should look good enough! :)

With 0,01%, it will be clipping somewhere between 679 and 913nits. If you use the upper limit of the histogram step, then you get 913nits. Nothing visibly blown-out.

0,1% 78 nits
0,05% 203 nits
0,02% 679nits (no blow out)
0,01% 913nits (basically perfect)
0% /none: 1045nits
Allow me to stress that we've already gone from 99.9% to 99.99% which is a 10x weaker clipping than you originally suggested! And that just by testing one scene I suggested. Now imagine the camera man in the "Mother" scene would have decided to step back a few more steps. The lamp would have been even smaller. In that case even 0.01% might have been to high. We might have needed 0.001% to get near perfect results.

The problem is that the histogram doesn't really tell us if clipping those ~ 0.01% pixels will be harmful to the quality impression of a human being or not. If those 0.01% pixels are the complete center of attention (as in the "Mother" scene) it's probably extremely important to not clip them. But if those 0.01% pixels are somewhat scattered over various image sections (e.g. helmet and arm in the Xmen scene), not being the complete center of attention, then clipping them might be somewhat more acceptable. But it's not really possible for madVR to judge which parts of an image a human being is most likely to put his attention on.

So my opinion right now is that any amount of clipping could potentially harm image quality. We simply cannot safely specify any amount that would be safe. Amount X might be safe in one scene but not in another. FYI, the measurement algorithm already includes some mild "clipping" of stray overbright pixels. Well, it's not really clipping, but due to the way I'm doing the measurements, the measured peak is already lower in many situations than a 100% accurate measurement would be. I don't really feel safe clipping even more now.

I think the "measurement chapter" just show how much every one of us here WANTS to help Madshi bring Madvr further up.
Normally we can't do *anything except testing.

Here we can try to put our time and skills to create /analyse/share tools for the rest of the community to alleviate some work from madshi.

:D
I think it's pretty cool to have lot's of "mad" guys here ready to do a lot *just* to get better picture quality.
Yes, I do appreciate all your feedback in this thread very much! Of course I tend to appreciate feedback about things that I actually asked for more than feedback about things I'm not currently working/focused on.

Would it much work to increase the resolution of the histogram?
That depends. If I simply increase it, toss the current file format and create a new file format with the increased resolution, then it wouldn't be a *LOT* of work, but still some hours. If you want more resolution, but the file format to stay compatible, then make it three times that, or even more.

Also, increasing the histogram resolution would make measurements slower. Not sure how much, but probably at least twice as slow as it is now, maybe more (depending on how high the final histogram resolution would be).

What I don’t get is why the need for an extra step on top of the measurement. Couldn’t it be automatically done by madMeasureHDR? Or are those 2% quality improvements so user/hardware dependent that it cannot be automatize?
Those 2% is what you get when you use madMeasureHDR.exe. There is no extra step on top of madMeasureHDR.exe needed. At least not in the long run. It's all still a work-in-progress at this stage.

Has anyone been getting additional banding on the latest builds ?
No extra banding here. Make sure your GPU is still set to 0-255. The banding is unlikely to come from madVR, IMHO, otherwise other users would already have complained. Some of the users in this thread are *very* sensitive to things like that.

This is a .iso of a BD Full during normal viewing,
I would like to understand if the measurements (and or correction) are working
Measurements seem to be working fine. This is the "live algo", though, meaning there doesn't seem to be a measurement file for madVR to work with, so madVR measures the video on the fly and adjusts to that.

What concerns me is that for the rest of us that don't use/rip to .mkv files, we'll be losing an improvement, even a small one. A lot of folks are going to be using actual purchased media on a "friendly" BD-XL reader in their HTPC or full rips, not just .mkv rips. How will madMeasureHDR.exe handle these?
I already answered the very same question just a page or two ago.

As I said earlier, the best scenario is for a version of madVR TM that's pretty much set and forget, mainly adjustable for each user by selecting a measured NIT value at their screen or display. All this other "stuff" (measurement files, scripts, different profiles for hdr targets, etc.) is not what I consider user friendly for the vast majority of madVR users. Hopefully, they won't really be needed at all in a future finished official release. Pretty please.
They are not needed. madVR's tone mapping will be set and forget. Unless you want to squeeze out the last 2% of quality, then things get more complicated. You can't have it all: Perfect quality can only be achieved if madVR knows all measurements of all frames of the movie in advance. And that kind of information is simply not stored on UHD Blu-Rays, not even the upcoming HDR10+ supports that. So what madMeasureHDR.exe gives you is quality that (probably, hopefully) surpasses the not-even-out-yet HDR10+. If you want that kind of quality, you have to provide madVR with the needed information to achieve that. That's what madMeasureHDR.exe is for. If that's all too complicated for your taste, then just forget about it and use the standard tone mapping in madVR, which is already near to HDR10+ quality, while offering you "set and forget" easy of use.

Although I agree that the end goal is that we won't have to use any processing tools after measurements, I disagree that the change is small.

Being able to provide a better value than MaxCLL when this is present or wrong in the metadata makes a HUGE difference when using my algo to select the best profile for each file.
When I'm saying that manually editing the measurement files is not necessary and brings no (big) improvement, I'm talking both about the average user on the one hand, and about a final future madVR build on the other hand. I just don't want users to get worried that using madVR is going to become ultra complicated. It's not going to be.

And the good news :

Planet Earth Disc 1 and 2 now are working ! New rip.
Was it the new rip which did the trick, or the improvments I made in build 27?

Madshi : I just had a discussion with another madVR user (where we made the hdr shootout 2). What does "[X] Output video in HDR format" mean ?
- it sends hdr meta data
- does it change the gamma ? It seems a pq gamma is used. With gamma 2.2 the colors are not right.
- is the dynamic hdr working ?
- When I can use dynamic hdr with a pq gamma like ST2084 ?
When that option is activated, madVR switches the GPU into "HDR" mode, which means the GPU informs the display that the data coming is in HDR (PQ transfer function). Furthermore, of course in this case madVR also outputs a PQ transfer function signal instead of gamma. Activating this option may be useful for some OLED users because some OLED displays switch into a different (brighter) driving scheme, when receiving an HDR signal, compared to SDR. However, activating this option will usually also mean that the display will apply its own tone mapping algorithm on the signal, which is not good for image quality. So my recommendation would be to turn it off - unless you have an OLED display. With an OLED display, you can try this option on vs off and use what looks better to your eyes.

I saw a weird glitch in the opening shot of The Revenant, on his wife's face as she's asleep during the first panning shot, but I don't think it's related to your algo. As I know you have the clip, you might want to take a look.
That's with a measurement file, right? Three questions:

1) Can you describe in short words how that weird glitch looks like, so I know what to look for?
2) Which target nits did you watch the movie with?
3) Does the same issue also occur when renaming/removing the measurement file (thus using the "live algo")?

Thanks.

Just watched Dark Knight Rises with 27. I had one small scene that I need to look at tomorrow but otherwise it looks fantastic. The one scene got noticeably bright for an instant and adjusted itself back to normal almost immediately. Was just a weird brightness jump I guess. I'll try to find the scene tomorrow and see if that's consistent.
Ok, since we are doing this I have noticed one scene in Skyscraper right at the beginning of the movie after the man sets off the bomb strapped to him and it goes to complete white. Right, when it cuts to the hospital it gets a little brighter and then goes back to correct brightness.
Same questions to both of you: Is that with a measurement file or without? And which time code is it?

I'm trying v27, is 100 the lowest target peak nits I can set to?
Yes.

The only thing I've noticed, somehow now my Kodi (whit dsplayer / madVR) is kicking my JVC RS420 into HDR picture mode when playing HDR movie. I don't remember seeing this behavior before but I could be wrong. The "output video in HDR format" is unchecked. I would think this would kick my projector into HDR picture mode. Maybe someone with JVC projector can confirm.
Maybe you accidently activated the OS HDR mode switch? Otherwise: Try if rebooting helps.

Just so you know, I posted on doom9 in the MKVToolNix thread to let the author(s) know that there might be a problem with remuxes of seamless branched titles, at least with madMeasureHDR. It's just a hook, I'm not gonna investigate any further and I already switched (back) to MakeMKV.
Please don't do that. It's extremely frustrating to developers if you report a vague bug and then refuse to follow-up on it. Just don't bother to report it in the first case, if you're not willing to follow-up.

When you are talking about trying dynamic intra-scene optimizations in "%", you are talking about 20sec / 4sec in "brightness reaction time"? I just wanted to make sure. ;)
The "brightness reaction time" is for the "live algo". Meaning it's for the algo which is used when no measurement file is available. The "dynamic intra-scene optimizations in %" are for the other algo, when a measurement file is available. This option was available in build 26, but I removed it in build 27, because I'm now setting it automatically.

Is there a step by step guide to set and starting using this feature of madvr?
Not at this point. This is a developer thread, for improving the algorithm. It's still a work-in-progress. If you're a user, just wanting to use the new algo, then please just wait for the next official madVR build, which shouldn't be too far away at this point. Or alternatively, if you dare, you can read the whole of this thread (or the last 50 pages or so) to catch up on what we were doing here in the past couple of weeks/months.

Quick tests with the flicker risk value:

The Matrix Reloaded: low APL-4 changes & high flicker risk -> OK
Mother: high APL-4 changes & very low flicker risk -> OK
Predator: very low APL-4 changes & very low flicker risk -> OK, but the flicker risk is not reliable here (it is just high for the first luminance increase)
Harry Potter 4: high APL-4 changes & low flicker risk -> OK
BvS: medium APL-4 changes & very low flicker risk -> OK
Jurassic World: Fallen Kingdom: very low APL-4 changes & high flicker risk -> OK

The APL-4 changes value is already doing everything right.

@madshi Did you find a scene where the flicker risk value might be useful?

Logically, it should be a scene where the APL-4 changes are high and the flicker risk is high too.
I don't really have a great scene at hand right now where APL-4 completely fails and the flicker risk value succeeds. However, let's have a look at what these two values actually measure, and what our actual goal is:

Goal: If the video gets brighter in the middle of a scene, we want to adjust the tone mapping curve as quickly as possible, so we don't blow out any highlight detail. However, we don't want the tone mapping curve adjustments to be visible by themselves. So we need a reliable indicator that tells us how quickly we can adjust brightness without producing any visible flickering, brightness jumps or pumping effects.

APL-4: This indicator compares the APL (it's not really APL but something similar) of the current frame to the frame 4 frames ago. If the difference between the two frames is high, APL-4 will be high. The reason why this indicator works is that we're most likely to notice brightness adjustment artifacts in very calm scenes, where not much else is happening. So visible brightness adjustments in such a calm scene would stick out like a sore thumb. In heavy action scenes, there's so much going on that we're distracted by that and probably won't notice brightness adjustments as much (or at all). However, there are 2 serious problems with APL-4:

1) Imagine a scene where the top half of the video is a bright sky (e.g. 300nits), and the bottom half is some middle brightness scenery (e.g. 70nits). Now imagine a car very quickly driving through the foreground in the bottom half of the screen. Because the car is in the foreground, it's pretty big in the frame, so APL-4 will show pretty large changes due to that. In some frames, the sun will produce specular highlights on the car, which will produce peak luminance values that are significantly brighter than the sky (e.g. 1000nits). In this situation, APL-4 will report high values, which will cause us to feel safe about adjusting the tone mapping curve very quickly. However, the top half of the screen (the sky) is totally static. What will happen is that as the tone mapping curve adjusts quickly up because of the 1000nits car reflections, the sky will show a sudden brightness jump. It will suddenly be rendered noticeably darker than before. This is an artifact that APL-4 cannot properly predict, so it will happen and we can't prevent it, using APL-4.

2) In your tests APL-1 didn't work well, but APL-4 did. Let's look at the "Mother" scene to understand why: The whole scene is very dark. Then, as the lamp gets turned on, the lamp starts glowing faintly, but visibly in the first frame. Then it gets brighter in the next frame, and still brighter in the frame after that. So it quickly and smoothly ramps up to its max brightness. APL-1 will not show very large values here because the ramp up is smooth, and APL-1 always compares direct neighbor frames. APL-4 will show a much stronger change because APL-4 looks 4 frames back. So the first 3 frames of the lamp being turned on are compared to a still competely dark frame, which is why APL-4 will ramp up to a much higher value than APL-1. *However*, there's a noticeable delay in APL-4 until it reaches the values we need for a quick brightness adjustment! See here:

Mother:
last dark frame: peak 6 nits, APL-4 0.15%
lamp on frame 1: peak 726 nits, APL-4 0.59%
lamp on frame 2: peak 885 nits, APL-4 3.09%
lamp on frame 3: peak 861 nits, APL-4 9.37%
lamp on frame 4: peak 893 nits, APL-4 15.35%
lamp on frame 5: peak 947 nits, APL-4 18.46%
lamp on frame 6: peak 921 nits, APL-4 17.82%
lamp on frame 7: peak 934 nits, APL-4 12.38%
lamp on frame 8: peak 938 nits, APL-4 7.45%
lamp on frame 9: peak 945 nits, APL-4 3.80%

Harry potter:
last dark frame: peak 173 nits, APL-4 0.00%
fight frame 1: peak 225 nits, APL-4 0.00%
fight frame 2: peak 266 nits, APL-4 1.59%
fight frame 3: peak 422 nits, APL-4 4.33%
fight frame 4: peak 767 nits, APL-4 9.33%
fight frame 5: peak 787 nits, APL-4 14.28%
fight frame 6: peak 893 nits, APL-4 15.11%
fight frame 7: peak 1468 nits, APL-4 19.99%
fight frame 8: peak 1703 nits, APL-4 24.01%
fight frame 9: peak 1703 nits, APL-4 30.04%

What you can see here is that APL-4 takes time to ramp up. E.g. in the Mother scene, although peak luminance jumps from 6 nits up all the way to 726 nits, APL-4 just goes up from 0.15% to 0.59%. Based on these numbers, madVR would consider it dangerous to adjust brightness quickly, so it would only very slowly adjust the tone mapping curve. Then the next frame goes from 726 nits to 885 nits, but *still* APL-4 reports a relatively modest 3.09%. So madVR would *still* not adjust quickly at all. Do you see how APL-4 has a noticeable delay, which is the opposite of what we need? APL-4 seems to have a delay of about 3-4 frames to give us the "correct" value which allows us to switch into fast brightness reaction times. But a reaction time of 0.1s is only 2.4 frames! So when APL-4 finally gives us proper values, already more than 0.1s has passed during which we didn't adjust brightness quickly at all!

flicker risk: This indicator tells us which percentage of the pixels would visibly change their brightness if we adjust the tone mapping curve. If the percentage number is low, we can probably adjust tone mapping curves quickly because it will only change a few pixels on screen (in a visible way), so no artifacts are to be expected. But if a large percentage of the pixels on screen would change their brightness, there's a high risk changing the tone mapping curve strongly would produce visible artifacts. As such, I believe this should be a pretty good indicator of how quickly we can change the tone mapping curve without getting artifacts. Plus, there's no delay.

You're right to notice that in some situations (e.g. Predator) the flicker risk suddenly goes down. The reason for that is very simple: When the tone mapping target nits is getting higher and higher, a larger percentage of pixels will fall below the tone mapping curve's "soft knee". Which means the higher the tone mapping target nits is, the less pixels will be affected by modifying the tone mapping curve. So actually the flicker risk indicator is correct in saying that suddenly there's no risk, anymore. Because once we have e.g. all pixels in the sky below the tone mapping "soft knee", we can increase the tone mapping target even more without modifying the sky pixels, anymore. So no brightness artifacts would be visible.

As it's currently designed, the "flicker risk" mainly checks if adjusting the tone mapping target *up*wards is problematic or not. It doesn't really check if adjusting it downwards is problematic, as well. But that's not a big problem because the "live algo" has a very slow darkness adjustments speed, anyway.

So to sum this up shortly: APL-4 guesses whether possible brightness adjustment artifacts might not be noticed because there's so much action on the screen. APL-4 might often be correct, but there's no guarantee, and it has a delay. Also, APL-4 doesn't know if brightness adjustment artifacts would occur in the first place. It just predicts if we would notice them, if they did occur. In contrast to that the "flicker risk" indicator tries to calculate if changing the tone mapping curve would produce visible brightness adjustment artifacts. Which is much nearer to what we *really* want to know, isn't it? So because of that I think "flicker risk" should be the more reliable indicator.

Thoughts?
 

·
Registered
Joined
·
1,386 Posts
Thoughts?
A brightness reaction time based on the flicker risk value seems to be the the same as based on the APL-4 one, but without any delay.

The only "problem" I see if when the luminance goes down very fast, but this is already taken in charge by the very slow darkness adjustments speed.

So let's try it for real :cool:
 

·
Registered
Joined
·
8,229 Posts
Skyscraper is with a measurement file and the timestamp on it is from 3:37 to 3:45 right at the beginning.
Ok, thanks!

Can anybody confirm issues with this scene? Maybe someone can cut this into a nice little sample?

A brightness reaction time based on the flicker risk value seems to be the the same as based on the APL-4 one, but without any delay.

The only "problem" I see if when the luminance goes down very fast, but this is already taken in charge by the very slow darkness adjustments speed.

So let's try it for real :cool:
Great! :) Any suggestions on which brightness reaction time we should use for which "flicker risk" values?
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter · #3,940 · (Edited)
I'm not a fan of the idea of clipping, to be honest. If we could reliably detect that there are some overbright pixels we could safely discard without a humanly visible loss in image quality, then I'd be all for that, but I don't think we can.


Alright. I've modified the algo slightly, and I've increased the minimum speed from 3% to 7%, based on votes by various users. That brings this scene back roughly to where it was before.


Allow me to stress that we've already gone from 99.9% to 99.99% which is a 10x weaker clipping than you originally suggested! And that just by testing one scene I suggested. Now imagine the camera man in the "Mother" scene would have decided to step back a few more steps. The lamp would have been even smaller. In that case even 0.01% might have been to high. We might have needed 0.001% to get near perfect results.

The problem is that the histogram doesn't really tell us if clipping those ~ 0.01% pixels will be harmful to the quality impression of a human being or not. If those 0.01% pixels are the complete center of attention (as in the "Mother" scene) it's probably extremely important to not clip them. But if those 0.01% pixels are somewhat scattered over various image sections (e.g. helmet and arm in the Xmen scene), not being the complete center of attention, then clipping them might be somewhat more acceptable. But it's not really possible for madVR to judge which parts of an image a human being is most likely to put his attention on.

So my opinion right now is that any amount of clipping could potentially harm image quality. We simply cannot safely specify any amount that would be safe. Amount X might be safe in one scene but not in another. FYI, the measurement algorithm already includes some mild "clipping" of stray overbright pixels. Well, it's not really clipping, but due to the way I'm doing the measurements, the measured peak is already lower in many situations than a 100% accurate measurement would be. I don't really feel safe clipping even more now.
Well. Let me stress out again that you are currently (sometimes) sacrificing dynamic to show ALL the pixels in a very compressed manner.

For me, picture dynamic is equally important. Clipping a few pixels vs dynamic is a compromise which should not be disregarded.

And personally, I am not shocked by the look of the clipped lamp at 200nits at all (especially if you have nothing to compare too).

If this is the price to get a lot more dynamic, it would be acceptable for me.

Probably not for you. But please don't say you are doing no harm by choosing to compress much more the movie than we could.

Compression is also harming the movie and the hdr dynamic intent.

The smaller the % clipping, the less harm it can do.
0.1% was an agressive first proposal.

As always in this thread, we then evaluate what should be the best target (s) and end up with different level based on viewer priority.

I showed you that with an even smaller number like 0.02%, you could still retain the mother lamp details and still gain some dynamic in other scene like the one if xmen

If the lamp would be smaller even, fully clipping it would be even less an issue. The smaller the element, the less important and the less obvious the clipping. It's the compromise to get more dynamic everywhere else in the movie.

Not accounting that clipping itself can also provides more dynamic.

All is compromise and user taste.
There is not one answer there. ;)

I believe it should be the user choice to accept a little clipping or no clipping at all.

But I understand your arguments. And I am not saying clipping should be a default activated option in madvr. Nor am I saying that 0.1% would be the best amount. 0.02% would probably be a lot safer while still providing benefits here and there.

In the end, it's the same discussion for the scene algorithm. Do we want to have a perfect algo never clipping or pumping at the cost of some global picture dynamic, or can we live with some very rare cases of pumping or clipping with the "live algo" with the advantage of a maximum picture dynamic.

All is a compromise that different people will rate differently.

:)
 
3921 - 3940 of 12911 Posts
Top