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 28th July 2015, 12:33   #2761  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 753
I think I see what you mean, but those aren't really the kind of gradients that need debanding. The most obvious bands occur when the total difference is 1 over a distance of 10 or more pixels, which would make the average difference less than 0.1.

Besides in the example you gave, 10 pixels spanning a total of 13 values, there might be a difference greater than 1 between several (at least 3) of those pixels but the difference between their rounded values and their actual value is at most 1 (or 0.5 if they were always rounded to the nearest value). True you can allow a debanding filter to change the value of a pixel by more than 1, but in my opinion that means you've started to remove noise and not just banding.

FWIW the current versions of my debanding script use statistical properties to try to distinguish between rounding errors and detail, which essentially make it impossible to simply allow it to remove slightly more 'noise'. This is a limitation that is caused by designing an algorithm specifically to remove rounding errors. If you used a general denoiser at a very low strength you should be able to simply dial up the strength to remove more noise, but those algorithm have the disadvantage that they're not as good at distinguishing between rounding errors and detail, so you might need to remove more detail in order to remove all banding.

What I'm trying to say is that both type of algorithms have their uses, but they do different things. Trying to use a debander to remove noise or a denoiser to remove banding might work but the result will be far from perfect.
Shiandow is offline   Reply With Quote
Old 28th July 2015, 13:10   #2762  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
I'd be very grateful for a denoise-checkbox in your algorithm though.
aufkrawall is offline   Reply With Quote
Old 28th July 2015, 13:36   #2763  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Ok, D3D9 and 11 look identical now (I also tested render scripts).

MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.

MPDN:


madVR:


EVR CP of MPC HC (ignore chroma scaling and just look at the wall behind the stairs):


Royal question: Who is right? madVR is known to be suitable for exact calibration. However, this doesn't have to be a guarantee.
What's the experts' opinion?

Edit: There is also a huge difference with the brown-orange carpet.
EVR-sync looks very close to madVR:

Last edited by aufkrawall; 28th July 2015 at 13:53.
aufkrawall is offline   Reply With Quote
Old 28th July 2015, 14:14   #2764  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,679
Quote:
Originally Posted by aufkrawall View Post
MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.
There are pixel details in the MPDN image that are simply not there with madVR, that makes me think the resizer (bicubic?) being used for madVR is slightly less sharp. Fairly small differences though at the end of the day.

A few edges and areas there with reasonable differences which would be still hard to notice, but there's generally a 1/1/1 or 2/2/2 difference which wouldn't be noticeable.
I do favor the MPDN image here up close simply because of the pixel detail. Would it make a shred of difference while watching video, nope. Would be interesting to see a slightly sharper madVR upscaler for comparison.

Last edited by ryrynz; 28th July 2015 at 14:19.
ryrynz is offline   Reply With Quote
Old 28th July 2015, 14:26   #2765  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.
As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?
Zachs is offline   Reply With Quote
Old 28th July 2015, 14:27   #2766  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,679
What was the deal with the d3d11 color difference (re latest update)?
ryrynz is offline   Reply With Quote
Old 28th July 2015, 14:35   #2767  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
It was actually just a tiny pixel shift in dx10/11 mode. Not something you can see with your naked eyes.
Zachs is offline   Reply With Quote
Old 28th July 2015, 14:51   #2768  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,290
Quote:
Originally Posted by Zachs View Post
On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.
As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?
no it doesn't. a normal calibration is done using the CMS from a TV and it has to work with every renderer/source.

3d is an exception most people on earth don't care about 3D anyway.
huhn is offline   Reply With Quote
Old 28th July 2015, 15:27   #2769  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Shiandow View Post
True you can allow a debanding filter to change the value of a pixel by more than 1, but in my opinion that means you've started to remove noise and not just banding.

FWIW the current versions of my debanding script use statistical properties to try to distinguish between rounding errors and detail, which essentially make it impossible to simply allow it to remove slightly more 'noise'. This is a limitation that is caused by designing an algorithm specifically to remove rounding errors. If you used a general denoiser at a very low strength you should be able to simply dial up the strength to remove more noise, but those algorithm have the disadvantage that they're not as good at distinguishing between rounding errors and detail, so you might need to remove more detail in order to remove all banding.

What I'm trying to say is that both type of algorithms have their uses, but they do different things. Trying to use a debander to remove noise or a denoiser to remove banding might work but the result will be far from perfect.
I think we're almost in philisophical land now. Your definition of banding and debanding seems to be slightly different to mine. Yours seems to be "banding = max 1 integer steps caused by rounding". Mine is more like "visible step lines in gradients that are not supposed to be there". Consequently, your ideal debanding algorithm would never remove more than rounding errors, while mine might, if the source seems to need it. I don't think madVR's debanding filter can be labeled "denoise", in any case. It's overall design is very much targetted at making gradients smoother and nothing else, which is unlike what any "noise reducer" would do. Also I would classify "noise" to be somewhat randomly distributed dots. Which is very different to banding.

Quote:
Originally Posted by aufkrawall View Post
MPDN still looks different to madVR with colors. MPDN is a bit closer to EVR CP of MPC HC, but they are different though.

Royal question: Who is right? madVR is known to be suitable for exact calibration. However, this doesn't have to be a guarantee.
What's the experts' opinion?
Might be as easy as a case of different matrix/primaries guesses. Which matrix and primaries have MPDN, EVR and madVR been using in your screenshots?

Quote:
Originally Posted by Zachs View Post
As I understand it (correct me if I'm wrong), calibration needs to be done for a specific renderer, doesn't it?
Ideally, every render would produce exactly the same (= correct) colors. If that were true, one calibration should suffice for all renderers. In real life things are not always as perfect. There are even standalone Blu-Ray players which produce slightly different colors. So sometimes in real life a calibration needs to be done per source device (or renderer). But of course that's not how it should be, in an ideal world.
madshi is offline   Reply With Quote
Old 28th July 2015, 16:57   #2770  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by ryrynz View Post
There are pixel details in the MPDN image that are simply not there with madVR, that makes me think the resizer (bicubic?) being used for madVR is slightly less sharp. Fairly small differences though at the end of the day.
It's both bilinear scaling via TMUs for comparison's sake.
What I notice, apart from that slight color difference, is that below the headband of the girl, there's a green square with madVR which isn't there with MPDN.
Most interesting is that it's always there with madVR and never with MPDN, no matter which scaling algorithm is used.

Quote:
Originally Posted by ryrynz View Post
A few edges and areas there with reasonable differences which would be still hard to notice, but there's generally a 1/1/1 or 2/2/2 difference which wouldn't be noticeable.
I do favor the MPDN image here up close simply because of the pixel detail. Would it make a shred of difference while watching video, nope. Would be interesting to see a slightly sharper madVR upscaler for comparison.
We shouldn't compare image quality by single pixels with the pictures above since it's just bilinear TMU.
With NNEDI3 quadrupling via OpenCL there's not a real difference either, apart from colors.

Quote:
Originally Posted by Zachs View Post
On my monitor, I really can't see any difference between EVR and MPDN. To rule out any rounding differences, try enabling dithering and see if you find the difference smaller.
The difference is still there with dithering (both random).
The difference between EVR CP and MPDN is veery small, but it's there. I just checked in a dimmed room. However, since it's so small, it could be related to chroma upscaling.
This could also apply to madVR and EVR-sync. We could say we have to groups here: EVR-CP and MPDN on the one side and madVR and EVR-sync on the other one.

Quote:
Originally Posted by madshi View Post
Might be as easy as a case of different matrix/primaries guesses. Which matrix and primaries have MPDN, EVR and madVR been using in your screenshots?
Both MPDN and madVR report BT.709, but madVR detects TV levels as input (information by upstream) while MPDN reports full range (not clear if it's meant for input or output).
Edit: Ok, I think it's surely meant for output.

Here's the sample again:
http://www20.zippyshare.com/v/0K5ArS12/file.html


Btw: MPDN doesn't accept PNGs with 8BPP whie it has no problems with 24BPP.
8BPP: http://www20.zippyshare.com/v/niiU7x21/file.html
24BPP: http://www20.zippyshare.com/v/USMxFxEL/file.html

Last edited by aufkrawall; 28th July 2015 at 17:00.
aufkrawall is offline   Reply With Quote
Old 28th July 2015, 17:09   #2771  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by aufkrawall View Post
What I notice, apart from that slight color difference, is that below the headband of the girl, there's a green square with madVR which isn't there with MPDN.
Most interesting is that it's always there with madVR and never with MPDN, no matter which scaling algorithm is used.
It seems there are actually 2 frames in that file. madVR shows the first, MPDN the 2nd. You can see that madVR has a decoder queue of 2/2.
madshi is offline   Reply With Quote
Old 28th July 2015, 17:25   #2772  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
oh my, you nailed it..
Thank you, madshi!

I need to take a look again at Handbrake's kind of frame counting. It may work a bit (or a frame?) different than avs trim...
aufkrawall is offline   Reply With Quote
Old 28th July 2015, 19:39   #2773  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,290
MPDN nnedi3 openCL doesn't work as madVr openCL nnedi 3 doesn't work.

Zachs does your openCL nnedi3 version use cl_nv_d3d9_sharing?

because it looks like this isn't part of newer drivers anymore.
huhn is offline   Reply With Quote
Old 29th July 2015, 00:11   #2774  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
They better bring it back. I don't see a reason why they need to remove it especially when all their earlier Win10 drivers have it. Maybe they feel they have such a lead in the market place they're giving AMD a chance to catch up?

EDIT: All jokes aside, unless they've implemented the KHR methods, they've just shot themselves in the foot by crippling their own products. Can you check if the corresponding KHR extensions are now part of their new drivers? You can dump all the OpenCL extensions with GPU Caps Viewer.

Last edited by Zachs; 29th July 2015 at 00:17.
Zachs is offline   Reply With Quote
Old 29th July 2015, 00:13   #2775  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
Quote:
Originally Posted by aufkrawall View Post
Btw: MPDN doesn't accept PNGs with 8BPP whie it has no problems with 24BPP.
8BPP: http://www20.zippyshare.com/v/niiU7x21/file.html
24BPP: http://www20.zippyshare.com/v/USMxFxEL/file.html
LAV is responsible for "not accepting" it. MPDN doesn't decode media files.
Zachs is offline   Reply With Quote
Old 29th July 2015, 00:20   #2776  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,290
Quote:
Originally Posted by Zachs View Post
They better bring it back. I don't see a reason why they need to remove it especially when all their earlier Win10 drivers have it. Maybe they feel they have such a lead in the market place they're giving AMD a chance to catch up?
i hope they just removed it by accident. and yes it is very sad that AMD doesn't deliver at the moment...
huhn is offline   Reply With Quote
Old 29th July 2015, 00:25   #2777  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
It could very well be that they have finally implemented the Khronos ones so they removed their equivalent NV extensions. Could you quickly dump the OpenCL extensions of their new drivers please?
Zachs is offline   Reply With Quote
Old 29th July 2015, 00:25   #2778  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,290
Quote:
Originally Posted by Zachs View Post
LAV is responsible for "not accepting" it. MPDN doesn't decode media files.
and why does the lavfilter in MPC-HC handle this 8 bit png?
huhn is offline   Reply With Quote
Old 29th July 2015, 00:34   #2779  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,290
Quote:
Originally Posted by Zachs View Post
It could very well be that they have finally implemented the Khronos ones so they removed their equivalent NV extensions. Could you quickly dump the OpenCL extensions of their new drivers please?
i did this already with gpu cap and no they didn't.

couldn't the Khronos api version the reason for the copyback issue with AMD? so not sure if this is a good idea...

thsi whole topic is a mystery for me any way. according to this source: https://anteru.net/2012/10/30/1998/

cl_khr_d3d10_sharing is a 1:1 copy from cl_nv_d3d10_sharing. nvidia has both version with should be 100 % the same and doesn't make any sense to me but what ever.
huhn is offline   Reply With Quote
Old 29th July 2015, 08:16   #2780  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
The Khronos API version is *not* responsible for the copyback issue. Intel GPUs use the Khronos API and don't have any copyback issues. The D3D9 version of Khronos differs quite noticeably from the NV version.
madshi is offline   Reply With Quote
Reply

Tags
direct3d, mpdn, nnedi3, opencl, reclock

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 15:18.


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