or Connect
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS
New Posts  All Forums:Forum Nav:

MadVR - ArgyllCMS - Page 17

post #481 of 1680
Thanks for dealing with and trying to educate my ignorant self, Graeme. redface.gif

I'm assuming the code to handle the information present in those profiles needs to be implemented specifically in a program for those transformations to be used. So, I'm guessing the best you can likely get in a scenario where PC gaming is a big chunk of your entertainment content would be to either get a device between the PC and display that can accept things like 3D LUTs to handle that and output a properly transformed signal to your TV, or make a separate mode specifically for games and set the on-display adjustments to sort of mimic the sRGB colour space as closely as possible.

As far as general desktop and video playback are concerned, leaving your display at its default state (or close to it?) and following the calibration and profiling process that you guys have already detailed is likely going to give the best results, I'm assuming.

I'm still unsure on the whole mode and gamut issues on my TV, since the Wide non-PC seems to cover the most, but then I've also been told that anything not using the PC mode specifically isn't using an RGB signal, and I don't know enough to check whether a YCbCr444 or RGB signal is being used and what difference that actually makes to the whole process.
post #482 of 1680
So I don't claim to be a colour management expert, or an expert in the use of madVR for that matter, but that being said:

General Info

The best possible solution for video picture quality should be to calibrate and profile the display in it's native state, and then link the resultant profile to the Rec.709 profile in a 3dlut.

The reality of course, is that it's difficult, if not impossible, to know what the display's native state is. What settings should you use?

Most displays, including all TVs that I'm aware of, must use LUTs in their internal processing in order to give you different picture modes such as 'Standard', 'Game', 'Cinema', 'Vivid' etc. I'm not sure if these modes use 3DLUTs, or RGB LUT curves, but I would suspect it's a 3DLUT of some form or other. It's also important to point out that the display panel probably does not have a native Rec.709 or sRGB response curve, and a LUT of some form is therefore required and used inside the panel anyway.

A 3dlut is able to reduce the size of the gamut of the display, but never increase it, so we can be pretty sure that the mode with the widest gamut has the least 3dlut transformations taking place, and that is therefore the one that I'd pick for calibration and profiling.

HD video content was created and mastered to the Rec.709 standard, which is what most of this thread discussion is surrounding. For video viewing, we want our displays to recreate colours exactly as the content producer / director intended, and the only way to do that is to make sure that each digital value in the video signal produces the correct colour on the display. Using a 3DLUT is common practice in professional content creation, so having this available to us home users, particularly using free software is frankly incredible!

Your TV

I can't speak to your specific model of TV, but in my LG Plasma case, setting the input name to 'PC' results in slightly less image processing. This is obvious because several of the image processing options are disabled once in this mode, so clearly they're bypassed. This is also the only way of getting a 4:4:4 signal to display on my TV.

Aside from the issues of getting a 4:4:4 output from your graphics card (RGB is always 4:4:4 by the way, and YCbCr can be only 4:2:2 or 4:4:4 according to the HDMI spec, so this is likely not really too big of an issue at all), almost all TVs today convert all input signals to YCbCr 4:2:2 for internal processing, before converting this back again to RGB for display.

The exception to this is the 'PC' mode on LG TVs (and other similar settings on other brands), where the 4:4:4 RGB signal seems to be allowed through and somehow bypasses the 4:2:2 YCbCr -> [Image processing and adjustments] -> 4:4:4 RGB transformations. The limitation here however, is that 'PC' mode only actually works for 60p input signals; as soon as the PC switches to video frame rates (23.976p, 24.0p, 29.97p 30p 50p & 59.94p etc.), the display goes back to using the 4:2:2 YCbCr processing. I have not found a way around this limitation.

I've not mentioned that fact that many LCD TVs have options for adjusting the backlight brightness. In an LED Backlit LCD I looked at a few weeks ago, the backlight output could be increased up to 450 nits, but as you did this, the colour balance went way too cool. In order to achieve something similar to a D65 white point, I had to turn down the backlight quite a bit. Calibration curves (2D LUT) could fix this, but you might be thowing away a lot of the 8-bit signal values in order to do this (and that would also reduce the brightness at least some of the way anyway) so I wouldn't recommend it.

Video content is usually mastered to 100 nits (100 cd/m2) peak brightness, so for video at least, there isn't a need to go brighter than this. If viewing in a bright environment however, you might want to do this.

Suggestions

Games:

If you're using your TV mostly for PC gaming, which would typically be at 60p anyway, I'd start by using PC mode to avoid the YCbCr 4:2:2 processing. I'd then set the backlight (if you have an option to adjust it) to be as bright as you'd like, whilst making sure that the white balance doesn't go too far blue (don't touch the white balance controls, only the backlight brightness for this).

Then calibrate using dispcal to (probably) sRGB gamma and (probably) D65 white point. You might however want to decrease the gamma if seeing more shadow detail (bad guys in the shadows) helps you with your games!

If your display has colour primaries that are close to sRGB and Rec.709, then that will already probably give you a pretty accurate image. The calibration curves (2DLUT) created with dispcal should set the white point, peak brightness and gamma curve correctly, and the display has the colour primaries pretty much correct anyway!

Note: As discussed earlier, HD video content assumes Rec.709 standards; I'm really not sure what standards PC game developers / producers are working to, so I really wouldn't know what standard to aim for.

Video:

For video content, I'd start with PC mode turned off (though most video content is not 60p, so actually setting PC mode to on or off won't make any difference if you're using madVR's frame rate setting function, or similar), and go through a complete calibrate profile and link process described in my previous post. Personally, I set my graphics card to output 23.976p manually when calibrating and profiling, as my display has a very slightly different gamut at each refresh rate, and most of my content is 23.976p.

You'll have installed the calibration curves with dispwin for use with PC Games, so make sure to disable these when you're doing the profiling.

For best picture quality, use the standard 'collink -a' command rather than collink -H. This will use the calibration curves when creating the 3DLUT for madVR. Set madVR to disable VideoLUT, and to use the 3DLUT you created from your profile. The only downside to this approach is that if you watch a video in a window, rather than fullscreen, you'll notice that the calibration curves are disabled when the video plays; as long as you watch videos in full screen, and shut down your player when you do anything else, this should give you the best result.

If you really do want to multi-task with madVR in a window, then use collink -H instead.

Final Thoughts

As has been said in previous posts, much of this is trial and error. You're going to have to try various options, check the results and see which option you're most happy with. A bit of understanding as to what is actually going on goes a long way, and Graeme's description a couple of posts ago describes that very well.

I hope that helps!
Edited by nezil - 7/17/13 at 3:01pm
post #483 of 1680
nezil, again, thank you for being as helpful as I could possibly ask of anybody. I really do appreciate you guys helping me to get a better handle on all of this.
Quote:
Originally Posted by nezil View Post

The best possible solution for video picture quality should be to calibrate and profile the display in it's native state, and then link the resultant profile to the Rec.709 profile in a 3dlut. [...] Most displays, including all TVs that I'm aware of, must use LUTs in their internal processing in order to give you different picture modes such as 'Standard', 'Game', 'Cinema', 'Vivid' etc. I'm not sure if these modes use 3DLUTs, or RGB LUT curves, but I would suspect it's a 3DLUT of some form or other. It's also important to point out that the display panel probably does not have a native Rec.709 or sRGB response curve, and a LUT of some form is therefore required and used inside the panel anyway.

A 3dlut is able to reduce the size of the gamut of the display, but never increase it, so we can be pretty sure that the mode with the widest gamut has the least 3dlut transformations taking place, and that is therefore the one that I'd pick for calibration and profiling.
Is the display LUT something that can/should be manipulated at all? Or should you generally just adjust the source to accomodate for the behaviour of the display? And, I'm guessing that this LCD is like your plasma, in that the Wide (non-PC mode) gamut option is probably the closest to its native state, since it seems to have the largest coverage at default settings.

Concerning the 4:2:2 processing outside of PC mode, with that Nvidia EDID override fix I linked to earlier, my TV passes the belle nuit test and the red and magenta blurry font tests, so I'm assuming that it is passing a 4:4:4 signal both with and without switching to the PC mode. If that's the case, I guess I could just follow a similar calibration process to what you guys have detailed for madVR, it's just that the profiling part of the process won't be useful for the games since they can't take advantage of it.

I also actually tried setting up both 24Hz and 23.976Hz custom resolution to see if they would work with the EDID fix, and it still displays the same kind of 4:4:4-test-passing image at least (albeit slower and laggier than the default 60Hz), and the TV information reads as 1080/24p.
Quote:
Final Thoughts
As has been said in previous posts, much of this is trial and error. You're going to have to try various options, check the results and see which option you're most happy with. A bit of understanding as to what is actually going on goes a long way, and Graeme's description a couple of posts ago describes that very well.

I hope that helps!
Yes, it definitely does help. Thanks again, nezil. I'll try to absorb what information I can, and try to keep myself from getting stressed out by my inexperience with everything.
post #484 of 1680
Quote:
Originally Posted by Some dillweed View Post

I'm assuming the code to handle the information present in those profiles needs to be implemented specifically in a program for those transformations to be used.
Typically yes, although this is not the case on all systems - some systems in some circumstances may implement color management as opt out, ie. so that a program gets emulated sRGB by default and has to explicitly opt out for native response or some other emulated color space. This may be the case with the latest version of OS X and MSWindows, but I'm not certain of the exact circumstances. The reason that this approach is becoming more common is to deal with wide gamut displays, which otherwise would have extremely hard to live with garish user interfaces.
Quote:
So, I'm guessing the best you can likely get in a scenario where PC gaming is a big chunk of your entertainment content would be to either get a device between the PC and display that can accept things like 3D LUTs to handle that and output a properly transformed signal to your TV, or make a separate mode specifically for games and set the on-display adjustments to sort of mimic the sRGB colour space as closely as possible.
Something like that. The VideoLUT per channel calibration curves can help with non color managed applications, particularly with regard to greys and overall tone response, but you can't shift the primary colors with them.
Quote:
As far as general desktop and video playback are concerned, leaving your display at its default state (or close to it?) and following the calibration and profiling process that you guys have already detailed is likely going to give the best results, I'm assuming.
Generally speaking yes, but it's hard to generalize and be right in all situations. It may be of benefit for instance to use the TV controls to set white point but nothing else.
Quote:
I'm still unsure on the whole mode and gamut issues on my TV, since the Wide non-PC seems to cover the most, but then I've also been told that anything not using the PC mode specifically isn't using an RGB signal, and I don't know enough to check whether a YCbCr444 or RGB signal is being used and what difference that actually makes to the whole process.
You may have a tradeoff type situation of gamut vs. signal handling. You would need to investigate to determine what your best choice is.
post #485 of 1680
Quote:
Originally Posted by nezil View Post

The best possible solution for video picture quality should be to calibrate and profile the display in it's native state, and then link the resultant profile to the Rec.709 profile in a 3dlut.
This seems to be the safest course, as many internal display controls are known to corrupt the colorspace. I would recommend trying to adjust the white point using the internal controls, and fall back on just calibration curves if that causes a problem.
Quote:
Most displays, including all TVs that I'm aware of, must use LUTs in their internal processing in order to give you different picture modes such as 'Standard', 'Game', 'Cinema', 'Vivid' etc. I'm not sure if these modes use 3DLUTs, or RGB LUT curves, but I would suspect it's a 3DLUT of some form or other. It's also important to point out that the display panel probably does not have a native Rec.709 or sRGB response curve, and a LUT of some form is therefore required and used inside the panel anyway.
Maybe, maybe not. The simplest processing is typically per channel curves so as to be able to emulate the default CRT like tone curve expectation. Some of the trick modes may do not-very-nice color stuff like boost chroma, increase the gamma, or even add dynamic or spatial effects. All such things will make proper color management difficult to impossible. They are mostly there to increase the length of the feature list, and to make a display eye catching to the casual viewer. They have nothing to do with accurate reproduction. Some displays seem to have primary and secondary colorant controls (RGBCMY), but from some of the feedback I've had about them, many are poorly implemented using matrix like math with very poor handling of the gamut limits, resulting in a mangled color space.
Quote:
A 3dlut is able to reduce the size of the gamut of the display, but never increase it, so we can be pretty sure that the mode with the widest gamut has the least 3dlut transformations taking place, and that is therefore the one that I'd pick for calibration and profiling.
Yes, if the natural gamut of the display is large, you really want to make that available to the color management rather than artificially restricting it.
Quote:

Note: As discussed earlier, HD video content assumes Rec.709 standards; I'm really not sure what standards PC game developers / producers are working to, so I really wouldn't know what standard to aim for.
sRGB is as good a guess as any.
Quote:
You'll have installed the calibration curves with dispwin for use with PC Games, so make sure to disable these when you're doing the profiling.
If you follow the normal recommendations, then this is taken care of automatically.
dispcal doesn't leave the calibration state to chance, and dispwin won't ether if you use the -k or -K option.
Quote:
For best picture quality, use the standard 'collink -a' command rather than collink -H. This will use the calibration curves when creating the 3DLUT for madVR. Set madVR to disable VideoLUT, and to use the 3DLUT you created from your profile.
The experimental tools aren't fully checked out or documented yet. With them and the latest MadVR you don't have to tell MadVR to disable VideoLUTs, the 3dLut will contain the appropriate curves (linear for -a), and MadVR will load them automatically. The idea is to make it all more foolproof and automatic.
Quote:
The only downside to this approach is that if you watch a video in a window, rather than fullscreen, you'll notice that the calibration curves are disabled when the video plays; as long as you watch videos in full screen, and shut down your player when you do anything else, this should give you the best result.
If you really do want to multi-task with madVR in a window, then use collink -H instead.
Correct. If you use collink -H then your would also typically load the same calibration curves for non MadVR use using diswin or as part of installing a system ICC display profile.
post #486 of 1680
Quote:
Originally Posted by gwgill View Post

This seems to be the safest course, as many internal display controls are known to corrupt the colorspace. I would recommend trying to adjust the white point using the internal controls, and fall back on just calibration curves if that causes a problem.
Just to clarify, do you mean balancing just the peak white and then doing the calibration and profiling normally, or just adjusting backlight to get the white brightness where you want? I just noticed that, untouched at the defaults, the pure blue luminance on this TV is way too low and red is overly bright. So if I only turn the backlight up and try to calibrate, the peak white drops a lot and so does the contrast along with it.
post #487 of 1680
Quote:
Originally Posted by gwgill View Post

Generally speaking yes, but it's hard to generalize and be right in all situations. It may be of benefit for instance to use the TV controls to set white point but nothing else.
You may have a tradeoff type situation of gamut vs. signal handling. You would need to investigate to determine what your best choice is.

I'd completely agree with Graeme on this. There isn't really a one case fits all answer to your question. For some TVs, the on-screen controls might be able to accurately adjust the white point, and maybe even the Gamma, but on other TVs the action of the controls might introduce other issues.

As an example, I can use the 20 point IRE adjustments on my display to get an almost perfect 10% greyscale result when checked with HCFR's default 10 level greyscale measurements. Unfortunately however, if you test for greater than 10 points in HCFR, you'll see that the result is a mess. This can actually be smoothed out a bit with further adjustment, I just want to make the point that using on-screen controls can be tricky, and it's actually easier to get a better final result by using ArgyllCMS dispcal.
Quote:
Just to clarify, do you mean balancing just the peak white and then doing the calibration and profiling normally, or just adjusting backlight to get the white brightness where you want? I just noticed that, untouched at the defaults, the pure blue luminance on this TV is way too low and red is overly bright. So if I only turn the backlight up and try to calibrate, the peak white drops a lot and so does the contrast along with it.

This was a question to Graeme, so he'll probably want to answer himself, but I'll give you my take on this as well.

The native colour response of an LCD display is influenced heavily by the backlight used. As I explained previously, many (most in fact) white LED backlight units have a pretty large blue peak in their spectral output, which results in an overly blue white point, particularly at higher brightness levels.

I tested a Sony Quantum Dot based display last week, and noticed that apart from it's wider colour gamut, it's colour balance is also improved. It seems that the Quantum Dot technology is able to produce Red and Green primaries that are at a more accurate luminance than White LED, allowing the user to drive the backlight harder without altering the colour balance.

You mentioned that your display is a CCFL backlit LCD model, and while I'm not as familiar with the spectral output of CCFL backlight units, it might be that the red part of the spectrum is larger than the blue or green.

In my experience, in their standard modes, LG TVs have a white point that is too warm. My Plasma has three settings for the white point - 'Warm', 'Medium' and 'Cool', and after setting these, you can then use the 2 point or 20 point controls to further adjust the white point. I have so far done my calibration and profiling using the default 'Warm' mode, and have left the 2 and 20 point IRE controls at default as well. The first thing that I notice with my Plasma, is that the peak brightness (and therefore contrast) is reduced from ~95 to ~85 nits by dispcal, just to bring the white point back to where it should be. It is possibly worth me testing to see if 'Medium' is a better starting point, and also if using the 2 point or 20 point IRE first gives a better end result.

This is exactly what is meant by saying 'You have to investigate to determine what your best choice is'.

In my opinion however, the difference between calibrating, profiling and linking from the default settings on the display, and spending many many hours trying different options will be minimal. This is largely because a 3dlut is significantly more powerful than any OSD on a TV that I've seen; it's method of operation is much more complex than the (comparatively simple) 20 point IRE greyscale adjustments and single point primary (and sometimes secondary) CMS adjustments that are present on a TV.

In summary then...

If you use the native display response (set the backlight wherever you like, and just leave it there after you're finished), you'll almost certainly get an extremely good end result using the ArgyllCMS / madVR process I ran through a few posts back. It might however not be the absolute best you can get...

If you really want the absolute best result, you'll have to try many options before using the ArgyllCMS / madVR process - adjust the backlight to different levels, try different colour temps in the OSD, try different adjustments to the OSD greyscale points etc.
post #488 of 1680
Yeah, you're right and I should just keep experimenting. In all of my previous efforts, the majority of what I had been doing was adjusting the 10-point gray scale balance on the TV. I also did adjust a few colour tints because I didn't realize at the time that those could compromise or compress the available gamut. I had managed to kind of manipulate it to a point where most of the 20-point measurements from HCFR either read as D65 or very close. So, it might be that I'll just have to try different adjustments like only changing the overall colour temperature, or only balancing the peak white, or balancing the whole gray scale as close to D65 as I can, etc. and then doing the calibration and profiling on all of those different setups to see which way works best with this TV while preserving as much gamut coverage as possible. At the very least, though, I probably shouldn't mess around with the CMS and should leave that for the software to profile and sort out..
post #489 of 1680
Quote:
Originally Posted by Some dillweed View Post

So, it might be that I'll just have to try different adjustments like only changing the overall colour temperature, or only balancing the peak white, or balancing the whole gray scale as close to D65 as I can, etc. and then doing the calibration and profiling on all of those different setups to see which way works best with this TV while preserving as much gamut coverage as possible. At the very least, though, I probably shouldn't mess around with the CMS and should leave that for the software to profile and sort out..

Sounds like a good plan... be prepared to spend a lot of time doing this :-)
post #490 of 1680
Thread Starter 
Quote:
Originally Posted by nezil View Post

Sounds like a good plan... be prepared to spend a lot of time doing this :-)

IMHO, I agree with all the posts regarding "there is no one set of settings" that can be applied to all the different environments and devices that are out there. I have 3 different TVs and all 3 use different workflows to achieve the best color performance. If you want the best performance out of your device, you will need to spend time to try out the different workflows and settings and compare them.

I have updated the first post to use the MadVR TPG for readings. The settings used in the first post should get satisfactory results. Better results can be attained by experimenting with the different options. smile.gif
post #491 of 1680
Quote:
Originally Posted by N3W813 View Post

I have updated the first post to use the MadVR TPG for readings. The settings used in the first post should get satisfactory results. Better results can be attained by experimenting with the different options. smile.gif

Thanks for updating the first page N3W813.

I'd like to point out that there are several differences between the workflow detailed on first page, and the more recent one that has been discussed by Graeme, Madshi and I. I have found that the more recent workflow creates significantly better results than even your updated one on page 1. I'm prepared to believe that it might be only the displays that I've tested that work better this way, but the fact that Graeme and Madshi have had similar results would indicate that it's a more repeatable and reliable approach.

The biggest differences are:
  • The use of dispcal to first correct the white point and bring the gamma curve into a more well behaved function. Graeme explained that it is far more effective to use the 2D Video LUT calibration to fix the white point than simply to rely on the profile linking to do this job; Madshi and my results confirm this.

    If your work flow assumes that the user has first attempted to calibrate their display using the available on screen controls first, and that the white point and gamma will be pretty good already as a result of this, then I imagine that the results will be similar. You don't mention this in your work flow however, and it's a critical point.

    Having said that... the work and testing that I've done have shown that dispcal is able to do a better job at fixing the white point at all IRE values that I have been able to achieve using the on-screen controls. With that in mind, I'd be tempted to suggest that many users would see better results by using dispcal rather than the OSD.
  • You recommend using -IB gamma parameter for the collink command. In theory I would also expect to use -IB, but Madshi and I have both found that -Ib seems to produce a better end result.
  • In your targen command, you don't include any single colour steps. Madshi found that primary and secondary accuracy was improved with some of these.
post #492 of 1680
I agree with nezil here. I think dispcal should be added into the recommended workflow. I didn't actually test whether targen single color steps improved the results or not, though. I just took the suggestion to add some single color steps from Graeme's tutorial.
post #493 of 1680
Thread Starter 
Quote:
  • The use of dispcal to first correct the white point and bring the gamma curve into a more well behaved function. Graeme explained that it is far more effective to use the 2D Video LUT calibration to fix the white point than simply to rely on the profile linking to do this job; Madshi and my results confirm this.

    If your work flow assumes that the user has first attempted to calibrate their display using the available on screen controls first, and that the white point and gamma will be pretty good already as a result of this, then I imagine that the results will be similar. You don't mention this in your work flow however, and it's a critical point.

    Having said that... the work and testing that I've done have shown that dispcal is able to do a better job at fixing the white point at all IRE values that I have been able to achieve using the on-screen controls. With that in mind, I'd be tempted to suggest that many users would see better results by using dispcal rather than the OSD.

I will add this to the workflow after testing this out. I do calibrate the white point and gamma using my TV's internal controls and allow the device linking 3dlut to make the final adjustments.
Quote:
[*] You recommend using -IB gamma parameter for the collink command. In theory I would also expect to use -IB, but Madshi and I have both found that -Ib seems to produce a better end result.

-IB uses the 'BT.1886 standard' to calculate the gamma, that is the only reason I've stated it for the workflow. It is up to each individual to choose the gamma curve he/she prefers. I myself go back and forth between -ib and -IB depending on the content. wink.gif
Quote:
[*] In your targen command, you don't include any single colour steps. Madshi found that primary and secondary accuracy was improved with some of these.

First of all, thanks for the reminder, I've updated the command for targen to 2000 OFPS patterns, which is the default for all my testing. On my 3 TVs, I was able to get less than 2 average dE2000 for 25% saturation sweeps on the primaries and secondaries using that pattern set. I've tried using single color steps before and IIRC they did not improve primary/secondary accuracy as much as increasing the number of OFPS patches. At 5500 OFPS patches, I was able to get less than 1 avg dE2000 for the sat sweeps and color checker readings.
post #494 of 1680
Sounds like you're on it N3W813!

BTW I hope I didn't come across as critical of your first page summary. You seem to have taken my comments in the spirit they were intended, so thanks!

Thanks actually for starting the thread... Madshi introduced me to the idea of using ArgyllCMS in a separate discussion, but it was your tutorial on page one that actually encouraged me to start running through the process and testing things out for myself.

As I said in an earlier post, the fact that we now have these tools available to us for free (ArgyllCMS and madVR) is incredible, and I'm quite sure that the end results are far better than can be accomplished with TV internal calibration alone. What we now have is professional quality display images, for the cost of a colourimeter... amazing!
post #495 of 1680
Quote:
Originally Posted by nezil View Post

As I said in an earlier post, the fact that we now have these tools available to us for free (ArgyllCMS and madVR) is incredible, and I'm quite sure that the end results are far better than can be accomplished with TV internal calibration alone. What we now have is professional quality display images, for the cost of a colourimeter... amazing!
I concur! Thanks a lot to all of you, guys, for keeping up the discussion.
post #496 of 1680
What would people find most useful in a calibration/LUT validation tool within HCFR? I was thinking of adding something like a 24pt color checker sequence with summary stats on min/max/avg dE. For previous validation I have used the ArgyllCMS tools to generate dE statistics (see here and here). These used large numbers of optimally distributed patches to evaluate the performance of the eeColor box under various configurations but I think that a simple set of "important" colors such as those in the Munsell system could be used to quickly evaluate workflows.
Edited by zoyd - 7/21/13 at 11:09am
post #497 of 1680
I apologize if this has been covered, but is there a way to set the amount of time a pattern will stay on the screen? I'm pretty sure that the speed with which this thing moves is too fast for my ST30. Also, is there a way to set the background level to anything other than solid black?
post #498 of 1680
@ttnuagmada,

What makes you think that it's running too fast? Are you getting no results from the testing?

Also, assuming that you're using the madVR test pattern generator, ArgyllCMS in verbose mode (recommended in every post in this thread) should tell you the delay that it sees between requesting a test patch, and it appearing on screen.

In short, the systems should be self correcting... I've not seen any issues like this myself, except when I've not had it configured correctly.
post #499 of 1680
The 2011 Panasonic plasmas are known to need 2.5-3 seconds for a patch to stabilize. So when it flies through the test patterns, it doesn't get ideal numbers. There were noticeable issues with the resulting 3Dlut.
post #500 of 1680
There's a slider in the madTPG GUI that allows you to set the background level to anything between black and white.

The measurement delay is controlled by ArgyllCMS. madTPG just does what Argyll tells it to do. So if you need a delay of 2.5-3 seconds, that's be something ArgyllCMS would have to implement.
post #501 of 1680
Quote:
Originally Posted by ttnuagmada View Post

The 2011 Panasonic plasmas are known to need 2.5-3 seconds for a patch to stabilize. So when it flies through the test patterns, it doesn't get ideal numbers. There were noticeable issues with the resulting 3Dlut.
I'd be interested to get more specific technical information on that.

With an i1 display pro, i1 pro or ColorMunki spectro the current software automatically calibrates for the latency through the system in displaying patches and the display and instrument reacting to a patch change. For other instruments there is a default 200 msec delay. There is also a settling heuristic that sets a minimum time to permit large level changes to settle.

You can set an override delay by setting the ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS environment variable : - see http://www.argyllcms.com/doc/Environment.html. The maximum you can set is 60000 msec (60 seconds).

If you can show a significant delta E between the default times and a manually set time, I'm interested to see some numbers.
post #502 of 1680
Quote:
Originally Posted by ttnuagmada View Post

The 2011 Panasonic plasmas are known to need 2.5-3 seconds for a patch to stabilize. So when it flies through the test patterns, it doesn't get ideal numbers. There were noticeable issues with the resulting 3Dlut.

I'd be interested in info regarding this as well, plasma phosphor response times are generally very fast (a couple of ms) and patch stabilization has never been an issue to my knowledge. Patch delay is generally limited by sensor response/integration time.
post #503 of 1680
Hello in the Tuto , you say:
Quote:
5. Start MadVR Test Pattern Generator

Enable "use fullscreen"

Use madTPG in Fullscreen is not great for plasma. the size of patterns is also too big with madTPG .
Don't forget the ABL effect on plasma. Patterns should be smaller in madTPG, and not a uniform background

with my panasonic plasma st60 , i use the pattern of dipscal and not madrTPG for that . FYI...
post #504 of 1680
@Rachel Camille,

You're absolutely right that madTPG with a full screen patch would not work well on a Plasma display, but madTPG has sliders to adjust the patch size (Image Area) and the background level. Setting the patch size to the smallest is almost exactly the same as the 10% windows in other software and test DVDs / Blu-rays. If your Plasma runs into APL issues at 10% screen area, I'd be very surprised. My (LG) Plasma doesn't.

It's important to use madTPG full screen, and to disable OSD with Plasmas, otherwise the other things on the screen will skew the results.

Apparently using madTPG as the renderer should produce more accurate results than the ArgyllCMS built in pattern generator; madshi will be able to comment on the reasons for this. Accuracy aside however, it is much better to use the same pattern generator for all of your work, or at the very least, the same size and shape of patch.

If madTPG is used with ArgyllCMS, it can then also be used with HCFR to confirm the results, all with the exact same renderer. The ArgyllCMS pattern generator for dispcal is a small square, while the madTPG is a rectangular window. On my Plasma, I did get slightly different results when I used dispcal's pattern generator, followed by HCFR with the AVS calibration disc files. Now that we have madTPG, I'm able to use it with both softwares, and it's much much more flexible. madTPG is able to show any colour patch that it's asked for, whereas the AVS calibration disc limited me to 5% steps for the greyscale.

Quote:
I'd be interested in info regarding this as well, plasma phosphor response times are generally very fast (a couple of ms) and patch stabilization has never been an issue to my knowledge. Patch delay is generally limited by sensor response/integration time.

I completely agree with Zoyd here; this is one of the significant major benefits of Plasma over LCD - response time. In fact the way that a Plasma display works, is entirely based on the fact that the response time is faster than (typically) 1/10 of a frame, hence the marketing term of 600Hz being used for Plasma displays.
Edited by nezil - 7/22/13 at 9:41am
post #505 of 1680
Don't quote me on this, but I seem to recall D-Nice talking about it, and Chad B mentions it in this post just the other day. I don't have any measurements to post, but I've definitely seen my set do this.
post #506 of 1680
@ttnuagmada,

Interesting posts... Plasmas can be finicky to measure and calibrate at the best of times, so I'm not surprised to read about this. The change ofter a few minutes makes a lot of sense as it reduces burn in, but the few seconds issue is strange. It's probably not a 'feature' of the panel itself, and rather something in the TV processing that's causing this.

Would you be able to post up some differences between taking readings immediately, after say 5 seconds, and after 2 minutes so that we can see how big a variation this really is?

Personally, I didn't notice this with my LG plasma, but would try to avoid having a test patch on the screen for an extended period of time. Thankfully, madTPG goes to a black screen as soon as ArgyllCMS or HCFR have finished requesting patches, so the screen is blank most of the time.
post #507 of 1680
I'll be happy to whenever I get the time to sit down and mess with it again, possibly this upcoming weekend.
post #508 of 1680
Quote:
Originally Posted by nezil View Post

The ArgyllCMS pattern generator for dispcal is a small square, while the madTPG is a rectangular window.
The Argyll test window is whatever size you make it. See http://www.argyllcms.com/doc/dispwin.html#P
post #509 of 1680
Quote:
Originally Posted by nezil View Post

The change ofter a few minutes makes a lot of sense as it reduces burn in, but the few seconds issue is strange. It's probably not a 'feature' of the panel itself, and rather something in the TV processing that's causing this.
If the TV has no settings that provide stable and repeatable output, then it isn't suitable for calibration and/or profiling. I would think it's not much good for viewing either....
post #510 of 1680
With both Panasonic and Samsung plasmas of the past several years I have never seen the kind of instability that would force one to have different settings based on how the display was sampled temporally. Especially regarding color dE these displays are very stable, far below the threshold of perception. Any settings changes from one calibration to another is typically the result of user inexperience (set-up, warm-up procedure for example), probe instability at low stimulus, or pattern geometry (loading). I think the kind of instability ChadB was referring to are very small changes in pixel efficiency (total luminance) based on hysteresis that will have no effect on what display settings or 3dLut corrections one would obtain.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS