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 9th May 2013, 14:00   #18761  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Doesn't this line on the post give you the date:

Last edited by madshi; 22nd February 2013 at 14:28.
Guest is offline   Reply With Quote
Old 9th May 2013, 15:33   #18762  |  Link
MSL_DK
Registered User
 
Join Date: Nov 2011
Location: Denmark
Posts: 137
Regarding madVR - ArgyllCMS. Please see this thread regarding "disable GPU gamma ramps."

SYS
Win7 x64
GPU: ATI HD 4850
madVR "fullscreen exclusive mode"
MSL_DK is offline   Reply With Quote
Old 9th May 2013, 16:03   #18763  |  Link
digitech
Registered User
 
Join Date: Jun 2012
Posts: 54
Quote:
Originally Posted by Dodgexander View Post
The latter is better. If you choose the former it should look notably worse because you are scaling the image twice.

Btw, can't you use dxva for the scaling also?I would have thought that would be better.

Sent from my Blade S using Tapatalk 2
Actually im using dxva for scaling i forgot to add, but i love the smooth motion function thats why i found in 1440x810 custom resolution it has no hiccups and no frames losts, when i do 1920x1080 only works fine if smooth motion is disabled, i think it finds the limits of my Nvidia ion gpu.
digitech is offline   Reply With Quote
Old 9th May 2013, 16:56   #18764  |  Link
Xaurus
Registered User
 
Join Date: Jun 2011
Posts: 288
Quote:
Originally Posted by neuron2 View Post
Doesn't this line on the post give you the date:

Last edited by madshi; 22nd February 2013 at 14:28.
Yeah, it gives me the date of when the post was updated. Since when is that equal to the date of the latest version?
__________________
SETUP: Win 10/MPC-HC/LAV/MadVR
HARDWARE: Fractal Design Node 804 | Xeon E3-1260L v5 | Supermicro X11SSZ-TLN4F | Samsung 2x8GB DDR4 ECC | Samsung 850 EVO 1TB | MSI GTX 1650 Super | EVGA G2 750
Xaurus is offline   Reply With Quote
Old 9th May 2013, 17:29   #18765  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by 6233638 View Post
I forget where now, but at least one of the hundreds of technical papers I've read over suggests that you should be measuring a 25mm spot-size from a display, rather than having the meter on the glass.
If you ever find the source, I'd be interested in reading it.

The only benefit I could image from having a meter far enough away to measure a full 25mm patch all at once, would be to compensate for the extremely low pixel density of large screen TVs. Add that to the high heat output of most large TVs, and I could see why tripods at an ample distance would be the preferred method for professional ISF calibrations. Though I still think I'd favor an adjustable arm tripod mount compared to what spectracal offers, even if I was going to have my meter at certain distance from the display.

On computer displays with high pixel-density and significantly lower heat output, using a tripod from a distance probably isn't beneficial as much. And I can't say I ran into any notable issues with repeatability or drift when I did my initial calibration of my Panasonic plasma via ColorHFCR a few months ago using the default holder against the screen. At a certain point, a balance needs to be struck between cost, practicality, and diminishing returns.

Quote:
Originally Posted by 6233638 View Post
And a lot of people mistake certification for calibration - it's my understanding that if the meter does not meet spec, you will have to buy a new one.
Probably depends how far out-of-spec the device actually is. I mean, the entire point of it getting sent to Switzerland, is so they have the facilities to update the firmware, perform minor repairs, and replace parts (extra charge) if need be. I'm sure it's probably fine, but considering my meter is now 5 years old, I'm reaching the point where I feel I need to get it re-certified for peace-of-mind that it is still functioning nominally, especially if I were going to calibrate an i1D3 or other meter against it as a reference.

Quote:
Originally Posted by MSL_DK View Post
Regarding madVR - ArgyllCMS. Please see this thread regarding "disable GPU gamma ramps."
...
"Something is wrong with madVR"
I'm not seeing how you came to the conclusion that something is wrong with madVR from that post.

If you use "collink -a tv.cal" you need to use a linear VideoLUT (fullscreen exclusive "disable GPU gamma ramps" or dispwin -c or Overlay mode)

If you use "collink" without that -a parameter you need load the tv.cal file into your VideoLUT (gamma ramps) and leave it enabled in madVR. Just remember that you cannot use Overlay mode.
cyberbeing is offline   Reply With Quote
Old 9th May 2013, 17:55   #18766  |  Link
MSL_DK
Registered User
 
Join Date: Nov 2011
Location: Denmark
Posts: 137
Quote:
Originally Posted by cyberbeing View Post
I'm not seeing how you came to the conclusion that something is wrong with madVR from that post.

If you use "collink -a tv.cal" you need to use a linear VideoLUT (fullscreen exclusive "disable GPU gamma ramps" or dispwin -c or Overlay mode)

If you use "collink" without that -a parameter you need load the tv.cal file into your VideoLUT (gamma ramps) and leave it enabled in madVR. Just remember that you cannot use Overlay mode.
Quote:
If you use "collink -a tv.cal" you need to use a linear VideoLUT (fullscreen exclusive "disable GPU gamma ramps")
"disable GPU gamma ramps" does not work in this case. look here http://www.avsforum.com/t/1471169/madvr-argyllcms/30#post_23291899

But I was not aware that dispwin-c was for Overlay mode. No wonder I got a bad result
MSL_DK is offline   Reply With Quote
Old 9th May 2013, 18:08   #18767  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by MSL_DK View Post
"disable GPU gamma ramps" does not work in this case. look here http://www.avsforum.com/t/1471169/madvr-argyllcms/30#post_23291899
I'm still confused because in that post you said you ran dispwin -c, at which point madVR "disable GPU gamma ramps" isn't supposed to do anything.

In any case, your yellowish results seem to suggest a problem with the Argyll 3DLUT you created, not madVR. The only other thought is because you have an ATI/AMD video card, make sure you have disabled "Use Extended Display Identification Data" in your catalyst control panel, as that option seemed to be causing trouble for a few people on the Argyll mailing list recently.

Quote:
Originally Posted by MSL_DK View Post
But I was not aware that dispwin-c was for Overlay mode. No wonder I got a bad result
No, Overlay mode is an alternative to dispwin -c, since both will result in a linear VideoLUT.
madVR's "disable GPU gamma ramps" option should be equivalent to running dispwin -c, but affects Fullscreen Exclusive mode only (though possibly broken on WinXP from what Graeme has said).

Last edited by cyberbeing; 9th May 2013 at 18:28.
cyberbeing is offline   Reply With Quote
Old 9th May 2013, 19:21   #18768  |  Link
MSL_DK
Registered User
 
Join Date: Nov 2011
Location: Denmark
Posts: 137
Quote:
Originally Posted by cyberbeing View Post
I'm still confused because in that post you said you ran dispwin -c, at which point madVR "disable GPU gamma ramps" isn't supposed to do anything.

In any case, your yellowish results seem to suggest a problem with the Argyll 3DLUT you created, not madVR. The only other thought is because you have an ATI/AMD video card, make sure you have disabled "Use Extended Display Identification Data" in your catalyst control panel, as that option seemed to be causing trouble for a few people on the Argyll mailing list recently.


No, Overlay mode is an alternative to dispwin -c, since both will result in a linear VideoLUT.
madVR's "disable GPU gamma ramps" option should be equivalent to running dispwin -c, but affects Fullscreen Exclusive mode only (though possibly broken on WinXP from what Graeme has said).
I am somewhat confused ... I have also tried to run collink "-a display.cal" without running dispwin -c and the result was precisely a yellowish tinge. (ON: fullscreen exclusive and "GPU gamma ramps")

But without collink "-a display.cal" and with dispwin display.cal do I get an almost perfect result. (ON: "fullscreen exclusive" OFF "GPU gamma ramps")

regarding dispwin ... Should dispwin-c, or dispwin "-a display.cal" run after every reboot of windows?
MSL_DK is offline   Reply With Quote
Old 9th May 2013, 19:42   #18769  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
Quote:
Originally Posted by Xaurus View Post
Yeah, it gives me the date of when the post was updated. Since when is that equal to the date of the latest version?
it usually is
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack)
Thunderbolt8 is offline   Reply With Quote
Old 9th May 2013, 20:20   #18770  |  Link
n3w813
Registered User
 
Join Date: Jan 2006
Posts: 80
Quote:
Originally Posted by MSL_DK View Post
But without collink "-a display.cal" and with dispwin display.cal do I get an almost perfect result. (ON: "fullscreen exclusive" OFF "GPU gamma ramps")
This is the correct method!

I think you are still confused on when to use what....

*** First make sure FSE is enabled in MadVR. Make sure when viewing results MadVR is in FSE mode***

If you run "dispwin -c" Then
---Run collink.exe with "-a display.cal"
---"Disable gpu gamma ramps" checkbox in MadVR has no effect on image
End with expected results

If you run "dispwin display.cal" Then
---Run collink.exe without "-a"
---Uncheck "Disable gpu gamma ramps" checkbox
End with expected results
n3w813 is offline   Reply With Quote
Old 9th May 2013, 20:57   #18771  |  Link
FlashGordon
Registered User
 
Join Date: Oct 2010
Posts: 42
madshi, is it possible to make the refreshRate file tags work even if the format isn't specified in the settings? For example, I currently only have 1080p24 as a display mode because I mostly watch films and NTSC DVDs were not triggering the change to 24hz. However, for the odd video file that I have, even if I tag it with [refreshRate=60], the display will still switch to 24hz because I don't have 1080p60 as a display mode in the settings. Is there a way you can make the filename tag override this and force the switch to whatever refreshRate is specified?
FlashGordon is offline   Reply With Quote
Old 10th May 2013, 02:34   #18772  |  Link
flanger216
Registered User
 
Join Date: Mar 2004
Posts: 140
Quote:
Originally Posted by 6233638 View Post
The Nvidia control panel is able to switch to 24/60Hz correctly though, so it's not that the OS can't do 24/60Hz. Something must have changed with how refresh rate switching works though.

The "good" thing about this, is that your post finally confirms what I had been unable to get an answer for - the problem is not specific to Nvidia cards, and affects AMD (and likely Intel) too. Previously it had been suggested that this was a driver bug, but I find unlikely that both Nvidia and AMD have the same bug.

A "fix" for this is to run ReClock or JRiver's VideoClock which will eliminate the stuttering caused by the framerate/refreshrate mismatch.

But I wish someone could figure out why the refresh rate switcher isn't working correctly so that we can get 24/60 back.

23Hz on my card outputs 23.970.. but 24Hz is 24.0000.
I can also reconfirm this bug --- manually switching to 24hz or 60hz works fine, but madVR's automatic switcher will never switch to these rates, and instead always forces the display either to 23hz or 59hz. I'm also using Windows 8, and I'm running ATI.

The problem persists with the "Use 24p for PAL" setting. PAL content used to trigger a switch to 24hz, but now it switches to 23hz instead.

However, all of these issues also occur with MPC-HC's internal refresh switcher. So I suspect madVR and MPC-HC (and likely other media software) use the same process to initiate a refresh switch, and that process has become bugged or deprecated under Windows 8.

Currently the only solution does seem to be Reclock. Which is a bit too bad, as I get lower CPU usage and (somehow?) less clock drift when simply bitstreaming.
flanger216 is offline   Reply With Quote
Old 10th May 2013, 10:04   #18773  |  Link
MSL_DK
Registered User
 
Join Date: Nov 2011
Location: Denmark
Posts: 137
Quote:
Originally Posted by n3w813 View Post
This is the correct method!

I think you are still confused on when to use what....

*** First make sure FSE is enabled in MadVR. Make sure when viewing results MadVR is in FSE mode***

If you run "dispwin -c" Then
---Run collink.exe with "-a display.cal"
---"Disable gpu gamma ramps" checkbox in MadVR has no effect on image
End with expected results

If you run "dispwin display.cal" Then
---Run collink.exe without "-a"
---Uncheck "Disable gpu gamma ramps" checkbox
End with expected results
Thanks for the explanation

>>>>>>>>>>>>>>>>>>

I have a question regarding madVR - ArgyllCMS ... Could this be an indication of "black crush"?

MSL_DK is offline   Reply With Quote
Old 10th May 2013, 10:08   #18774  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Many meters are rather inaccurate at 10%, its not a clear indication for anything without knowing more.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 10th May 2013, 10:18   #18775  |  Link
MSL_DK
Registered User
 
Join Date: Nov 2011
Location: Denmark
Posts: 137
Quote:
Originally Posted by nevcairiel View Post
Many meters are rather inaccurate at 10%, its not a clear indication for anything without knowing more.
Thank you ... What information can I contribute? The instrument is a i1Display3

Last edited by MSL_DK; 10th May 2013 at 12:21.
MSL_DK is offline   Reply With Quote
Old 10th May 2013, 12:37   #18776  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Well I've been working on profiling again tonight, and I seem to be making progress. Changed my workflow yet again, notably I got rid of dispcal completely, and re-adjusted my GDM-F520 for the most consistent gamma response and white balance across the luminance range that I could manage via pre-calibration in ColorHFCR2 instead of Argyll's built-in method. Also pulled out the masking tape, so I wouldn't have to hold my meter for the large patch set.

Code:
dispwin -c

targen -v -d3 -s21 -g21 -m5 -f256 PreCond_256

dispread -v -w -H -F PreCond_256

colprof -v -qh PreCond_256

targen -v -d3 -G -e8 -s41 -g81 -m5 -f1084 -c PreCond_256.icm GDMF520_1084

dispread -v -w -H -F GDMF520_1084

colprof -v -qh GDMF520_1084
If anybody was wondering, my logic of using this combination of targen switches along with the use of the dispread -w switch, was so I'd actually have measurement data points which would be useful outside of Argyll. A good number level steps interlaced throughout my gamut as well, to ensure that Argyll would have little excuse for messing up what should be a predicable gamma & basic internal structure of my CRT's gamut cube. Though aside from my particular goals with a patch set formed in this way, most flat-panel displays would likely benefit more from replacing the multi-dimensional patches with full-spread patches in the larger set, similar to the command line example in Argyll's Scenarios documentation. YMMV.


Preconditioning set of 256:
-s21 = 20 levels (5% steps) Red, Green, Blue
-g21 = 20 levels (5% steps) Grayscale
-m5 = 4 levels (25% steps) Multi-dimensional [Red, Green, Blue channel mixtures]
-f256 = 64 full spread patches


LAB cLUT ICC profile created from 256 set to precondition the full 1084 patch set, basically a scaled up version:
-s41 = 40 levels (2.5% steps) Red, Green, Blue
-g81 = 80 levels (1.25% steps) Grayscale
-m5 = 4 levels (25% steps) Multi-dimensional
-f1084 = 768 full spread patches
-e8 = 8 White Point readings to better average out any bad readings when my i1pro catches my CRT refresh at a bad time



My main goal tonight was to see how well collink's BT.1886 gamma scaling would function when used alone. Now that I seem to have an extremely solid LAB cLUT monitor profile, likely in part because of the recent targen/dispcal/dispread changes Graeme made the other day, collink 3DLUT results seem more promising. Too tired now to actually take measurements to verify what values the 3DLUT is actually outputting, but I'm not noticing the same blatantly visible errors I was seeing with my first attempts using existing profiles created via dispcalGUI's workflow & bundled patch sets.


@Graeme
Files resulting from my profiling workflow tonight:
http://www.mediafire.com/?kgbsafbobjk1pc1

[Edit: I notice that a XYZ cLUT profile from this ti3 data continues to give poor tone smoothness (visible banding) on gradients compared to the LAB cLUT profile which is very smooth]

Some other night, I'll need to add dispcal back into the mix, and see if this level of quality can be maintained with my preferred gamma curve.

Possible Bug: If you use a RGB -> LAB cLUT as your ICC source device profile, collink generates an invalid 3DLUT. madVR outputs a black screen and complains the 3DLUT does not contain primary information. If you can't reproduce this, I must have made an error when creating the LAB cLUT device profile.

Last edited by cyberbeing; 11th May 2013 at 05:38.
cyberbeing is offline   Reply With Quote
Old 10th May 2013, 13:01   #18777  |  Link
Graeme Gill
Registered User
 
Join Date: Aug 2011
Location: Australia
Posts: 51
Quote:
Originally Posted by MSL_DK View Post
I have a question regarding madVR - ArgyllCMS ... Could this be an indication of "black crush"?
It depends on the details of how the 3dlut was created, but I would imagine that your just seeing your displays not quite perfectly neutral black coming through. The alternative is to boost the black point to be able to neutralize it, but I imagine that you probably would prefer to maintain your contrast ratio.
Graeme Gill is offline   Reply With Quote
Old 10th May 2013, 13:43   #18778  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by cyberbeing View Post
The only benefit I could image from having a meter far enough away to measure a full 25mm patch all at once, would be to compensate for the extremely low pixel density of large screen TVs. Add that to the high heat output of most large TVs, and I could see why tripods at an ample distance would be the preferred method for professional ISF calibrations.
And those are useful benefits. It also helps reduce issues caused by narrow viewing angles. (LCD, OLED etc.)

Quote:
Originally Posted by cyberbeing View Post
At a certain point, a balance needs to be struck between cost, practicality, and diminishing returns.
While I did end up buying the SpectraCal brackets because they are convenient, I just bought the cheapest 5 section tripod (or maybe it was 6?) so that it was very compact and folded down to less than a foot in length.
Before I bought the SpectraCal brackets I just used some large rubber bands to attach the meter to the quick mount plate on the tripod head.

You're not trying to take photographs with the thing, so cost doesn't really matter, it's more about getting it off the surface of the screen than anything else.


Quote:
Originally Posted by cyberbeing View Post
Probably depends how far out-of-spec the device actually is. I mean, the entire point of it getting sent to Switzerland, is so they have the facilities to update the firmware, perform minor repairs, and replace parts (extra charge) if need be. I'm sure it's probably fine, but considering my meter is now 5 years old, I'm reaching the point where I feel I need to get it re-certified for peace-of-mind that it is still functioning nominally, especially if I were going to calibrate an i1D3 or other meter against it as a reference.
Well it's up to you, but as long as you've taken care of it (don't drop it, store it away from heat and sunlight, keep a desiccant in the box) and it is passing the X-Rite self-tests, I doubt meter certification is going to do anything other than send it back saying it's OK. They're very stable meters and I've seen ones older than that pass certification without any trouble.
6233638 is offline   Reply With Quote
Old 10th May 2013, 16:32   #18779  |  Link
petran79
Registered User
 
Join Date: Aug 2007
Posts: 87
I did upgrade the GPU, from an Nvidia GTS450 to a GTX660

Now in Windows 7 there are no issues with MadVR.

But on Windows XP, after the upgrade any video I play with MadVR shows dropped frames for like 10-15 seconds, then plays normally and after a while dropped frames appear again for the same length. If I choose other renderers videos play normally. If I choose lower settings in Madvr, delay may appear much later or not at all if the video is lower in quality.

No matter if its in MPC or Potplayer or any player.

With the lower tier GPU all videos played normally with MadVR on XP.

No big issue as I mostly use Windows XP for old games and play videos on Windows 7

this must be probably an Nvidia driver issue rather than MadVR.
petran79 is offline   Reply With Quote
Old 10th May 2013, 20:55   #18780  |  Link
maco07
Registered User
 
Join Date: Jun 2009
Posts: 9
Hi madshi. Can you share with us in wich new features are you working for next madVR version?

Great work!! I'm using madVR sin 0.3x!
maco07 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 06:10.


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