ColorHCFR v2.0 Available... - Page 9

When you measure the colors it stops after magenta. You don't do 100% gray (white) again and it uses the value for 100% you obtained at the last step of the grayscale (sort of the first step of the color measuring). If they had it set up to do gray/white again, you could do 75% all the way through. But, for now, it looks like you have to do 100% colors.

If you use the "measure primary and secondary colors" button, it does read white again. I don't know why it doesn't do that all the time.
Roy

IIRC, this has worked consistently for me. Note that there is an option in the Preferences->General Tab to measure white with the primaries and secondaries measure.

I think I figured it out. You have to run the 100% colors or the Delta Luma (and perhaps other calculations) get screwed up. I believe the program is expecting the primairies and secondaries to be at 100%. Originally, I thought I had messed up on my color settings based on a very high Delta Luma... but that was not the case. My settings were good. I just fed the program the wrong data (75% colors instead of 100%) when running through a last set of measurements.

Ha! I have not used that button. I use the button that combines grayscale with primary/secondary colors. It does the 100% white as the last step of the grayscale and doesn't repeat at the end of the colors. Consequently, you have to use 100% colors. I know that you can compare colors at 75% or 100% as long as you are consistent and include white at the same %. I don't know what calculations the program makes that would matter re: 100% vs 75%.

Any chance of making that (first lum/contrast->prim/secs->...) more obvious in the program?
And, any possibility to include a toggle option to use either 75% or 100% patterns?

Why did you decide to use 100%?

I thought the recommendations from the calibrators on this forum have always been to use the 75% windows rather than 100% because some color decoders are less accurate at a full 100%?
Roy

I'm interested too about the 100%/75% patterns question.

In the while some little suggestions for the pgm:

- when saving an image (Charts) could you fill in the same name of the .chc plus something like " - CIE" or " - RGB", etc depending on the chart being saved.

- add a new tab\\window with a spreadsheet like grid to let user make annotations: for example what settings are used on the set within the .chc (contrast, brightness, etc)

- Windows tiling isn't much useful if you want to compare charts... the windows have some constraints, you can't shrink them to below some extents...

A question: does HCFR makes "multiple reads" from sensor before sticking for a measured value? If not could be handy to let user choose hom many "reads" should be performed from sensor and pull an avergae out of it; It could help us users owning some crappy sensors.... I see my Eyeone's free measurements jumping upp and down, when enlarging scale and looks like it could benefit from multiple reads/average...

you've got a "comment" area in the main tab.


You can open a tab in a new window to compare charts (right click on the tab and select "open tab in a new window").

Hello

That's an idea we never had before... I will try to implement it in a next version.

As Ki_ answered, you can store this kind of things in information textbox.

You can shrink windows to a very little size except if they contain a "measures" tab. For windows containing only graph tabs, the size can be very very small. You can close the measure tab in current window, it is not mandatory to keep it open.

I already described how to put manual entries in ColorHCFR.ini file to obtain this feature. Look at my previous posts in this thread.

Georges

Why? It takes almost no time at all to do this yourself.


Yes, but only if you have "average many reads on dark measurements" selected in the preferences for your sensor.

It defaults to 8 read loops or until it reaches a value of 10 cd/m^2. You can control this in the ColorHCFR.ini file found in the HCFR installation folder. Open it with notepad and look for the entry [SensorName], e.g. [EyeOne] and add these lines below that entry:

MinRequestedY=10
MaxReadLoops=8

If you want that average applied to all measurements simply increase the value for MinRequestedY, e.g:

MinRequestedY=1000000

This will ensure that all results are the average of 8 measurements, but to be honest I don't thik you will gain much precision and when measuring from a plasma you could potentially get worse results because of drift in the sensor at high amplitude signals. IMHO, the default is working well with respect to Display 2/LT and a plasma TV.

Edit: Oops, Georges had already replied, sorry. It could actually be nice with that feature when I think a bit more about it. Good idea, blutarsky, and thanks to Georges for trying to implement it

Hello Roy

It's only a personal choice. Some people will say 75% is right, and 100% is wrong, with strong arguments, and other people will say the exact opposite, with strong arguments too.

You are talking about some color decoders less accurate at 100%. Ok, but how many color decoders ? A vast majority ? And less accurate, ok, but what is the error margin ? Is this error margin greater than measuring probe error margin ?

At the opposite, we can argue that 100% primary colors are less perturbated by black level of two other components. If you measure primary colors at 75% and 100% on a poor contrast level diffuser, you will obtain a significantly smaller gamut triangle with 75% patterns than with 100% patterns. And this difference is far more than color decoder approximations issues... Where is the truth ?

We made a choice, which seems largely accepted and used on our side of the pond... but which seems different than yours. Anyway, the software allow you to use the patterns you prefer, even if it is a little less practicle at 75%. So, is there really a trouble ?

Regards
Georges

Think of a filename like:

"Pioneer 508XD - CS=2 G=1 - PS3 (YCC) - AVCHD@1080p - REC709.chc"

and youl'd like to save multiple screenshots....


About the average:

HCFR takes a huge amaount of time when sticking to "average many reads on darks", on darks. I don't know how many reads are done by default, but if it defaults to 1 and does 8 when the above is checked, we could go for 2/3 attempts to avoid long timings...

George, what about the 75% patterns? Yesterday I had a go with 75% AVCHD patterns and it looked like HCFR was soaring on blu, while in HCFR v.2 DVD it hangs a bit...

EDIT: Ok! New dumb rule: re-read thread before posting!

Argh!!!

I've just discovered I was using HCFR with an old eyeone.dll, while having a newer one....

old version: 3.3.1.115 - 15/02/2006
new version: 3.4.0.131 - 03/07/2007

Did I waste my time with an unreliable version?

Where did you get the new one? I just checked my version and it is 2/15/2006 as well...

I think it was swapped in some Xrite directories when I've updated the match3 utility...!!

No, Georges, no trouble. I'm just trying to wrap my head around the problem. I spent a bit of time understanding the whole concept of "saturation" and how it differs from "luminance" when I first started looking at calibration.

So now I think I've got that concept under control. The CIE diagram depends on the saturation of the colors and not their intensity, and if I had a perfect color decoder and perfect gray scale it would look the same regardless of the brightness of the source. Then you come along and seem to be saying that the brightness of the color pattern matters, which is not what I would expect.

It seems to me that we're using one point to validate the accuracy of the color decoder throughout the brightness scale. I would naively think that picking a point somewhere in the middle of the scale has a better chance of achieving less error on the average throughout the scale than picking a point on one end. We want to pick a point bright enough that the color decoder dominates the gray scale, but still far enough away from the end that fluctuations in the accuracy of the decoder are more averaged out throughout the range of brightness.

So I think I understand why I saw the suggestion to use the 75% windows. I just wanted to understand what criteria led to your picking 100%.
Roy

Ok, let me explain a little more that point

Theoretically, primary color luminance does not change the measured point position on CIE diagram... theoretically In practice, you have a difference. Imagine if you have a contrast ratio of 100:1 (really poor isn't it ). Red primary is composed of 100% of red, 0% of green, and 0% of blue, theoretically. But since black is not black, your red is 100% red, with 1% green and 1% blue. Those remaining components of other primaries move the red point toward white, a little... When measuring red with 75% luminance pattern, you have 75% of red, but still 1% of green and 1% of blue. They become relatively more important, and their influence increase the move toward white. Not much, but it reduces your gamut triangle.

Indeed, higher is your contrast ratio, lower is this gamut reduction effect. And actually, with modern projectors, I easily admit we can neglect it, certainly in the same proportion than color decoder issues

The point is: we can argue both for 75% and 100% patterns. This is an endless war, because both are good, and none is theoretically perfect. And it is absolutely useless to try to make a compromise using 90% patterns ! :lol:

Georges

Thanks Georges. I can see that. Just to make sure we're on the same page, wouldn't it be 75% red, 0.75% green, 0.75% blue, or something like that. Certainly I can see it wouldn't be zero.

You're talking about a constant offset caused by black not being black. But isn't it actually worse than that? Because in reality, in our non-perfect world, the red primary isn't the correct frequency and saturation of red as defined by the standard. So the red pixel itself is contributing a non-zero green and blue component that differs from the standard and is dependent on the intensity of the red gun. And of course the same is true of the green and of the blue pixels. I'd expect the effect of the non-standard primary pixel colors to swamp any effect of black not being zero....

BTW, I've got a rear project LCD, and my contrast ratio is more like 95:1....

The title well explains..... aiming for the proper color reference: before even thinking "calibration", what if you're unsure about the colour reference in your video chain?

So I'm unsure. Are you? How is your player dealing with 601/709? Are you moving those colorpoints on the CIE chart in the right direction?

Unsure if my PS3 is converting correctly/badly the color reference... or leaving it properly.... what about my TV?

So what I did? Make some tests!

Basically I've used the HCFR DVD.2 and AVCHD 709 DVD.

The test:
- reset all TV controls, filters, etc.; set an average contrast
- played the DVDs on my PS3, set to output YCbCr
- measured grayscale and colors in HCFR

The playback:
- HCFR DVD @576p (let the TV do the upconversion, should be on REC 601 reference)
- HCFR DVD @1080p (let the PS3 do the upconversion, unknown color reference treatment)
- AVCHD DVD @1080p (should be on REC 709 reference)

The results?
The x & y are almost the same values!

..... Is that normal?

What's happening? Are all the signals converted to some reference, regardless what is encoded on disk?
Are the measurements the same, because....???
I'm attaching the 3 .chc for your eyes....

Experts please do comment!

 

Color Reference tests.zip 4.341796875k . file

If you are expecting x,y coordinates to change for primaries, then they won't. There are two distinct issues at hand that get confused a good deal.

1) Color decoding - This is what we talk about with Rec. 709/601 matrices. Color decoding has nothing to do with your x,y primary coordinates, so switching between a Rec. 601 and Rec. 709 disc won't show any difference in the vast majority of cases (PS3 included).

2) Color gamut - Gamut refers to the space enclosed by the three primaries. The gamut of a display is a physical property, and in most cases can't be changed. A test disc can't really do anything about this.

I always recommend using HD test patterns (Rec. 709 encoded) for calibrating HD players. It isn't that you can't get it right by upscaling an SD disc, but rather that you don't know if you got it right in most cases. You take out one source of error if you use an HD disc.

Now, I'm pretty sure that HD is worldwide. By that I mean that 1080p on a PAL land TV expects the same signal and encoding as a 1080p NTSC tv when it comes to HD signals. Maybe Patrice can comment on that. If that is the case (I'm almost positive that it is), then I would suggest using AVS HD to calibrate your PS3. You can then check your color decoding using both an HD and SD disc. If the player does the "twist" correctly, then your color decoding should be correct for both discs.

hi gang, just a couple of questions for the HCFR team. I noticed that you have used a luxmeter on the advanced tab. My question is this your recommendation for a luxmeter model or will any luxmeter work. And second does the luxmeter information override the probe readings? From what I can see a luxmeter would change your gamma and grayscale readings mostly on the low end is this what we are shooting for? Thanks again for this great FREE program and all of the time and effort the entire team has put into it. simple the best.

I was told it's better to calibrate with SD sources just because almost no material exist encoded in REC 709, although labeled as "HD"

You're getting it confused again.

There is a lot of material that uses Rec. 709 encoding (all HD should, AFAIK).

There is some speculation that HD mastering houses are still using displays with SMPTE-C primaries, so some people recommend adjusting your display primaries (if possible) to match SMPTE-C instead of Rec. 709 primaries. They are two different issues.

There are varying opinions on this, but I would calibrate to Rec. 709 primaries and assume all HD is encoded with the Rec. 709 encoding matrix. You can't possibly go switching everything around everytime somebody masters some material incorrectly, so you set it to what it should be and roll the dice.

Hello

There is one and only one luxmeter recognized: the LX-1108. And we do not recommand using a luxmeter if you already have a colorimeter. This dev is experimental, we made some tests to see if it can give better results, and the answer is actually "no". But if you already have this luxmeter, why not play with ?

The luxmeter measures and the colorimeter measures are both present, you can display one or the other, or both, and you have tools to compare data, if you want to check Y measures accuracy.

You can measure luminance curves with the luxmeter alone, by using the simulated sensor and the luxmeter. But this use is only for people owning the luxmeter and no colorimeter (I don't know anybody in this situation )

Georges

thank you that answered my question perfectly.

IF we have results to post and get input on, where should these be posted? Should the old thread using the previous version be used?

I actually posted here, and did get some feedback, but I think I shouldn't have posted actual calibration graphs here. Sorry about that.

Hello,

I have a feature request:

I have connected my laptop with a s-video cable and to my CRT directview tv and used the buildin patterns.
This was the first time because i prefer to use my DVD-player but a must say its
works like a charm.
There is one problem and that is the fullscreen patterns,i used the 10% windows from
the HCFR dvd because that's a better choice for crt televisions.

So my question is can u make 10% or 25 % windows for the automeasure of greyscale/primaries etc.

thanks,

Danny