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.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 11th July 2016, 05:19   #38621  |  Link
AngelGraves13
Registered User
 
Join Date: Dec 2010
Posts: 255
SR AB was nice especially for upscaled MPEG-2 DVDs. It really smoothed out the rough edges in the transfers and made SR look smoother.

SR AR on the other hand does practically nothing and should be removed.
AngelGraves13 is offline   Reply With Quote
Old 11th July 2016, 07:52   #38622  |  Link
madshi
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.
madshi is offline   Reply With Quote
Old 11th July 2016, 08:54   #38623  |  Link
Betroz
Is this for real?
 
Betroz's Avatar
 
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
Betroz is offline   Reply With Quote
Old 11th July 2016, 09:34   #38624  |  Link
madshi
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.
madshi is offline   Reply With Quote
Old 11th July 2016, 09:40   #38625  |  Link
Betroz
Is this for real?
 
Betroz's Avatar
 
Join Date: Mar 2016
Location: Norway
Posts: 168
Quote:
Originally Posted by madshi View Post
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.
Yes people have different hardware in their systems, so that makes sense of course. It's just that madvr 0.90.17 workes well on my HTPC now, so I'm wondering if upgrading is worth it for me, and hense the performance question. Thanks anyway
__________________
My HTPC : i9 10900K | nVidia RTX 4070 Super | TV : Samsung 75Q9FN QLED
Betroz is offline   Reply With Quote
Old 11th July 2016, 09:42   #38626  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Well, if you don't need deringing, the new HDR algos, or the new Bilateral algos, and if you haven't run into any of the 0.90.17 bugs then there's no problem staying with 0.90.17.
madshi is offline   Reply With Quote
Old 11th July 2016, 12:56   #38627  |  Link
Betroz
Is this for real?
 
Betroz's Avatar
 
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
Betroz is offline   Reply With Quote
Old 11th July 2016, 13:00   #38628  |  Link
foozoor
Registered User
 
foozoor's Avatar
 
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!
foozoor is offline   Reply With Quote
Old 11th July 2016, 13:05   #38629  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by foozoor View Post
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!
He modified the 2-pass version into 1-pass, by removing some features. So speed is better, but quality is slightly lower. I'm not sure if that is what many users want?
madshi is offline   Reply With Quote
Old 11th July 2016, 13:23   #38630  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,323
Quote:
Originally Posted by madshi View Post
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.
1. Thank You so much for making this multithreading! I CAN use this now on my old rig, and it can do wonders with 4K content! (Now I can remove my processing profiles, that were created for only this reason.)
2. All the HDR related bugs are fixed (that I know of) that were present in 0.9.21. Thanks!
Quote:
Originally Posted by Betroz View Post
Yes people have different hardware in their systems, so that makes sense of course. It's just that madvr 0.90.17 workes well on my HTPC now, so I'm wondering if upgrading is worth it for me, and hense the performance question. Thanks anyway
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
chros is offline   Reply With Quote
Old 11th July 2016, 13:30   #38631  |  Link
Sarasa
Lost In The Web
 
Sarasa's Avatar
 
Join Date: Apr 2010
Posts: 35
Quote:
Originally Posted by madshi View Post
...
Try reinstalling your GPU drivers, or try a different GPU driver version.
...
After some more test I found my problem, it's not a driver one, it's my alim that starting to show sign of "to old" (7 Years), when the GPU kick to high gear it ask more that the alim can still give and bang
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
Sarasa is offline   Reply With Quote
Old 11th July 2016, 15:07   #38632  |  Link
James Freeman
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.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 15:24   #38633  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
It should not clip, unless the frame peak luminance is higher than the metadata claims.
madshi is offline   Reply With Quote
Old 11th July 2016, 15:40   #38634  |  Link
James Freeman
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.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 15:43   #38635  |  Link
madshi
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.
madshi is offline   Reply With Quote
Old 11th July 2016, 16:00   #38636  |  Link
James Freeman
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.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 16:16   #38637  |  Link
madshi
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.
madshi is offline   Reply With Quote
Old 11th July 2016, 16:22   #38638  |  Link
James Freeman
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.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 16:27   #38639  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Leaving headroom also means highlights getting duller. There's no free lunch here.
madshi is offline   Reply With Quote
Old 11th July 2016, 16:31   #38640  |  Link
James Freeman
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.
James Freeman is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

Forum Jump


All times are GMT +1. The time now is 08:22.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.