MadVR - ArgyllCMS - Page 16 - AVS Forum
Forum Jump: 
 20Likes
Reply
 
Thread Tools
post #451 of 2510 Old 07-08-2013, 12:59 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,420
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 19 Post(s)
Liked: 113
Quote:
Originally Posted by Chronoptimist View Post

The thing I liked about the 3DLUT support in MadVR was that I just entered values and it worked, it would be nice if it shipped with an integrated package that had a simple GUI and calibrated the display automatically.

Maybe I will build in support for Argyll automation sooner or later, I haven't decided yet. First of all I'd like to get more feedback from users confirming the parameters I suggested work well for them, too. Or maybe suggesting different parameters.

Back in the day I thought yCMS would be the one and only solution and there was no other calibration solution in sight that could be used as an alternative. Today the situation is a bit different. There's ArgyllCMS, which already supports madVR right now. But there's also Calman, ChromaPure and LightSpace, all of which might sooner or later add support for madVR, too. So I'm not sure if it makes sense for me to add a GUI for only one of these calibration solutions to madVR. But then, only one of them is free, so I might still do that.

Quote:
Originally Posted by Chronoptimist View Post

I suspect this would be very problematic when MadVR is only outputting 8-bit to my display - it's likely to introduce a lot of banding if you are reducing color from 100/100. At around 65/100 I can easily create test patches that measure BT.709 with 100% accuracy, so that is hopefully all that will be needed with ArgyllCMS.

You're forgetting dithering. There should not be any noticeable banding problems. Just give both (100/100 vs 65/100) a try to see which produces better results.
madshi is online now  
Sponsored Links
Advertisement
 
post #452 of 2510 Old 07-08-2013, 01:04 AM
AVS Special Member
 
Chronoptimist's Avatar
 
Join Date: Sep 2009
Posts: 2,559
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 203
Quote:
Originally Posted by madshi View Post

Maybe I will build in support for Argyll automation sooner or later, I haven't decided yet. First of all I'd like to get more feedback from users confirming the parameters I suggested work well for them, too. Or maybe suggesting different parameters.

Back in the day I thought yCMS would be the one and only solution and there was no other calibration solution in sight that could be used as an alternative. Today the situation is a bit different. There's ArgyllCMS, which already supports madVR right now. But there's also Calman, ChromaPure and LightSpace, all of which might sooner or later add support for madVR, too. So I'm not sure if it makes sense for me to add a GUI for only one of these calibration solutions to madVR. But then, only one of them is free, so I might still do that.
I use CalMAN, which supports automated calibration - though not with MadVR. I have not had good success with ArgyllCMS in the past, with a lot of banding showing in resulting calibrations. I use a separate package for PC LUT generation which mostly avoids banding, but CalMAN 5 was supposed to have PC LUT generation when I bought it, but I have never been able to figure out how though.
Quote:
Originally Posted by madshi View Post

You're forgetting dithering. There should not be any noticeable banding problems. Just give both (100/100 vs 65/100) a try to see which produces better results.
I definitely see an increase in banding and posterization when using yCMS. Dither can only help so much, and it's likely due to interactions between the display's LUT and the video card/madvr LUT. Too bad no televisions allow direct LUT manipulation like some PC monitors do. (Eizo)
Chronoptimist is offline  
post #453 of 2510 Old 07-08-2013, 03:03 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by madshi View Post

Is it the display which went into sleep mode or the whole PC? Not sure how to prevent that, will have to investigate...
Call SetThreadExecutionState(ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED) every now and again (I call it every patch update typically), and this seems to stop the screensaver and powersaver, seems to work OK in NT4 through to Win8.
gwgill is offline  
post #454 of 2510 Old 07-08-2013, 03:06 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,420
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 19 Post(s)
Liked: 113
Quote:
Originally Posted by gwgill View Post

Call SetThreadExecutionState(ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED) every now and again (I call it every patch update typically), and this seems to stop the screensaver and powersaver, seems to work OK in NT4 through to Win8.

Thanks for the heads up. The latest version v0.86.8 already calls "ES_DISPLAY_REQUIRED | ES_CONTINUOUS" and that seemed to do the trick on a quick check.
madshi is online now  
post #455 of 2510 Old 07-08-2013, 03:42 PM
AVS Special Member
 
gtgray's Avatar
 
Join Date: Jul 2006
Posts: 3,379
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 12 Post(s)
Liked: 44
I have been watching this thread for a long time. While I am all for a free solution and interface to ChromaPure or Calman would be ideal. I use ChromaPure with a Radiance and it is idiot proof enough for me to get excellent results doing auto-calibration. If all I had to do was is run ChromaPure and let it and madVR talk together and set do all the configuration that would be sensational. If SpectraCal provided that support I would finally by the Enthusiast version.

I just don't want to fight a battle with a command line driven interface. Not that it scares me, as I assume batch files can handle that. I just need to know that it works properly and produces results beyond what I get with the Radiance alone. I have pretty much made JRiver my media center and all playback is with madVR anymore.

I have not been willing to spend the time experimenting with the many recent releases.... I just have to much going on and for me that kind of work (calibration) needs to happen after everyone else in the house goes to bed. So it kind of needs to work... it is a feature I would have no problem paying for.

Just another blank signature.
gtgray is offline  
post #456 of 2510 Old 07-08-2013, 07:55 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by madshi View Post

I'd like to have your opinion on "-ir" vs "-iaw". On my display "-iaw" seems to work better, but I've seen you suggesting "-ir".
It would help if you explained more specifically what you mean by "better" ?
Quote:
Maybe it depends on the circumstances which one produces better results? E.g. does one of them work better with too wide primaries and the other one with too narrow primaries? Or are there any other circumstances where you would recommend "-ir" over "-iaw" or vice versa? Thanks!
There's probably not a whole lot of difference between -iaw and -ir in practice, although -iaw hasn't been as extensively tested. -ir has the advantage of relying on the more detailed calibration for setting the white point, and avoiding any possibility of clipping due to any discrepancy in the white point measurements between calibration and profiling. There may well be the latter, since calibration pretty much relies on one set of measurements to establish the white point, wheras in profiling the white point is the consensus of the model applied to all the data points. Relying on the calibration to establish the white point opens up the full range of white point relative intents, including Perceptual to more smoothly map a large gamut into a smaller gamut, or Saturation, which will also expand a smaller gamut to fill a larger one.
gwgill is offline  
post #457 of 2510 Old 07-08-2013, 11:48 PM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,420
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 19 Post(s)
Liked: 113
Quote:
Originally Posted by Chronoptimist View Post

I use CalMAN, which supports automated calibration - though not with MadVR. I have not had good success with ArgyllCMS in the past, with a lot of banding showing in resulting calibrations. I use a separate package for PC LUT generation which mostly avoids banding, but CalMAN 5 was supposed to have PC LUT generation when I bought it, but I have never been able to figure out how though.
I definitely see an increase in banding and posterization when using yCMS. Dither can only help so much, and it's likely due to interactions between the display's LUT and the video card/madvr LUT.

Banding/posterization can have multiple reasons. If the 3dlut has banding baked in, dithering won't help. However, if the 3dlut is "good", I don't think there should be visible banding.

Quote:
Originally Posted by gtgray View Post

I have been watching this thread for a long time. While I am all for a free solution and interface to ChromaPure or Calman would be ideal. I use ChromaPure with a Radiance and it is idiot proof enough for me to get excellent results doing auto-calibration. If all I had to do was is run ChromaPure and let it and madVR talk together and set do all the configuration that would be sensational. If SpectraCal provided that support I would finally by the Enthusiast version.

I just don't want to fight a battle with a command line driven interface. Not that it scares me, as I assume batch files can handle that. I just need to know that it works properly and produces results beyond what I get with the Radiance alone. I have pretty much made JRiver my media center and all playback is with madVR anymore.

I have not been willing to spend the time experimenting with the many recent releases.... I just have to much going on and for me that kind of work (calibration) needs to happen after everyone else in the house goes to bed. So it kind of needs to work... it is a feature I would have no problem paying for.

For now ArgyllCMS is the only choice we have, and from my tests it seems to work fine. Of course I can't compare it to the commercial solutions because they don't support madVR, so I can't really say whether they would produce better or worse results. At least the SpectraCal guys already expressed interest in maybe adding madVR support, but it's been a while and they didn't really do anything yet. Maybe I'll ping them about it again later, but first I'd like to get ArgyllCMS+madVR working well, and fix the last madVR/madTPG related bugs (if there are any).

Quote:
Originally Posted by gwgill View Post

It would help if you explained more specifically what you mean by "better" ?

Well, have a look at these HCFR results, comparing -ir and -iaw on my LCD computer monitor (and of course for I've used "dispcal -qu -t6500 -gs" for both of these):

gamma.jpg - rgb.jpg - cie.jpg <-- collink -ir
gamma.jpg - rgb.jpg - cie.jpg <-- collink -iaw

As far as I can see, -iaw beats -ir in all those HCFR test results. Or am I misinterpreting the HCFR results?

Quote:
Originally Posted by gwgill View Post

There's probably not a whole lot of difference between -iaw and -ir in practice, although -iaw hasn't been as extensively tested. -ir has the advantage of relying on the more detailed calibration for setting the white point, and avoiding any possibility of clipping due to any discrepancy in the white point measurements between calibration and profiling. There may well be the latter, since calibration pretty much relies on one set of measurements to establish the white point, wheras in profiling the white point is the consensus of the model applied to all the data points. Relying on the calibration to establish the white point opens up the full range of white point relative intents, including Perceptual to more smoothly map a large gamut into a smaller gamut, or Saturation, which will also expand a smaller gamut to fill a larger one.

Please try to see this from an end user point of view: End users don't really want to study color science in order to be able to use ArgyllCMS. What you're saying probably sounds like rocket science to the typical end user and just makes them afraid to even try. They simply want to know "Which intent should I be using?". And they want a simple answer. In the best case the answer should be: "The recommended intent to use is -bla". In the worst case the answer should be: "If your primaries are too wide, the recommended intent is -bla. If some of your primaries are too narrow, the recommended intent is -bla2."

You can see in the last 1-2 pages of this thread that there are a number of users who'd like to try madVR+ArgyllCMS, but they shy away from using the command line tools, and from understanding all those complex parameters. So I think in order to make madVR+ArgyllCMS fit for the "masses", we should find defaults for all parameters that produce good results in the majority of situations and then maybe I can write a little GUI to automate the whole process somehow. For that I would need to decide e.g. which intent I should be using. So it's important for me to know which intent is "best". Yes, I know, probably all of those intents have their advantages and disadvantages, and probably there is no "best" intent. But I have to use/recommend some default, and it should ideally result in pleasing image quality and also in cleanly looking HCFR measurement reports. So which would you recommend for such a "one fits all" intent? And would you recommend a different intent if the primaries are too wide vs. too narrow?
Elix and kasper93 like this.
madshi is online now  
post #458 of 2510 Old 07-09-2013, 02:12 AM
AVS Special Member
 
Elix's Avatar
 
Join Date: Jun 2011
Location: Dungeon, Pillar of Eyes
Posts: 1,184
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 23
I can sign under these words. I am going to try your parameters this week if it helps.
Elix is offline  
post #459 of 2510 Old 07-09-2013, 08:49 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by madshi View Post

Well, have a look at these HCFR results, comparing -ir and -iaw on my LCD computer monitor (and of course for I've used "dispcal -qu -t6500 -gs" for both of these):

gamma.jpg - rgb.jpg - cie.jpg <-- collink -ir
gamma.jpg - rgb.jpg - cie.jpg <-- collink -iaw

As far as I can see, -iaw beats -ir in all those HCFR test results. Or am I misinterpreting the HCFR results?
Neither result is close to what I'd hope to see.

Interpreting the significance of a log/log plot is difficult because it's not perceptual, as well as being numerically undefined at 0 and 100%. An L* error plot vs. level would be more useful. None the less, it seems rather far from what I'd expect. If I had the display in front of me I'd do a couple of readings at 80% and checks of the calibration, profile and link tables and figure out what is not right.

The RGB plot I assume is the neutral axis. Again, I'm not sure what use "RGB" values are, since they can't be a perceptual measure. a* b* delta E vs. L* would be more useful. But it would seem that the calibration white point goal or achievement is not correct. One possible explanation is that "dispcal -t 6500" is not quite the same as Rec709 white, although it's very close. Better would be to use "dispcal -w 0.3127,0.3290" [ I'll change the tutorial to reflect this. ] I'd be surprised if that explains the error completely, but without knowing what "RGB" means, it's hard to tell. Again, if I had the display in front of me then a look at the dispcal verbose output and a couple of measurements would quickly clear this up.

Interpreting the Chromaticity plot is also difficult. For one thing it's the wost possible scale - x,y is known to be highly non-perceptual, and then it's been highly squeezed in the y direction!. u'v' would be much better, and keep the scale square. But the main uncertainty is what's being plotted : are these the pure colorants from black to 100%. or are they a mid level from zero saturation to 100% ?
But it's nowhere near Zoid's results http://www.avsforum.com/t/1464890/eecolor-processor-argyllcms/90#post_23383629 which is what I'd expect out of an Argyll device link. Some quick checks on the previous profiles you've sent me hint that if the test values are pure RGB colorant values, then some of this may be a result of your display having too small a gamut in the blue, but this is not a complete explanation for the result. A problem in the calibration, profile or transform seems likely as well.
Quote:

You can see in the last 1-2 pages of this thread that there are a number of users who'd like to try madVR+ArgyllCMS, but they shy away from using the command line tools, and from understanding all those complex parameters.
I'm afraid I don't really get that reaction - there's no need to understand all possible parameters to use the software. It's designed to default to useful behaviour, and the tutorial shows exactly where to start when being applied to Video. Why are there so many options ? - mainly because people have asked for them, and the fact that it's a toolkit, not a single purpose application.

And I think it's a mistake to assume that a GUI would solve that problem - it might even make things worse by shoving all the options in your face, rather than them being invisible if you don't use them!

But it is what it is, about 15 years worth of effort, and I'm not about to attempt some radical change in it's curent form, since no-one is prepared to pay me to do it. That's the tradeoff for it being available for free, and being able to respond rapidly to bug reports and feature requests, and being cross platform.
Quote:
So I think in order to make madVR+ArgyllCMS fit for the "masses", we should find defaults for all parameters that produce good results in the majority of situations and then maybe I can write a little GUI to automate the whole process somehow. For that I would need to decide e.g. which intent I should be using. So it's important for me to know which intent is "best". Yes, I know, probably all of those intents have their advantages and disadvantages, and probably there is no "best" intent. But I have to use/recommend some default, and it should ideally result in pleasing image quality and also in cleanly looking HCFR measurement reports. So which would you recommend for such a "one fits all" intent? And would you recommend a different intent if the primaries are too wide vs. too narrow?
Defaults would be what the tutorial recommends. Other choice are for exploration and solving problems. I really don't understand why many people seem to ignore the tutorial, re-invent it all from scratch, and then complain that it's hard to do this !

Don't do that - follow the tutorial. If it's misleading or wrong, or doesn't allow for a common situation, let me know, and I'll fix it.
gwgill is offline  
post #460 of 2510 Old 07-09-2013, 11:44 PM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,420
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 19 Post(s)
Liked: 113
Quote:
Originally Posted by gwgill View Post

Neither result is close to what I'd hope to see.

Oh, ok. It was the best I could achieve...

Quote:
Originally Posted by gwgill View Post

Interpreting the significance of a log/log plot is difficult because it's not perceptual, as well as being numerically undefined at 0 and 100%. An L* error plot vs. level would be more useful. None the less, it seems rather far from what I'd expect. If I had the display in front of me I'd do a couple of readings at 80% and checks of the calibration, profile and link tables and figure out what is not right.

The RGB plot I assume is the neutral axis. Again, I'm not sure what use "RGB" values are, since they can't be a perceptual measure. a* b* delta E vs. L* would be more useful.

I've simply used the default HCFR settings and then the 3 tabs "Gamma", "RGB Levels" and "CIE Diagram". I'm far from a calibration expert. How can I create those L* error plot etc measurements you mentioned with HCFR?

Quote:
Originally Posted by gwgill View Post

But it would seem that the calibration white point goal or achievement is not correct. One possible explanation is that "dispcal -t 6500" is not quite the same as Rec709 white, although it's very close. Better would be to use "dispcal -w 0.3127,0.3290" [ I'll change the tutorial to reflect this. ] I'd be surprised if that explains the error completely, but without knowing what "RGB" means, it's hard to tell. Again, if I had the display in front of me then a look at the dispcal verbose output and a couple of measurements would quickly clear this up.

Interpreting the Chromaticity plot is also difficult. For one thing it's the wost possible scale - x,y is known to be highly non-perceptual, and then it's been highly squeezed in the y direction!. u'v' would be much better, and keep the scale square. But the main uncertainty is what's being plotted : are these the pure colorants from black to 100%. or are they a mid level from zero saturation to 100% ?

In HCFR I've used the "measure grayscale, primary and secondary colors" and "measure all colors saturation scales", whatever that does exactly. How can I switch HCFR to u'v' and how can I keep the scale square? I've simply used the HCFR defaults because I don't know any better.

Quote:
Originally Posted by gwgill View Post

But it's nowhere near Zoid's results http://www.avsforum.com/t/1464890/eecolor-processor-argyllcms/90#post_23383629 which is what I'd expect out of an Argyll device link. Some quick checks on the previous profiles you've sent me hint that if the test values are pure RGB colorant values, then some of this may be a result of your display having too small a gamut in the blue, but this is not a complete explanation for the result. A problem in the calibration, profile or transform seems likely as well.

Blue and red being to narrow was my best guess as for why the results are not as good as zoyd's. After all, zoyd's display can cover the whole gamut, while mine can't.

You're saying you could quickly find out what the problem is, by looking at the files and doing some quick measurements. Maybe you can guide me through it, if it's not too much work? That is, if you think this might be a bug in Argyll that is worth looking at. I can't really judge if it is...

Quote:
Originally Posted by gwgill View Post

I'm afraid I don't really get that reaction - there's no need to understand all possible parameters to use the software. It's designed to default to useful behaviour, and the tutorial shows exactly where to start when being applied to Video. Why are there so many options ? - mainly because people have asked for them, and the fact that it's a toolkit, not a single purpose application.

And I think it's a mistake to assume that a GUI would solve that problem - it might even make things worse by shoving all the options in your face, rather than them being invisible if you don't use them!

But it is what it is, about 15 years worth of effort, and I'm not about to attempt some radical change in it's curent form, since no-one is prepared to pay me to do it. That's the tradeoff for it being available for free, and being able to respond rapidly to bug reports and feature requests, and being cross platform.
Defaults would be what the tutorial recommends. Other choice are for exploration and solving problems. I really don't understand why many people seem to ignore the tutorial, re-invent it all from scratch, and then complain that it's hard to do this !

Please don't get me wrong: I don't expect you to change ArgyllCMS in any way. I know exactly where you're coming from, since my "eac3to" tool is also a command line tool with many options, and I let other developers create GUIs for it. I'm not trying to make you change Argyll in any way, the only thing I'm trying to find is a set of default parameters that could/should be used when using madVR+ArgyllCMS. Yes, there is the turorial, but it's not always totally clear which values are recommended in which situation. E.g. it mentions "-ir", "-ila", "-ip", "-ims", while you personally also told me "-iaw" might be worth a try. That are 5 options, and it's not really clear to the end user which one should be used. Then you also mention 3 different ways for "Viewing conditions adjustment and gamut mapping", without really explaining why or in which situation the end user should choose which of those 3 options.

Quote:
Originally Posted by gwgill View Post

Don't do that - follow the tutorial. If it's misleading or wrong, or doesn't allow for a common situation, let me know, and I'll fix it.

It's neither wrong nor misleading, but I find it not clear enough sometimes. The tutorial (and the whole ArgyllCMS documentation) feels to me like: "You can do A, or B, or C, or D", and then sometimes a technical explanation follows like "A uses a flux compensator, B instead uses black hole mechanics while C and D are based on the UltraViolet spec". Which all leaves the end user scratching his head which option he should choose, because the tutorial doesn't really clearly recommend one of the options, nor does it explain the benefits/disadvantages of the alternatives in real life. Ok, maybe I'm exaggerating a little bit, but I hope you get what I mean?

Ideally, IMHO the tutorial would contain a very specific recommendation which parameters to use exactly. For some things it does, but not for everything. If there are some alternatives at some point, then the tutorial could still mention them, but then it should also contain an explanation which clearly explains *why* (e.g. under which specific circumstances) you would use the alternative instead of the recommendation. And the explanation should try to avoid terms which only color science experts understand, and instead explain things in such a way that the average end user understands it.

Again: Please don't get me wrong. My current HTPC software doesn't even have any documentation at all, let a lone a tutorial. So you're WAY ahead of me. It's just that calibration is a quite difficult/complex topic, and after all these tests I've done I'm still not 100% sure if the Argyll parameters I've chosen are really the best I could choose or not...
madshi is online now  
post #461 of 2510 Old 07-10-2013, 12:38 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,432
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 80 Post(s)
Liked: 300
Quote:
Originally Posted by madshi View Post



Ideally, IMHO the tutorial would contain a very specific recommendation which parameters to use exactly. For some things it does, but not for everything. If there are some alternatives at some point, then the tutorial could still mention them, but then it should also contain an explanation which clearly explains *why* (e.g. under which specific circumstances) you would use the alternative instead of the recommendation. And the explanation should try to avoid terms which only color science experts understand, and instead explain things in such a way that the average end user understands it.

Again: Please don't get me wrong. My current HTPC software doesn't even have any documentation at all, let a lone a tutorial. So you're WAY ahead of me. It's just that calibration is a quite difficult/complex topic, and after all these tests I've done I'm still not 100% sure if the Argyll parameters I've chosen are really the best I could choose or not...

Calibration at this level of refinement requires a heavy user investment in learning how to evaluate the results using perceptual metrics (the various dE values) to zero in on the best settings. Often times this also includes specific knowledge on how a particular display interacts with the LUT and the degree to which it can be pushed around within it's nominal operating space. So coming up with default parameters to get you results below say dE of 5 (which you might have on average now) may be achievable but to get the kind of results where average dE < 1 has to be accomplished by the user.
zoyd is online now  
post #462 of 2510 Old 07-10-2013, 01:05 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,420
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 19 Post(s)
Liked: 113
Quote:
Originally Posted by zoyd View Post

Calibration at this level of refinement requires a heavy user investment in learning how to evaluate the results using perceptual metrics (the various dE values) to zero in on the best settings. Often times this also includes specific knowledge on how a particular display interacts with the LUT and the degree to which it can be pushed around within it's nominal operating space. So coming up with default parameters to get you results below say dE of 5 (which you might have on average now) may be achievable but to get the kind of results where average dE < 1 has to be accomplished by the user.

From a programming point of view, I see no reason why it shouldn't be possible to achieve "perfect" measurement results (within the accuracy and repeatability of the meter and display) without any user tweaks, as long as the display can cover the full source gamut. In theory, if you measured every possible 8bit color, it should be possible to create a 3dlut which achieves "perfect" results. Since we can't measure every possible color, we have to interpolate the measurements. Of course there's some accuracy loss expected due to the interpolation. But that's the only thing I see that would limit the accuracy of the calibration. So why would the user need to do learn how to "evaluate the results using perceptual metrics"? Shouldn't the software be able to do everything without needing any user involvement? The only thing the user should have to do is to make sure his display is configured in such a way that it covers the full source gamut. But probably I'm too naive and in real life things are not as simple as I imagine?

Anyway, let's say the user tweaks are necessary for some reason to achieve best results: How many users have the knowledge and the time to do such fine tuning? The users that have, can always use all the ArgyllCMS custom options. These are not the users I'm concerned about. I'm mostly concerned about end users who lack the knowledge and/or time to learn color science and who just want to achieve the best possible results with a simple one click solution. What are the best default options to use for these end users? Practically spoken: If I were to add a simple button to madVR which says "calibrate this display using ArgyllCMS", with no questions asked (literally), which Argyll parameters should I use? And if there is one option that you think I should offer to the end user, which would it be? And how would I explain this option to the average end user in a way he understands?

@zoyd, since you're the HCFR expert, can you tell me how to do those kind of measurements Graeme mentioned with HCFR? Thanks!
madshi is online now  
post #463 of 2510 Old 07-10-2013, 11:56 AM
Newbie
 
onaga's Avatar
 
Join Date: Jun 2009
Posts: 7
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
HI Guys

I have a question regarding the Calibretion in Madvr and the video card LUT, firts sorry if i writte too bad, english is not my native lenguaje.

My monitor does not have OSD controls exept for brightness, all gamma, color temperature, contrast and RGB levels it has to be done through the Video card LUT settings.

The Monitor Default settings are pretty out of the normal view condittion recommendation, default gamma its around 1.90, color temperature is too hight, like 7000k or so, pretty cold, the gamut its pretty weird too, it exceeds the red gamut point, the blue one es pretty nearly to the srgb recommendation and it lacks a very part of the green one.

Well, al this problems can be solve using a good colorimeter( i1 Display), using the Xrite program i can archive a good 2.20 gamma and a good color temperature (D65), the gamut it still pretty the same because off the leak of RGB controls i think, with all kind of measurement always ended the same(red too wide, green too out of the spot, blue in the sRGB spot).

so... this is my question, l create a 3dlut using all the recommendation in this thread, taking measurement without a profile active, using madvr test generetor etc, so, is there a problem if a i use, after creating the 3dlut, a third party program or the dispcal itselft in order to create a profile to correct the gamma ,white point and color temperature in all windows based programs?(specially in navigation).

the tutorial recommend to disable the gpu gamma ramps in madvr, but when i do this as i say, gamma go too low and color temperature raise pretty nasty.

its bad to ahve the 3dlut active in madvr meanwhile there is a icm profile correcting all the other settings in windows?.

also dispcal creates a .icm profile after the measurements, its bad use it for windows?

thanks!!! and very sorry if you have a hard time understanding my problem, specially for the writting, my english its no so good...
onaga is offline  
post #464 of 2510 Old 07-10-2013, 09:13 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by onaga View Post

the tutorial recommend to disable the gpu gamma ramps in madvr, but when i do this as i say, gamma go too low and color temperature raise pretty nasty.
Madshi & I have been working towards a solution to exactly this problem. The idea is to embed the VideoLUT curves in the 3dLut, so that MadVR can make sure that the graphics card is set correctly when playing video, or that calibration curves are being applied correctly when displaying video in overlay mode. MadVR will restore the original VideoLUT calibration when it exits.

This ensures correct video playback without having the compromise the normal desktop setup, and allows for different calibration curves for the two situations. It is then up to the user to decide how they want their calibration setup. One choice is to share a single set of VideoLUT curves between desktop and Video playback. This may mean compromising one function or the other (particularly white point - Video uses D65 while graphic arts typically aims for D50. I tend to use D55 as a compromise), but means that there will be no switch in appearance of the desktop when video is being played. The other choice is to use specialised calibration curves for each situation, and put up with the screen change during video playback, or use a video overlay mode or full screen.
gwgill is offline  
post #465 of 2510 Old 07-11-2013, 12:51 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by madshi View Post

So why would the user need to do learn how to "evaluate the results using perceptual metrics"?
Because otherwise you risk wasting your time on irrelevancies. Using a perceptual measure provides an objective means of ordering errors by perceived importance, and knowing when you've done enough.
Quote:
Anyway, let's say the user tweaks are necessary for some reason to achieve best results: How many users have the knowledge and the time to do such fine tuning?
I'm not much of a believer in tweaks - they tend to be a fallback when all else fails. An objective, repeatable process is the goal. But often there are tradeoffs, and it's typically best to leave it up to the end user to decide what tradeoffs they want to make.

Another aspect is that there are an unknown number of situations and equipment and equipment behavior out there - no one piece of software can hope to anticipate all possible such situations or behavior, or be thoroughly tested under all possible circumstances. So there are certainly many situations in which I'm guessing and extrapolating, and hence do not want to make pronouncements that are simply unfounded, nor cut off options that may turn out to be necessary, or may need to be explored simply to eliminate them. So the end users are just as much part of the process of development as cutting code, in providing feedback as to what works and what doesn't.
Quote:
The users that have, can always use all the ArgyllCMS custom options. These are not the users I'm concerned about. I'm mostly concerned about end users who lack the knowledge and/or time to learn color science and who just want to achieve the best possible results with a simple one click solution. What are the best default options to use for these end users? Practically spoken: If I were to add a simple button to madVR which says "calibrate this display using ArgyllCMS", with no questions asked (literally), which Argyll parameters should I use? And if there is one option that you think I should offer to the end user, which would it be? And how would I explain this option to the average end user in a way he understands?
If that is your aim, then you need to become familiar with what works and what doesn't yourself.
gwgill is offline  
post #466 of 2510 Old 07-11-2013, 01:05 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by madshi View Post

I've simply used the default HCFR settings and then the 3 tabs "Gamma", "RGB Levels" and "CIE Diagram". I'm far from a calibration expert. How can I create those L* error plot etc measurements you mentioned with HCFR?
Sure, I understand, but I can't help you much with HCFR, since it's not something I use. My comments were partly in relation to opportunities to improve HCFR for those in a position to influence it, and mostly to say that it's not really possible for me to make a judgement about how well the profiling process has worked in your situation from such results.
Quote:
You're saying you could quickly find out what the problem is, by looking at the files and doing some quick measurements. Maybe you can guide me through it, if it's not too much work? That is, if you think this might be a bug in Argyll that is worth looking at. I can't really judge if it is...


OK, here's how I'd check what's going on with the transfer curve:

[and a note for those following along, ArgyllCMS is a color management toolkit, so it is ideal for tackling unanticipated tasks. But there is no special Video "figure out what's wrong with my color" button, because that's very task specific. And this type of thing is necessary mostly because all this is still under development and verification, it's not something that should normally be needed.]

Grab the latest copy of the experimental tools, since I've made some changes to make the following processes simplier than they otherwise would be.

http://www.argyllcms.com/Win32_collink_3dlut_ex.zip

I'll show as examples the output of running these checks on my display.

First check - check if the 75% neutral axis output really has a significant error:

Run the link command again with the same options you used/are testing (to a dummy output file), with the -v flag (verbose output).

Capture the BT.1886 verbose information output, e.g.:

In 75.0% -> XYZ in 0.563522 -> bt.1886 0.536329, log/log 2.166, Lab 78.247177 -0.000040 0.000035

Run dispwin through the video display system to display a 75% patch:

MadTPG.exe

Check that the 3dLUT being checked is in place in MadVR settings and any calibration curves are properly in place.

dispwin -dmadvr -m

You advance each patch by hitting return.
Stop at the white patch for the moment.
In a different window run:

spotread -ew

and also set -y whatever or -X whatever to match your calibration/profiling setup

Take the white reference reading

Take another reading in the same spot and check that you get close to Lab 100, 0, 0

Hit return on the dispwin window to advance the patch to 75% grey.

Take a reading of 75% grey, and grab the 75% results, e.g.:

Result is XYZ: 51.252248 53.137075 43.809343, D50 Lab: 77.955860 0.046051 0.028869

Check it against the collink verbose output for 75% above.

So a delta E of about 0.244 - not bad considering my display is not very uniform, and I did the calibration and profile some weeks ago.


Second Check If there is a significant error, then start to figure out why it is occurring.

Lookup what 75% input is being translated to by the 3dLut:

xicclu -et -Et 3dlut.icm
0.750000 0.750000 0.750000 [RGB] -> Lut -> 0.768942 0.769324 0.767517 [RGB]

(I'll assume that you have used calibration curves.)

If you used -a to combine the calibration curves with the 3dlut, then undo the calibration curves of the above 3dlut output to return the calibrated device rather than raw device values:

xicclu -fb display.cal
0.768942 0.769324 0.767517 [RGB] -> 0.758770 0.750586 0.764098 [RGB]

If you didn't use -a because you used -H or you manually installed thecalibration curves using "dispwin display.cal", then the 3dLut output will be calibrated device values.

Lookup what the profile predicts for the display calibrate device values:

xicclu -ff -ir -pl display.icm

0.768942 0.769324 0.767517 [RGB] -> Lut -> 78.298016 -0.035602 -0.149678 [Lab]

Which is very close to the target value for 75% of Lab 78.247177 -0.000040 0.000035.

Third Check Check that the 3dLut output values result in the target color.

Translate the 75% calibrated device values to raw device values:

xicclu -ff display.cal
0.768942 0.769324 0.767517 [RGB] -> 0.778055 0.785218 0.770643 [RGB]

Feed that value to dispwin in native output mode:

dispwin -dmadvr -C 1,1,1 -C 0.778055,0.785218,0.770643 -n -m

and measure the result using white point relative:

spotread -ew

Result is XYZ: 50.852465 52.746204 43.123070, D50 Lab: 77.724916 -0.014366 .480866

which is very close to what we measured through the 3dLut and calibration curves in the first check.
gwgill is offline  
post #467 of 2510 Old 07-11-2013, 01:33 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by madshi View Post

Ideally, IMHO the tutorial would contain a very specific recommendation which parameters to use exactly. For some things it does, but not for everything. If there are some alternatives at some point, then the tutorial could still mention them, but then it should also contain an explanation which clearly explains *why* (e.g. under which specific circumstances) you would use the alternative instead of the recommendation. And the explanation should try to avoid terms which only color science experts understand, and instead explain things in such a way that the average end user understands it.
I understand what you mean, and I'll review it and try and re-inforce what to try first - but the problem is that I don't know what to recommend - I'm not omnipotent, and I only have a finite amount of time in the day!

So a lot of the alternatives are there along the lines of "try this out and tell me which works best", or "if the first thing doesn't work for you, here are some other things you could try".

The other aspect that I'm conscious of is that it will get very, very confusing, and very tedious to write and to read if I try and iterate out every possible combination. This sort of stuff isn't going to work:
Quote:
If you have a i1 display pro or ColorMunki display and are using a CRT, and this is listed as display 1, use:
dispcal -r c blach blah

If you have a i1 display pro or ColorMunki display and are using a CRT, and this is listed as display 2, use:

dispcal -d2 -r c blach blah

If you have a i1 display pro or ColorMunki display and are using a CCFL IPS LCD, and this is listed as display 1, use:

dispcal -r l

If you have a i1 display pro or ColorMunki display and are using a RGB LED IPS LCD, and this is listed as display 1, use:

dispcal -r b

If you have a i1 display pro or ColorMunki display and are using a RGB LED IPS LCD, and this is listed as display 2, use:

dispcal -d2 -r b

.
.
.
and on ad infinitum. The possible combinations are astronomical, so it's up to the user to be smart enough once they are given the hint, to pick the combinations they need.
gwgill is offline  
post #468 of 2510 Old 07-12-2013, 02:36 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,432
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 80 Post(s)
Liked: 300
Quote:
Originally Posted by madshi View Post

Quote:
Originally Posted by zoyd View Post

Calibration at this level of refinement requires a heavy user investment in learning how to evaluate the results using perceptual metrics (the various dE values) to zero in on the best settings. Often times this also includes specific knowledge on how a particular display interacts with the LUT and the degree to which it can be pushed around within it's nominal operating space. So coming up with default parameters to get you results below say dE of 5 (which you might have on average now) may be achievable but to get the kind of results where average dE < 1 has to be accomplished by the user.

From a programming point of view, I see no reason why it shouldn't be possible to achieve "perfect" measurement results (within the accuracy and repeatability of the meter and display) without any user tweaks, as long as the display can cover the full source gamut. In theory, if you measured every possible 8bit color, it should be possible to create a 3dlut which achieves "perfect" results. Since we can't measure every possible color, we have to interpolate the measurements. Of course there's some accuracy loss expected due to the interpolation. But that's the only thing I see that would limit the accuracy of the calibration. So why would the user need to do learn how to "evaluate the results using perceptual metrics"? Shouldn't the software be able to do everything without needing any user involvement? The only thing the user should have to do is to make sure his display is configured in such a way that it covers the full source gamut. But probably I'm too naive and in real life things are not as simple as I imagine?

Anyway, let's say the user tweaks are necessary for some reason to achieve best results: How many users have the knowledge and the time to do such fine tuning? The users that have, can always use all the ArgyllCMS custom options. These are not the users I'm concerned about. I'm mostly concerned about end users who lack the knowledge and/or time to learn color science and who just want to achieve the best possible results with a simple one click solution. What are the best default options to use for these end users? Practically spoken: If I were to add a simple button to madVR which says "calibrate this display using ArgyllCMS", with no questions asked (literally), which Argyll parameters should I use? And if there is one option that you think I should offer to the end user, which would it be? And how would I explain this option to the average end user in a way he understands?

@zoyd, since you're the HCFR expert, can you tell me how to do those kind of measurements Graeme mentioned with HCFR? Thanks!

Every display and sensor has its limitations as well as the correction LUT, so the user must learn these limitations for her own equipment and balance them using dE metrics and experimentation. At some level this becomes just an academic exercise as you reach the limits of the equipment precision and your own perception.

An HCFR tutorial is on my todo list.
zoyd is online now  
post #469 of 2510 Old 07-13-2013, 12:11 PM
Newbie
 
onaga's Avatar
 
Join Date: Jun 2009
Posts: 7
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by madshi View Post

The "-H" parameter is an invention of Graeme. He hasn't made it officially available yet, though. Basically you use "-H" instead of "-a" to attach the "cal" file to the 3dlut, and the 3dlut is then created in such a way that it builds on top of this cal file. If you load such a 3dlut in madVR, v0.86.7 will automatically load the cal file into the GPU VideoLUTs. The purpose of this solution is that you can get calibration for Photoshop and other applications active at the same time as madVR 3dlut correction. The final calibration quality in madVR might be a bit less accurate compared to using a "simple" 3dlut (and disabling the GPU VideoLUTs), though, because the GPU VideoLUTs are simply lower quality compared to what madVR does. But if it's important for you to have other applications calibrated at the same time as video playback then this is an option for you...

Is this parameter already working?¿
onaga is offline  
post #470 of 2510 Old 07-14-2013, 01:32 AM
Newbie
 
manoutdoor's Avatar
 
Join Date: Jul 2013
Posts: 2
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Playback was a bit choppy so I may be at the limits of what my PC can handle.thank you 5.gif
manoutdoor is offline  
post #471 of 2510 Old 07-14-2013, 12:59 PM
Advanced Member
 
hungro's Avatar
 
Join Date: Mar 2007
Posts: 587
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 10 Post(s)
Liked: 52
Do I place my meter on the laptop screen ? then run the patterns using DisplayCalGUI .I am using a laptop to calibrate with. I got to the point that calibration and profiling is complete but I did not install the profile step 14 in the "Old Work Flow" Where do I go from here?
hungro is offline  
post #472 of 2510 Old 07-15-2013, 11:15 AM
Member
 
Some dillweed's Avatar
 
Join Date: Dec 2009
Posts: 46
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
I'm sorry if it's been asked previously, but I didn't really see anything in-depth up to now and I'm curious as to the pre-calibration or pre-"calibrate&profile" steps we should be taking before using ArgyllCMS (or dispcalGUI).

Up to this point (before kind of finding out about the more in-depth uses of ArgyllCMS/dispcalGUI), my general workflow has been:
  • set LG's colour space to Standard since it seems to produce the closest to "proper" results for HCFR's colour saturation points (not sure if this is right)
  • set brightness by the method where you measure pure [0,0,0] black and lower until it doesn't get any darker,
    or
  • set brightness so the 5% point's gamma in HCFR is in line with the rest at 2.20 with "Display gamma with black point compensation" enabled
  • set contrast as high as possible that maintains the ability to produce a D65 pure [255,255,255] white (with the appropriate grayscale adjustments on the TV)
  • adjust the available 10-point grayscale to as flat as possible 2.20 across all values (whether black point compensation is enabled or not)
  • adjust tints on a couple of colours if needed (after hearing/reading more about this, I'm questioning whether the CMS, main Color and main Tint should be adjusted at all from their defaults)
  • if needed, readjust brightness in MPC-HC (with madVR) using the AVSHD or GCD black clip pattern
  • if brightness adjustments were made, re-check the colour balance and adjust red and blue values if necessary, leaving greens as they ended up

And most recently, I've gone from there to experimenting with dispcalGUI to create a calibration and profile using 2.2 gamma and XYZ LUT + matrix options.

This is all using the standard HDMI (no PC label) "ISF Expert" settings on my TV with an EDID override on my Nvidia video card to get a proper 4:4:4 signal. Everything's set to 0-255 full RGB levels because I only use the TV hooked up to my PC.

So, I kind of have a few of questions related to this:
  1. Am I wrong to use black point compensation in HCFR?
  2. Should I stick to the non-PC mode since it doesn't seem to have the forced Edge Enhancer that the PC mode has? Or would the PC mode still likely be the least affected signal on an LG 42LK450?
  3. The Wide gamut option shifts reds towards orange but green is closer to a proper hue, Standard shifts greens slightly towards yellow but red and blue seem to line up better, and the PC mode has a response similar to what zoyd posted here a while ago, but with a couple of colours skewing in different directions. Am I right in choosing to calibrate to the non-PC mode Standard gamut?
  4. Is there anything else immediately noticeably wrong with what I've been doing?

Sorry for the wall of text that is essentially a cry for help. I know zoyd mentioned something about trying to write up an HCFR tutorial. I just figured that I'd post what I've been doing and see if there's anything inherently wrong with how I'm handling this in my pre-calibration process.

Oh yeah, one other thing as far as how the 3D LUTs and profiles are actually used by your system: as I understand it, profiles/.icm files are only useful for colour-managed programs, which basically means they're not applied to things like games, for instance. Is the 3D LUT information only stored in the profile, so you won't be able to make use of it unless using a colour-managed program (like the madVR renderer)? That's my general understanding, but I just want to make sure. If that's the case, then what should people like me be doing with the on-TV controls before getting to the ArgyllCMS or dispcalGUI "Calibrate" step?
Some dillweed is offline  
post #473 of 2510 Old 07-15-2013, 11:50 PM
Member
 
nezil's Avatar
 
Join Date: May 2013
Location: Northern California - SF Bay Area
Posts: 112
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 29
@Some dillweed:

You mention that you're using an LG display, but you don't say if it's an LCD (CCFL or LED) or Plasma model, which does have some impact on the methodology.

I personally have an LG 50PK950 TV, which is a 50" Plasma model about 3 years old. I do also have a 47" LG LCD, but I've not started the work on calibrating that yet, as I prefer the look of the Plasma picture (at least I did 3 years ago - LCD has caught up quite a bit since then). I'll talk you through what I've tried since then, and what I'm now using, along with notes for what I'd do if I were working with the LCD.

TV Settings

On my Plasma TV, the 'Wide' gamut mode provides a native response that is far wider than Rec.709 for the Red and Green primaries. The 'Normal' gamut mode is closer to Rec.709, but actually pulls the Green and Red inside the gamut a little too much. The brief testing that I did with the LCD showed that the gamut setting did absolutely nothing. I think it might be left in the OSD from the Plasma image adjustments, and simply doesn't have a function with LCD... but that might just be my LCD!

Given that knowledge:
  • I set ISF Expert Mode 1 to Wide Gamut, Black Level High, and leave the rest untouched. This will be used for the ArgyllCMS / madVR calibration. This is the input mode used for my HTPC, which I use for almost all my video.
  • I set ISF Expert Mode 2 to Standard Gamut, and then go through a normal calibration process that you described in your post. This is the input mode used for other video sources that won't work with a 3DLUT(BD Player / Apple TV etc.)

Side note: You mentioned that you had done an EDID override that enabled 4:4:4 processing; could you let me know some more about this. I did play with the Input labelling and found that I was able to get 4:4:4 processing at 60p if I set the label to 'PC'. I was never able to get 24p 4:4:4 working with my TV, and I'd love to know what you did to achieve that!

PC Process

First things first, as you already mentioned, your graphics card should be set to 0-255 rather than 16-235 and RGB rather than YCbCr. If necessary, use madshi's NVLevelTweaker to make sure that your graphics card really is outputting 0-255.

The rest of the process is basically what madshi detailed on page 15, but I'll repeat it here so that it's all in one place - credit to madshi for detailing this first (not to mention his work creating and updating madVR!).

Make sure you've got the latest version of the updated tools from Graeme (see first post), as well as the latest madVR build which includes the Test Pattern Generator. You can set yourself up using a second display on your HTPC, or you can run madTPG on your HTPC, and ArgyllCMS on a laptop - this is the approach I used, as I didn't have a spare second display handy.

First calibrate your display using dispcal:

  • Start madTPG, and set it up as you'd like it. For most of the calibration, you'll want to disable VideoLUTs and disable 3dlut. If you're working on a Plasma display, you'll want the 'Image Area' set as small as possible, 'Background level' as low as possible, Disable OSD and the TPG full screen. For a Plasma at least, this will result in a totally black screen.
  • On the laptop, or in a second screen window, run the dispcal command to calibrate the display to the sRGB Gamma curve with a White point of 6500K:
    Code:
    dispcal -v -dmadvr -m -qu -gs -w 0.3127,0.3290 dispcal
    
  • The -m switch deactivates prompts for adjusting display settings. Since we're trying to get the best results from the display's native response, these prompts aren't necessary.
  • You might want to use a Colorimeter Calibration Spectral Sample file to get more accurate results (-X switch). If you do use this, make sure to use the same one in HCFR later when you check your results. I used the Plasma family one myself, and was happy with the results.
  • Resulting File: dispcal.cal

If you'd like, at this point you can install the resulting dispcal.cal file temporarily on your HTPC and test the results using HCFR. Set this up to also use madVR as the renderer, and to use the same .ccss spectral sample file if you used one in the calibration. Make sure that madTPG does not disable VideoLUTs this time!

You should see in HCFR, that the white point is now pretty good, and the gamma is a smooth curve. It shouldn't represent the BT.1886 curve, and that's because we asked dispcal for an sRGB curve. The primaries should not have changed at all, and that's fine for this part of the process.

Create a set of test patches:

  • Run targen with the parameters that you'd like to use, in order to generate a set of test patch values. Madshi recommends the following:
    Code:
    targen -v -d3 -G -g100 -s40 -f3000 dispread
    
  • The larger the set of patches, the longer it will take to profile your display. Since I left mine going whilst doing something else, I chose 6500 total patches, with 100 grey, and 100 single channel patches. 6500 patches took several hours in the next section, and was almost certainly overkill.
  • Resulting File: dispread.ti1


Profile the display

  • Using the newly created patch set, profile the display, applying the calibration file to the test values when taking the measurements:
    Code:
    dispread -v -dmadvr -K dispcal.cal dispread
    
  • Make sure the madTPG is set to disable VideoLUTs again before you start!
  • If you used a .ccss file previously, you'll want to use that again here with the -X switch.
  • This will take a while, depending on the size of your patch set...
  • Resulting File: dispread.ti3


Create an ICC profile

  • Using colprof, create an .icm profile from the readings you just made
    Code:
    colprof -v -qh -aX dispread
    
  • If you have time to spare, you could run the 'Ultra' quality process for this, using -qu rather than -qh
  • Resulting File: dispread.icm


Link ICC profiles and create a madVR compatible 3DLUT

  • Use the collink command to link the dispread.icm profile you just created to the Rec709.icm profile, and create a 3dlut file
    Code:
    collink -v -qh -G -iaw -Ib -3m -et -Et -a dispcal.cal Rec709.icm dispread.icm 3dlut.icm
    
  • The -a switch tells collink to include the dispcal.cal data into the resulting 3dlut
  • Again, if you have spare time, you could run the 'Ultra' quality process using -qu rather than -qh. I did this, and found negligible difference, and therefore probably wouldn't bother another time.
  • Resulting File: 3dlut.icm & 3dlut.3dlut


Usage

Now it's simply a case of telling madVR to use the resulting .3dlut file in the settings page.

You can test your results by using HCFR and madTPG, though make sure that madTPG is not set to disable 3dlut, and is set to disable VideoLUTs.


Other Usage Scenarios

  • As madVR is set to disable VideoLUTs, you could install the dispcal.cal file to your OS, and this would fix the white point for all applications. madVR won't use, and will actually disable the VideoLUT when it runs, but it will re-enable it when you stop playing a file. This won't straighten out any colour issues native to your display, but will at least set the white point correctly. My understanding is that the VideoLUTs will be disabled even if madVR is running in a window, which may not be desirable if you're doing something else with your display other than watching a video.
  • If you'd like to use the VideoLUTs all of the time, you can use the -H option in collink, which will then include the VideoLUTs in the 3dlut file, rather than use them to build the 3dlut file. madVR can then load this file into the graphics card when a video is played. This is at the expense of some image quality, theoretically.
  • It is also possible to load the VideoLUTs file before the profiling stage, and then just set madVR and madTPG to not disable VideoLUTs, again, potentially sacrificing some image quality.
Some dillweed likes this.
nezil is offline  
post #474 of 2510 Old 07-16-2013, 12:33 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,420
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 19 Post(s)
Liked: 113
Quote:
Originally Posted by gwgill View Post

I'm not much of a believer in tweaks - they tend to be a fallback when all else fails. An objective, repeatable process is the goal. But often there are tradeoffs, and it's typically best to leave it up to the end user to decide what tradeoffs they want to make.

I agree with that it would be nice to not have to do tweaks. The problem with the tradeoffs is that the normal user doesn't know how to evaluate and compare tradeoffs and how to judge which is the best overall solution. I don't know these things myself.

Quote:
Originally Posted by gwgill View Post

Another aspect is that there are an unknown number of situations and equipment and equipment behavior out there - no one piece of software can hope to anticipate all possible such situations or behavior, or be thoroughly tested under all possible circumstances. So there are certainly many situations in which I'm guessing and extrapolating, and hence do not want to make pronouncements that are simply unfounded, nor cut off options that may turn out to be necessary, or may need to be explored simply to eliminate them. So the end users are just as much part of the process of development as cutting code, in providing feedback as to what works and what doesn't.

Yes, I can perfectly understand that. You probably do have a lot more experience with which Argyll options can have which effects and may produce which tradeoffs, compared to everyone else, though. So even if you're guessing and extrapolating, your guesses are probably more reliable than those of most other people, so I still value them.

Quote:
Originally Posted by gwgill View Post

Sure, I understand, but I can't help you much with HCFR, since it's not something I use. My comments were partly in relation to opportunities to improve HCFR for those in a position to influence it, and mostly to say that it's not really possible for me to make a judgement about how well the profiling process has worked in your situation from such results.

@zoyd? biggrin.gif

@Graeme, if I may ask, which software are you using instead of HCFR to double check the quality of ArgyllCMS calibrations?

Quote:
Originally Posted by gwgill View Post

OK, here's how I'd check what's going on with the transfer curve: [...]

Thanks, I'll give this a try when I find some time.

Quote:
Originally Posted by gwgill View Post

I understand what you mean, and I'll review it and try and re-inforce what to try first - but the problem is that I don't know what to recommend - I'm not omnipotent, and I only have a finite amount of time in the day!

So a lot of the alternatives are there along the lines of "try this out and tell me which works best", or "if the first thing doesn't work for you, here are some other things you could try".

Yes, I fully understand. But I think you probably do have a certain order of things you would try yourself, if you had to calibrate a new display. E.g. first of all you would try intent "blabla". And if that didn't work as well as expected, maybe you would try intent "blabla" instead etc. If you calibrate a new display yourself, you don't try *all* intents and compare them, do you? This is information that would be valuable to the average user to save some time...

Quote:
Originally Posted by gwgill View Post

The other aspect that I'm conscious of is that it will get very, very confusing, and very tedious to write and to read if I try and iterate out every possible combination. This sort of stuff isn't going to work: [...]
and on ad infinitum. The possible combinations are astronomical, so it's up to the user to be smart enough once they are given the hint, to pick the combinations they need.

Of course, I would never expect something like that, that's very much overkill. What I'd like to see is simply a short summary of which thought processes *you* would go through when deciding which parameters to use as the very first try when calibrating a new display. User are not stupid, so you don't have to spell out everything to the last letter. But a short summary of your own workflow to find the "best" options for a new display would be interesting and helpful, I think. Additionally I could imagine you posting some guidelines separated for each important option. E.g. would something like the following make sense?

(1) Hints to choose the intent:

- if your display's primaries are all too wide, first try intent "-blabla"
- if your display's primaries are all too narrow, first try intent "-blabla"
- if your display's primaries are already mostly correct, first try intent "-blabla"
- intent "-blabla" has the practical benefit of maximizing contrast and brightness, while compromising on ...
- intent "-blabla" has the practical purpose of achieving perfect colors, but compromises on ...
- if you have a plasma, definitely try intent "-blabla" first
- if you have meter blabla, the intent "-blabla" may produce weird ...

(2) Hints to choose the ...

You get what I mean? Just a lose list of hints, based on your experience, helping the user find a good intent to try for his setup. Same for other important options. The hints can be as vague as you like, with words like "often" and "sometimes" thrown in to make sure everybody gets that they're just some random experiences and may not be true for every hardware. Still such a list of hints could be very helpful, I think. But I don't know if this is feasible, it's just what came to my mind...

Quote:
Originally Posted by nezil View Post

[*] Start madTPG, and set it up as you'd like it. For most of the calibration, you'll want to disable VideoLUTs and disable 3dlut.
Quote:
Originally Posted by nezil View Post

[*] Make sure the madTPG is set to disable VideoLUTs again before you start!

FWIW, I think dispcal and dispread auto disable VideoLUTs and 3dlut via the madTPG remote API, so you shouldn't have to do this manually.

Nice summary overall.
madshi is online now  
post #475 of 2510 Old 07-16-2013, 12:40 AM
Member
 
nezil's Avatar
 
Join Date: May 2013
Location: Northern California - SF Bay Area
Posts: 112
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 29
And here are my results:

LG 50PK950 Plasma - THX Cinema Mode (Standard Gamut, Black Level High) - No Correction:
LG 50PK950 Plasma - ISF Expert Mode (Wide Gamut, Black Level High) - Dispcal Calibration Only:
LG 50PK950 Plasma - ISF Expert Mode (Wide Gamut, Black Level High) - ArgyllCMS / madVR Correction:
I think there is still work to be done, as the white point is really nice at lower IREs, but degrades somewhat after the collink. This was the best I've been able to achieve so far, and it does look very good.
nezil is offline  
post #476 of 2510 Old 07-16-2013, 01:54 PM
Member
 
Some dillweed's Avatar
 
Join Date: Dec 2009
Posts: 46
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally Posted by nezil View Post

@Some dillweed:

You mention that you're using an LG display, but you don't say if it's an LCD (CCFL or LED) or Plasma model, which does have some impact on the methodology. [...] The rest of the process is basically what madshi detailed on page 15, but I'll repeat it here so that it's all in one place - credit to madshi for detailing this first (not to mention his work creating and updating madVR!).
Wow. Well, thank you both for the detailed processes, then. I'm using a 42LK450 (a 2011 CCFL LCD model), so I'm not sure what would be different, but I'll definitely take the time and read/go through this properly. So, aside from the gamut and black level settings, you leave everything at the defaults for your 3DLUT mode?edit: Sorry, yeah, it looks like it.

I'm still not completely sure about the colour space option myself [snip]. edit: Testing the size/coverage of the three modes with everything at default seems to have the Wide and Standard with the same level of coverage in sRGB (99.0%), but Wide has a slightly larger sRGB volume (106% vs. 105%). The PC mode shows 97% coverage and 100.4% volume. I'm guessing the PC mode is the right one, according to what I've now been told elsewhere. Otherwise the TV is displaying YCbCr444 instead of the proper RGB signal that's being sent to it?

I'm guessing there's no real way to force the LUT calibration or profile to remain enabled for games, so doing the standard adjustments like you would for a standalone device like a blu-ray player or console is probably the best I can get, right? edit: I'm assuming that making the source account for the native/default behaviour of the display would be better than doing on-display adjustments? But if that isn't an option then making a separate "games only" mode with only on-display adjustments is probably better than doing nothing.
Quote:
Side note: You mentioned that you had done an EDID override that enabled 4:4:4 processing; could you let me know some more about this. I did play with the Input labelling and found that I was able to get 4:4:4 processing at 60p if I set the label to 'PC'. I was never able to get 24p 4:4:4 working with my TV, and I'd love to know what you did to achieve that!
I haven't actually tried using 24Hz/24p on here, I've just got it treating my LCD as a DVI-connected monitor instead of a TV by using the EDID retrieval and driver INF modding method outlined here with a DVI-HDMI cable. It basically kills the HDMI audio pass-through.
Some dillweed is offline  
post #477 of 2510 Old 07-16-2013, 09:44 PM
Member
 
baii's Avatar
 
Join Date: Jul 2013
Posts: 16
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Assume I have a perfect srgb display (typical dell ultrasharp hm series), is there any benefit using madvrtpg calibration versus using other profiling software come with the meter or dispcalgui and set "this display is already calibrated"?
baii is offline  
post #478 of 2510 Old 07-16-2013, 10:21 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by baii View Post

Assume I have a perfect srgb display (typical dell ultrasharp hm series), is there any benefit using madvrtpg calibration versus using other profiling software come with the meter or dispcalgui and set "this display is already calibrated"?
While the sRGB and Rec709 primaries are the same, the transfer curves are not, and there doesn't seem to be any way of telling MadVR that - it only has settings for Rec709 or a pure power curve.

Note also that there is a big difference between a display that is calibrated to/emulating an sRGB display vs. creating an ICC profile for the display. The latter does not change or calibrate the display - it characterizes it and allows Applications (vie a CMM) to transform color values to suite the display or emulate a different display colorspace.
Some dillweed likes this.
gwgill is offline  
post #479 of 2510 Old 07-16-2013, 11:12 PM
Member
 
Some dillweed's Avatar
 
Join Date: Dec 2009
Posts: 46
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Yeah. I just started grasping that concept earlier. Is there any way to essentially force a program to keep a calibration? Does the video card at least keep the calibration curves loaded? Or do programs need to have some form of built-in colour management for any of this to function or remain loaded?

[edit:] Actually... no, I thought I knew what I was doing and how this works, but I have no clue what I'm doing here. I don't really understand why the non-PC mode would be able to produce a wider range of the sRGB gamut compared to the PC mode, and why there's such a big difference in the luminance of the various colours between the PC and non-PC primaries. But, I guess this is stuff I should go scour the internet for.
Some dillweed is offline  
post #480 of 2510 Old 07-17-2013, 05:22 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 561
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 24 Post(s)
Liked: 70
Quote:
Originally Posted by Some dillweed View Post

Yeah. I just started grasping that concept earlier. Is there any way to essentially force a program to keep a calibration? Does the video card at least keep the calibration curves loaded? Or do programs need to have some form of built-in colour management for any of this to function or remain loaded?
Calibration curves are not color management. You can't emulate colorspaces using per channel calibration curves.

In relation to color profiles, calibration curves typically server three purposes - setting a white point and maximum brightness, making a display easier to profile, and improving the response curves and neutrals of non color managed applications.

Profiling is used to solve the n x m device problem. If you have n source or target colorspaces (like sRGB or Rec709 or SWOP or ISOcoated or FOGRA39 etc.) and m display or output devices, then if you have to create a calibration table to turn one into the other you need to create n x m calibration tables, one for each possible combination. By creating separate color profiles for each n and each m, then you have reduced it to an n + m problem (much smaller), and can compute each transformation as you need them (that's what a Color Management Module does).

By linking something like Rec709 with your display profile using collink into a 3dLut, you are providing a means for MadVR to transform the Video playback color values into the values needed by your particular display to reproduce the video color as intended.
Some dillweed likes this.
gwgill is offline  
Reply Display Calibration

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off