or Connect
AVS › AVS Forum › Display Devices › Display Calibration › HCFR - Open source projector and display calibration software
New Posts  All Forums:Forum Nav:

HCFR - Open source projector and display calibration software - Page 44

post #1291 of 3446
Thread Starter 
Quote:
Originally Posted by vega509 View Post

sure can

That looks good, if you run ColorHCFR as a 32bit application (maybe there is some sort of compatibility mode you can turn on?) it should work.
post #1292 of 3446
Quote:
Originally Posted by zoyd View Post

That looks good, if you run ColorHCFR as a 32bit application (maybe there is some sort of compatibility mode you can turn on?) it should work.

tried all the way back to winxp sp3. getting the error
post #1293 of 3446
Thread Starter 
Quote:
Originally Posted by vega509 View Post

tried all the way back to winxp sp3. getting the error

That's the error you get when the winusb driver is not being used to open the port. I'll have to get hold of a win7 machine and find a driver installation that works.
post #1294 of 3446
Quote:
Originally Posted by zoyd View Post

That's the error you get when the winusb driver is not being used to open the port. I'll have to get hold of a win7 machine and find a driver installation that works.

you may want to look at how v 3.0.0.0 handled the i1pro.

thanks zoyd
post #1295 of 3446
Hello John,

I´m in trouble getting my Spider4 not detected by the hcfr software

I have installed HCFR 3.0.4.0
I running Win7 64bit.
runned : spyd4en.exe
I finally created a spyd4cal.bin (folder: user/roaming/color)
- how gonna use that ..bin?
stil in the HCFR the spyder is not to choose
??

followed those rules
dont connect the spyder
install datacolor software,
installed HCFR,
executed the spyd4en.exe (double click)
File spyd4cal.bin created finally there: c:\\Users\AppData\Roaming\color\
reinstalled Datacolor
pluged spyder4 into USB
deinstalled the spyder4 driver
unpluged and pluged in the spyder4
found the spyder in the device manager...
cant update the driver with the hcfr driver (where to find????)
restarted the pc several times
in the HCFR software no spyder to chose.
the spyder driver is telling me:
C:\Windows\system32\Drivers\dccmtr.sys
C:\Windows\system32\WdfCoinstaller01001.dll
Port_#0002.Hub_#0004

this does not work:
http://sourceforge.net/p/hcfr/wiki/Spyder%204/
cd c:\program files (x86)\HCFR Calibration\Tools



This drives me crazy, just one little step before beeing able to start first calibration

I hope you could help me.
Thanks smile.gif
post #1296 of 3446
Quote:
Originally Posted by zoyd View Post

I made a change in the D3 meter code that has stabilized it quite a bit. Simply setting the baseline integration time to a larger value (1.5 sec which is the default for CM for low light conditions) did the trick. I don't know anything about git and merging in new code etc. so here is a standalone package with the change.



edit:

Made a proper installation package:

HCFRsetup.exe


Can we run the old and new version on the same PC to compare? HCFR runs fine from a folder without proper installation?

thx

bob
post #1297 of 3446
Thread Starter 
Quote:
Originally Posted by spongebob View Post

Can we run the old and new version on the same PC to compare? HCFR runs fine from a folder without proper installation?

thx

bob

yes, no problem.
post #1298 of 3446
Quote:
Originally Posted by zoyd View Post

I made a change in the D3 meter code that has stabilized it quite a bit. Simply setting the baseline integration time to a larger value (1.5 sec which is the default for CM for low light conditions) did the trick. I don't know anything about git and merging in new code etc. so here is a standalone package with the change.

edit:

Made a proper installation package:

HCFRsetup.exe
Hey Zoyd,

I'll install this on my Win7/64 machine and see if it works with the i1Pro.

Does this version include the latest (post 3.0.0.4 release) i1Pro code that JohnAd had in Git? I compiled and have been using some of his later 3.0.0.4+ code and it works for the i1Pro, but JohnAd didn't release it because of issues with simultaneously connected meters.

-JD
post #1299 of 3446
Thread Starter 
yes, this is the current 3.0.4.0 source from sourceforge so multiple meters work fine after making the driver update. I used i1pro 2 and D3 at the same time without any issues but it was on winxp.
post #1300 of 3446
I'm getting the same error that Vega509 displayed above. I'm using the libusb instead of the winusb driver, but that shouldn't matter:


Did you download the code from the Zip file or Git? The 3.0.4 version I compiled was from the latest files in Git and that was where the i1Pro was working, but not with simultaneous meters.
post #1301 of 3446
I´m in trouble getting my Spider4 not detected by the hcfr software

It works rolleyes.gif

what was my trouble?

CMD
I followed now the more clearer steps down to the folder
C:
cd program files (x86)
cd HCFR Calibration
cd Tools
make a dir to check if you are in the right folder!
execute just typing the following!

spyd4en.exe –v -S u

(here it was important that there are blanks after the .exe and each other...... .exe_-v_S_-u)

Here I could clearly see that my PC is writing something into the machine
following steps:
- rebooting
- deinstalled Datacolor, Spyder 4
- pluged in Spyder4 again
- in the hardwaremanager, install the right driver
?
Where?
- Folder: Windows (C:) / Program Files (x86) / HCFR Calibration / Drivers

Thats it
my mistake was that I typed always in CMD "Programm" instead of Program

Now my HCFR is working with the spyder very easily
post #1302 of 3446
Thread Starter 
I git cloned the code. the i1 pro requires that winusb be loaded along with libusb-1.0A in the version that supports multiple meters.
Edited by zoyd - 1/29/13 at 2:45am
post #1303 of 3446
> I made a change in the D3 meter code that has stabilized it quite a bit.
> Simply setting the baseline integration time to a larger value (1.5 sec
> which is the default for CM for low light conditions) did the trick. I don't
> know anything about git and merging in new code etc. so here is a
> standalone package with the change.

I'm sure it did, but you're throwing away one of the major advantages of the D3, it's speed.

It would help if you could download the latest ArgyllCMS development snapshot at http://www.argyllcms.com/Argyll_dev_src.zip and check the stability on your test case using spotread (ie. "spotread -yr"). I've tweaked the refresh display code to up the integration time to 0.4 seconds minimum, and also change the crossover from period to frequency measurement mode to improve consistency for refresh type displays such as plasmas. If you don't want to or can't compile the source, you can find an MSWin binary at http://www.argyllcms.com/disptools.win32.zip. [ It's always better to try and fix these sorts of problems upstream.]
post #1304 of 3446
Thread Starter 
Quote:
Originally Posted by gwgill View Post

> I made a change in the D3 meter code that has stabilized it quite a bit.
> Simply setting the baseline integration time to a larger value (1.5 sec
> which is the default for CM for low light conditions) did the trick. I don't
> know anything about git and merging in new code etc. so here is a
> standalone package with the change.

I'm sure it did, but you're throwing away one of the major advantages of the D3, it's speed.

It would help if you could download the latest ArgyllCMS development snapshot at http://www.argyllcms.com/Argyll_dev_src.zip and check the stability on your test case using spotread (ie. "spotread -yr"). I've tweaked the refresh display code to up the integration time to 0.4 seconds minimum, and also change the crossover from period to frequency measurement mode to improve consistency for refresh type displays such as plasmas. If you don't want to or can't compile the source, you can find an MSWin binary at http://www.argyllcms.com/disptools.win32.zip. [ It's always better to try and fix these sorts of problems upstream.]

Speed is still quite good but I agree that further optimization is beneficial. I'll fold the Argyll changes into the HCFR d3 code and test it directly.

Any comment on the i1pro driver issue? In John's multimeter argyll wrapper the only way I can get the usb "open" api to work is by forcing the winusb driver to load ( WINUSBCO_DEV in the inf) I saw you made a note somewhere about the i1pro not being happy with winusb but so far I have not seen problems operationally.
Edited by zoyd - 1/29/13 at 4:43am
post #1305 of 3446
Quote:
Originally Posted by zoyd View Post

Speed is still quite good but I agree that further optimization is beneficial. I'll fold the Argyll changes into the HCFR d3 code and test it directly.

Any comment on the i1pro driver issue? In John's multimeter argyll wrapper the only way I can get the usb "open" api to work is by forcing the winusb driver to load ( WINUSBCO_DEV in the inf) I saw you made a note somewhere about the i1pro not being happy with winusb but so far I have not seen problems operationally.

Folding the latest driver improvements in might not be entirely straightforward, since I've made a lot of changes to the instrument access library API aimed at improving its operation in a GUI environment, although it would be possible with some effort to extract the specific i1d3 stuff and apply it back.

I'm not aware of any i1pro issues - yes there was a problem a while back with having more than one instrument open at a time, but from the feedback I got from JohnAd I thought that had been sorted out. The way ArgyllCMS is structured it's not actually possible to open more than one instrument from a single application (although perfectly possible to open more than one instrument using more than once instance of an application), so it's not easy for me to test this particular aspect.

A lot of the issues people have, seem to be in not understanding that ArgyllCMS needs to use different system USB drivers than the instrument manufacturers software. I'm not sure how clear the HCFR doco is on that. I've certainly put a step by step in the Argyll documentation: http://www.argyllcms.com/doc/Installing_MSWindows.html
post #1306 of 3446
Quote:
Originally Posted by zoyd View Post

I git cloned the code. the i1 pro requires that winusb be loaded along with libusb-1.0A in the version that supports multiple meters.
Okay, I'll try that if I have time tonight. I have 32 and 64 bit Windows 7 machines to test this on if needed.
post #1307 of 3446
Quote:
Originally Posted by jdbimmer View Post

Okay, I'll try that if I have time tonight. I have 32 and 64 bit Windows 7 machines to test this on if needed.
I installed the winusb driver on Win 7 64 from the HCFR libusb folder and the i1Pro displayed a "can not start device" message in Device Manager. I couldn't access it from any of the HCFR versions, so I reverted back to libusb.

Edit: Same error in Win 7 32 bit. My guess is the problem is with the inf file.
Edited by jdbimmer - 1/29/13 at 9:15pm
post #1308 of 3446
Thread Starter 
Quote:
Originally Posted by gwgill View Post


I'm not aware of any i1pro issues - yes there was a problem a while back with having more than one instrument open at a time, but from the feedback I got from JohnAd I thought that had been sorted out.

There is some esoteric usb com problem with the i1pro. The current status is:

1. Initial version 3.0.0.0 of the argyll wrapper code works fine with the i1pro but supports only one meter at a time and doesn't support the d3 or colormunki.
2. Versions >3.0.0.0 which support multiple meters (including the d3/colormunki) but throws an error in icoms when trying to open the i1pro. Spotread works fine.
3. If I modify the i1pro inf to include the standard winusb.dll as a required device driver everybody's happy but so far working on win32xp only.
Edited by zoyd - 1/30/13 at 4:15am
post #1309 of 3446
Quote:
Originally Posted by zoyd View Post

There is some esoteric usb com problem with the i1pro. The current status is:

1. Initial version 3.0.0.0 of the argyll wrapper code works fine with the i1pro but supports only one meter at a time and doesn't support the d3 or colormunki.
2. Versions >3.0.0.0 which support multiple meters (including the d3/colormunki) but throws an error in icoms when trying to open the i1pro. Spotread works fine.
3. If I modify the i1pro inf to include the standard winusb.dll as a required device driver everybody's happy but so far working on win32xp only.

If spotread works fine, then there is something particular in either the way HCFR is using instlib, or some difference to the ArgyllCMS V1.4 code. Is there a specific error message in the 2nd case ? (ie. instlib debug output). I'm not sure why switching to winusb would make any difference, nor why winusb would be restricted to win32xp (certainly winusb is used for some instruments in ArgyllCMS V1.4 on 32 and 64 bit Vista & Win7).
post #1310 of 3446
Thread Starter 
yes, the specific error is:
Code:
libusb:debug [unsupported_open] unsupported API call for 'open'


Some googling led me to force loading of the winusb driver, particularly this post

"Remember that when using libusb on
Windows (unless you are using a WinUSB WCID device [1] on Windows 8),
you must install a relevant compatible driver, which currently means
WinUSB for libusb-1.0."

and

"USB_API_UNSUPPORTED (which is not an error code, but an API value used
internally) simply means that, while a device was found, it is not using
the WinUSB driver so we can't access it."
post #1311 of 3446
Quote:
Originally Posted by zoyd View Post


3. If I modify the i1pro inf to include the standard winusb.dll as a required device driver everybody's happy but so far working on win32xp only.


NTx86.5.1_Device = "LIBUSB0_DEV" ; 32 bit WinXP
shouldn't that actually be:

NTx86.5.1_Device = "WINUSBCO_DEV" ; 32 bit WinXP

works like a charm
Edited by Losha - 1/30/13 at 11:36am
post #1312 of 3446
Thread Starter 
Quote:
Originally Posted by Losha View Post

NTx86.5.1_Device = "LIBUSB0_DEV" ; 32 bit WinXP
shouldn't that actually be:

NTx86.5.1_Device = "WINUSBCO_DEV" ; 32 bit WinXP

works like a charm

we know, that was established back in this post. The inf in that package is already modified so that the i1pro will work with winxp using the winusbco_dev driver line.
post #1313 of 3446
Quote:
Originally Posted by zoyd View Post

yes, the specific error is:
Code:
libusb:debug [unsupported_open] unsupported API call for 'open'

Some googling led me to force loading of the winusb driver, particularly this post

"Remember that when using libusb on
Windows (unless you are using a WinUSB WCID device [1] on Windows 8),
you must install a relevant compatible driver, which currently means
WinUSB for libusb-1.0."

I'm not sure how HCFR is packaged - in the ArgyllCMS V1.4 package the Microsoft WinUSB installables for 32 and 64 bit are included and used in the driver instalation.
Quote:
Originally Posted by zoyd 
"USB_API_UNSUPPORTED (which is not an error code, but an API value used
internally) simply means that, while a device was found, it is not using
the WinUSB driver so we can't access it."

Hmm. It's hard to know why this is the error - it means that the libusb code couldn't identify the system driver being used by the device, which is strange because it will recognize WinUBS, libusb0 and HidUsb.

[ArgyllCMS V1.5 beta drops libusb and WinUSB completely, and uses the libusb-win32 (libusb0) system driver, and simplifies the device setup by using a single .inf file.]
post #1314 of 3446
Thread Starter 
Quote:
Originally Posted by gwgill View Post

I'm not sure how HCFR is packaged - in the ArgyllCMS V1.4 package the Microsoft WinUSB installables for 32 and 64 bit are included and used in the driver instalation.
Hmm. It's hard to know why this is the error - it means that the libusb code couldn't identify the system driver being used by the device, which is strange because it will recognize WinUBS, libusb0 and HidUsb.

[ArgyllCMS V1.5 beta drops libusb and WinUSB completely, and uses the libusb-win32 (libusb0) system driver, and simplifies the device setup by using a single .inf file.]


HCFR uses the ArgyllCMS V1.4.0 libusb1 folder for driver installation and most of the meters have infs that load winusb_dev but the i1pro.inf looks like this:
Code:
; These 8 determine which type of driver is installed & used for each platform:
; LIBUSB0_DEV   libusb0.sys kernel driver (Win2K to Win7, signing needed on 64 bit)
; PTLIBUSB0_DEV ptlibusb0.sys kernel driver (Win2K to Win7, signed by PRUFTECHNIK)
; WINUSBCO_DEV  Install & use latest WinUSB kernel driver (WinXP to Win7)
; WINUSB_DEV    Use installed WinUSB kernel driver (Vista to Win7) 

Default_Device      = "LIBUSB0_DEV"           ; Default
NTx86.5.0_Device    = "LIBUSB0_DEV"           ; 32 bit Win2K
NTx86.5.1_Device    = "LIBUSB0_DEV"           ; 32 bit WinXP
NTamd64.5.1_Device  = "PTLIBUSB0_DEV"         ; 64 bit WinXP
NTx86.6_Device      = "LIBUSB0_DEV"           ; 32 bit Vista
NTamd64.6_Device    = "PTLIBUSB0_DEV"         ; 64 bit Vista
NTx86.6.1_Device    = "LIBUSB0_DEV"           ; 32 bit Win7
NTamd64.6.1_Device  = "PTLIBUSB0_DEV"         ; 64 bit Win7

I also tried the V1.5 inf and get the same error as above.
post #1315 of 3446
Quote:
Originally Posted by zoyd View Post


HCFR uses the ArgyllCMS V1.4.0 libusb1 folder for driver installation and most of the meters have infs that load winusb_dev but the i1pro.inf looks like this:
Code:
.
.

If HCFR is using the same instlib code as ArgyllCMS V1.4, then I don't understand how it is possible for spotread to work and HCFR to get this type of error. There must be some inconsistency between the instlib and/or libusb code in HCFR to cause this. Having both on the same machine provides the perfect situation to track down what that difference is :-)
Quote:
Originally Posted by zoyd View Post

I also tried the V1.5 inf and get the same error as above.

That's never likely to work - V1.5b doesn't install WinUSB and doesn't install libusb1A.dll, etc.

There is some cross compatibility if the libusb0.sys is the driver used by an instrument, but idealy the old V1.4 driver should be removed and the V1.5b one freshly installed, and the V1.5b instlib/applications used with it.
post #1316 of 3446
Thread Starter 
Quote:
Originally Posted by gwgill View Post

There must be some inconsistency between the instlib and/or libusb code in HCFR to cause this. Having both on the same machine provides the perfect situation to track down what that difference is :-)

yep, when John updated the libusb code to handle multiple meters something broke.
post #1317 of 3446
Quote:
Originally Posted by zoyd View Post

yep, when John updated the libusb code to handle multiple meters something broke.

maybe a question that has been answered already, but why not go back to the windows / x-rite drivers like version 2 had?
post #1318 of 3446
Thread Starter 
Because the point of creating an open source project was so that the code could be published (no copyright issues) for everyone to work on.
post #1319 of 3446
Quote:
Originally Posted by vega509 View Post

maybe a question that has been answered already, but why not go back to the windows / x-rite drivers like version 2 had?

You can do anything you like or course - if you can rustle up the expertise and time to do it :-)

To use the manufacturers drivers entails someone R.E. the API's to their driver system and testing and maintaining the result. While some of the older instruments have known DLL API's, the newer instruments have differences, and are harder to access if you use X-Rite's install, since they have moved to a server architecture. Some hybrid Argyll/OEM instrument access approach is theoretically possible, but it would be ugly to organize.

The fact that ArgyllCMS spotread works indicates that there is probably a trivial bug in the HCFR code in regard to the i1pro. If no-one is prepared to look into that, then I see little hope of proceeding with a larger task such as reverting to using the manufacturers drivers.
post #1320 of 3446
Quote:
Originally Posted by zoyd View Post

I made a change in the D3 meter code that has stabilized it quite a bit. Simply setting the baseline integration time to a larger value (1.5 sec which is the default for CM for low light conditions) did the trick. I don't know anything about git and merging in new code etc. so here is a standalone package with the change.



edit:

Made a proper installation package:

HCFRsetup.exe

awesome! I'll definitely play around with it this weekend and report back.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › HCFR - Open source projector and display calibration software