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

MadVR - ArgyllCMS - Page 12

post #331 of 1688
Quote:
Originally Posted by monvo View Post

Ok, thanks, but one after another is right? Wouldn't -ym be more suitable for the use on a plasma? If it's the same that I can select in dispcal then it's also the same I use in hcfr with good results.

The correction file would have to be meter specific, I can't use one found somewhere on the net, right?

I guess a black background (-F) is recommended?

So change dispcal to dispwin and add the -E parameter (only there?) and I should be set?

I wanna get everything as right as possible before running the program, because every runthrough with 2500 samples will take approximately 1 1/2 - 2 hours.

You should get a good workflow going with a smaller set of patches first, it's easy to get the primaries/secondaries in order and decent gamut behavior with as low as 250 patches. Find what works and then do the long run.

How are you running patterns within madVR?

Also, I think I mentioned this in the other thread you have, the gamma plots indicate you may have contrast set too high. Do you see a color shift in white clipping patterns or perhaps one of the colors clipping prior to 235? What is your peak white reading on a smallish window?
Edited by zoyd - 6/14/13 at 3:05pm
post #332 of 1688
Peak white APL small is Y=120 (35ftL). I don't see a colorshift in clipping patterns and the colors all begin to clip at the same point (245-255 area), well into WTW. Contrast is at 50 out of 60 and the gamma at 40 looks exactly the same.

I'm running the after patterns with the AVS 709 mp4 files inside mpc-hc with lav decoders + splitter and madVR.
post #333 of 1688
Quote:
Originally Posted by monvo View Post

Gamma is all over the place (I used the 2.2 setting), the secondary colors are wrong and the greyscale is far from perfect.
I've precalibrated the display as good as I could with my bluray player, because they share the same input (AVR in the middle). The greyscale I archived with the 2point control on the display is better than this one.

Another suggestion, do grayscale/gamma/RGB saturations both with and without the 3dlut active so you can see what delta's are being created just by the 3dlut. Are you calibrating the video card in the process? There can be differences between running patterns through the video card and your DVD based calibrations so beware.
post #334 of 1688
What do you mean by calibrating the video card? I haven't calibrated again for the pc besides the bluray player, if that's what you mean.

Tomorrow I'll do a comparison, now is bed time.
post #335 of 1688
Your video card can alter the test patterns if it contains it's own calibration factors (gamma ramps) so you have to be careful when comparing PC to blu-ray player. You can recalibrate your display using PC test patterns as a starting point or you can try to match the video card generated response to your blu-ray player if you don't want to have two different sets of settings on your display.
post #336 of 1688
Gill, may I ask for a feature? If you're not the the one I should be asking then sorry. I'm using dispcalGUI and I want it to detect current gamma curves on startup and not reset to what was set there before. There are two goals to this:
- to be able to profile using curves created in other software
- to be able to offset with higher gamma on low IRE to compensate for the crushed blacks to make calibration better (update the current windows profile). Without that initial gamma curves a colorimeter isn't able to take readings on low IREs.
post #337 of 1688
Quote:
Originally Posted by zoyd View Post

Your video card can alter the test patterns if it contains it's own calibration factors (gamma ramps) so you have to be careful when comparing PC to blu-ray player. You can recalibrate your display using PC test patterns as a starting point or you can try to match the video card generated response to your blu-ray player if you don't want to have two different sets of settings on your display.

This is the comparison between bluray and pc, the pc running madVR with calibration and gpu gamma ramps disabled:


As you can see, the delta E between the two is mostly below 1, so I guess most of it is meter variance.
post #338 of 1688
Quote:
Originally Posted by monvo View Post

This is the comparison between bluray and pc, the pc running madVR with calibration and gpu gamma ramps disabled:


As you can see, the delta E between the two is mostly below 1, so I guess most of it is meter variance.

yes, that is similar to what I see for differences between the two so you do not need to calibrate your video card (dispcal step), just profile and link. Assuming you have the correct switches in the work flow you should get good results.
Edited by zoyd - 6/15/13 at 10:22am
post #339 of 1688
@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.

Of course it would also be possible to make this work with your "-C" switch. However, doing that would have several disadvantages compared to integrating direct support into dispcal/dispread:

(1) I'd have to create a special exe which reads your "-C" switch shell commands and feeds them to madVR.
(2) The user would have to copy that special exe to the ArgyllCMS folder to make the "-C" switch work nicely.
(3) You would lose some of the extra features my header offers, like showing a progress bar, disabling 3dlut processing, showing a message to the user etc...

If you have any questions, or any feature wishes, or if you want anything changed, just let me know...

For your interest, here's the full demo source code, to show you how easy it would be for you to integrate this directly into dispcal/dispread:
Code:
#include <windows.h>
#include "..\\..\\interfaces\\madVRTestPattern.h"

// ***************************************************************

double GrayRamp[11][3] =
  { {0.0, 0.0, 0.0}, {0.1, 0.1, 0.1}, {0.2, 0.2, 0.2}, {0.3, 0.3, 0.3},
    {0.4, 0.4, 0.4}, {0.5, 0.5, 0.5}, {0.6, 0.6, 0.6}, {0.7, 0.7, 0.7},
    {0.8, 0.8, 0.8}, {0.9, 0.9, 0.9}, {1.0, 1.0, 1.0} };

void MeasureTestPattern()
{
  // replace "Sleep()" with your measurement code
  Sleep(1000);
}

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
  if (!madVR_IsAvailable())
    MessageBox(0, "madVR network dll not found.", "Error", MB_ICONERROR);
  else
    if (madVR_ConnectDialog())
    {
      madVR_Disable3dlut();
      madVR_SetOsdText(L"measuring display, please wait...");
      madVR_ShowProgressBar(_countof(GrayRamp));
      for (int i1 = 0; i1 < _countof(GrayRamp); i1++)
      {
        if (!madVR_ShowRGB(GrayRamp[i1][0], GrayRamp[i1][1], GrayRamp[i1][2]))
        {
          MessageBox(0, "Test pattern failure.", "Error", MB_ICONERROR);
          break;
        }
        // sleep a bit to work around display input latency
        Sleep(50);
        MeasureTestPattern();
      }
      madVR_Disconnect();
    }

  return true;
}
post #340 of 1688
Found a test pattern bug in v0.86.4, updated to v0.86.5 now. I've now also added support for applying VideoLUTs via pixel shaders in the madVR rendering pipeline. The madVR test pattern interface now has a "madVR_SetDeviceGammaRamp()" API, similar to the win32 API.

I've done a comparison test with "dispcal", using the standard version shipping with ArgyllCMS, compared to a "hacked" version which renders test patterns via madVR and also loads VideoLUTs into madVR instead of into the GPU/OS. Here are the results:

"dispcal -R", standard version:
Code:
Effective LUT entry depth seems to be 8 bits

"dispcal -R", hacked version:
Code:
Effective LUT entry depth seems to be 11 bits

The dispcal LUT bitdepth test seems to be confused by madVR's dithering, though. It always reports something between 10 and 12 bits, even if I disable madVR's internal VideoLUT processing. As soon as I disable dithering in madVR, "dispcal -R" reports 8bit for madVR, too.

"dispcal -v -qh -g2.2", standard version:
Code:
Doing iteration 1 with 12 sample points and repeat threshold of 1.131371 DE
Maximum neutral error (@ 0.065376) = 1.025152 deltaE
Average neutral error = 0.564147 deltaE
Number of measurements taken = 17
Doing iteration 2 with 24 sample points and repeat threshold of 0.800000 DE
Maximum neutral error (@ 0.149071) = 0.777113 deltaE
Average neutral error = 0.458905 deltaE
Number of measurements taken = 32
Doing iteration 3 with 48 sample points and repeat threshold of 0.565685 DE
Maximum neutral error (@ 0.112547) = 0.554384 deltaE
Average neutral error = 0.371079 deltaE
Number of measurements taken = 90
Doing iteration 4 with 96 sample points and repeat threshold of 0.400000 DE
Maximum neutral error (@ 0.270920) = 0.868365 deltaE
Average neutral error = 0.378488 deltaE
Failed to meet target 0.400000 delta E, got worst case 0.494394
Number of measurements taken = 387

"dispcal -v -qh -g2.2", hacked version:
Code:
Doing iteration 1 with 12 sample points and repeat threshold of 1.131371 DE
Maximum neutral error (@ 0.600780) = 0.910872 deltaE
Average neutral error = 0.449099 deltaE
Number of measurements taken = 16
Doing iteration 2 with 24 sample points and repeat threshold of 0.800000 DE
Maximum neutral error (@ 0.799620) = 0.769273 deltaE
Average neutral error = 0.363566 deltaE
Number of measurements taken = 29
Doing iteration 3 with 48 sample points and repeat threshold of 0.565685 DE
Maximum neutral error (@ 0.084070) = 0.559845 deltaE
Average neutral error = 0.298248 deltaE
Number of measurements taken = 58
Doing iteration 4 with 96 sample points and repeat threshold of 0.400000 DE
Maximum neutral error (@ 0.335450) = 0.515840 deltaE
Average neutral error = 0.267182 deltaE
Number of measurements taken = 111

@Graeme, do these results make sense to you? It seems that applying the VideoLUT via pixel shaders inside of the madVR rendering pipeline does help accuracy. One thing I don't understand is the "Number of measurements taken". Why is that number so much lower when using the madVR hacked "dispcal"? Does the number of measurements taken depend on how accurate the results are?
post #341 of 1688
Sorry, I'm really busy right now with another project [ I have a "ghost" to get flying over the heads of a theater audience ], and can't really look into this until at least next week.
Quote:
Originally Posted by madshi View Post

@Graeme, do these results make sense to you? It seems that applying the VideoLUT via pixel shaders inside of the madVR rendering pipeline does help accuracy. One thing I don't understand is the "Number of measurements taken". Why is that number so much lower when using the madVR hacked "dispcal"? Does the number of measurements taken depend on how accurate the results are?

Yes, dispcal interacts with the display behaviour. When it's attempting to locate device values that result in target neutral values, quantization can frustrate any convergence on the goal. It's not smart enough to recognize that quantization is happening and that it's tried all possible values near the goal. So if quantization is reduced using dithering, it converges more quickly and smoothly.

It's not actually necessary to implement the calibration curves in MadVR from a quality perspective - using collink -a will have the same effect. There may be other reasons that this is useful, but off hand I don't have the time to think through what that might be.
post #342 of 1688
Quote:
Originally Posted by gwgill View Post

Sorry, I'm really busy right now with another project [ I have a "ghost" to get flying over the heads of a theater audience ], and can't really look into this until at least next week.

No problem at all. Good luck with that ghost... smile.gif

Quote:
Originally Posted by gwgill View Post

It's not actually necessary to implement the calibration curves in MadVR from a quality perspective - using collink -a will have the same effect.

Using "collink -a" makes sense. However, dispcal has to create the CAL file first. And during the refinement passes dispcal repeatedly calls GDI32's SetDeviceGammaRamp() which is often limited to rounded 8bit. This will probably hurt the resulting CAL file quality somewhat. If dispcal used the higher quality madVR_SetDeviceGammaRamp() for the refinement process, the final CAL file quality should be better (at least for use with "collink -a").
post #343 of 1688
Alright, I am just beginning to wrap my head around this. Before I invest some time and my limited brain power too much into this endeavor...a quick question: Can this be used to calibrate a Panasonic GT50 (North American) or only displays that allow for display control and such?

EDIT: I see that it can. This is going to take some thought before I decide if this is something I can do. I'm not sure what my video card is capable of given that I am using a 2012 Macbook Pro Retina and perform my calibrations via Windows 7 in Parallels 8.
Edited by HD-Master - 6/17/13 at 9:59am
post #344 of 1688
Thread Starter 
Quote:
Originally Posted by HD-Master View Post

Alright, I am just beginning to wrap my head around this. Before I invest some time and my limited brain power too much into this endeavor...a quick question: Can this be used to calibrate a Panasonic GT50 (North American) or only displays that allow for display control and such?

This workflow will work on ANY display. All you need is a HTPC and the software/hardware requirements listed in the first post.
post #345 of 1688
Quote:
Originally Posted by N3W813 View Post

Quote:
Originally Posted by HD-Master View Post

Alright, I am just beginning to wrap my head around this. Before I invest some time and my limited brain power too much into this endeavor...a quick question: Can this be used to calibrate a Panasonic GT50 (North American) or only displays that allow for display control and such?

This workflow will work on ANY display. All you need is a HTPC and the software/hardware requirements listed in the first post.

Thanks. I have a Macbook Pro w/ HDMI and Windows 7 via Parallels 8 and an i1D3.
post #346 of 1688
Thread Starter 
Just for clarification, the media must be played through a media player that supports MadVR video renderer in order for the color correction to be applied.
post #347 of 1688
I gave things a quick check. No issues with the media playing. The issue I have is that both the calibrate and calibrate & profile buttons are grayed out for some reason.
post #348 of 1688
Thread Starter 
DispcalGUI is probably not detecting your meter. Not sure if it works through Parallel.
post #349 of 1688
Wonderful thread! Thanks for info provided by all.
post #350 of 1688
Time to update the guide, isn't it ? smile.gif
post #351 of 1688
Thread Starter 
Quote:
Originally Posted by fallengt View Post

Time to update the guide, isn't it ? smile.gif

It is... updated. smile.gif
post #352 of 1688
Thanks!
Quote:
Originally Posted by N3W813 View Post

2013-06-18 - Replaced workflow with commands for ArgyllCMS tools only. Removed the use of DispcalGUI.
May I ask why?
post #353 of 1688
Thread Starter 
Quote:
Originally Posted by Elix View Post

Thanks!
May I ask why?

Wanted to take an unnecessary program out of the equation. There are too many options in DispcalGUI that I do not understand nor know exactly how they affect the resulting 3DLUT. With the direct ArgyllCMS command lines, I know exactly what options I'm using and I can get support directly from Graeme. smile.gif
post #354 of 1688
Quote:
Originally Posted by N3W813 View Post

Wanted to take an unnecessary program out of the equation. There are too many options in DispcalGUI that I do not understand nor know exactly how they affect the resulting 3DLUT. With the direct ArgyllCMS command lines, I know exactly what options I'm using and I can get support directly from Graeme. smile.gif

I think this is the best decision. Although dispcalgui provides a cute GUI, it has not been updated with the latest changes by Graeme, and wasn't designed for the purpose we are using it. Did anyone notify the author about this thread? Maybe would be interesting to see the results! biggrin.gif
post #355 of 1688
Quote:
Originally Posted by N3W813 View Post

It is... updated. smile.gif

Am I the only one who finds that there are added a masiv amount of grain?
post #356 of 1688
Thread Starter 
Quote:
Originally Posted by MSL_DK View Post

Am I the only one who finds that there are added a masiv amount of grain?

No grain here on 3 different displays using the exact command lines in the 1st post. Have you downloaded the latest beta files?
post #357 of 1688
Quote:
Originally Posted by N3W813 View Post

It is... updated. smile.gif
One more thing, how do I profile my field meter against my i1Pro using ArgyllCMS
post #358 of 1688
Thread Starter 
Quote:
Originally Posted by fallengt View Post

One more thing, how do I profile my field meter against my i1Pro using ArgyllCMS

Read doc/ccxxmake.html in the ArgyllCMS install folder. smile.gif

Once a ccmx file is created, add '-X [filename].ccmx' to dispread command.
Edited by N3W813 - 6/19/13 at 2:45pm
post #359 of 1688
Quote:
Originally Posted by N3W813 View Post

No grain here on 3 different displays using the exact command lines in the 1st post. Have you downloaded the latest beta files?

Yes I have ...

@gwgill and others.

When I add dispwin test.cal I see a difference in color and contrast on my desktop

When I run dispread -k test.cal I see no difference ... it is as if test.cal not being added ... I'm about to run dispread -K test.cal to see if it makes any difference to the final result ... I fails to achieve a satisfactory result ... grainy picture and too much red :-(

Code
Code:
dispwin.exe -v -d1 -c
dispcal.exe -v -d1 -m -qh -yn -X i1d3.ccss -t 6504 "-P0.49226006192,0.488372093023,3.3485915493" "-w0.312713,0.329016" -g 2.2 -o TVmtx.icm "SA5005.p2.2"
targen.exe -v -d3 -G -f2500 -g128 -c TVmtx.icm "madVR"
dispread.exe -v -k SA5005.p2.2.cal -yn -X i1d3.ccss "-P0.49226006192,0.488372093023,3.3485915493" "madVR"
colprof.exe -v -qh -bl -aX "madVR"
collink.exe -v -3m -qh -et -Et -Ib -G -iaw Rec709.icm madVR.icm EGEN_3DLUT.icm
dispwin.exe -v -d1 SA5005.p2.2.cal

Edited by MSL_DK - 6/20/13 at 12:24pm
post #360 of 1688
If you use "dispread -k" then you also need to use "collink -a". At least that is my understanding?
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS