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 14

post #391 of 3446
Thread Starter 
Quote:
Originally Posted by JohnAd View Post

For those having issues I've uploaded a new version with no real changes (except maybe around the timing) but with some extra logging and crash handling

https://sourceforge.net/projects/hcf...ndows/3.0.2.0/

If those with an i1Pro/multiple meter issues could send me the stderr.log and any minidump.dmp files that are in the c:\\program files\\HCFR Calibration Directory.

By the way thanks a lot for all the testing and help so far.

John


Here is the output of stderr for the i1pro problem:

Code:
usb_get_paths about to look through devices:
usb_check_and_add() called with VID 0x1d6b, PID 0x1
Get config desc. 0 failed
usb_check_and_add() called with VID 0x971, PID 0x2000
usb_check_and_add() found known instrument
icoms: There don't appear to be any serial ports
i1pro: About to init coms
i1pro: About to init USB
icoms: About to set usb port characteristics
icoms: About to open the USB port, tries 0
icoms: USB port needs opening
icoms: About to open USB port 'usb:/bus0/dev2/ (GretagMacbeth i1 Pro)'
Opening USB port 'usb:/bus0/dev2/ (GretagMacbeth i1 Pro)' config 1 failed (Other error) (Permissions ?)icoms: delete called
post #392 of 3446
Quote:
Originally Posted by zoyd View Post

Here is the output of stderr for the i1pro problem:

Code:
Opening USB port 'usb:/bus0/dev2/ (GretagMacbeth i1 Pro)' config 1 failed (Other error) (Permissions ?)icoms: delete called

Thanks. I think I've worked out what causes that one, some memory wasn't zeroed before use.

I'm not sure about the crash yet though so if sombody can try the 2 meter thing and send me the crash log that would be great.

John
post #393 of 3446
Quote:
Originally Posted by Bluescale View Post

Hi John,

Can you explain what you mean by the bolded part?

Sorry for not being clearer, I'm part way though trying to understand why the images sometimes don't finish displaying properly while the reading are being taken. I've made some fixes but they are not fully tested.

John
post #394 of 3446
Quote:
Originally Posted by DaGamePimp View Post

Noticing the Spyder 4 takes a much longer time between low level (< 30 IRE) read refreshes but blasts through the upper level reads like lightning. Where as the Spyder 3 is pretty consistent speed wise on everything except full field black (0 IRE). I understand the logic behind the low level reads taking longer just find it odd that the meters vary so much.

Is this something with HCFR or is this simply the design of the meter?

Possibly a bit of both, the way the colorimeters seem to work is that they need to "collect" as much light as possible during each read without going over some limit or saturating, they way this is controlled is to take a quick reading to get an idea of light level then calculate a sensible read time then do the real reading. The logic for this varies a lot by meter as there are various issues for each one and Graeme is contantly revising.improving the code to deal with issues.

Quote:
Originally Posted by DaGamePimp View Post

* Oh and I noticed that a 0 IRE read during greyscale will sometimes crash HCFR 3.0.1.0 when using the Spyder 4.

If that happens with 3.0.2.0 please send me the minidump.dmp file?

John
post #395 of 3446
Quote:
Originally Posted by jdbimmer View Post

If you have a Chroma 5, try it, it might work as an i1Display1 using the Argyll drivers. I have this Monaco Optix http://www.argyllcms.com/doc/instruments.html#mox and it works with the Argyll drivers, and the hardware looks exactly like a Chroma 5, so maybe it will work??: http://catalogs.infocommiq.com/avcat...-rite-chroma-5

A very good point, would be handy to know the USD Vendor and device ID (this instructions for getting these from the device manager should be above).

Thanks

John
post #396 of 3446
Invisible glitch with the last line of data in Win7 and stayed.
post #397 of 3446
I finally used my i1D3 last night... Win7 x64... HCFR 3.0.1.0...

No issues as far as recognizing the meter at all. One comment that slimer777 made "For the i1D3, I use the preinstalled xrite driver and HCFR simply detects it and works fine." Not sure what version of Windows slimer was using but at least with Windows 7, you don't need to preinstall any xrite driver.

Had same problem as DaGamePimp... program abruptly closed during 0 IRE read... but just the first time. Reran HCFR and it was fine. Will install 3.0.2.0 and if it happens again, I'll send the data.

On the "Sensor selection" screen, "How do you want to calibrate the sensor?" is inactive, which is correct. But on the "Argyll Meter Property Page" the "Calibrate meter" bar is active... unsure if that's right.

Also on the "Argyll Meter Property Page" the display type defaults to "i1D3 Non-Refresh display" which is where I left it. Noticed there is also an option to select "i1D3 Refresh display". Not sure what the difference is or if I'll ever need to change it.

Overall, for a first time calibration, I was more than pleased. Before the calibration, Color Temp was too high, Blue was too high... neither of those where even close... and Red was slightly too low. Since the calibration, although not perfect so I need to tweak, but the results are way better than they've ever been and it was noticeable watching TV afterward.

Your timing with updating HCFR couldn't have been better, with me anyway, as I was returning the i1D3 when I was lead to this thread the day you released 3.0.0.0. Thanks.
post #398 of 3446
Quote:
Originally Posted by 65Cobra427SC View Post


....Also on the "Argyll Meter Property Page" the display type defaults to "i1D3 Non-Refresh display" which is where I left it. Noticed there is also an option to select "i1D3 Refresh display". Not sure what the difference is or if I'll ever need to change it.


.



Same here, I've always left it at default. I like to know the difference also.
post #399 of 3446
Quote:
Originally Posted by 65Cobra427SC View Post

On the "Sensor selection" screen, "How do you want to calibrate the sensor?" is inactive, which is correct. But on the "Argyll Meter Property Page" the "Calibrate meter" bar is active... unsure if that's right.

I think there is some confusion introduced by the translation here, there are 2 seperate processes that both get translated back to calibrate.

On the meter selection list the calibration files are matrix adjutments to compensate for drift and so on, on the argyll page calibration button calls any meter specific calibration functionality, for example locking on to the crt refresh rate or measuring a white tile.

Over time I'll try and get the English UI a bit more sensible.

Quote:
Originally Posted by 65Cobra427SC View Post

Also on the "Argyll Meter Property Page" the display type defaults to "i1D3 Non-Refresh display" which is where I left it. Noticed there is also an option to select "i1D3 Refresh display". Not sure what the difference is or if I'll ever need to change it.

The refresh display is for crt/plasma displays with a detectable refresh rate.
post #400 of 3446
John,

I was under the impression that meter "calibrate" was for a totally black read (not the display 0 IRE) and not a white tile?

Is this something specific to the Argyll drivers?

Thank You,
Jason
post #401 of 3446
Quote:
Originally Posted by DaGamePimp View Post

John,

I was under the impression that meter "calibrate" was for a totally black read (not the display 0 IRE) and not a white tile?

Is this something specific to the Argyll drivers?

Thank You,
Jason

It depends on the meter, the colorimeters tend to have crt refresh rate fix and black calibrations, the spectros tend to have tiles/special modes.

John
post #402 of 3446
Quote:
Originally Posted by JohnAd View Post

The refresh display is for crt/plasma displays with a detectable refresh rate.

Now that's interesting...I'll have to see what sort of results I get if I change this setting.
post #403 of 3446
Quote:
Originally Posted by 65Cobra427SC View Post

Had same problem as DaGamePimp... program abruptly closed during 0 IRE read... but just the first time. Reran HCFR and it was fine. Will install 3.0.2.0 and if it happens again, I'll send the data.

I did a brief calibration run last night, and had HCFR crash on me a couple times during a 0 IRE read. Both times the meter was in continuous mode, and went from a very bright read screen (say 80 or 100 IRE) to 0. The sudden change caused it to terminate.
post #404 of 3446
Quote:
Originally Posted by JohnAd View Post

It depends on the meter, the colorimeters tend to have crt refresh rate fix and black calibrations, the spectros tend to have tiles/special modes.

John

Indeed, I just was not aware HCFR had spectro support.

I have yet to own a spectro (considering one for profiling) so I have always done the black read for meter calibration (had me scared there for a minute).

Thanks again!
Jason
post #405 of 3446
Quote:
Originally Posted by JohnAd View Post

A very good point, would be handy to know the USD Vendor and device ID (this instructions for getting these from the device manager should be above).

Thanks

John

The Monaco Optix is:
Manufacturer: Sequel Imaging
USB\\VID_0670&PID_0001&REV_0519
USB\\VID_0670&PID_0001

Now we need someone with a Chroma 5 to compare and/or try it.

Also, the view images timing issue seems to be resolved in 3.02
post #406 of 3446
DaGamePimp,

Quote:


Ok, had to rename folder since it only searched for express or pro and mine is elite package

Any chance of letting me know which folder and how you called it, please? I'm in the same boat, and don't want to make a mistake.

Thanks-Vince
post #407 of 3446
2stroker,

If Win7-64... c:\\program files (x86)\\Datacolor\\Spyder4Elite\\

Rename "Spyder4Elite" folder to "Spyder4Pro" and it should work.

Don't forget you have to remove the Datacolor driver and install the supplied Spyder 4 driver that comes with HCFR3.

You can also check to be sure the spyd4cal.bin file was created per John's previous instructions.

Path... C:\\Users\\****\\AppData\\Roaming\\color\\spyd4cal.bin

Best of luck,
Jason
post #408 of 3446
Quote:
Originally Posted by DaGamePimp View Post

2stroker,

If Win7-64... c:\\program files (x86)\\Datacolor\\Spyder4Elite\\

Rename "Spyder4Elite" folder to "Spyder4Pro" and it should work.

Don't forget you have to remove the Datacolor driver and install the supplied Spyder 4 driver that comes with HCFR3.

You can also check to be sure the spyd4cal.bin file was created per John's previous instructions.

Path... C:\\Users\\****\\AppData\\Roaming\\color\\spyd4cal.bin

Best of luck,
Jason

Jason,

Many thanks for the reply.

I have the correct driver installed and spyder4 comes up for selection in HCFR, and the Argyll driver shows in device manager.

Yesterday I tried to change that folder name , but whatever I do it will not allow me to do that, ' access denied, or file/folder in use' message comes up on my desktop win7 32 and laptop xp. I've tried again this morning, but it's still the same. I will do a Google later to see if I have any restrictions in place, or I'm missing something.Have to say it's so annoying to get this close and can't finish it off!

Also, a big THANK YOU to JohnAd and all other contributors to this Phoenix of a program.

Regards-Vince
post #409 of 3446
Thread Starter 
Just tested a D3 with 3.0.2.0 and everything worked fine except low level readings generate a crash. There is no debug output when this happens.
post #410 of 3446
Quote:
Originally Posted by zoyd View Post

Just tested a D3 with 3.0.2.0 and everything worked fine except low level readings generate a crash. There is no debug output when this happens.

Hmm, no messages, no error log is odd, is there a minidump.dmp file?

If not I'll have to add some more logging and try and see what's going on.

Thanks

John
post #411 of 3446
Thread Starter 
That's right, no .dmp file and the stderr log just stops in midstream. I think it happens when the probe reports X=Y=Z=0.
post #412 of 3446
Quote:
Originally Posted by zoyd View Post

That's right, no .dmp file and the stderr log just stops in midstream. I think it happens when the probe reports X=Y=Z=0.

Interesting, could be an uncaught divide by zero, i'll try simulating that.

Cheers

John
post #413 of 3446
Thread Starter 
Quote:
Originally Posted by JohnAd View Post

Interesting, could be an uncaught divide by zero, i'll try simulating that.

Cheers

John

ok, did a little more testing. I was able to get very low readings only if I approached the levels slowly like this:

1. Get readings at 10%
2. Drop to 5% ok
3. Drop to 0% ok
4. Panel off = 1 reading of 0 and then crash.

If I jump from fast readings at say 50% down to a 5% pattern it will crash every time so there appears to be a timing issue with changing integration times on the probe. I'm still not convinced it's not my set-up using a vbox so I'll grab a pc and try with that.
post #414 of 3446
Quote:
Originally Posted by zoyd View Post

ok, did a little more testing. I was able to get very low readings only if I approached the levels slowly like this:

1. Get readings at 10%
2. Drop to 5% ok
3. Drop to 0% ok
4. Panel off = 1 reading of 0 and then crash.

If I jump from fast readings at say 50% down to a 5% pattern it will crash every time so there appears to be a timing issue with changing integration times on the probe. I'm still not convinced it's not my set-up using a vbox so I'll grab a pc and try with that.

Thanks for following up on this, those are some very interesting results, if you had the stderr.log from that run it would help a lot, even without that does point to a meter issue, I'll ensure there is better logging in the next version so that either Graeme or I can get to the bottom of this.

I did find one wierd divide by zero error that may have caused some random memory overwriting but I don't think would behave in the way you're seeing.

John
post #415 of 3446
Thread Starter 
Quote:
Originally Posted by JohnAd View Post

Thanks for following up on this, those are some very interesting results, if you had the stderr.log from that run it would help a lot, even without that does point to a meter issue, I'll ensure there is better logging in the next version so that either Graeme or I can get to the bottom of this.

I did find one wierd divide by zero error that may have caused some random memory overwriting but I don't think would behave in the way you're seeing.

John

I did see some garbage written in output windows, stuff like -1.#J

Here are the last few readings from the log:

Code:
i1d3: Sending cmd 'Measure1' args '01 25 a8 2a 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 01 de 03 00 00 6d 03 00 00 fa 02 00 00' ICOM err 0x0
i1d3: Sending cmd 'GetDiffuserPositio' args '94 00 00 00 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 00 00 00 00 00 00 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: i1d3_get_diff got 0
i1d3: Sending cmd 'Measure1' args '01 25 a8 2a 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 01 97 01 00 00 e0 01 00 00 58 02 00 00' ICOM err 0x0
i1d3: Sending cmd 'GetDiffuserPositio' args '94 00 00 00 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 00 00 00 00 00 00 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: i1d3_get_diff got 0
i1d3: Sending cmd 'Measure1' args '01 25 a8 2a 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 01 97 01 00 00 e0 01 00 00 58 02 00 00' ICOM err 0x0
i1d3: Sending cmd 'GetDiffuserPositio' args '94 00 00 00 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 00 00 00 00 00 00 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: i1d3_get_diff got 0
i1d3: Sending cmd 'Measure1' args '01 25 a8 2a 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 01 10 00 00 00 14 00 00 00 1d 00 00 00' ICOM err 0x0
i1d3: Sending cmd 'Measure2' args '02 20 00 28 00 3a 00 07'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 02 f2 aa e5 02 a4 f2 cc 04 00 00 00 00' ICOM err 0x0
i1d3: Sending cmd 'GetDiffuserPositio' args '94 00 00 00 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 00 00 00 00 00 00 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: i1d3_get_diff got 0
i1d3: Sending cmd 'Measure1' args '01 25 a8 2a 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 01 01 00 00 00 01 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: Sending cmd 'Measure2' args '02 02 00 02 00 02 00 07'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 02 94 69 30 00 be 1d 3d 00 c7 2e 86 00' ICOM err 0x0
i1d3: Sending cmd 'Measure2' args '02 04 00 00 00 00 00 01'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 02 57 b6 5d 00 00 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: Sending cmd 'GetDiffuserPositio' args '94 00 00 00 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 00 00 00 00 00 00 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: i1d3_get_diff got 0
i1d3: Sending cmd 'Measure1' args '01 25 a8 2a 00 00 00 00'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response icoms: About to return hid read 64 bytes, ICOM err 0x0
 '00 01 01 00 00 00 01 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: Sending cmd 'Measure2' args '02 02 00 02 00 02 00 07'icoms: About to return hid write 64 bytes, ICOM err 0x0
 ICOM err 0x0
i1d3: Reading response
post #416 of 3446
Thread Starter 
Some further testing on performance of the D3 reveals some loss of precision over the D2 to increase the speed of the probe. I hope there is some way to adjust the integration times chosen for the various light levels, the range between 3-15 cd/m^2 appears most problematic. Here is a time series plot of the RGB level and deltaE for 3 stimulus levels (20%,30%,40%) along with the same measurement using a D2, the D3 is considerably noisier in the red channel. The standard deviation is approximately a factor of 2 worse which means we need a factor of 4 increase in integration time (or number of samples) for this range of stimulus to get the same precision as the D2.

D3

D2
post #417 of 3446
Quote:
Originally Posted by zoyd View Post

Some further testing on performance of the D3 reveals some loss of precision over the D2 to increase the speed of the probe. I hope there is some way to adjust the integration times chosen for the various light levels, the range between 10-50 cd/m^2 appears most problematic. Here is a time series plot of the RGB level and deltaE for 3 stimulus levels (20%,30%,40%) along with the same measurement using a D2, the D3 is considerably noisier in the red channel. The standard deviation is approximately a factor of 2 worse which means we need a factor of 4 increase in integration time (or number of samples) for this range of stimulus to get the same precision as the D2.

D3

D2

Wow, zoyd, great work. This would explain why calibrations tend to run too red for me with this version of HCFR and the D3.
post #418 of 3446
Thread Starter 
I don't know what display you are using but the probe measures 500 kelvin high on my plasma so if you don't profile against a spectro you will push the calibration 500 kelvin too low (on a plasma). I can post the conversion matrix if you need it. The data was posted to demonstrate a loss of precision, not accuracy.
post #419 of 3446
Is there any way to chance preference white point to more... Cool White? like 9300k. The highest I can get I D75 white which is 7500K.
post #420 of 3446
@zoyd

Some very interesting results, it does indeed look like speed is being traded for accuracy, I'm wary of plain averaging maybe best 2 of 3 might best.

By the way I'm still looking at improving the crash handling so that we can hopefully get the missing bit of that file next time, looks like the error is being buffered to me and we're missing the useful bit ...

John
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