[JohnAd]



Quote:
Originally Posted by DaGamePimp /forum/post/21844238


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

 

[Bluescale]



Quote:
Originally Posted by JohnAd /forum/post/21842896


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.

 

[Bluescale]



Quote:
Originally Posted by 65Cobra427SC /forum/post/21842773


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.

 

[DaGamePimp]



Quote:
Originally Posted by JohnAd /forum/post/21844699


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

 

[jdbimmer]



Quote:
Originally Posted by JohnAd /forum/post/21842094


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

 

[2stroker]

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

 

[DaGamePimp]

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

 

[2stroker]



Quote:
Originally Posted by DaGamePimp /forum/post/21856898


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

 

[zoyd]

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.

 

[JohnAd]



Quote:
Originally Posted by zoyd /forum/post/21860674


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

 

[zoyd]

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.

 

[JohnAd]



Quote:
Originally Posted by zoyd /forum/post/21861437


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

 

[zoyd]



Quote:
Originally Posted by JohnAd /forum/post/21861455


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.

 

[JohnAd]



Quote:
Originally Posted by zoyd /forum/post/21863800


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

 

[zoyd]



Quote:
Originally Posted by JohnAd /forum/post/21863917


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

 

[zoyd]

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

 

[Bluescale]



Quote:
Originally Posted by zoyd /forum/post/21864331


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.

 

[zoyd]

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.

 

[fallengt]

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.

 

[JohnAd]

@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