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

MadVR - ArgyllCMS - Page 30

post #871 of 1684
Yes, on the same PC. madTGP is running in "fullscreen exclusive" mode on my second monitor with the rest of the desktop being displayed on the first.
post #872 of 1684
Thread Starter 
Quote:
Originally Posted by fhoech View Post


By the way, I'm currently troubleshooting a bothersome problem that sometimes happens when using madTGP through Argyll CMS (and only then! Argyll CMS own patch display seems to be unaffected). It seems sometimes the displayed patch will not update quick enough, so that the currently displayed color is measured again and thus the reading for that patch will be wrong. You can see this as extremely similar XYZ values in the TI3 file for consecutive different RGB numbers. E.g. from a TI3 file I recently measured:

I 'think' Graeme implemented an option to adjust the measure delay for both dispcal.exe and dispread.exe...not 100% sure though. I thought I've had read it in a thread somewhere.
post #873 of 1684
Quote:
Originally Posted by fhoech View Post

It seems sometimes the displayed patch will not update quick enough, so that the currently displayed color is measured again and thus the reading for that patch will be wrong.
Hmm, I had what sounds like a less severe version of this problem when I measured patches for my monitor across my local network on my laptop (since I only have one monitor, this allowed me to run the pattern generator in fullscreen and still see the commandline output). What happened was that the patch display delay would be measured as 0 ms, and as a result the delay before measuring the next patch would be too short, so measurements would get mixed with the previous patch (resulting in measurement errors). I worked around this by setting the environment variable ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS to 200.

Edit: Ah, I see N3W813 said the same thing just above. Didn't see there was a new page biggrin.gif But yes, it's an environment variable called ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS. Not the most elegant solution, but it worked for me at the time smile.gif
post #874 of 1684
Quote:
Originally Posted by fhoech View Post

Yes, on the same PC. madTGP is running in "fullscreen exclusive" mode on my second monitor with the rest of the desktop being displayed on the first.

frown.gif Can you reproduce the problem? Which GPU and OS are you using? And which GPU driver version?
post #875 of 1684
Quote:
Can you reproduce the problem?
Not at will. In a 600+ patches measurement, it's likely to occur atleast once though.
Quote:
Which GPU and OS are you using? And which GPU driver version?
This is a Windows 7 system with an nvidia GTX 465. Driver 327.23.
post #876 of 1684
Hi,
I have a very similar problem when I use image with hcfr with I1D3, after some gray scale reading the patch and the probe aren't in sincro and the reading are completly wrong.
I have a gt520 and windows 7.
Regards.
post #877 of 1684
Quote:
Originally Posted by TimHamburg View Post

should I try to get the Gamma with 3dlut more towards the BT.1886 curve HCFR shows me?

Hi Tim,

as Florian has already suggested you, try the BT1886 absolute 2.4 setting in dispcalGUI. ( I don't know well the updated version of dispcalGUI, but I think absolute 2.4 is equivalent to the option IB in collink, in which case it fits much better your JVC!

The relative option (Ib in collink) should help in keeping lower (and predictable) the overall brightness of poor contrast displays, when it's applied to them the BT1886 tone curve. But your JVC has plenty of contrast so using absolute 2.4 should result in a curve that perfectly follows the BT1886 ideal curve, so in your case giving an even more contrasty picture, with an overall lower brightness, which I think it's better in your white-walled room. Both option gives you clear details in shadows.

Hope to hear opinions from people more expert than me, but I'd say that with a JVC you should consider only the absolute option (again, provided it's the equivalent of -IB)
post #878 of 1684
Quote:
[...] I think absolute 2.4 is equivalent to the option IB in collink [...]
Yes, that is correct. 'absolute' = IB = 'technical' gamma, 'relative' = Ib = 'effective' gamma.
post #879 of 1684
I just released dispcalGUI 1.5.2.5 and have subsequently removed the snapshot files.

The most relevant changes towards the last snapshot (1.5.1.0):
  • Added patch sorting functionality to testchart editor.
  • Show profile self check info in the profile installation dialog.
  • Added a feature to check measurement files for suspicious measured values. This is very much experimental, but in my testing worked fairly well. This was developed in response to the occasional problems I was having with misreads when using madTPG. You can also use it to check existing measurement files (and profiles, if they contain embedded measurement data). Find it in the "Tools" menu.
  • Added two additional profile verification charts.
  • Updated testcharts and presets again: Optimized body centered cubic grid layouts of variable sizes with additional single channel steps. The "massive" chart variation is also back (2527 patches). In addition, for each size starting with the "very large" charts (994 patches), there are several preconditioned OFPS-based charts with the same amount of single channel steps and total patches. In my testing though, body-centered cubic grid based charts resulted in the lowest delta E (although not by any significant margin, the difference was around 0.1 -0.2 dE in favor of the BCC grid based ones. YMMV.)

http://dispcalgui.hoech.net/#download

Enjoy!
post #880 of 1684
@fhoech:

First of all, thanks for the new release! A few questions:

Based on your testing for profiling, which test chart do you recommend to create a high quality madVR 3DLut. The "madVR" test chart or the massive test chart for LUT profiles, optimized for 2.2 Gamma with Rec. 709 primaries?

I would also like to ask, could you still consider adding the -qu option to be selectable in the GUI for the dispcal reading?

In the 3Dlut creation apply calibration (vcgt) doesn't seem to be picked by default, I assume it's needed?

Is it intended that doing a dry run with the "calibrate and profile" button only creates the command line entries for dispcal? To get the entries for dispread I need to click 'profile only'.
post #881 of 1684
Quote:
Based on your testing for profiling, which test chart do you recommend to create a high quality madVR 3DLut. The "madVR" test chart or the massive test chart for LUT profiles, optimized for 2.2 Gamma with Rec. 709 primaries?
I'd use the madVR preset (which uses the "XXL" BCC chart, 1399 patches), but on the other hand if you don't mind waiting longer, you could also use one of the larger charts. In my testing OFPS (even preconditioned) was not superior to BCC grid layout (although I only tested patch counts of 1000 and up), but as I said YMMV. I don't think you go wrong with either BCC or OFPS, the differences are probably too small.
Quote:
I would also like to ask, could you still consider adding the -qu option to be selectable in the GUI for the dispcal reading?
I'm still a bit hesitant smile.gif The Argyll docs do state it's meant as a testing mode for a reason... but if you absolutely must have it, you can always enter it in the additional command line parameters for dispcal which should override anything you set in the GUI.
Quote:
In the 3Dlut creation apply calibration (vcgt) doesn't seem to be picked by default, I assume it's needed?
Hmm. If the profile contains a vcgt, this should be enabled automatically.
Quote:
Is it intended that doing a dry run with the "calibrate and profile" button only creates the command line entries for dispcal? To get the entries for dispread I need to click 'profile only'.
Yes, that is expected.
post #882 of 1684
Thread Starter 
Thanks for the update, Florian! smile.gif I may need to redo my calibration and see if I can get even lower dEs. biggrin.gif

Now just waiting for the profile verification task with integration of madTPG with 3DLUT. wink.gif
Quote:
Originally Posted by fhoech View Post

I just released dispcalGUI 1.5.2.5 and have subsequently removed the snapshot files.

The most relevant changes towards the last snapshot (1.5.1.0):
  • Added patch sorting functionality to testchart editor.
  • Show profile self check info in the profile installation dialog.
  • Added a feature to check measurement files for suspicious measured values. This is very much experimental, but in my testing worked fairly well. This was developed in response to the occasional problems I was having with misreads when using madTPG. You can also use it to check existing measurement files (and profiles, if they contain embedded measurement data). Find it in the "Tools" menu.
  • Added two additional profile verification charts.
  • Updated testcharts and presets again: Optimized body centered cubic grid layouts of variable sizes with additional single channel steps. The "massive" chart variation is also back (2527 patches). In addition, for each size starting with the "very large" charts (994 patches), there are several preconditioned OFPS-based charts with the same amount of single channel steps and total patches. In my testing though, body-centered cubic grid based charts resulted in the lowest delta E (although not by any significant margin, the difference was around 0.1 -0.2 dE in favor of the BCC grid based ones. YMMV.)

http://dispcalgui.hoech.net/#download

Enjoy!
post #883 of 1684
I actually tried using madtpg for regular calibration/profiling and it seem to be little bit faster and allow the use of qu with dispcalgui. Didn't do enough trial to say if it get lower de, but using argyll patch and the 54patch verify tool say the profile and calibration is good.
post #884 of 1684
Quote:
Originally Posted by fhoech View Post

I just released dispcalGUI 1.5.2.5 and have subsequently removed the snapshot files.

The most relevant changes towards the last snapshot (1.5.1.0):
  • Added patch sorting functionality to testchart editor.
  • Show profile self check info in the profile installation dialog.
  • Added a feature to check measurement files for suspicious measured values. This is very much experimental, but in my testing worked fairly well. This was developed in response to the occasional problems I was having with misreads when using madTPG. You can also use it to check existing measurement files (and profiles, if they contain embedded measurement data). Find it in the "Tools" menu.
  • Added two additional profile verification charts.
  • Updated testcharts and presets again: Optimized body centered cubic grid layouts of variable sizes with additional single channel steps. The "massive" chart variation is also back (2527 patches). In addition, for each size starting with the "very large" charts (994 patches), there are several preconditioned OFPS-based charts with the same amount of single channel steps and total patches. In my testing though, body-centered cubic grid based charts resulted in the lowest delta E (although not by any significant margin, the difference was around 0.1 -0.2 dE in favor of the BCC grid based ones. YMMV.)

http://dispcalgui.hoech.net/#download

Enjoy!

Really nice, I like the measurement file checker!

One small hitch I ran into when calibrating a display using the -E option (scenario 3 here) The current profiling step forces -k "filename.cal" but that generated an incorrect range for my display while -K "filename.cal" works fine when added as an overide argument. But this a pain because "filename" has to be manually entered for a new calibration.
Quote:
If the calibration file provided created using video range encoding (dispcal -E), then the -E option in dispread will be triggered automatically.
post #885 of 1684
Indeed, -K with a capital K is the correct usage when using madTPG.exe. It lets madVR apply the calibration to its output in high bit depth and in the correct way instead of relying on the video LUTs.
post #886 of 1684
Quote:
The current profiling step forces -k "filename.cal" but that generated an incorrect range for my display while -K "filename.cal" works fine when added as an overide argument.
When using madVR (madTPG), the argument will always be -K. Are you not using madTPG?
post #887 of 1684
Quote:
Originally Posted by fhoech View Post

When using madVR (madTPG), the argument will always be -K. Are you not using madTPG?

no, this is for the eeColor box feeding a 16-235 display.
Edited by zoyd - 10/24/13 at 6:55am
post #888 of 1684
So, the behavior between -K and -k is different with regards to level encoding? That's certainly unexpected. I always thought that the only difference between using -K instead of -k would be that the video LUT is not used by the former, but instead the test values are altered before being displayed (that's atleast what the documentation says).
post #889 of 1684
Quote:
Originally Posted by fhoech View Post

So, the behavior between -K and -k is different with regards to level encoding? That's certainly unexpected. I always thought that the only difference between using -K instead of -k would be that the video LUT is not used by the former, but instead the test values are altered before being displayed (that's atleast what the documentation says).

That's what I thought too and this may be just a quirk with my video card but when the calibration that is performed using dispcal -E is loaded into the card it scales everything sent to it to 16-235. So then if -k and -E are both set in dispread I get two scalings, one from loading the tables and one from modified patch values. if -K is used instead the tables don't get loaded (they are just applied to the scaled patch values) and everything is fine.
post #890 of 1684
Quote:
So then if -k and -E are both set in dispread I get two scalings
Ah, so that's what is going on smile.gifSeems like a quirk in dispread, it should probably not scale the values again if the cal file was created with dispcal -E. But the immediate solution should not be using -K, but to not use the dispread -E option when the cal file has been created with -E.

*edit*

Ok I was wrong, just tried it and dispread does the right thing regardless if -E is specified when the cal file already scales the values. So it seems indeed like a quirk specific to your system/setup.
Edited by fhoech - 10/24/13 at 9:02am
post #891 of 1684
Quote:
Originally Posted by fhoech View Post

Ah, so that's what is going on smile.gif Seems like a quirk in dispread, it should probably not scale the values again if the cal file was created with dispcal -E. But the immediate solution should not be using -K, but to not use the dispread -E option when the cal file has been created with -E.

yes but it's not an option, dispread automatically uses -E if the cal file was created with -E
post #892 of 1684
I just tried different combinations of -E, -k, -K on dispread (all using the same cal file created with dispcal -E).
As I don't have a display that would clip a 0-255 signal to 16-235, I had to work under the assumption that a correct interpreted -E parameter should lead to less bright whites, and brighter than normal blacks on my NEC.
*edit* seems I made a mistake somewhere. Redoing the tests now...
Edited by fhoech - 10/24/13 at 12:29pm
post #893 of 1684
It looks to me like dispread needs to disregard -E when -k or -K are present and contain a calibration file where -E was used - for dumb users like me.
post #894 of 1684
Ok, here are the results.
The native black and white luminance for my NEC at its current settings (no videoLUT) are 0.24 cd/m2 and 129 cd/m2 respectively.

First I created a cal file by running dispcal -gs -E.
Loading that calfile with dispwin results in reduced white (spotread reported 107 cd/m2) and increased black (measured at 0.83 cd/m2) as expected.

I then did a few runs with dispread.

dispread -K file.cal, dispread -k file.cal: black at 0.24 cd/m2, white at 129 cd/m2 = no scaling
dispread -E -K file.cal: Black at 0.83 cd/m2, white at 107 cd/m2 = black scaled (correctly), white scaled (correctly)
dispread -E -k file.cal: Black at 1.41 cd/m2, white at 88 cd/m2 = black scaled (incorrectly?/twice?), white scaled (incorrectly?/twice?)

So -E -k is indeed scaling incorrectly, and the implicit scaling when a cal file created by dispcal -E is used was not working, one has to specify -E, but then also -K needs to be used to get correct results, like you originally said. Seems like a bug in dispread.
post #895 of 1684
Quote:
Originally Posted by fhoech View Post


First I created a cal file by running dispcal -gs -E.

dispread -K file.cal, dispread -k file.cal: black at 0.24 cd/m2, white at 129 cd/m2 = no scaling

This is a problem because I think it means the calibration is not being applied when using -k.
post #896 of 1684
No the calibration is applied (you can easily verify this by calibrating to a whitepoint different than native), but at the wrong levels.
post #897 of 1684
Oh that's good. So as I understand it implicit -E is not working for either -k or -K and explicit -E is not working with -k?
post #898 of 1684
Thanks for the new improvements made in DispcalGUI wink.gif

I'm using DispcalGUI with a personal testchart (quite the same as N3W813, for the same reasons : pretty bad gamut on the JVC X35 - natively : 2500 OFPS, 17 multidimensional, 128 grey)
I succeeded to get rid of my whiter whites (above 235) which I was able to see a few days ago (I was using a white point too bright-blue as a starting point for calibrating the display)
Anyway, the problem remains about blacks. Whatever I choose a BT.1886 2.4 or pure power gamma, I get an increase in brightness on the first APL levels. Even if I set brightness setting a few clicks down on my JVC X35, the levels of 14-15-16 are clipping on a regular mapping test (ACS 709) frown.gif
I don't know how i could manage this thing and consequently, the lower intra-contrast ratio that occurs. Color accuracy is definitely better while the contrast is getting worse. frown.gif
Should i turn on Black point compensation (i don't think it works in the direction of keeping blacks low) or something else about regulating Black level in advanced options ?
Thank you for your help smile.gif
post #899 of 1684
Quote:
Originally Posted by zoyd View Post

Oh that's good. So as I understand it implicit -E is not working for either -k or -K and explicit -E is not working with -k?
Yes.

I may have found a workaround that spares you the hassle of supplying a -K parameter with filename in dispcalGUI:
  • Set -E as additional commandline option for dispcal.
  • DO NOT set -E or -K for dispread.
  • Create the calibration as usual (if you already have one created with dispcal -E, skip this step)
  • Make sure "settings" in dispcalGUI is set to "<current>"
  • Select "load calibration from file.." in the options menu and select the cal file created by dispcal -E.
  • Select "profile only". Embed calibration and do not reset video card gamma table.
post #900 of 1684
Thanks, that worked fine. I take that back, that workflow does produce the right levels for dispread but then you can't include the cal in the LUT because you don't want to modify levels in the end product. So for my work flow -E in dispcal must be followed by -E and -K in dispread if I want to include the grayscale calibration from dispcal in the final LUT.


edit:
One more update, after further testing the above does produce good gray scale and color correction if the scaling switches to collink are -et -En. TV scale input, normal scale output. Normally for the eeColor box they are -et -Et. However, even though the calibration works this way a strange side effect of this method is that level 235 gets stretched to 255 and boosts peak output at the display while black stays where it should.
Edited by zoyd - 10/26/13 at 7:45pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS