or Connect
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS
New Posts  All Forums:Forum Nav:

MadVR - ArgyllCMS - Page 14

post #391 of 1680
Okay ... I dug a little deeper ... I thought that it was possible to make a pre-calibration via Calman / MPC-HC / madVR and then run ArgyllCMS ... I have learned that it is not! I then tried to reset my TV to default and run ArgyllCMS including dispcal, bad result ... I then looked for some known options to offset + gain and brightness and ran ArgyllCMS, better! I do not own a BD-player, therefore a pre-calibration via Calman / MPC-HC / madVR
post #392 of 1680
Quote:
Originally Posted by gwgill View Post

Quote:
Originally Posted by zoyd View Post

I believe you are supposed to use -E for dispcal and dispread if your video card is set to full range.
It's hard to know what the context is, but if your display is full range (o..255), then you don't use the -E switch in dispcal or dispread. If you think my tutorial says otherwise, please point out where, and I'll fix it...

An alternative to loading the calibration curves into the video card which may give you higher quality is to leave the video card linear (dispwin -c) and include the calibration curves in the 3dLUT using collink -a.

It looks like I misinterpreted your statement under the madVR workflow to mean that the -E switch was being provided for 0-255 systems to provide a means to calibrate an measure with 16-235 levels because that is what madVR expects. In other words, one would change the display to accept limited range and then use the -E switch for the measurements and reading, and then switch it back to full range for use with madVR. Sorry for the misunderstanding.

@madshi: your workflows 1-3 make sense to me, thanks for the post
post #393 of 1680
Here's a "hack" that will manipulate dispcal & dispread to use madVR's test pattern generator, and it will also use madVR's pixel shader based VideoLUT implementation instead of the GPU VideoLUT, resulting in higher bitdepth processing. Furthermore, this will also work over LAN. So you can run Argyll on your laptop, while madVR runs on your HTPC. Both the test patterns and the VideoLUT will be defined by dispcal/dispread, but through the hack actually transported to the PC running madVR.

http://madshi.net/HookArgyll.rar

The hack involves ugly things like loading a little kernel mode driver, injecting a hook dll into dispcal/dispread etc. So it's an ugly solution, but it works just fine (for me at least). Don't worry, the hack is automatically and cleanly gone after you reboot. I do hope that Graeme will implement native support for madVR's test pattern and VideoLUT solution when he finds some time. Then we can just trash the hack.

When using this solution, please do not ever use the dispcal/dispread "-E" parameter. Instead make sure you have configured your display, GPU and madVR so black and white are displayed correctly.

In order to activate the hack, just start "HookArgyll.exe". Afterwards use dispcal/dispread just as you would normally do, but add a "-Cbla.exe" parameter to the list of parameters. You might also want to add "-P0.0,0.0,0.1,0.1" to hide Argyll's own test pattern drawing. When you're done with calibration work, simply start "HookArgyll.exe" another time to remove the hack from the OS, or reboot the OS, which will have the same effect.

P.S: There's a small bug in madVR v0.86.6 which results in the internal VideoLUT processing not using linear interpolation. This will be fixed in the next build, which should improve accuracy further...
post #394 of 1680
madshi
Can you add an OSD showing 1 of XXXX reason is that my TV turns off at 0,0,0 and I could imagine that it could be a problem. Otherwise, I look forward to trying with madVR :-)
post #395 of 1680
I'm not sure what you mean exactly? What does "1 of XXXX" mean? You mean like a progress bar? That's not possible because dispcal/dispread don't inform me about the progress.
post #396 of 1680
Thread Starter 
Quote:
Originally Posted by madshi View Post

I'm not sure what you mean exactly? What does "1 of XXXX" mean? You mean like a progress bar? That's not possible because dispcal/dispread don't inform me about the progress.
Madshi,
Actually, you can choose display anything in one of the corner's. Some text, logo, anything. Some TVs, like my Sharp LE640 for instance, will turn off the panel completely when fed a full field 0,0,0 signal, incorrectly representing the MLL. Therefore, the readings for 0 black will be incorrect.

PS - I added your explanation of the 3 scenarios for -E usage in the 2nd post of this thread. Thanks! smile.gif
Edited by N3W813 - 6/25/13 at 10:09am
post #397 of 1680
I can't seem to get to square one with calibrating with madVR and I have not idea what is wrong.

I have a display that need to be at 16-235 because everything comes through the Radiance to the same HDMI port. I used the NVidia provided hack to enable 0-255 via registry changes. It apparently doesn't work because the Radiance says the input level is video.

The levels are video levels coming out of madVR as they are out of WMC... but here's the rub. Even though the image level is clearly the same as EVR out in WMC when I try to use AVS 709 mp4. with madVR I have to raise black level all the way up to max to get 17 and 18 to flash. I don't know if this some issue between LAV or madVR and AVS 709 mp4. But if I can't get a test pattern to behave in madVR I don't feel I can start Argyll and madVR. I am going to go through the steps again using the madlevels tweaker this time... but the AVS 709 disk looks fine with black at 16 using the TVs default brightness setting of 31 maybe 32, with madVR in JRiver I am needing a setting of 63 (max) to get 17 to be visible.
post #398 of 1680
Ok, I've uploaded a new build (same link) which shows an OSD message during all the test patterns...
post #399 of 1680
Quote:
Originally Posted by madshi View Post

Ok, I've uploaded a new build (same link) which shows an OSD message during all the test patterns...

 

Great but some CRT and LCD screens crush the blacks when there's some white being displayed simultaneously, will that be the case? Or do you show the OSD message before/after the measurement has been made?

 

Some TV's turn off their backlight when sent a pure black screen, A less harmful "fix" might be to send the next lighter shade?

 

Either way, if you could please make the OSD optional this would be great because this fix for LCD TV's(trying to hide their light bleeding) will break compatiblity with black crushing CRT's for sure =/


Edited by leeperry - 6/25/13 at 12:37pm
post #400 of 1680
Argh. How do the built in test pattern generators in HCFR and Argyll handle these problems?
post #401 of 1680
Quote:
Originally Posted by MSL_DK View Post

madshi
Can you add an OSD showing 1 of XXXX reason is that my TV turns off at 0,0,0 and I could imagine that it could be a problem. Otherwise, I look forward to trying with madVR :-)

Wait, did you actually test this and found it to be a problem? Or were you just posting a random guess? Next time please make sure there actually *is* a problem before reporting it. After thinking about it I think I wasted time by creating a modified build because the problem probably wasn't really a problem in the first place, due to dithering producing some random pixels other than 0,0,0.
post #402 of 1680

Well, whatever HCFR or Argyll don't show any OSD in their calibration window while measurements are being made, mostly because stray light would be a major issue(especially with videoprojectors, the original goal of HCFR).

 

TV's that turn off their backlight when sent a pure black screen do fubar the measurements from 0 to the next step(10IRE?), so maybe you guys could pull a 1 IRE test pattern in order to nail it down? Possibly through an extra option, only to be enabled if your TV plays this "trick".

 

This would also ensure that the backlight LED's aren't turned off during the calibration pass and that their colorimetry doesn't fluctuate due to this.

 

PS: having more thought about it, what those nasty TV's would need is an option in mVR to never output 0 IRE black because they lag quite a bit when turning off their backlight, it's utterly annoying when there are many fade-to-black effets in movies because you basically miss half a second of picture after each fade. Cap it to 1 IRE = problem solved :)

 

OTOH, a quick fix is to set 1-255 as output levels in mVR I guess.


Edited by leeperry - 6/25/13 at 7:17pm
post #403 of 1680
Quote:
Originally Posted by madshi View Post

Argh. How do the built in test pattern generators in HCFR and Argyll handle these problems?
Argyll's test window can be set to whatever size you want. Filling the rest of the screen with black is optional. So you can leave something else showing on the screen, or have it fully fill it.
post #404 of 1680
Quote:
Originally Posted by gwgill View Post

Argyll's test window can be set to whatever size you want. Filling the rest of the screen with black is optional. So you can leave something else showing on the screen, or have it fully fill it.

Oh no I think we are headed straight into the quicksand that is calibrating plasmas here.
post #405 of 1680
Quote:
Originally Posted by madshi View Post

@Graeme,

the latest madVR v0.86.4 build (just released) now supports remote controlled test patterns. Would you consider adding support to dispcal/dispread for this? If you look into the "developers" folder shipping with madVR, you'll find a header and cpp file for this, plus a very simple demo application which demonstrates how to do this. It's really very simple. The header/cpp uses dynamic linking, so there's no problem if madVR is not installed, and it should (hopefully) work for any C++ compiler. I've only tested with MSVC++, though.
I'm looking into it, although it will create even more confusion by providing yet another set of possible workflows. I'm not quite sure how to explain all the options in a way that's easily comprehensible. My inclination is to use diagrams since that's what works for me, but it will take a little time to put them together.

Problems: I can't use madVRTestPattern.h and madVRTestPattern.cpp due to the lack of a license. I would need a more permissive license - an "MIT" or "BSD" would be the best for wide use (e.g. see Argyll/icc/License.txt). I'll also have to see how well it compiles with the various compilers (MSVC++ V6 to MingW), and have to figure out if there is a problem calling it from my C code - I may have to recode it in C, although that would create a problem in keeping it up to date with your latest API.

My initial thought is to make it a -d option and building up another display access type along the lines of webwin.c, although selecting a display could be interesting.
post #406 of 1680
Quote:
Originally Posted by gwgill View Post

I'm looking into it, although it will create even more confusion by providing yet another set of possible workflows. I'm not quite sure how to explain all the options in a way that's easily comprehensible. My inclination is to use diagrams since that's what works for me, but it will take a little time to put them together.

Problems: I can't use madVRTestPattern.h and madVRTestPattern.cpp due to the lack of a license. I would need a more permissive license - an "MIT" or "BSD" would be the best for wide use (e.g. see Argyll/icc/License.txt). I'll also have to see how well it compiles with the various compilers (MSVC++ V6 to MingW), and have to figure out if there is a problem calling it from my C code - I may have to recode it in C, although that would create a problem in keeping it up to date with your latest API.

My initial thought is to make it a -d option and building up another display access type along the lines of webwin.c, although selecting a display could be interesting.

Can I simply do "license: public domain"? Or "license: do whatever you want"? Or would "BSD" actually be preferable? In any case, that's not really important to me, since these are basically just headers, nothing more. Just let me know which works best for you.

Please feel free to make any necessary changes to the headers. If you do need to create a new "c" version, you could just send the final version back to me. I'd be happy to ship it with future madVR builds and keep it up to date in the future, too, of course.

When using the madVR headers, selecting different displays won't work, instead you could choose different madVR instances on the LAN. But I'm not sure if that's worth the effort. HCFR is currently using "madVR_BlindConnect()" which will simply connect to the first madVR instance found on the LAN (local instances preferred over LAN instances). The display is automatically defined by which display the selected madVR instance is running on. Instead of "madVR_BlindConnect()" you could also use "madVR_ConnectDialog()" which will open up a GUI dialog, letting the user choose a madVR instance from the list of instances found on the LAN. Use whichever you prefer. I think making this part of the "-d" option is a good idea. E.g. you could use "-dm" or "-dmvr" or "-dmadVR" or something like that. If that option is activated, please also use "madVR_SetDeviceGammaRamp" instead of GDI32's "SetDeviceGammaRamp", so that the VideoLUT is also transferred to the target computer/display.

It would be nice if you could also allow the "-P" option to hide your own test pattern window completely. Currently "-P0,0,0,0" is rejected. Maybe you could allow it? Or alternatively maybe you could auto hide your own test pattern window if madVR is selected to draw the test patterns?

Thanks!
post #407 of 1680
Quote:
Originally Posted by madshi View Post

Can I simply do "license: public domain"? Or "license: do whatever you want"? Or would "BSD" actually be preferable? In any case, that's not really important to me, since these are basically just headers, nothing more. Just let me know which works best for you.

Please feel free to make any necessary changes to the headers. If you do need to create a new "c" version, you could just send the final version back to me. I'd be happy to ship it with future madVR builds and keep it up to date in the future, too, of course.
Maybe it's not so relevant - it made more sense to re-code the .dll & function loading in my code.
Quote:
When using the madVR headers, selecting different displays won't work, instead you could choose different madVR instances on the LAN. But I'm not sure if that's worth the effort. HCFR is currently using "madVR_BlindConnect()" which will simply connect to the first madVR instance found on the LAN.
That's all I'm currently doing.
Quote:
It would be nice if you could also allow the "-P" option to hide your own test pattern window completely. Currently "-P0,0,0,0" is rejected. Maybe you could allow it? Or alternatively maybe you could auto hide your own test pattern window if madVR is selected to draw the test patterns?
If MadVR is selected as the "display", then it won't create any other test patch display.

Problem: I'm using MPC-HC, and it doesn't work unless I open a video of some sort - ie. MadVR doesn't get started until MPC-HC starts to render something. Is there a way to fix this ?
post #408 of 1680
Quote:
Originally Posted by gwgill View Post

Problem: I'm using MPC-HC, and it doesn't work unless I open a video of some sort - ie. MadVR doesn't get started until MPC-HC starts to render something. Is there a way to fix this ?

There's currently no other solution, unfortunately. MPC-HC doesn't even load the madVR DLL before a video is opened. I might create a separate test pattern tool (basically a tiny tiny media player which automatically loads madVR) at some point in the future to make things a bit more intuitive.
post #409 of 1680
Thread Starter 
@Graeme,
Today, while I was running a calibration on my laptop's LCD, I found significantly raised black levels using latest beta binaries (06/09/13). Then, just for testing, I replaced the binaries from a set that was updated on 05/21/13. Result had no raised black level. I've attached the binaries, scripts, and .cal files in the attached zip file. Please take a look when you get a chance.

Thanks smile.gif

dispcal.disparities.zip 1368k .zip file

EDIT:
I just compared the 2 resulting .cal files. In the raised black level one (laptop.0609.cal), there are 2 lines that are not in the normal one (laptop.0521.cal).
Code:
KEYWORD "TV_OUTPUT_ENCODING"
TV_OUTPUT_ENCODING "YES"

** parameter '-E' was NOT used in both commands (you can verify the batch files)
Edited by N3W813 - 6/28/13 at 3:53pm
post #410 of 1680
Quote:
Originally Posted by N3W813 View Post

I just compared the 2 resulting .cal files. In the raised black level one (laptop.0609.cal), there are 2 lines that are not in the normal one (laptop.0521.cal).
Code:
KEYWORD "TV_OUTPUT_ENCODING"
TV_OUTPUT_ENCODING "YES"

** parameter '-E' was NOT used in both commands (you can verify the batch files)
Right, but if you read the documentation you will notice that this happens if -E is used in dispcal, so that the resulting .cal will trigger the appropriate TV encoding when it's loaded into the HW or used with dispread.
post #411 of 1680
Quote:
Originally Posted by N3W813 View Post

Code:
KEYWORD "TV_OUTPUT_ENCODING"
TV_OUTPUT_ENCODING "YES"
** parameter '-E' was NOT used in both commands (you can verify the batch files)
Yep, looks like a bug. It will muck things up. I'll update with a fix shortly.
post #412 of 1680
post #413 of 1680
Thread Starter 
Thanks Graeme. smile.gif I've updated the first post.
post #414 of 1680
I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with versions that support displaying test patches through MadVR using the "-d madvr" option.

Note that while this then avoids the need for using the -E flag in dispcal and dispread when the display needs video encoding, you need to be careful to setup the Graphics Card VideoLUTs the way you want them if MadVR plays through them, since calibrating and profiling through MadVR doesn't touch the Graphics Card VIdeoLUTs.
post #415 of 1680
Hmm. I want to calibrate and profile with MadVR for the potential increased accuracy, but I also want everything else to use the LUT and ICC profile.

What would be really nice is something like a system service that applies MadVR's shader-based LUT to my desktop, but works with games too (games usually don't support profiles, but I use a small program that keeps my VideoLUT loaded so I still get something out of it).
post #416 of 1680
Quote:
Originally Posted by gwgill View Post

I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with versions that support displaying test patches through MadVR using the "-d madvr" option.

Note that while this then avoids the need for using the -E flag in dispcal and dispread when the display needs video encoding, you need to be careful to setup the Graphics Card VideoLUTs the way you want them if MadVR plays through them, since calibrating and profiling through MadVR doesn't touch the Graphics Card VIdeoLUTs.

Thanks a lot!! biggrin.gif



I've been doing some testing today with your new build, using madVR as a test pattern generator. Generally it seems to work fine. I think I identified some problems with collink, though. Let me recapture what I did:

First of all I measured the uncalibrated display. See here:

http://madshi.net/argyll/native_gamma.png
http://madshi.net/argyll/native_rgb.png
http://madshi.net/argyll/native_cie.png

As you can see, red and blue primaries are too narrow, while green is too wide. Gamma is weird.

Now I wanted to try the following 3 different workflows:

a. Let dispcal correct gamma and white point.
b. Let dispcal correct gamma, let collink correct white point.
c. Skip dispcal completely, let collink do everything.

As a very first step I played with dispcal to confirm that it's working correctly. So I created different cal files, all with madVR as test pattern generator. Then I loaded them into the VideoLUTs by using dispwin and measured the outcome with HCFR. Here are some results:

dispcal -dmadvr -g2.4
http://madshi.net/argyll/dispcal_g24_gamma.png
http://madshi.net/argyll/dispcal_g24_rgb.png

dispcal -dmadvr -G2.4 -f0
http://madshi.net/argyll/dispcal_G24_f0_gamma.png
http://madshi.net/argyll/dispcal_G24_f0_rgb.png

dispcal -dmadvr -G2.4 -f0 -t6500
http://madshi.net/argyll/dispcal_G24_f0_t6500_gamma.png
http://madshi.net/argyll/dispcal_G24_f0_t6500_rgb.png

After looking at these results I'd say that dispcal is working reasonably well with madVR as test pattern generator. The results are not perfect, but near enough for the default medium quality, I guess.

However, now it's getting interesting. Next step was trying to create 3dlut files with the calibration baked in via "collink -a", compared to skipping calibration completely. Here are the results:

collink -ia -IB (no calibration)
http://madshi.net/argyll/collink_ia_IB_gamma.png
http://madshi.net/argyll/collink_ia_IB_rgb.png
http://madshi.net/argyll/collink_ia_IB_cie.png

dispcal -dmadvr -g2.4; collink -ia -IB -a
http://madshi.net/argyll/dispcal_g24_collink_ia_IB_a_gamma.png
http://madshi.net/argyll/dispcal_g24_collink_ia_IB_a_rgb.png
http://madshi.net/argyll/dispcal_g24_collink_ia_IB_a_cie.png

dispcal -dmadvr -G2.4 -f0; collink -ia -IB -a
http://madshi.net/argyll/dispcal_G24_f0_collink_ia_IB_a_gamma.png
http://madshi.net/argyll/dispcal_G24_f0_collink_ia_IB_a_rgb.png
http://madshi.net/argyll/dispcal_G24_f0_collink_ia_IB_a_cie.png

dispcal -dmadvr -G2.4 -f0 -t6500; collink -ia -IB -a
http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_gamma.png
http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_rgb.png
http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_cie.png

Looking at these results it seems to me that collink has problems producing a good gamma response if it also has to correct the white point at the same time. The only way I could get a reasonably good gamma response was to let dispcal correct the gamma and white point beforehand. In any other situation the gamma response produced by collink was pretty bad. (In case you're wondering: It was even worse when not using "-IB", but I've not uploaded screenshots for that.)

Unfortunately letting dispcal correct gamma and white point first and then running "collink -a" afterwards produces a not-so-optimal RGB balance in the lower IREs for me. So that doesn't seem to be the ultimate solution, either.

What do you think?

( files uploaded here: http://madshi.net/argyll/files.rar )
post #417 of 1680
Great post madshi!

I hadn't done such extensive testing myself, but was having similar results. My situation is complicated by the fact that I'm using a Plasma display, and am not yet able to use madVR as the renderer because of the on-screen messages and progress bar.

I'm really looking forward to using all of these tools to create an image that's close to perfect!

Thanks so much for the work that's going in to this.

Neil.
post #418 of 1680
Quote:
Since color management overrides calibration curves, I'm not sure aiming for gamma 2.4 is the best thing, given the very steep slope near zero, which probably reduces the control the 3dLUT can exert. I'd be following the tutorial and using something like -gs or -gl.
Quote:
However, now it's getting interesting. Next step was trying to create 3dlut files with the calibration baked in via "collink -a", compared to skipping calibration completely. Here are the results:

.....

dispcal -dmadvr -G2.4 -f0 -t6500; collink -ia -IB -a
http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_gamma.png
http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_rgb.png
http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_cie.png

Looking at these results it seems to me that collink has problems producing a good gamma response if it also has to correct the white point at the same time. The only way I could get a reasonably good gamma response was to let dispcal correct the gamma and white point beforehand. In any other situation the gamma response produced by collink was pretty bad. (In case you're wondering: It was even worse when not using "-IB", but I've not uploaded screenshots for that.)
I'm not sure what you mean by "good gamma", so the plots mean little to me. The response curve is what it is when all the factors are taken into account. A perfect power curve is impossible with a real world display - none of them have a zero black. You certainly don't expect a flat log/log plot for BT.1886. What's of more interest is any error between the expected response curve and the actual response curve.

As explained in the tutorial, trying to correct the white point using collink is not recommended, because it reduces flexibility in the choice of intent. If you are correcting the white point using calibration, then follow the tutorial and use relative colorimetric (collink -ir) as a starting point, not -ia.
post #419 of 1680
Quote:
Originally Posted by gwgill View Post

I'm not sure what you mean by "good gamma", so the plots mean little to me. The response curve is what it is when all the factors are taken into account. A perfect power curve is impossible with a real world display - none of them have a zero black. You certainly don't expect a flat log/log plot for BT.1886. What's of more interest is any error between the expected response curve and the actual response curve.

Well, HCFR does show the expected and actual response curves. If you look here:

http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_gamma.png

... the yellow and white curves have a nearly identical form. So this looks "good" or "correct" to me. However, that's the only case where HCFR shows a good match between expected and actual response curve. Look at these:

http://madshi.net/argyll/collink_ia_IB_gamma.png
http://madshi.net/argyll/dispcal_g24_collink_ia_IB_a_gamma.png
http://madshi.net/argyll/dispcal_G24_f0_collink_ia_IB_a_gamma.png

They all look "bad", in the sense that the expected (white) and actual (yellow) response curves totally differ in their shape. The actual response curve (yellow) has a shape which is clearly not good, or am I missing something?

Quote:
Originally Posted by gwgill View Post

As explained in the tutorial, trying to correct the white point using collink is not recommended, because it reduces flexibility in the choice of intent. If you are correcting the white point using calibration, then follow the tutorial and use relative colorimetric (collink -ir) as a starting point, not -ia.

I understand that. But what if I'm happy with -ia? I don't see why that would have an effect on the gamma response curve? Why does collink produce such weird gamma responses when I let collink correct the white point? Doesn't that indicate a gamma related bug in collink? My tests indicate that collink is currently not able to correct the white point and produce a reasonably acceptable gamma response at the same time. Ok, we can work around this problem by letting dispcal correct the white point. But if this really is a bug in collink then fixing it might also improve the final result even if we do let dispcal correct the white point?

As far as I understand, the recommendations by N3W813 and zoyd in this thread have always been to skip dispcal completely and to let collink do all the work (e.g. see first post of this thread). But it seems that when doing that, collink produces a rather bad gamma response (at least in my case it does). So would you say, the recommendations by N3W813 and zoyd were bad, and we should always use dispcal to correct the white point?
post #420 of 1680
My recommendation is to calibrate WP and gamma with display controls first and then dispcal if needed, but only if the video card is in your final flow (i.e. for HTPCs). tweaking the display after the 3dlut is also needed in some cases.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS