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

MadVR - ArgyllCMS - Page 32

post #931 of 1679
Quote:
Originally Posted by zoyd View Post

@Graeme

Don't know if you caught the discussion a couple pages back but Florian and I had trouble with the dispread -k and -K switches not implicitly using -E.
Florian provided a fix. It's in the current ArgyllCMS development source code snapshot.
post #932 of 1679
Hi everyone,
in these days I'm approaching to dispcalGUI. I'm not a calibrator expert, but I have some knowledge and I done a quite decent calibration of my 50VT60 with a i1 Display Pro.

I tried twice to create a profile with dispcalGUI, but both times the picture resulting was too dark - starting from 100 cd/m2 the result was around 50 cd/m2.

So I just wondering if there some kind of options to set up with plasma. Black and white level drift compensation could help? Other hints?
In particular I'm quite surprised that discalGUI uses 100% field patterns when with plasma is recommended to use 10% window patterns (APL or not). Is there a way to change the size of these patterns?


Thanks!
Edited by Speeder82 - 11/14/13 at 7:07am
post #933 of 1679
Quote:
Originally Posted by kasper93 View Post

Current dispcalGUI will load dispcal.cal to GPU videolut which is not recommended because it has lower processing quality than madVR. Hence -K parameter... Look at #909 post. I don't have time to test it right now, so I might be wrong. But take a look at Zoyd posts, everything is in there.
Not quite true. In the current version 1.5.3.1 of dispcalGUI, -K will always be used if using madTPG, so the workflow is an exact reproduction of the commandline-only flow afaik. The additional "don't use videoLUT" option that I added in the 1.5.5.0 snapshot is for the case where madTPG is not used.
Quote:
Originally Posted by Speeder82 View Post

I tried twice to create a profile with dispcalGUI, but both times the picture resulting was too dark - starting from 100 cd/m2 the result was around 50 cd/m2.

So I just wondering if there some kink of options to set up with plasma. Black and white level drift compensation could help? Other hints?
In particular I'm quite surprised that discalGUI uses 100% field patterns when with plasma is recommended to use 10% window patterns (APL or not). Is there a way to change the size of these patterns?
Hmm. The brightness will be lower if the requested whitepoint is different from the native whitepoint of the display. If it's a lot lower, the native whitepoint is probably far from the requested one. Btw, when using madTPG you have to set the field size in madTPG itself. If not using madTPG, you can simply resize the measurement window to the desired size prior to starting the measurements.
post #934 of 1679
Quote:
Originally Posted by fhoech View Post

Hmm. The brightness will be lower if the requested whitepoint is different from the native whitepoint of the display. If it's a lot lower, the native whitepoint is probably far from the requested one. .
Thank you for the hint to resize the window pattern.
Speaking of brightness, I'm quite sure that the whitepoint calibrated is around 6500K, the same I request to dispcal, but I used 10% window to calibrate and full field with dispcal so maybe the APL reduced the overall brightness with the latter.
post #935 of 1679
Quote:
Originally Posted by Speeder82 View Post

Thank you for the hint to resize the window pattern.
Speaking of brightness, I'm quite sure that the whitepoint calibrated is around 6500K, the same I request to dispcal, but I used 10% window to calibrate and full field with dispcal so maybe the APL reduced the overall brightness with the latter.

correct, never use full fields with plasma, keep them under 15% area.
post #936 of 1679
Quote:
Originally Posted by zoyd View Post

correct, never use full fields with plasma, keep them under 15% area.
Yeah, I know.. I configured dispcal and launched it without thinking about patterns.
Speaking of patterns.. is it more correct to use black background or around 20% like GCD patterns?
Thanks
post #937 of 1679
gray backgrounds are a better simulation of operating conditions during normal viewing than black backgrounds, 20% is a good choice.
post #938 of 1679
Ok, thank you.
Another questions:
- should I select the correction 'Spectral EDR for plasma' or leave it blank?
- Black and White leve drift compensation could be useful?

Thanks
post #939 of 1679
Yes, use the edr correction. B/w drift doesn't really matter
post #940 of 1679
Last but not least, should I use some specific i1 D3 correction matrix like you set up for HCFR or there's no need (or possibility) with dispcalGUI?

Thanks
post #941 of 1679
Only if you have constructed your own using the create matrix correction feature of dispcalgui which requires a spectrometer for reference, otherwise stick with the edr
post #942 of 1679

 

Noise with using madVR TPG

 

Hi,

I've been searching this whole thread for similar problems but couldn't find anything useful, so...

 

When using DispcalGUI with the standard Argyll TPG I get perfectly still test patterns. But when I use the madVR TPG with DispcalGUI I get such strange "noise" especially visible in dark patterns. It looks like artifacts in bad encoded Xvid-videos yet not with a normal refresh-rate but with a refresh rate of about 1 Hz, so it changes every second. It's like a thousand squares with slightly different shades of grey (or different luminance of colored patterns).

 

Has anyone else encountered that problem before or does anyone have ideas on what I could do about that?

 

Thanks.

post #943 of 1679

hi i got my i1 display pro so i give this a try

 

so i followed the instructions from the first page and run in an error.

Quote:

Command line:
  dispcal.exe
    -v2
    -dmadvr
    -c1
    -yn
    -qh
    -m
    "-w0.3127,0.329"
    -G2.4
    -f0
    -k0
    -A4.0
    "madVR 2013-11-14 0.3127x 0.329y Rec. 1886 S XYZLUT"


Setting up the instrument
dispcal: Error - new_disprd() failed with 'Instrument Access Failed'

 

so i tryed the cmd based one and got the same error.

 

Quote:
dispcal: Error - new_disprd() failed with 'Instrument Access Failed'

 

i found this : 

Quote:
Note that the Huey and i1 Display ProColorMunki Display and the (experimentally supported) ColorHug colorimeter appears as an HID (USB Human Interface Device Class) device, and hence will be assigned to the default MSWindows HID driver. You therefore don't need to install an Argyll usb system driver for these instruments, although it is possible to select the libusb0.sys driver as an alternative to the default HID driver.

i even tryed the argyll usb driver but i get the same error and i can't use my i1 display pro with the i1 profiler. i killed the x-rite process too...

 

i found some very old bug reports with "instrument access failed" but nothing new.

 

so i don't know what went wrong at all. an idea anyone? and this is the second pc i tried it

post #944 of 1679
Thread Starter 
Quote:
Originally Posted by mightyhuhn View Post

hi i got my i1 display pro so i give this a try
so i followed the instructions from the first page and run in an error.
so i tryed the cmd based one and got the same error.
i found this : 
i even tryed the argyll usb driver but i get the same error and i can't use my i1 display pro with the i1 profiler. i killed the x-rite process too...
i found some very old bug reports with "instrument access failed" but nothing new.
so i don't know what went wrong at all. an idea anyone? and this is the second pc i tried it

It looks like the software cannot access your meter hardware, most likely a driver issue. You can try the drivers provided by Spectracal. It can also be the hardware itself if it continues to fail on multiple computers. What OS are you running these machines?

http://color.spectracal.com/downloads
Quote:
Originally Posted by bmw525i View Post

Noise with using madVR TPG
When using DispcalGUI with the standard Argyll TPG I get perfectly still test patterns. But when I use the madVR TPG with DispcalGUI I get such strange "noise" especially visible in dark patterns. It looks like artifacts in bad encoded Xvid-videos yet not with a normal refresh-rate but with a refresh rate of about 1 Hz, so it changes every second. It's like a thousand squares with slightly different shades of grey (or different luminance of colored patterns).

This is madVR's dithering function at work and it is expected. Head over the the madVR's thread at Doom9 for explanation from Madshi. You will need to do a search for the specific posts.
http://forum.doom9.org/showthread.php?t=146228
post #945 of 1679
Quote:
It looks like the software cannot access your meter hardware, most likely a driver issue. You can try the drivers provided by Spectracal. It can also be the hardware itself if it continues to fail on multiple computers. What OS are you running these machines?


it works fine with the i1profiler software so the hardware should be fine. both pc are on win 7 x64.

i just installed the calman driver and resourecess but nothing changed. the i1 display pro still works with i1profiler and not with argyll.

the devie is still a hid so i have to anuelly reinstall the device?

Quote:
Note that the Huey and i1 Display Pro, ColorMunki Display and the (experimentally supported) ColorHug colorimeter appears as an HID (USB Human Interface Device Class) device, and hence will be assigned to the default MSWindows HID driver. You therefore don't need to install an Argyll usb system driver for these instruments, although it is possible to select the libusb0.sys driver as an alternative to the default HID driver.


so these informations are just outdated ?

post #946 of 1679
@mightyhuhn:

Your i1 Display Pro is pretty recent, right? X-Rite seems to have changed the firmware around, necessitating an ArgyllCMS update. Here's the relevant post on the Argyll CMS mailinglist: http://www.freelists.org/post/argyllcms/Unable-to-calibrate-using-Colormunki,1 (the post is about a similar problem with the ColorMunki Display, which is basically the same instrument)
post #947 of 1679

it's 2 days old yeah right.

 

to bad these are 64 bit updates these arn't working with madvr.

 

Quote:
failed to load madhcnet64.dll

 

it's working now but not with madtpg.

 

so thanks i think the next version of argyll will do the trick.

post #948 of 1679
The 32-bit binaries are a little further down in the same thread: http://www.freelists.org/post/argyllcms/Unable-to-calibrate-using-Colormunki,3
post #949 of 1679

thanks again but it still crashed.

Quote:

Session log: madVR 2013-11-14 0.345741x 0.358666y Rec. 1886 F-S XYZLUT.log

Working directory:
  c:\
   users\
    admini~1\
     appdata\
      local\
       temp\
        dispcalGUI-tzkhrn\

Command line:
  dispcal.exe
    -v2
    -dmadvr
    -c1
    -yn
    -ql
    -m
    "-w0.345741,0.358666"
    -G2.4
    -f0
    -k0
    -A4.0
    "madVR 2013-11-14 0.345741x 0.358666y Rec. 1886 F-S XYZLUT"


Setting up the instrument
Product Name:      i1Display3
Serial Number:     I1-13.A-02.163218.09
Firmware Version:  v1.03
Firmware Date:     05Jun12
...aborted.
Calibration has not been finished.

 

same error with the 32 bit version it is still saying this: http://abload.de/img/argyllerrorqadpd.png

i reinstall the hole argyll stuff again tomorrow and report back.

post #950 of 1679
Make sure that there are no xrite services running in the background.
post #951 of 1679
Quote:
same error with the 32 bit version it is still saying this: http://abload.de/img/argyllerrorqadpd.png
It seems it is still using the 64-bit version of Argyll CMS. Make sure to point it at the 32-bit ones (Menu File, Locate Argyll CMS executables).
post #952 of 1679
Quote:
Originally Posted by zoyd View Post

Only if you have constructed your own using the create matrix correction feature of dispcalgui which requires a spectrometer for reference, otherwise stick with the edr
Hi,
Yesterday I run dispcal with your advices and the result was much better, except that image was too red. Infact the red was oversaturated, the temperature was around 6000K and the CIE was all shifted to right (red).

It's the same problem that many users have with HCFR and this probe, issue managed with a correction matrix specific for i1 D3 that has your name - don't know if you known it smile.gif. So I thought something like that it has been created for dispcalGUI. Otherwise, is there a way to convert the .thc HCFR file to a filetype that dispcalGUI can read or insert manually the corrections?
post #953 of 1679
Quote:
Originally Posted by Speeder82 View Post

Quote:
Originally Posted by zoyd View Post

Only if you have constructed your own using the create matrix correction feature of dispcalgui which requires a spectrometer for reference, otherwise stick with the edr
Hi,
Yesterday I run dispcal with your advices and the result was much better, except that image was too red. Infact the red was oversaturated, the temperature was around 6000K and the CIE was all shifted to right (red).

It's the same problem that many users have with HCFR and this probe, issue managed with a correction matrix specific for i1 D3 that has your name - don't know if you known it smile.gif. So I thought something like that it has been created for dispcalGUI. Otherwise, is there a way to convert the .thc HCFR file to a filetype that dispcalGUI can read or insert manually the corrections?

Using the ccss correction should not have resulted in readings that were any different than not using one. dispcal should have an end result of D65 in either case, it doesn't care whether you are using a corrected probe or not and should adjust your calibration appropriately, so something went wrong. I'm skeptical that a D65 calibration achieved using a .ccss corrected probe is noticeably worse than a D65 calibration using a borrowed .ccmx corrected probe. They both measure within a couple of dE on my display but I've not looked into it extensively.

You can hand edit a .ccmx file and enter in the matrix values from HCFR if you want.
post #954 of 1679
Quote:
Originally Posted by zoyd View Post

You can hand edit a .ccmx file and enter in the matrix values from HCFR if you want.
Where can I find a .ccmx file and how can edit it? With a text editor?

The .ccss file is one thing and I used it in HCFR, the same file used by dispcalGUI; but it's insufficient to achieve a visual correct calibration with the i1D Pro, infact only with your correction matrix in HCFR I can obtain an almost correct grey scale, not reddish.
Edited by Speeder82 - 11/15/13 at 5:41am
post #955 of 1679
Download one from http://dispcalgui.hoech.net/colorimetercorrections/ , it's a plain text file
post #956 of 1679
Thank you!!
post #957 of 1679
What is the difference calibrating to srgb vs rec 1886(tone curve)?
post #958 of 1679
The sRGB curve is 2.4 gamma based but has a straight segment towards black, thus the overall effective gamma is around 2.2, and (atleast by default) black offset is all output (this is configurable though), and Rec. 1886 uses a 'technical' gamma of 2.4 with a black offset that is by default all input (parameters of the 1886 curve are also configurable, you could use a 2.2 gamma instead of 2.4).
(If you're interested in a more in-depth explanation of 'effective' vs 'technical' gamma and black output vs. input offset, see the dispcal documentation of the -g, -G and -f parameters.)

For a color-managed environment (e.g. when actually using the 3D LUT or ICC profile) it doesn't make a difference, because the source space tone response will be reproduced no matter what you choose during calibration. As I understand it, there is the possibility that using a calibration tone curve that doesn't 'compress' the RGB values towards black as much as a purely power-based curve improves the accuracy of the profiling slightly as it makes it easier for the characterization to assess the display response near black.
post #959 of 1679

still not working. it still need madHcNet64.dll

 

and ti's for sure the 32 bit version.

 

so this is wrong named, wrong complied or the 32 bit version really needs madHcNet64.dll for what ever reason

http://www.freelists.org/post/argyllcms/Unable-to-calibrate-using-Colormunki,3

post #960 of 1679
Quote:
Originally Posted by mightyhuhn View Post
 

still not working. it still need madHcNet64.dll

 

and ti's for sure the 32 bit version.

 

so this is wrong named, wrong complied or the 32 bit version really needs madHcNet64.dll for what ever reason

http://www.freelists.org/post/argyllcms/Unable-to-calibrate-using-Colormunki,3


It's a problem with that 32 bit version you get from this link! I don't know why but that version doesn't work for me either.

I had the same problem like you with my brand new i1 Display Pro :-)

 

So I compiled a 32 bit version of Argyll on my own (from the new source files from Graeme) that is working for me. If you want to give it a try, just send me a PM and I can give you the link to the files.

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS