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 84

post #2491 of 3446
Thread Starter 
ccss loading has been fixed, new installation can be found through the link in my sig and it's labeled beta2. It's a little bit different now, I removed the spectral type dropdown and all choices will appear in the display type dropdown: non-refresh, refresh, + any ccss files if the probe supports them. If you need both refresh and a ccss choose refresh first and do your calibration and then choose the ccss and continue on to measurements.

Also added in this version:
-default dE choices loaded using the "recommended" selection of color difference dropdown
-24 Pantone skin swatches to the internal pattern generator


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

This is already done for primaries and secondaries "Detect primary colors during user measures" will lock on to the correct color in free measures mode if you are within deltaxy = 0.05. But this not practical for grayscale because keying off of target luminance levels is tricky. I do plan to allow a selected video level column to be updated in real-time, this is already partially implemented using the internal pattern generator.

I would suggest skipping the auto-select based on deltaxy and instead only target the column that the user clicks on. That is already in place for colors, one can click - but then the autoselect takes over. It gets messy if you forgot to pause the pattern disk and it switches to the next chapter... I think we are better off if we click the intended column explicitly and not use auto-select. That would carry over for the grayscale columns as well and be consistent through the GUI.
Quote:
Originally Posted by barsk 
2) Possibility to start a gray scale run on a freely chosen point.
Quote:
Originally Posted by zoyd 
This is overkill, you are talking about saving a few seconds out of a full 30 second grayscale sweep.

I don't think so. I tend to do a LOT of sweeps since the behaviour of my display is somewhat tricky sometimes so if just running free measuments on a IRE will not tell me what happens to all the neighbouring IREs. A sweep is much more to the point. But I don't always need a full sweep. A drop-down with a starting point for the sweep would be just nice. The low IREs are the ones taking most time. Skipping them saves a LOT of time over a session with a tricky display.
Quote:
Originally Posted by zoyd 
The targeting mode will not change. A more efficient way to calibrate primaries and secondaries than what you are doing is to use the single layout shown below in free measures. This shows both visually and by numbers in real-time the effects of your adjustments.
Well, I found it unintuitive to what HLS changes affect the position of the arrow target. Maybe I need a bit more training. Is there a guide to this somewhere? Tracking the dot in realtime in the gamut diagram was actually quite nice. In combination with checking dE and delataxy.
Quote:
Originally Posted by barsk 
4) Saturation sweeps would be better off done in ONE run instead of each primary and secondary color separately.
Quote:
Originally Posted by zoyd 
Already available.
Cannot see that. Saturation scale sweeps as they are called in the GUI are separate. There are 6 sweeps to complete. I suggest at least to combine primaries in one sweep and secondaries in one sweep.
Quote:
Originally Posted by zoyd 
Ultimately this is a DIY program and I personally have no desire for implementing additional hand-holding features.

I can understand that. I am by no means enforcing anything. You, John and others have done a GREAT job and I applaud that. All thumbs up. However the thread name is HCFR - whats needed. And my suggestions was in line to answer just that. To bring a good tool to become a great tool. I could maybe do some work regarding this myself as a contributor to the project if needed. However am am a Java guy nowdays and my C/C++ coding was done a loong time ago. But I might look into it someday when time allows. No promises.
post #2493 of 3446
Quote:
What exactly was wrong with the projector mode? Are you referring to the projector spectral sample that was included in previous versions?

Zoyd:
Previous versions ignored the projector selection and defaulted to normal display mode (called emissive spot mode in Argyll). I updated it to support the projector -p mode that some meters like the i1pro have. From the Argyll documentation -p switch means "Use telephoto measurement mode (absolute results)", I don't know what that mode is or how to use it. The D3/munki do not have that mode.

I asked Graeme about this and this was his answer:

> On a side note. Zoyd mentioned that the latest beta now has support for
> a projector mode that uses a "-p" option to the drivers. Something that
> was not enabled earlier.
> As I did a calibration on my projector with that old version that did
> not employ "-p", is that calibration wrong and needs to be redone?

"No, it makes no difference to any device other than the
ColorMunki spectro, and with that device the software knows what
position it is in anyway.

Graeme Gill."
post #2494 of 3446
Thread Starter 
Quote:
Originally Posted by Barsk View Post


Cannot see that. Saturation scale sweeps as they are called in the GUI are separate.

Do you not see these options in the saturation menu?

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

I knew the messages would get old quick, I was gonna wait until someone unlocked "super awesome" before removing.

Got grayscale average dE 0.22, colors average dE 0.66 and color checker average dE 1.23, only got rating "Awesome calibration!" mad.gifwink.gif
What do you need for "Super awesome calibration!", maby hand edited results to perfect tongue.gif

Great work again, thanks zoyd smile.gif
post #2496 of 3446
Thread Starter 
Quote:
Originally Posted by Make73 View Post

Got grayscale average dE 0.22, colors average dE 0.66 and color checker average dE 1.23, only got rating "Awesome calibration!" mad.gifwink.gif
What do you need for "Super awesome calibration!", maby hand edited results to perfect tongue.gif

Great work again, thanks zoyd smile.gif

Not good enough. tongue.gif
post #2497 of 3446
Quote:
Originally Posted by zoyd View Post

Do you not see these options in the saturation menu?

Sorry, I have found these options now. I used the drop down list which covers most options, but not all...

If I can suggest something from these findings then it would be that it would make better sense to have the primaries and secondaries sat sweep in the droplist instead of these separate six we have now. Simplifies the droplist and pulls in what you most usually need. My 2 cents.
post #2498 of 3446
Quote:
Originally Posted by zoyd View Post

If you need both refresh and a ccss choose refresh first and do your calibration and then choose the ccss and continue on to measurements.


Jeff Foxworthy would like to know if your rednecking HCFR with this^ procedure....biggrin.gif

I could not get both refresh and my edr together.It was one or thee other and yes I tried what you said in the quotes.

I just tried new beta and it felt no different than last time.One measure will be 100% the next will be 93%...
post #2499 of 3446
Thread Starter 
Quote:
Originally Posted by PeterLewis View Post


I could not get both refresh and my edr together.It was one or thee other and yes I tried what you said in the quotes.

As previously stated, refresh mode syncing is not available for the colormunki.
Quote:
I just tried new beta and it felt no different than last time.One measure will be 100% the next will be 93%...

Feelings don't count, post data demonstrating the problem you are having and I will look at it. Now that the ccss is loading again, are you measuring about the same grayscale response as before? Using the same patterns, set-up, etc.
post #2500 of 3446
Quote:
Originally Posted by zoyd View Post

As previously stated, refresh mode syncing is not available for the colormunki.
Feelings don't count, post data demonstrating the problem you are having and I will look at it. Now that the ccss is loading again, are you measuring about the same grayscale response as before? Using the same patterns, set-up, etc.

One thing I noticed was having both version installed, beta and 3.0.5.2 that 305 was measuring fine then once i switched to the beta it was measuring like previous beta and then once I went back to 3052 it was reading like the beta.eek.gif

So I uninstalled both versions ,saved my munki DLL then I reinstalled 3.0.5.2 and put back my munki DLL and it was good as new...

So the issue could lie in having both versions installed and its confusing something in the chain.I will try uninstalling 3052 completely later and just use beta on a clean install...

Btw ,you avoided the Foxworthy comment tongue.gif
post #2501 of 3446
Thread Starter 
Quote:
Originally Posted by PeterLewis View Post

One thing I noticed was having both version installed, beta and 3.0.5.2 that 305 was measuring fine then once i switched to the beta it was measuring like previous beta and then once I went back to 3052 it was reading like the beta.eek.gif

So I uninstalled both versions ,saved my munki DLL then I reinstalled 3.0.5.2 and put back my munki DLL and it was good as new...

So the issue could lie in having both versions installed and its confusing something in the chain.I will try uninstalling 3052 completely later and just use beta on a clean install...

I really doubt there is any issue with drivers but starting fresh will avoid any confusion on your part. wink.gif
Quote:
Btw ,you avoided the Foxworthy comment tongue.gif

I'd be happy to update with an office of diversity approved color set. rolleyes.gif
post #2502 of 3446
Here are the new beta test from new version, one with 20 ire free measures and the next with 30 ire and they look a bit worse than last beta.The 3052 version was done earlier today before i uninstalled it...

3.0.5.2 v2.zip 3k .zip file

beta test 20ire.zip 1k .zip file

beta test 30ire.zip 1k .zip file
post #2503 of 3446
Thread Starter 
Quote:
Originally Posted by PeterLewis View Post

Here are the new beta test from new version, one with 20 ire free measures and the next with 30 ire and they look a bit worse than last beta.The 3052 version was done earlier today before i uninstalled it...

I'll take a look, was the ccss correction applied in all three measurement sets?
post #2504 of 3446
I haven't had a chance to do a new calibration with the beta, but I just loaded one of my old chc files into the new beta and the 'Recommended' method for calculating dE for grayscale uses CIE76(uv) with Absolute Y w/o gamma. Color gamut defaults to CIE2000. I thought CIE2000 was also recommended for grayscale? And is it still recommended to include gamma in calculating dE for final grading? I never fully understood which dE formula was best for grayscale and color gamut, and wondered if there was a definitive formula them.
Edited by rahzel - 11/7/13 at 12:25pm
post #2505 of 3446
Guys, I will politely ask for someone with a profiled i1d pro against a spectro to do some measures with same patterns with the correction matrix and one with the generic edr on a panasonic plasma. I m pretty sure that the edr reads red far to high in all ire's and that's the reason I'm left with a green tinge on my st60 independent of the patterns in use. Thank you!
Edited by Andrei_VVB - 11/7/13 at 1:42pm
post #2506 of 3446
Quote:
Originally Posted by zoyd View Post

I'll take a look, was the ccss correction applied in all three measurement sets?

Yes,I applied the plasma edr,now if it took or not, I dont know.By the readings it still seems like something is off somewhere.

I used de2000 w/gamma just like the previous chc. test runs.

If you look at my new 3.0.5.2 v2 measurement it is very consistent with the other 3.0.5.2 greyscale run from the other day and my original 40ftl calibration and the one with the lowered contrast as well.

I would like to hear from Barsk if he see's the same as well in the new beta, as he has an i1D3.
post #2507 of 3446
Hi Everyone, I'm wondering what the current state of the i1Display Pro and this software is. I've been searching a lot on this thread and found that it has gone through a lot of refinements in methods for low light readings, and noisy at certain IRE levels, and some stuff about needing matrixes provided by someone else in order for it to be accurate, etc.

I'm looking to get the NEC SpectraSensor Pro for my NEC computer monitor. This sensor is reported to work just fine as an i1Display Pro with Argyll, so I assume that means it would work for HCFR. I want to use this sensor to calibrate my monitor using NEC software, however, I also would like to use it with HCFR to calibrate my LCoS JVC-RS40 projector. I have done this in the past using the old NEC specrasensor which is just a custom calibrated i1Display 2, but I believe it has drifted and I'm looking to upgrade.

Thanks.
post #2508 of 3446
Thread Starter 
Quote:
Originally Posted by rahzel View Post

I haven't had a chance to do a new calibration with the beta, but I just loaded one of my old chc files into the new beta and the 'Recommended' method for calculating dE for grayscale uses CIE76(uv) with Absolute Y w/o gamma. Color gamut defaults to CIE2000. I thought CIE2000 was also recommended for grayscale? And is it still recommended to include gamma in calculating dE for final grading? I never fully understood which dE formula was best for grayscale and color gamut, and wondered if there was a definitive formula them.

The default grayscale formula was chosen for ease of adjustment, CIE76(uv) is more sensitive to gray scale chromaticity errors, but I would still proof everything on the same scale (CIE2000 Absolute Y with gamma).
post #2509 of 3446
Thread Starter 
Quote:
Originally Posted by Andrei_VVB View Post

Guys, I will politely ask for someone with a profiled i1d pro against a spectro to do some measures with same patterns with the correction matrix and one with the generic edr on a panasonic plasma. I m pretty sure that the edr reads red far to high in all ire's and that's the reason I'm left with a green tinge on my st60 independent of the patterns in use. Thank you!

The ccss based corrections are pretty good, I wouldn't expect them to cause visible errors in your calibrations unless the plasma spectral distribution is dramatically different that the supplied edr. So I would expect Panasonics prior to this year to exhibit behavior similar to the measurements below. I don't know about this year's plasmas however, in particular the VT and ZT are supposed to have a more saturated native red primary.


The table shows dE2000 errors of each probe configuration relative to the i12pro used to profile.


This plot shows a comparison of ccss corrected to profiled. The red and blue channels are still undercorrected (blue a little high, red a little low) by about 1%. The relative error between the two probes is the light colored line at the bottom and runs on average 1 dE across the board.
post #2510 of 3446
Thread Starter 
Quote:
Originally Posted by PeterLewis View Post

Yes,I applied the plasma edr,now if it took or not, I dont know.By the readings it still seems like something is off somewhere.

I used de2000 w/gamma just like the previous chc. test runs.

If you look at my new 3.0.5.2 v2 measurement it is very consistent with the other 3.0.5.2 greyscale run from the other day and my original 40ftl calibration and the one with the lowered contrast as well.

I would like to hear from Barsk if he see's the same as well in the new beta, as he has an i1D3.

I compared ccss loaded measurements between 3.0.5.2 and beta2 using my D3 and they are essentially identical except for some random errors in the 20% and 30% measurements, maximum dE = 0.8. Furthermore the deltaxy measurements are well within probe repeatability tolerances so you are chasing after a problem that does not exist (as far as I can tell).




I did find one problem with the new code though, creating profiles is currently broken.
Edited by zoyd - 11/7/13 at 2:41pm
post #2511 of 3446
Quote:
Originally Posted by zoyd View Post

Furthermore the deltaxy measurements are well within probe repeatability tolerances so you are chasing after a problem that does not exist (as far as I can tell).
.

I have done countless measurements and rechecks with 3.0.5.2 and it tells me consistently that my red is 99/100% for my red reading in the 30ire while the beta keeps saying/dropping down to 93% so I would not call that chasing after problems that does not exist when I have provided visual proof.

If I were to add red according to the beta at the 30ire peoples faces would look like they are on fire.mad.gif

We need others to weigh in on this beta testing using the plasma spectral only.

I'm almost willing to bet that the issue is not the spectral,it has to be something in the new code somewhere because this did not happen with all the previous hcfr with the older argyll code.
Edited by PeterLewis - 11/7/13 at 4:53pm
post #2512 of 3446
Thread Starter 
Quote:
Originally Posted by PeterLewis View Post


If I were to add red according to the beta at the 30ire peoples faces would look like they are on fire.mad.gif

That is overstating what the measurements are telling you.

Here is the 20% and 30% data you sent to me
Code:
3.0.5.2

x 0.311000  0.307636
y 0.331839  0.327961
Y 3.697756  8.434181

beta2

x 0.313392  0.311480
y 0.331604  0.327961
Y 3.653055  8.356387

so for 20% you measure dx = 0.0024, dy = 0.0002, for 30% dx = 0.0038, dy = 0

A dx of 0.002 - 0.003 might result in a 1-2 click adjustment of your red and blue bias, hardly enough to cause fiery faces. By the way, this generates a difference in the red reading of 3.6%, half of what you state above.

If you really want to chase after this and nail down whether or not this is a true systematic offset from the previous code you need more statistics and should do what I first suggested. Run the gray scale sequence leaving the 30% pattern up and calculate the average and standard deviation of the 10 measurements. Do this for both versions of the code and with/without the ccss correction. Those numbers will tell you what, if any, statistical offset exists between the two versions and whether or not it is due to the ccss correction. I have done these tests with the D3 and no offset exists for this probe.

Here are aggregate results of my D3 testing:

profiled
average +/- 1 stdev dx between 3.0.5.2 and beta: -0.0017 +/- 0.0015
average +/- 1 stdev dy between 3.0.5.2 and beta: 0.0011 +/- 0.0012

ccss'd
average +/- 1 stdev dx between 3.0.5.2 and beta: -0.0016 +- 0.0018
average +/- 1 stdev dy between 3.0.5.2 and beta: 0.0013 +/- 0.0015

All averages are within 1-sigma of 0 meaning there is no statistically significant offset


Before you repeat all that there is one other thing you can try. I've made a beta3 package that increases the munki integration time to 800 ms, this will slow it down some but maybe you will be happier with the stability. Give it a try.
Edited by zoyd - 11/7/13 at 6:56pm
post #2513 of 3446
What was the intergration time with 3.0.5.2?
post #2514 of 3446
Thread Starter 
400ms in the first two betas. For 3.0.5.2 it depends on whether you have refresh or non-refresh set. With non-refresh it's 500 ms, with refresh (even though you can't sync) it's 1 sec.
post #2515 of 3446
Quote:
Originally Posted by zoyd View Post

400ms in the first two betas. For 3.0.5.2 it depends on whether you have refresh or non-refresh set. With non-refresh it's 500 ms, with refresh (even though you can't sync) it's 1 sec.

Trust me ,I always had refresh selected since it is a plasma along with the edr on all past version's of HCFR and refresh always worked better for me over non-refresh.

So I would recommend to include back in the refresh selection as well as the drop down spectral selections with 1 sec (refresh) .5 sec (nonfresh) reading for the munki in the beta just like you had it in 3.0.5.2 and earlier versions.

Like Momma always says, if it wasnt broke dont fix it.biggrin.gif
post #2516 of 3446
I have found a bug I think.

When I use the "track the yellow dot" method to fine tune CMS settings I nailed the dot inside the square but got a rather large deltaxy anyway. I then fine tuned using the bulls eye and viewing deltaxy instead and got deltaxy down to zero. Watching the graph with the zero result clearly positioned the dot well outside the rectangle (on the oversaturated side) . The bug seems to affect secondaries most or maybe only. The dot I tracked was the yellow one so the bug caused it to end up to the right of its square, when it should have been spot on in middle.

I was on 75% Rec 709 when this happened if that has anything to do with it. Haven't checked in normal Rec 709 space. I think the 75% Rec 709 only affects where the gamut outline is drawn, not the position of target squares and dots so the bug is probably not dependent on that setting. This bug affects the saturation tracking graphs and if you use that to visually get a picture of your results the bug will affect that severely. I think this is a high priority bug to crush.

I used 3.0.5.2, not the beta.
post #2517 of 3446
Thread Starter 
Quote:
Originally Posted by Barsk View Post

...bug...

I was on 75% Rec 709

yes, this was an issue for special color space modes (75% and CC6) in 3.0.5.2, it's fixed in the betas
post #2518 of 3446
Quote:
Originally Posted by zoyd View Post

Before you repeat all that there is one other thing you can try. I've made a beta3 package that increases the munki integration time to 800 ms, this will slow it down some but maybe you will be happier with the stability. Give it a try.

I will patiently await for a beta4 package for further testing.

Hopefully the option to chose Refresh or Non Refresh will be included as well as the drop down Spectral list.

AND most importantly the " Adjusted Intergration Time" 1sec for refresh and 0.5sec for Non Refresh.rolleyes.gif
post #2519 of 3446
I tried to go through the whole thread to get my answers but I got lost...

I bought X-Rite i1Display Pro. I installed the drivers that came with it. I downloaded the latest official HCFR 3.0.4.0 and it recognized my X-Rite colorimeter from the very beginning. I ran the tests and calibrated my HDTV.

The biggest problem I had was that readings were not always consistent. I had to measure several times and use either the average read or the one that appeared most of the time. Is this normal for this colorimeter?

What is this Argyll driver? Does it stabilize readings and make them more consistent? Do I need it?

BTW, I have not found any updated drivers on X-Rite website. I used the one that came on CD with the package, but I figured that maybe there are newer ones that fix reading instabilities?

Also, is newer HCFR build more compatible with this colorimeter? Maybe the unstable readings are caused by HCFR? I cannot open HCFR 3.0.4.0 saved file in HCFR 3.0.5.2....

I wish I have known of HCFR before paying a fortune for CalMAN 5...

I noticed that I get similar issue as other people - blue gamma shooting up at 90%. And then, in Black Pattern Test, the 2nd gray from the right top and 2nd gray from the left bottom is visibly more red than grey.... However, RGB is a straight line...
Edited by MonarchX - 11/8/13 at 12:08pm
post #2520 of 3446
OMFG! So, when I do not use a correction file in HCFR 3.0.4.0 I get a flat RGB line, but when I do use one in 3.0.5.2 then my red is a separate line! So, I take it that the correction file is what I should be using to get accurate readings, right????
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