[zoyd]



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


@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

It looks to me to be purely statistical so either increase the integration by 4 for that range of luminances (I don't know if it's settable by signal level) or average 4 samples. I also don't know how that interacts with the probe's internal auto-integration level code. It would probably be better to work with the argyll team to change it at the driver level instead of averaging in HCFR since it will improve their readings as well.

 

[JohnAd]



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


It looks to me to be purely statistical so either increase the integration by 4 for that range of luminances (I don't know if it's settable by signal level) or average 4 samples. I also don't know how that interacts with the probe's internal auto-integration level code. It would probably be better to work with the argyll team to change it at the driver level instead of averaging in HCFR since it will improve their readings as well.

Your tests do look like normal random noise, in my own tests with the i1d2 I occasionally (but still more often that I'd expect) get a rogue result which would skew an average but would get picked up with a rejection type filter. The rogue result issue is why I'd prefer to use a rejection filter and an averge rather than just an average. It would also help with situation where the image changes mid read which is more likely the longer the read time.


Agree that ideally we'd be increasing the integration time in the driver layer but there are other issues at play there too not least the lack of a sensible timeout mechanism which I think means we have to stay quite conservative at the low light levels to avoid hangs. But I'll review the code and speak with Graeme to see what if anything can be done.


John

 

[dml1333]

Now that I have an i1D3 along with my old DTP-94, I can also reproduce the crash with i1D3 whenever I run a grayscale using a setting on my Samsung plasma that allows it to turn completely off during the 0% measurement.


There is also a different problem that is related to too quick timing with the i1D3. When starting any of the automated measures such as grayscale or primaries, the confirming dialog box in HCFR comes up in the middle of the screen (it always has). When running with "View Images", rather than "DVD manual", using my laptop with HDMI out or my HTPC, I usually have HCFR running in full screen mode. The confirming dialog box will then usually be directly under the meter and it seems that the i1D3 is starting to take measurements before the dialog box goes away and the 0% screen comes up. This causes a totally bad reading for 0% which also messes up the gamma calculation. A temporary workaround has been for me to move the dialog box out from under the meter (every time I start a measurement), and then the readings are fine. I wonder if other meters might also experience this when used with View Images? A very short delay after getting the OK click and before starting an actual measurement might solve the problem for all (just a suggestion).

 

[dml1333]

I know there was brief mention of using the EDR calibrations that come with the i1D3 and using i1d3ccss to convert them to Argyll format. I couldn't tell if version 3.0.1.0 or 3.0.2.0 is supposed to use them (and present those choices in the Argyll meter dialog), or is that a feature that is planned for a future version? I also wonder if the 500 degree kelvin error that was mentioned in an earlier post might be partially corrected if the appropriate correction file was used?


BTW, I have successfully run simultaneous measures with my DTP-94 and the i1D3, and do see a consistent offset between the two. However, I don't have a spectro to be able to tell which is more accurate.

 

[JohnAd]



Quote:
Originally Posted by dml1333 /forum/post/21868248


I know there was brief mention of using the EDR calibrations that come with the i1D3 and using i1d3ccss to convert them to Argyll format. I couldn't tell if version 3.0.1.0 or 3.0.2.0 is supposed to use them (and present those choices in the Argyll meter dialog), or is that a feature that is planned for a future version? I also wonder if the 500 degree kelvin error that was mentioned in an earlier post might be partially corrected if the appropriate correction file was used?

The tool is in 3.0.2, the generated ccmx files will be used in a later version (in the next weeks rather than months)


John

 

[JohnAd]



Quote:
Originally Posted by dml1333 /forum/post/21868214


Now that I have an i1D3 along with my old DTP-94, I can also reproduce the crash with i1D3 whenever I run a grayscale using a setting on my Samsung plasma that allows it to turn completely off during the 0% measurement.

Thanks, the crash is still proving difficult to track down. If you could help test the next verfsion that would be great.

Quote:
Originally Posted by dml1333 /forum/post/21868214


There is also a different problem that is related to too quick timing with the i1D3. When starting any of the automated measures such as grayscale or primaries, the confirming dialog box in HCFR comes up in the middle of the screen (it always has). When running with "View Images", rather than "DVD manual", using my laptop with HDMI out or my HTPC, I usually have HCFR running in full screen mode. The confirming dialog box will then usually be directly under the meter and it seems that the i1D3 is starting to take measurements before the dialog box goes away and the 0% screen comes up. This causes a totally bad reading for 0% which also messes up the gamma calculation. A temporary workaround has been for me to move the dialog box out from under the meter (every time I start a measurement), and then the readings are fine. I wonder if other meters might also experience this when used with View Images? A very short delay after getting the OK click and before starting an actual measurement might solve the problem for all (just a suggestion).

Hmmm, I think the pause might be in the wrong place, should be addresssed in the next version.


John

 

[zoyd]

So the following files can be generated from my i1d3 disk, can someone describe how they could be used? I would like to compare them to my i1pro based correction to see which to recommend for plasmas.


CCFLFamily_07Feb11.ccss

WGCCFLFamily_07Feb11.ccss

ProjectorFamily_07Feb11.ccss

WLEDFamily_07Feb11.ccss

RGBLEDFamily_07Feb11.ccss

 

[JohnAd]



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


So the following files can be generated from my i1d3 disk, can someone describe how they could be used? I would like to compare them to my i1pro based correction to see which to recommend for plasmas.


CCFLFamily_07Feb11.ccss

WGCCFLFamily_07Feb11.ccss

ProjectorFamily_07Feb11.ccss

WLEDFamily_07Feb11.ccss

RGBLEDFamily_07Feb11.ccss

They are just text files, you should be able to look at the matrices in notepad and compare them to your one.


By the way, which display type did you use in your tests above, Graeme mentioned that plasmas might be better with a refresh based display type.


John

 

[zoyd]

thanks John, I believed I did use the refresh based option but I'll check it. The .ccss files contain full spectral data and can be used to form probe corrections within dispcalGUI but I don't think an equivalent exists for HCFR use, maybe I can convert them to matrix based from dispcalGUI.

 

[JohnAd]



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


thanks John, I believed I did use the refresh based option but I'll check it.

I thought you said you did, did you calibrate the meter before the run to lock onto a white patch, a stderr.log from that might be handy to confirm thta it found the right refresh rate.

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


The .ccss files contain full spectral data and can be used to form probe corrections within dispcalGUI but I don't think an equivalent exists for HCFR use, maybe I can convert them to matrix based from dispcalGUI.

Sorry I was thinking of the ccmx files which are matrices

Can you send me the files I don't think I've seen them.


I'll be adding the ui to load those up in the next week or so, there may be a interim version to gather more diagnostics on the various crashes and possible fixes for the i1pro issues but that's the next feature.


John

 

[zoyd]

.ccss files are here. I'll confirm tonight whether it locks onto the correct refresh rate and remeasure the stability.

 

[zoyd]

Checked my measurements and I did have the probe synched in refresh mode. Here is another set comparing the D2 and D3 in various modes. I ran my display at both 60Hz and 96Hz and the worst performance was the D3 in refresh mode on a 60Hz screen. Both red and correlated color temperature had a bit more than twice the error of the other measurements. The probe synched at 30Hz on the 60Hz screen and 24Hz on the 96Hz screen, the patterns are 24 fps.


60Hz 100% White tile
Code:

i1d3: instrument inited OK
i1d3: Sending cmd 'SetLED' args '21 01 05 01 02 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 21 00 00 00 00 00 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: Refresh period = 33.513524 msec
i1d3: integration time quantize to 0.201081 secs
i1d3: Refresh period = 33.127407 msec
i1d3: integration time quantize to 0.231892 secs

96Hz 100% White tile
Code:

i1d3: instrument inited OK
i1d3: Sending cmd 'SetLED' args '21 01 05 01 02 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 21 00 00 00 00 00 00 00 00 00 00 00 00' ICOM err 0x0
i1d3: Refresh period = 41.650735 msec
i1d3: integration time quantize to 0.208254 secs
i1d3: Refresh period = 41.775024 msec

edit: Added D3 synched at 30Hz to a 30 FPS pattern, this one generates the largest instability with the 1-sigma CCT = 2% (130K).


Also took a look at the skewness parameter and John was right, the D3 had some larger spikes (non-normal distribution) but it wasn't correlated with whether the probe was being used in sync or non-sync mode.

 

[anta1974]

You write:

Enter the location of the new drivers, which are in the Drivers directory under the location of the ColorHCFR executable. The drivers will normally be found in C:\\Program Files\\HCFR Calibration\\Drivers.

But I using a driver argyll and all the excellent (good)!

I have Colormunki Photo.
You can do so?

Why there are differences in the performance measurement CALMAN 4.4 and your program?
What the correct?

 

[65Cobra427SC]

Something I noticed during a previous calibration which I'm not familia6r with... forgot about it till now...


When measuring grey scale I noticed it takes longer to measure 0 IRE than it does to measure 100 IRE. There is a definite pause when measuring 0 IRE but the time is shorter for each subsequent test pattern and by the time I get to ~ 70 IRE it's requesting the next screen instantly. Just curious if this is normal?

 

[DaGamePimp]



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


Something I noticed during a previous calibration which I'm not familia6r with... forgot about it till now...


When measuring grey scale I noticed it takes longer to measure 0 IRE than it does to measure 100 IRE. There is a definite pause when measuring 0 IRE but the time is shorter for each subsequent test pattern and by the time I get to ~ 70 IRE it's requesting the next screen instantly. Just curious if this is normal?

Perfectly normal, more time is spent at the lower IRE to give a more accurate read.


Jason

 

[anta1974]

When you edit fields in the grayscale value of 0% program closes with an error.

Windows 7 x64

HCFR 3.0.1 and 3.0.2

original no error.

 

[65Cobra427SC]



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


Perfectly normal, more time is spent at the lower IRE to give a more accurate read.


Jason

Thanks!

 

[dml1333]

With both HCFR 3.0.2 or 3.0.1, if you double click on a .chc file, the program appears to hang during startup with the transparent graphic displayed. However after closing (using right-click on the task bar icon), an error dialog is revealed (it was underneath the graphic), and it says "Unexpected File Format". Version 2.1 would open the .chc file to view prior calibrations. This one is pretty minor IMHO, so I would suggest putting it low on the list.


I'm really glad that the work to utilize the .ccss is high on the list. And thanks for the great work!

 

[gingerman]

Hey guys, quick note. Using HCFR 3.0.1.0 I started to cal a my JVC X30 (46 hours on the lamp) with a Spyder4 we had around the office about a week ago. No issues, but probably not the best tool for the job. Switched to a i1d3 later in the week. Following the guide at curtpalme.com I have made a night and day difference in the picture quality. Sometimes I get an error when starting a new hcfr file about driver loading for the i1d3, a reboot clears it everytime and it is off to calibrating. I am sure it has to do with the xrite sw, which I just disabled in the msconfig startup. I've done greyscale with the DVE BluRay, and I just did the primary colors with the AVS709 disc. Supprisingly I had to push the color control to +4 on to get the red primary to 21% of the 100% Y. Going by eye I would have expected to need to dial the color down, which is testement to the need for a app and meter.

 

[JohnAd]



Quote:
Originally Posted by anta1974 /forum/post/21878583


When you edit fields in the grayscale value of 0% program closes with an error.

Windows 7 x64

HCFR 3.0.1 and 3.0.2

original no error.

I can't reproduce this, can you send any minidump files produces in 3.0.2.0 or later versions.


Thanks


John