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 May 2016, 19:11   #37901  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 445
Quote:
Originally Posted by fhoech View Post
Under Windows, there's SetDeviceGammaRamp for the desktop (which always takes a 3x256 entries table with 16-bit precision integers) and equivalent functionality for D3D fullscreen.
But I think what madshi was talking about was how to calculate the values. madVR uses 257 * x (with x from 0 to 255) to generate 16-bit values that go from 0 to 65535, whereas the program assumes that a linear ramp will use 256 * x (generating 16-bit values from 0 to 65280). Personally I think madVR's way makes more sense - it's correctly rounded, and the high bits are the same regardless.

Incidentally, I found it interesting that such a simple algorithm produces correct rounding: (x / 255.0) * 65535.0 reduces to 257.0 * x since 65535 / 255 = 257. I think it's easier to see why this must be true if you think of it as 256 * x + 1 * x, or 0x100 * x + 0x1 * x in hexadecimal. Since the maximum value of x is 0xff, the maximum value is 0x100 * 0xff + 0xff = 0xffff - there's no overlap between the two. The same goes for 8-bit to 24-bit: 0x10000 * x + 0x100 * x + 0x1 * x produces no overlap for values of x between 0 and 0xff, and the maximum value is 0xffffff - therefore 2^24 - 1 must be divisible by 2^8 - 1 - and indeed it is: 16777215 / 255 = 65793. That's probably not the most mathematically rigorous, but I found it enlightening. But I digress

Last edited by Ver Greeneyes; 11th May 2016 at 19:20.
Ver Greeneyes is offline   Reply With Quote
Old 11th May 2016, 19:35   #37902  |  Link
har3inger
Registered User
 
Join Date: Feb 2014
Posts: 139
Quote:
Originally Posted by XMonarchY View Post
Where's the option for the new Anti-Ringing algorithm? Is it better than the old one? I can't find it anywhere in the settings...
New setting works different from the upscale/downscale antiring filter.

Dering removes source ringing before any sizing is done. Antiring removes ringing that is introduced by most scaling algorithms but shouldn't affect source ringing at all.
har3inger is offline   Reply With Quote
Old 11th May 2016, 19:54   #37903  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,120
Can I ask for further improvements in the 6:4 film mode used for p60 video? I don't know if you use it all that often which is why it's in the state it's in or if it's extremely hard to detect the pattern accurately, but it's not very polished from my use of it. It's probably the least polished feature I've found in madVR, by far. It sometimes takes several seconds to detect a pattern change resulting in the slow-mo playback look, it sometimes seems to displays frames out of order, or it flashes a random frame it shouldn't after a pattern change. It feels like an experimental / alpha feature. The 3:2 mode for i60 content works much, much, much, much better.
Stereodude is offline   Reply With Quote
Old 11th May 2016, 21:37   #37904  |  Link
Uoppi
Registered User
 
Join Date: Oct 2015
Posts: 99
Quote:
Originally Posted by aufkrawall View Post
I don't think there is a difference in "quality". LL downscaling should maintain the original brightness of the unscaled image while gamma light is darker. So imho it makes sense to use LL when there is just downscaling happening (imho it doesn't even matter which downscaling algorithm is used, LL is always brighter and GL a bit less aliased).

However, SuperRes also makes the image even brighter (in GL more than in LL, that's a little confusing since it's the opposite way around compared to image scaling) and must be fed with image in GL when SuperRes itself also works in GL to avoid aliasing introduction (and fed with LL when it works in LL).
So, it should be best to define script profiles to achieve LL downscaling when there is no upscaling with SuperRes and to use GL downscaling when SuperRes in GL is used (it should be used in GL since probably most content is that way).
1. Does this also apply when using SuperRes only for chroma?

2. Just to make sure I understood right: when downscaling UHD -> 1080p (no SuperRes), it would be best to UNtick the linear light option?

3. And in even simpler terms: when no SuperRes = UNtick linear light, when SuperRes involved = tick linear light box?
Uoppi is offline   Reply With Quote
Old 11th May 2016, 22:23   #37905  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,105
Quote:
Originally Posted by huhn View Post
why don't you post an example?
I tried to quickly capture some images and could not find any good examples. I'll leave the AR filter on for a while to see if anything jumps out as offensive. It seemed to flatten the edges of objects but I can't see it in still frames.
Warner306 is offline   Reply With Quote
Old 11th May 2016, 22:32   #37906  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,708
Uoppi, you got it exactly the wrong way around.

Just image downscaling: downscale in LL to preserve original brightness (LL checkbox for downscaling ticked)
When there is downscaling because of image doubling and SuperRes is used: downscale in GL (LL checkbox for downscaling unticked) and use SuperRes in GL (LL checkbox for SuperRes unticked as well)

However, the effect for SuperRes of LL/GL used for image downscaling after image doubling probably is very small in most cases. It's much more important how the image of the video (untouched by madVR) has been downscaled before.
We can't say this for sure and can only assume that downscaling in GL by content creators/providers is most common. The results with SuperRes seem to confirm this assumption, but I don't think anyone tested lots of material with this.
aufkrawall is offline   Reply With Quote
Old 11th May 2016, 22:36   #37907  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,604
Quote:
Originally Posted by Uoppi View Post
1. Does this also apply when using SuperRes only for chroma?

2. Just to make sure I understood right: when downscaling UHD -> 1080p (no SuperRes), it would be best to UNtick the linear light option?

3. And in even simpler terms: when no SuperRes = UNtick linear light, when SuperRes involved = tick linear light box?
1. Ignore all gamma/linear talk for chroma, chroma does not have gamma and linear light, those are luma concepts.

2. It is the other way around, downscale in linear light if downscaling the source directly but downscale in gamma light when downscaling after image doubling.

3. Again, it is the other way around. no SuperRes = tick linear light, when SuperRes involved (ignoring chroma) = UNtick linear light box.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 11th May 2016, 23:08   #37908  |  Link
QBhd
QB the Slayer
 
QBhd's Avatar
 
Join Date: Feb 2011
Location: Toronto
Posts: 453
madshi,

It seems mixed upscaling (target 1024x768) is broken again... First pic is latest madVR (no settings changed), second pic is madVR v0.90.17





I really wanted to try the new De-Ringing...

QB
__________________
QBhd is offline   Reply With Quote
Old 11th May 2016, 23:18   #37909  |  Link
fhoech
Registered User
 
fhoech's Avatar
 
Join Date: Nov 2010
Location: Stuttgart, Germany
Posts: 17
Quote:
Originally Posted by Ver Greeneyes View Post
Personally I think madVR's way makes more sense
Not only that, it's the only correct way - a linear 16-bit ramp with the goal to not alter the input in any way has to start at 0 and end at 65535, not 65280, so the CalibrationTester is simply wrong :-)

Btw, I think of the math in a slightly different way: The increment step is 65535 / <number of entries per channel - 1>, i.e. 65535 / (256 - 1) or 65535 / 255.
Why subtract 1 from the number of entries per channel? Because the first entry is zero, and so we have (256 - 1) = 255 entries left to increment up to the maximum channel value of 65535. Sorry for the OT :-)
fhoech is offline   Reply With Quote
Old 11th May 2016, 23:24   #37910  |  Link
70MM
X Cinema Projectionist NZ
 
Join Date: Feb 2006
Location: Auckland NZ
Posts: 280
Quote:
Originally Posted by 70MM View Post
Guys Ive just checked with my installer and he says we are installing madvr correctly in conjunction with JRiver. He said the madVR install he did was using the Program Files/madVR folder, not the one in the user folder so he updated the folder under users and will see how it goes....

He made this video showing how the APPLY is greyed out. Can you check and see what we are doing wrong please?
https://www.youtube.com/watch?v=TGHo...ature=youtu.be
Any help on this please guys as I have my installer coming back today to try and get madvr installed correctly?
70MM is offline   Reply With Quote
Old 12th May 2016, 00:44   #37911  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
Quote:
Originally Posted by 70MM View Post
Any help on this please guys as I have my installer coming back today to try and get madvr installed correctly?
Do you have access to the machine to copy files? If so, then find the JRIver plugins/madvr folder as mentioned above and unzip/extract the madvr.zip into that folder. I'd clear it first and make sure MediaCenter is not running. Also, you might go ahead and get rid of any other installs of madVR for clarity.

Not much else to it, we've been doing it this way for years with madVR and MediaCenter, not sure what an "installer" is going to do any differently.

Why does the "installer" have access to the machine, but you apparently don't?
__________________
Win7Ult || RX560/4G || Ryzen 5
noee is offline   Reply With Quote
Old 12th May 2016, 00:48   #37912  |  Link
70MM
X Cinema Projectionist NZ
 
Join Date: Feb 2006
Location: Auckland NZ
Posts: 280
Quote:
Originally Posted by noee View Post
Do you have access to the machine to copy files? If so, then find the JRIver plugins/madvr folder as mentioned above and unzip/extract the madvr.zip into that folder. I'd clear it first and make sure MediaCenter is not running. Also, you might go ahead and get rid of any other installs of madVR for clarity.

Not much else to it, we've been doing it this way for years with madVR and MediaCenter, not sure what an "installer" is going to do any differently.

Why does the "installer" have access to the machine, but you apparently don't?
Ok we will check this today. I have my installer for the home cinema do all this stuff as he built the PC for me and is much more up with all the PC stuff than me. If I wanted complete control of it I would take it, but I don't know the install stuff.

I have learnt all the settings in madvr which he doesn't know as well as I, its just the install stuff/updates I need him for.
70MM is offline   Reply With Quote
Old 12th May 2016, 04:41   #37913  |  Link
70MM
X Cinema Projectionist NZ
 
Join Date: Feb 2006
Location: Auckland NZ
Posts: 280
Quote:
Originally Posted by noee View Post
Do you have access to the machine to copy files? If so, then find the JRIver plugins/madvr folder as mentioned above and unzip/extract the madvr.zip into that folder. I'd clear it first and make sure MediaCenter is not running. Also, you might go ahead and get rid of any other installs of madVR for clarity.

Not much else to it, we've been doing it this way for years with madVR and MediaCenter, not sure what an "installer" is going to do any differently.

Why does the "installer" have access to the machine, but you apparently don't?
Thanks for that, we completely cleared the directory where madVR was installed and started from scratch. So we had to reconfigure all the settings again. But now the new ringing setting under artefacts works correctly.

Thanks again for your help...
70MM is offline   Reply With Quote
Old 12th May 2016, 05:21   #37914  |  Link
mogli
Registered User
 
Join Date: May 2015
Posts: 71
Quote:
Originally Posted by Asmodian View Post
[...]
2. It is the other way around, downscale in linear light if downscaling the source directly but downscale in gamma light when downscaling after image doubling.
[...]
Why is that? Because image doubling is happening in gamma light, too?
mogli is offline   Reply With Quote
Old 12th May 2016, 06:07   #37915  |  Link
omarank
Registered User
 
Join Date: Nov 2011
Posts: 180
Quote:
Originally Posted by fhoech View Post
Under Windows, there's SetDeviceGammaRamp for the desktop (which always takes a 3x256 entries table with 16-bit precision integers) and equivalent functionality for D3D fullscreen.

Btw, don't use the prehistoric X-Rite (or rather LOGO/GretagMacbeth) Calibration Tester to test video card gamma ramp linearity - it doesn't work right and from what I know, never did (you can even see it in your screenshot, the end value for a linear ramp should be 65535, but LUT tester thinks it should be 65280, which probably means the developers made the mistake that they assumed each step above zero increases by 256 instead of the correct 257). There's other tools to check video card gamma ramp linearity (e.g. either Argyll's dispcal -V when used with a linear cal file which will show the discrepancy if any in percent, or DisplayCAL's curve viewer which will show "linear" in the status area if you hover the graph of a linear gamma ramp when "show calibration from video card" is checked).
Quote:
Originally Posted by fhoech View Post
Not only that, it's the only correct way - a linear 16-bit ramp with the goal to not alter the input in any way has to start at 0 and end at 65535, not 65280, so the CalibrationTester is simply wrong :-)

Btw, I think of the math in a slightly different way: The increment step is 65535 / <number of entries per channel - 1>, i.e. 65535 / (256 - 1) or 65535 / 255.
Why subtract 1 from the number of entries per channel? Because the first entry is zero, and so we have (256 - 1) = 255 entries left to increment up to the maximum channel value of 65535. Sorry for the OT :-)
Thanks for explaining this. I am convinced that how madVR/Argyll/DisplayCAL handle/view the GPU LUT is the correct way to do.

However, I still have a concern. I was using the Calibration Tester not to reset the LUT but to check the status of the LUT. I did this testing on three systems with different GPUs – Intel, AMD and Nvidia. In all three systems there was no ICC profile used and there was no application manipulating the LUT. In this condition, the default state of the LUT was found different than it was when madVR reset the LUT (through “disable GPU gamma ramps”) as you would have seen in the Comparison that I posted. So by default the LUT is set as slightly non-linear. Yesterday I also observed that if in Nvidia control panel -> Adjust Desktop Color Settings -> “Use NVIDIA Settings” is selected, the state of the LUT changes to linear from the default slightly non-linear state. Similarly, if in AMD settings -> Desktop Color -> “Reactivate AMD Color Controls” is selected (with default gamma 1.00), the state of the LUT changes to linear from slightly non-linear. I was wondering if there is any implication of this slightly non-linear state of the LUT? Could it be that the GPU driver doesn’t do any processing of the LUT when it is set in this slightly non-linear state (the default OS state)?
omarank is offline   Reply With Quote
Old 12th May 2016, 13:18   #37916  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 445
Quote:
Originally Posted by omarank View Post
Could it be that the GPU driver doesn’t do any processing of the LUT when it is set in this slightly non-linear state (the default OS state)?
Maybe, but the only processing it has to do is a table lookup, so I doubt it matters at all for performance.

Incidentally, while writing my own little program to keep my LUT loaded (a lot of games disable it when they go fullscreen), I saw a lot of problems on an Intel GPU. The LUT would get reset by various events (by Windows security dialogues and the like), but the GPU would be convinced that the old LUT was still loaded - and loading it again would do nothing.

I eventually solved this by setting the LUT unconditionally, and quickly switching back and forth between two imperceptibly different LUTs (the actual LUT, and the same LUT with all 16-bit values increased by 1) once every few seconds. Thankfully doing so didn't seem to cause video playback glitches, but having the GPU just flat-out lie to you is pretty annoying.

Quote:
Originally Posted by madshi View Post
Quote:
Originally Posted by Ver Greeneyes View Post
Hmm, with the new build I seem to be getting image doubling if the window is smaller than the video. It turns off if the window is the exact size as the video. I have image doubling set to "only if the scaling factor is 1.5x (or bigger)", so I shouldn't be getting supersampling!
Ooops, will have to check that.
I've worked around this bug for now by adding a profile that explicitly disables image doubling if ((scalingFactor.x < 1.0) && (scalingFactor.y < 1.0)).

Last edited by Ver Greeneyes; 12th May 2016 at 13:56.
Ver Greeneyes is offline   Reply With Quote
Old 12th May 2016, 14:19   #37917  |  Link
Uoppi
Registered User
 
Join Date: Oct 2015
Posts: 99
Many thanks aufkrawall and Asmodian for explaining the downscaling light options! Indeed, I got it wrong so now I have linear light enabled only with UHD -> 1080p scaling (I've shot a lot of UHD stuff on my Samsung Note 4). I always use SuperRes along with doubling though, so best to settle for gamma light for the other profiles then.

BTW, speaking of Samsung Note 4 and its variable frame rate clips: am I dreaming, or can LAV filters affect how smoothly VFR vids are handled in madVR? It feels as if dropped/repeated frames seem less jarring/glitchy as of late. It seems to me this happened after updating my Kodi DSPlayer which had the most up-to-date LAV package (the player itself is no longer being developed). I would think a dropped frame is a dropped frame though, so maybe I've just grown accustomed to VFR's inherent glitchiness, dunno...

Last edited by Uoppi; 12th May 2016 at 14:21.
Uoppi is offline   Reply With Quote
Old 12th May 2016, 16:41   #37918  |  Link
fhoech
Registered User
 
fhoech's Avatar
 
Join Date: Nov 2010
Location: Stuttgart, Germany
Posts: 17
Quote:
Originally Posted by omarank View Post
In this condition, the default state of the LUT was found different than it was when madVR reset the LUT
Check if "Use Windows display calibration" is enabled (Windows Color Management settings -> "Advanced" tab), it has the same problem as the CalibrationTester (which is pretty embarrassing for MS to be honest, you would think that they would know their own APIs better...).

Quote:
Originally Posted by Ver Greeneyes View Post
Incidentally, while writing my own little program to keep my LUT loaded (a lot of games disable it when they go fullscreen)
If you're using SetDeviceGammaRamp, this may not be enough for fullscreen (D3D) games, because the APIs allow for different video card gamma tables in desktop/windowed mode and fullscreen (exclusive) mode where the latter can only be influenced from within the actual game process (or via DLL injection, there's a small utility called ColorClutch which uses this method).
fhoech is offline   Reply With Quote
Old 12th May 2016, 16:48   #37919  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 445
Quote:
Originally Posted by fhoech View Post
If you're using SetDeviceGammaRamp, this may not be enough for fullscreen (D3D) games, because the APIs allow for different video card gamma tables in desktop/windowed mode and fullscreen (exclusive) mode where the latter can only be influenced from within the actual game process (or via DLL injection, there's a small utility called ColorClutch which uses this method).
Yes, thankfully I've only come across one game that used the D3D API to overwrite the gamma ramps (The Bard's Tale), and I was able to fix that using a hook I wrote myself (which also puts the game into windowed mode to fix the alt-tab crashes). Didn't know about Color Clutch though, I'll have to remember that if I run into another game that sets the gamma ramps.

Last edited by Ver Greeneyes; 12th May 2016 at 16:52.
Ver Greeneyes is offline   Reply With Quote
Old 12th May 2016, 17:15   #37920  |  Link
XMonarchY
Registered User
 
Join Date: Jan 2014
Posts: 489
Quote:
Originally Posted by har3inger View Post
New setting works different from the upscale/downscale antiring filter.

Dering removes source ringing before any sizing is done. Antiring removes ringing that is introduced by most scaling algorithms but shouldn't affect source ringing at all.
Thanks!

I do not watch any anime, so I assume enabling both - 1. the new De-Ringing + 2. Reducing Dark Halo's improves image quality in films.

What causes that ringing to begin-with? Does it affect specific Scaling Algorithm methods, like NNEDI3, Jinc, etc. ? Before this new De-Ringing, there already were Anti-Ringing features. Did these original features fail at removing ringing and dark halos?
__________________
8700K @ 5Ghz | ASUS Z370 Hero X | Corsair 16GB @ 3200Mhz | RTX 2080 Ti @ 2100Mhz | Samsung 970 NVMe 250GB | WD Black 2TB | Corsair AX 850W | LG 32GK850G-B @ 165Hz | Xonar DGX | Windows 10 LTSC 1809
XMonarchY 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:27.


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