Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
11th July 2016, 07:52 | #38622 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
You guys know the drill: Please provide me with samples + screenshots which show that SuperRes Anti-Bloating helps in some situations, and I will reconsider. I've removed it because I couldn't really see any benefit in my own tests, and the feedback from the majority of users seemed to confirm that.
Anti-ringing for sharpening and SuperRes is not finished yet, it will be improved in a future version. My SuperRes shader has had some fast and effective anti-ringing code built into it for a long time, which is really useful and will definitely stay. However, the extra SuperRes anti-ringing option adds another anti-ringing shader pass on top of that. In most cases this extra option does nothing, so maybe I'll remove it, but I wanted to wait until I've implemented the "final" version and then do some tests with real world images and test patterns to see if it might not sometimes have a positive effect on SuperRes. I do think it might, because the built in anti-ringing has some limitations and isn't always perfect. |
11th July 2016, 08:54 | #38623 | Link |
Is this for real?
Join Date: Mar 2016
Location: Norway
Posts: 168
|
@madshi
When your changelog states that you have improved performance with some of your algos, is it posible to say by how much? Like 10ms lower rendering time or something like that.
__________________
My HTPC : i9 10900K | nVidia RTX 4070 Super | TV : Samsung 75Q9FN QLED |
11th July 2016, 09:34 | #38624 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Usually I can't say in ms because it depends on the GPU. Could maybe say in percent, but even that might be GPU dependent. The only performance improvement in 0.90.22 is black bar detection, which in this rare case is actually CPU dependent. Black bar detection CPU cost should be about 3x lower now than it was before.
|
11th July 2016, 09:40 | #38625 | Link | |
Is this for real?
Join Date: Mar 2016
Location: Norway
Posts: 168
|
Quote:
__________________
My HTPC : i9 10900K | nVidia RTX 4070 Super | TV : Samsung 75Q9FN QLED |
|
11th July 2016, 12:56 | #38627 | Link |
Is this for real?
Join Date: Mar 2016
Location: Norway
Posts: 168
|
Well the deringing feature is one that I need, so I will upgrade some day. Thank you for your work and support madshi
__________________
My HTPC : i9 10900K | nVidia RTX 4070 Super | TV : Samsung 75Q9FN QLED |
11th July 2016, 13:00 | #38628 | Link |
Registered User
Join Date: Feb 2012
Posts: 116
|
Could you re-add the one-pass adaptive sharpen?
A guy (igv) ported and improved this shader for the mpv hook system: https://gist.github.com/igv/8a77e4eb...bb94c1c50c317e I don't really know what he improved but it looks amazingly on my sister's laptop with a weak intel hd3000 iGPU. The two-passes version is too intensive! I prefer adaptive-sharpen than crispen-edge/finesharp. Thanks again for this build! |
11th July 2016, 13:05 | #38629 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
|
|
11th July 2016, 13:23 | #38630 | Link | |
Registered User
Join Date: Mar 2002
Posts: 2,323
|
Quote:
2. All the HDR related bugs are fixed (that I know of) that were present in 0.9.21. Thanks! Go ahead to 0.9.22, it seems to work fine.
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED77G2(2160p@23/24/25/29/30/50/59/60Hz) | madvr config |
|
11th July 2016, 13:30 | #38631 | Link | |
Lost In The Web
Join Date: Apr 2010
Posts: 35
|
Quote:
Oh well, was going to change it next month, seem I need to advance the schedule
__________________
Windows 11 11th Gen Intel(R) Core(TM) i5-11400F Nvidia Geoforce RTX 3050 MPCHC - madVR - Lav Filters - XySubFilter |
|
11th July 2016, 15:07 | #38632 | Link |
Registered User
Join Date: Sep 2013
Posts: 919
|
I have noticed that the HDR algorithm clips the highlights even when compress highlights is selected.
Is it how it should be? I thought compress = NOT Clip.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410. |
11th July 2016, 15:40 | #38634 | Link |
Registered User
Join Date: Sep 2013
Posts: 919
|
Ah, okay.
I also noticed that "preserve Hue" will clip the colors if the color is too saturated. Isn't the point of "measure peak luminance" is to prevent clipping, or it works only when the measured luminance is lower than the metadata peak? This does not take into account that the mastering monitor may have ABL and the peak luminance actually below the metadata value. I think the image quality would benifit from measuring the peak luminance even if it slightly higher that the metadata value to prevent clipping.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410. Last edited by James Freeman; 11th July 2016 at 15:47. |
11th July 2016, 15:43 | #38635 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
"Preserve hue" does not clip, it desaturates in a hue linear color space. Please re-read the tone mapping discussions on the previous 5 pages or so of this thread. This topic has been discussed extensively there.
|
11th July 2016, 16:00 | #38636 | Link |
Registered User
Join Date: Sep 2013
Posts: 919
|
Perhaps it would be better if I post images of what I see and then ask questions.
Compress only: Compress and Hue (HQ): At 400nit. It looks like the brightest areas of the headlights and tent are clipped when I enable Hue correction. Or maybe they are so desaturated that the gradations are completely lost? Did you consider my previous post that ABL might effect the true peak luminance and in reality it may be lower than the metadata value but higher in code value? I heard that at least few movies were mastered on the Samsung HDR TV that has obvious ABL behavior with anything above 2% window. I believe many (if not all) of the professional studio HDR monitors also have ABL to some extent, so it will not be wise to clip AT the metadata value.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410. Last edited by James Freeman; 11th July 2016 at 16:10. |
11th July 2016, 16:16 | #38637 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
As I've explained a couple of pages ago, after tone mapping (compression) there may be colored pixels (e.g. red/orage in this case) which have a luminance value assigned to it which is near to the peak luminance of the video. E.g. I suspect those pixels which are red/orage without hue correction, are near to the peak luminance of the video. The problem with that is that your display reaches its peak luminance with *white* pixels, not with red pixels. So if your display can only do 400 nits, and the video asks for a 400 nits red pixel, what can madVR do? Without hue correction, I simply do nothing. Which means the RGB pixel will go out of bounds (outside of 0-255 for PC levels), which without hue correction will then simply be clipped to the legal RGB range. This will modify hue, but it might preserve some color differences. If you enable hue correction, madVR detects this situation and it will then desaturate such 400 nits red pixels just as much as necessary to make them fit into the legal RGB range. In this case they get almost or even completely desaturated/white. Yellow is less effected because it has more green in it than red, and green produces much more luminance than red. So in this situation hue correction may lower perceived detail because the difference between white and bright yellow is much smaller than the difference between red and bright yellow. However, without hue correction, the exact hue isn't reproduced correctly, and the luminance is WAY too dark.
I don't think this is a case of incorrect metadata or ABL related problems. P.S: You can see the same effect in the spheric tent in the background. Without hue correction it's WAY too dark, but is nicely red. This is likely again an area which is near to the video's peak luminance, but with a highly saturated red color. Turning hue correction on will detect this and desaturate the pixel accordingly. So the pixel goes towards white, which is not nice, but which helps reproducing the correct luminance. Last edited by madshi; 11th July 2016 at 16:19. |
11th July 2016, 16:22 | #38638 | Link |
Registered User
Join Date: Sep 2013
Posts: 919
|
Now I understand , thanks.
The ABL is a different issue, I just posted it in the same go; I see clipped highlights where they should not be, the reason I assume is ABL when mastering. Not to be repetitive but: true peak luminance in reality may be lower than the metadata value but higher in code value. Therefor it is not wise to clip at the metadata value in software. Leave some "headroom" to compensate for the ABL behavior of the mastering monitor. Or even better, measure the peak white code value even if it's above the metadata peak value. I hope this makes sense.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410. Last edited by James Freeman; 11th July 2016 at 16:30. |
11th July 2016, 16:31 | #38640 | Link |
Registered User
Join Date: Sep 2013
Posts: 919
|
That's where your "measure peak white" comes in, but it should do its job with code values above metadata values also, not only below like it does now (I assume).
The colorist is not limited to the code values of the peak luminance of his monitor, he might use higher code values while pushing the ABL of his monitor. We must remember that the code values control the LED backlight, and they do NOT actually clip the code values if the the backlight can't go brighter.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410. Last edited by James Freeman; 11th July 2016 at 16:40. |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|