AVS › AVS Forum › Display Devices › Display Calibration › Fork of HCFR Started - What's needed?
New Posts  All Forums:Forum Nav:

# Fork of HCFR Started - What's needed? - Page 3

Quote:

I'm not sure I understand why you'd want this and what the difference would be to simply supplying your own reference primaries taken from your actual primaries

Because it takes a long time to calculate it manually

Basically, if a primary's xy coordinate changes, its Y target must change along with it, otherwise there is a non linear relationship between that primary and the white point. For example, D65 white in the rec709 space is comprised of target Y's of red 21.2%, green 71.5%, blue 7.2%. But those percentages only apply if those red green and blue are at their designated xy coordinates, otherwise D65 will not be produced. This is why different colour spaces have different Y targets. So if we change their xy coordinates, then their Y targets must change along with them as per the formula (taken from this article).

To simplify it, if a primary's saturation is too low, it's luminance (Y) must go up, in order to produce D65. If its saturation is too high, it's luminance must come down, in order to produce D65.

If a primary's saturation is too high, and you don't lower its Y, then the result is a non linear relationship between that colour and the white balance. What we ultimately want is a 1:1 relationship between the primaries and the white point they produce when mixed together.

I don't believe Chromapure or Calman offer this calculation, so it would be a real boon to have it in HCFR

### AVS Top Picks

Quote:
Originally Posted by assm0de

I don't believe Chromapure or Calman offer this calculation, so it would be a real boon to have it in HCFR

They both have multiple ways of getting luminance and saturation right, but Calman doesn't by default allow measuring every saturation level like ChromaPure as I understand it (100%, 75%, 50%, and 25%).
Quote:
Originally Posted by coderguy

They both have multiple ways of getting luminance and saturation right

But do they dynamically calculate new Y targets for the primaries and secondaries based on their measured xy coordinates? I was told that they do not, however I don't own the software.
Quote:

I think HCFR excludes Y errors from dE, is that what you mean or is there a bigger issue?

Not sure what you mean here, is this for non-additive displays?

John

Some of the guys here pretty much covered it.

What I mean is that in HCFR, it doesn't tell you what the target Y value should be for the primary or secondary colors you're calibrating to. It tells you the measured Y value, but not the target Y value. So you end up having to use a spreadsheet or an application like "AccuPel Display Calibration Calculator" to calculate the target Y value based on a greyscale Y reading.

E.g

For Rec.709 Luma Y is 0.2126R, 0.7152B, and 0.0722G - If my Y reading is 1 for 100% grey, then target Y for 100% Red should be 0.2126. If my Y reading is 30 for 100% grey, then target Y for 100% Red should be 6.3792

What would also be cool is some sort of aid in color calibration with RGB controls instead of HSL controls. For example, the Lumagen Radiance and the Panasonic BT300 series reference plasma use RGB controls for Gamut adjustments (instead of HSL).
Quote:
Originally Posted by coderguy

I'm not disagreeing, just discussing, but just worried some of those technical bugs could be a pain to work out in C++. I've been coding over 20+ years now (old guy from way back), but if you are wanting to fix the existing data, some of it might be flawed at the root source, and the reports might need re-done to provide an accurate application that can calibrate in all forms. People will hopefully test it against other apps and let you know, but still may just be easier to create a wrapper and throw the raw data somewhere else for re-compilation into new reports.

Understand where you're coming from, for me I've got a load of code kicking about that I can use for the calcs if required, it's all in C++ so keeping the whole thing in that is easier for me.

Quote:
Originally Posted by coderguy

I will fully support whatever method you wish to go though, you won't get any grief here, just trying to offer an experienced opinion on how these C++ bug fix projects sometimes turn out, but it could turn out fine as well...

Thanks, it's always useful to hear that people think you're mad
I've done worse cleanups though, multidec which was the codebase dscaler grew from was far far worse, and some of the code I've dealt with professionally

John
Quote:
Originally Posted by assm0de

To simplify it, if a primary's saturation is too low, it's luminance (Y) must go up, in order to produce D65. If its saturation is too high, it's luminance
must come down, in order to produce D65.

I'm still not sure I get where the calculation would be that useful. So you have a display with non-standard primaries (who doesn't) then first thing you do is get your white right and then maybe the greyscale. Next you look at the primaries and they are off with quite large errors in xy and Y, so what next? My question is why you'd want to see the results of those calculations, what are you going to do with them? All comparing the primaries to that result will tell you is how non-additive your display is for the primaries, is that what you want to know? What do you do with that once you know it? If calibrating with a cms wouldn't you want to see dE to the correct target rather than anything else.

John
Quote:
Originally Posted by 703

What I mean is that in HCFR, it doesn't tell you what the target Y value should be for the primary or secondary colors you're calibrating to.

Yes, this is annoying, I need to find somewhere to put this.

Then we can all more easily argue about what the number should be

John
Quote:

I'm using the drivers and code from the argyllcms project which seems to support it already so yes it's possible and with no licensing from x-rite required, that code is only compatible with open source software though.

Excellent news then! Getting Display 3 support into HCFR will keep many people happy I think. IMHO that would be the number one complaint I hear from people about HCFR.

Kal
Quote:

What do you do with that once you know it? If calibrating with a cms wouldn't you want to see dE to the correct target rather than anything else.

Calculating Y based on xy of the primaries is basically just an alternate target for displays with limited color adjustments. If you can't target the xyY of the intended colorspace, it's merely one option of how to try to go about setting controls such as color and tint. Personally I use it because the displays I've owned have nearly worthless color controls.
Quote:

My question is why you'd want to see the results of those calculations, what are you going to do with them?

For instance if the CMS doesn't allow you to get the x-y accurate, or if you are just trying to set the Color control to the optimal setting.

Like on my 51d450, green remains a little oversaturated despite maxed out settings in the CMS to desaturate it. So in this case I use a lower Y target for green as per the formula, but it takes a long time calculate :/
Quote:
Originally Posted by assm0de

For instance if the CMS doesn't allow you to get the x-y accurate, or if you are just trying to set the Color control to the optimal setting.

Like on my 51d450, green remains a little oversaturated despite maxed out settings in the CMS to desaturate it. So in this case I use a lower Y target for green as per the formula, but it takes a long time calculate :/

Can you make us a spreadsheet that does that calculation?
Quote:
Originally Posted by 703

Can you make us a spreadsheet that does that calculation?

There's at least one other spreadsheet posted to the forum that has the custom colorspace calculations, but I know it's included in http://www.avsforum.com/avs-vb/showt...7#post15607437
Quote:
Originally Posted by alluringreality

There's at least one other spreadsheet posted to the forum that has the custom colorspace calculations, but I know it's included in http://www.avsforum.com/avs-vb/showt...7#post15607437

Ahh yes, I remember this excel file. The worksheet is called "COLOR Corrector". Prehaps JohnAd could look at re-using the formula if its correct.
Quote:
Originally Posted by 703

Prehaps JohnAd could look at re-using the formula if its correct.

Looks good to me
Quote:
Originally Posted by 703

Prehaps JohnAd could look at re-using the formula if its correct.

I think the formula is correct but I'm still not sold on it's usefulness. It tells you where you are, not where you want to go.

I can see that calculating the best pirmary targets possible given the actual primaries and white point and assuming standard hue, saturation controls and then using those as target, but that's a different calculation and requires a workflow approach which the software doesn't really do at the moment. Also in general I'd like to avoid a explosion of options and extra numbers as it's already complicated enough.

John
Quote:

I think the formula is correct but I'm still not sold on it's usefulness. It tells you where you are, not where you want to go.

I'll give another example: the Dell U2412 monitor. This display has a blue primary that is significantly undersaturated, off hue, and cannot be corrected. HCFR reports the delta luma for blue is +48%, as well as significant Y errors for the other colours. When in fact the true story is that the Y's are spot on for all primaries and secondaries, given its gamut (paste into spreadsheet to see). I guess it would be nice if HCFR could reflect this.

Quote:

Also in general I'd like to avoid a explosion of options and extra numbers as it's already complicated enough.

John

That's cool. Those of us who want to use the calculation can just use the spreadsheet as it's quite easy to copy-paste from HCFR
Quote:

It tells you where you are, not where you want to go.

A custom color space mainly just provides alternate "delta luma" values for setting brightness of colors when you have limited color controls.

Quote:
Originally Posted by assm0de

4. Measure luminance and saturation tracking of primaries and secondaries at 10% and 25% step intervals.

The program can already do 10% and 25% saturation by changing the setting under Measures > Parameters.
John,

Do you guys need (and are you taking) donations for this project? I'm not sure if you need to purchase anything for testing/integration. I'm sure a lot of us that don't have the expertise or time to participate would happily throw in a few dollars as our finances allow.

This is awesome. Thanks so much.
Quote:
Originally Posted by assm0de

HCFR reports the delta luma for blue is +48%, as well as significant Y errors for the other colours. When in fact the true story is that the Y's are spot on for all primaries and secondaries, given its gamut (paste into spreadsheet to see). I guess it would be nice if HCFR could reflect this.

Then we have very different definitions of spot on...

As I was saying, probably not very clearly, was that in this situtation the errors are real, your blue is noticably wrong and too bright and the other colours have to be dimmer to give you the right white.

Moving to the Y targets given by that formula only tells you the degree to which the display is non-linear which would be expected to be small, its doen't help in anyway that I can see with what to do next, which is to minimize errors against the real targets which will be hard/impossible to do well for this kind of display without a cms.

It just seems to me to give a false sense of nearness to a "target" rather than anything that has any real meaning.

John
Quote:

It just seems to me to give a false sense of nearness to a "target" rather than anything that has any real meaning.

John

If I understand correctly, they want to know the right luminance target in the wrong gamut and adjust the saturation control to that (using red for example) rather than minimize dE. I'm not convinced that this is a better approach than sticking with minimum dE.
Quote:

Then we have very different definitions of spot on...

They are spot on given the gamut. I obviously did not mean they are spot on relative to sRGB.

Quote:

Moving to the Y targets given by that formula only tells you the degree to which the display is non-linear which would be expected to be small, its doen't help in anyway that I can see with what to do next, which is to minimize errors against the real targets which will be hard/impossible to do well for this kind of display without a cms.

It depends on the display. On the U2412 for instance, the different picture modes all have the same gamut, but different colour luminance. eg. Multimedia mode has blue closer to sRGB spec, but red is way overcooked. In this case I can compare modes and pick the one that is most linear. That makes 2 of my displays that have benefited from the formula
Quote:
Originally Posted by zoyd

If I understand correctly, they want to know the right luminance target in the wrong gamut and adjust the saturation control to that (using red for example) rather than minimize dE.

No, it is the luminance that is to be optimised when saturation/hue is off and cannot be adjusted, for the purpose of linear tracking of primaries relative to white.

Quote:
Originally Posted by zoyd

I'm not convinced that this is a better approach than sticking with minimum dE.

I guess it depends on the dE formula that is being used, specifically how it takes into account perceptual uniformity of saturation-luminace. If a colour is more saturated, it appears brighter despite having the same Y. If the dE formula takes this into account, then it should suggest a lower Y target to minimise dE anyway. HCFR is not doing this.
The dE formula HCFR uses is weighted heavily to perceptual performance. It will not suggest a different luminance target, it tells you the correct target and then with whatever controls you have you minimize your perceptual errors and you are done. There is no point in knowing alternative targets, they will not give you a better dE. The only reason to try and hit the other targets would be if for some reason having higher dE but linear white point to color luminance ratio was somehow "better", if you can argue that, then it would make sense.
Quote:
Originally Posted by zoyd

I'm not convinced that this is a better approach than sticking with minimum dE.

Agreed as I said at the start I'd accept that a measure expressing the additivity/linearity of the display might be interesting but that the use of these values as targets seems odd. I'd probably express the non-linearity as the dE between actual and primary based white, you could also express the non-linearity of secondaries using the same approach.

John
not sure what the argumentation is for not taking the "custom gamut" in to account is (if you calibrate to 100% saturation).

if you cant get the primaries hue and saturation in place (and you want to calibrate to 100% saturation - for whatever reason) then by definition your luminance of the primaries will have to be corrected. (this should ONLY be done after you have done everything you can to get the hue and saturation as close to the reference gamut as possible. This will also have an impact of the Hue, Saturation and Luminance of your secondaries (this should also be calculated based on the hue and saturation of your primaries).

However no mater what, you should measure how your CMS is tracking at 25, 50 & 75% saturation/amplitude. to ensure you are calibrating to the right test patterns.
Quote:
Originally Posted by visca blaugrana

no mater what, you should measure how your CMS is tracking at 25, 50 & 75% saturation/amplitude.

Personally I agree that it makes sense to at least check the saturation measurements when you do have access to CMS controls. In the measurements thread I remember one person was able to get their 100% saturation measurements rather close to the intended color space, but when they checked saturation the CMS controls had introduced non-linear points on the CIE chart for saturation. Basically the CMS on the display was broken, and it's difficult to say if introducing hue changes for the colors was actually preferable to simply using the default CMS setting that had a more-ideal saturation plot but non-standard primaries and secondaries.

Quote:
Originally Posted by zoyd

The only reason to try and hit the other targets would be if for some reason having higher dE but linear white point to color luminance ratio was somehow "better", if you can argue that, then it would make sense.

Quote:

..Moving to the Y targets given by that formula only tells you the degree to which the display is non-linear which would be expected to be small, its doen't help in anyway that I can see with what to do next, which is to minimize errors against the real targets which will be hard/impossible to do well for this kind of display without a cms.

It just seems to me to give a false sense of nearness to a "target" rather than anything that has any real meaning.

John

Exactly. There is a lot of misunderstanding regarding the use of Greg Rogers' display calculator and other related spreadsheets. The clearest quote (and the whole thread is a good read) is: http://www.avsforum.com/avs-vb/showt...5#post16329415

Quote:
Originally Posted by gregr

Quote:
Originally Posted by Originally Posted by kjgarrison

want my TV to look as good as it can given that I cannot adjust the primaries xy coordinates. Not at all. I can adjust their Y values, and I can adjust the secondaries xyY usually to whatever it needs to be (I can't push a secondary's xy outside of the triangle formed by the primaries, but I can pull it inside.)

Now I'm the one that is confused. Are you trying to adjust a TV using just its Color and Hue (Tint) controls? The calculator is really aimed at doing a display calibration with some type of a color management system (CMS). It you only have Color and Hue controls you are extremely limited in what you can do.
Quote:
Originally Posted by Originally Posted by kjgarrison

When I use your calculator with inputs for the "custom" primary colors' xy coordinates, I get lines from the primaries to their respective secondaries that intersect nicely and reassuringly at the white point. The secondaries are not, of course, where the Rec709 (the standard I choose) secondaries are located, but the primaries and their secondaries are lined up right with respect to white (D65).

Of course on re-reading your posts above, I now see and understand that you said that is exactly how it is supposed to work. And that this just means that my TV is doing it's color decoding in a standard way, making this more of a test of how my TV works than a tool for me to adjust it's faulty colors.

YES! You have it now. If the lines connecting primaries to their corresponding complementary colors ALL intersect at the white reference, then your YCbCr->RGB color decoder is working in a standard manner (it is "orthogonal" in technical terms) and there are no other "odd" non-linearities in the system. This a pre-requisite to achieving totally accurate color using YCbCr (digital) or YPbPr (analog) input signals. (If you input RGB signals, then this should always be true because there is no color decoding.) Once you have the color decoding correct, it is then necessary to have the correct RGB primary x,y values and the correct white point (and a constant gray scale) to achieve totally accurate color. And that requires a CMS or a display with standard primaries.

If you only have Color and Hue controls (no CMS) then the only things you can do to improve color accuracy if you have non-standard primary colors is to "slightly" modify the white reference point to shift the complementary colors closer to the standard, and/or to use the Hue control to simultaneously rotate all of the complementary colors closer to their standard targets. The calculator can help you minimize the errors when making those adjustments. When you are done with that you will probably not like the flesh colors on every piece of video you watch. You would then adjust the Color control to optimize the appearance of the flesh tones, and you might find the Color control would be a little different for different source material (such is the nature of trying to compromise a non-accurate system).

If you have TV with service level adjustments for the color decoder, you could also modify the color decoding (so it's no longer orthogonal - as defined above) which can also help to improve the overall color accuracy in a system with the wrong primary colors. But that is definitely not something anyone should do unless they have great experience in these matters, because A) you are more likely to make things worse than when you started even if it looks better to you on a few things, and B) if you aren't careful keeping exact track of what you did, you may never get back to the factory setup. This is a real recipe for disaster - you were warned!

As a long time DScaler user - excellent work by the way, I am really looking forward to your work on the HCFR fork.One lazy convenience feature I would like is a button to recalibrate the meter directly from the toolbar, without having to select the meter dialog first..
Quote:
Originally Posted by jdbimmer

Exactly. There is a lot of misunderstanding regarding the use of Greg Rogers' display calculator and other related spreadsheets. The clearest quote (and the whole thread is a good read) is: http://www.avsforum.com/avs-vb/showthread.php?p=16329415#post16329415

Thanks for the link i'll take a look.

Quote:
Originally Posted by jdbimmer

.One lazy convenience feature I would like is a button to recalibrate the meter directly from the toolbar, without having to select the meter dialog first..

Quote:
Originally Posted by zoyd

There is no point in knowing alternative [Y] targets, they will not give you a better dE.

Yes they will, for the reason that an increase in saturation is perceived by human vision as an increase in brightness (Y). Thus, in order to minimise dE, Y should be reduced for colours that are oversaturated, per the formula.
Quote:
Originally Posted by assm0de

Yes they will, for the reason that an increase in saturation is perceived by human vision as an increase in brightness (Y). Thus, in order to minimise dE, Y should be reduced for colours that are oversaturated, per the formula.

I think "better dE" in the original context meant lower dE (including L diff) against the actual primary targets.

Obviously if you change your target to be based off your actual primaries you'll be nearer to those but what have you achieved by doing that? Your display hasn't got more accurate because you're using a different formula or target and in fact by using a different target you may well end up making things worse (as measured by dE to actual targets)

John
New Posts  All Forums:Forum Nav:
Return Home
Back to Forum: Display Calibration
• Fork of HCFR Started - What's needed?

### AVS Top Picks

AVS › AVS Forum › Display Devices › Display Calibration › Fork of HCFR Started - What's needed?