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

MadVR - ArgyllCMS - Page 15

post #421 of 1698
Quote:
Originally Posted by madshi View Post

They all look "bad", in the sense that the expected (white) and actual (yellow) response curves totally differ in their shape. The actual response curve (yellow) has a shape which is clearly not good, or am I missing something?
Right - although they probably are not working off exactly the same black value.
Quote:
I understand that. But what if I'm happy with -ia? I don't see why that would have an effect on the gamma response curve?
My guess is that it's clipping. The source and destination are normalised for Y = 1, but if they have different colors (which is the case when your display isn't D65 while your source is), then the white end up out of gamut and clips, hence the roll off in response near white. You won't get this with relative colorimetric since the white points are mapped exactly to each other.

Another potential fix is to use -iaw, which is designed to specifically avoid this type of clipping, although I've never found a use for it....
post #422 of 1698
So to recapture, @Graeme, your recommended approach is to always use dispcal first and to let dispcal both correct the white point and realize the desired gamma response. Is that correct? If so, do you then recommend to not use the collink "-IB" switch because dispcal was already supposed to realize the gamma response? Or if my aim is to get BT.1886 gamma, would you recommend to use both "dispcal -G2.4 -f0" and "collink -IB"? I'd really like to find a recommended set of parameters. Would you agree with the following?
Code:
dispcal -dmadvr -G2.4 -f0 -t6500
dispread -dmadvr
colprof -aX
collink -3m -et -Et -G -ir -IB   // -IB or not -IB, that's the question?

And for a pure power curve this?
Code:
dispcal -dmadvr -g2.4 -t6500
dispread -dmadvr
colprof -aX
collink -3m -et -Et -G -ir

Any improvement suggestions from your side? Thanks!
post #423 of 1698
Quote:
Originally Posted by madshi View Post

So to recapture, @Graeme, your recommended approach is to always use dispcal first and to let dispcal both correct the white point and realize the desired gamma response. Is that correct?
No, that's not correct.

If absolute intent is used, the per channel calibration has no direct bearing on the resulting transfer curve or white point - the link totally determines the transformation.

If a relative intent is used, then the white point is determined by the uncalibrated or per channel calibrated state of the device (because relative intent maps source white to destination white), but the trasfer curve and everything else about the transformation is determined by the link.

The per channel calibration curves have a secondary effect on the profile - by calibrating the device in a detailed per channel manner, they can make the device better behaved & therefore improve the accuracy of the profile which is created from a sparcer set of 3D samples.

So while more complex, a per channel calibration step that determines the white point & potentially improves the device neutral balance and transfer characteristic followed by a profile should give the highest quality result. But in everything other than the white point, the target behavior is determined by the source profile + -ib/-iB adjustment + intent. The actual achieved result will of course depend also on the limitation of the display and its profile.
Quote:
If so, do you then recommend to not use the collink "-IB" switch because dispcal was already supposed to realize the gamma response?
See above. The source profile modified by -IB determine the transfer characteristic, not the per chanel calibration curves.
Quote:
Or if my aim is to get BT.1886 gamma, would you recommend to use both "dispcal -G2.4 -f0" and "collink -IB"? I'd really like to find a recommended set of parameters. Would you agree with the following?
As indicated in the tutorial, I recommend an initial
Code:
     collink -v -3m -et -Et -Ib -G -ir Rec709.icm TV.icm HD.icm
or
Code:
     collink -v -3m -et -Et -Ib n.nn -G -ir Rec709.icm TV.icm HD.icm
as a place to start. Obviously you need to add "-a file.cal" if per channel calibration curves are to be part of the 3dLUT rather than being loaded into the Graphics card VideoLUT.
post #424 of 1698
Quote:
Originally Posted by gwgill View Post

If absolute intent is used, the per channel calibration has no direct bearing on the resulting transfer curve or white point - the link totally determines the transformation.
Quote:
Originally Posted by gwgill View Post

See above. The source profile modified by -IB determine the transfer characteristic, not the per chanel calibration curves.

But that doesn't match my test results. I've used "-ia" (absolute intent) for all my tests. But the resulting gamma response (that is what you mean with the transfer curve, correct?) is *very* different, depending on the dispcal parameters. Compare these 2:

http://madshi.net/argyll/dispcal_G24_f0_collink_ia_IB_a_gamma.png
http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_gamma.png

The only difference is the use of the -t6500 parameter. Other than that both the dispcal and collink parameters are identical, using absolute intent. Still, the resulting final gamma response is very different. That doesn't match what you just said, or did I misunderstand you?

You mentioned earlier that the crappy gamma response produced by collink might be a result of clipping due to an out-of-gamut white point. But the problem only occurs when collink corrects the white point. It does not occur at all if I let dispcal correct the white point.

Quote:
Originally Posted by gwgill View Post

So while more complex, a per channel calibration step that determines the white point & potentially improves the device neutral balance and transfer characteristic followed by a profile should give the highest quality result.

Ok, thanks.

Quote:
Originally Posted by gwgill View Post

As indicated in the tutorial, I recommend an initial
Code:
     collink -v -3m -et -Et -Ib -G -ir Rec709.icm TV.icm HD.icm
or
Code:
     collink -v -3m -et -Et -Ib n.nn -G -ir Rec709.icm TV.icm HD.icm
as a place to start. Obviously you need to add "-a file.cal" if per channel calibration curves are to be part of the 3dLUT rather than being loaded into the Graphics card VideoLUT.

Ok, thanks. Which dispcal parameters would you recommend to use? Your tutorial mentions:

"dispcal -t 6500 -gs"

I do wonder why you're using "-gs" here. If we plan to use "-Ib" for collink, wouldn't "-G2.4 -f0" for dispcal be a better match? Or is there a specific reason why "-gs" might be better? Just trying to collect the most optimal parameters to use...

Thanks!
post #425 of 1698
Quote:
Originally Posted by madshi View Post

But that doesn't match my test results. I've used "-ia" (absolute intent) for all my tests. But the resulting gamma response (that is what you mean with the transfer curve, correct?) is *very* different, depending on the dispcal parameters. Compare these 2:

http://madshi.net/argyll/dispcal_G24_f0_collink_ia_IB_a_gamma.png
http://madshi.net/argyll/dispcal_G24_f0_t6500_collink_ia_IB_a_gamma.png

The only difference is the use of the -t6500 parameter. Other than that both the dispcal and collink parameters are identical, using absolute intent. Still, the resulting final gamma response is very different. That doesn't match what you just said, or did I misunderstand you?
Right, this is a result of gamut clipping. With no white point adjustment the neutral axis starts hitting the side of the gamut using absolute intent. With the calibration adjusting the white point, clipping doesn't occur, and the transfer curve is unaffected. Using collink -iaw should avoid this though.

Calibration will have an effect, but it's a secondary effect, affecting the quality and (in this case) limits.
Quote:
You mentioned earlier that the crappy gamma response produced by collink might be a result of clipping due to an out-of-gamut white point. But the problem only occurs when collink corrects the white point. It does not occur at all if I let dispcal correct the white point.
Precisely. Collink is trying to correct the white point within the volume of the display gamut, and the neutral axis crashes into the edge of the gamut and clips before it's hit the white luminence level.

With the white point corrected by the calibration, the source and destination volumes white points coincide, so the neutral axis doesn't hit the side of the gamut.
Quote:
Ok, thanks. Which dispcal parameters would you recommend to use? Your tutorial mentions:

"dispcal -t 6500 -gs"

I do wonder why you're using "-gs" here. If we plan to use "-Ib" for collink, wouldn't "-G2.4 -f0" for dispcal be a better match? Or is there a specific reason why "-gs" might be better? Just trying to collect the most optimal parameters to use...
It's a bit of a guess on my part, but calibrating to a high power like 2.4 is likely to make the channels hard to control near black - ie. the output will depend on tightly controlling very small values in the cLUT, therebye reducing accuracy. By calibrating to a slightly less extreme curve such as sRGB or L*, the level near black will not be too far from the target, and will be controllable by the cLUT without needing extreme tollerances of very small values.

It would be worth experimenting with this aspect, once the overall process is working correctly.
post #426 of 1698
Quote:
Originally Posted by gwgill View Post

It's a bit of a guess on my part, but calibrating to a high power like 2.4 is likely to make the channels hard to control near black - ie. the output will depend on tightly controlling very small values in the cLUT, therebye reducing accuracy. By calibrating to a slightly less extreme curve such as sRGB or L*, the level near black will not be too far from the target, and will be controllable by the cLUT without needing extreme tollerances of very small values.

It would be worth experimenting with this aspect, once the overall process is working correctly.

Ok, thanks. Will give that a try...
post #427 of 1698
There's a new madVR build available now:

http://madshi.net/madVR.zip (v0.86.7)

This new build contains a new "madTPG.exe" test pattern generator application with several configuration options.
post #428 of 1698
Thread Starter 
Quote:
Originally Posted by madshi View Post

There's a new madVR build available now:

http://madshi.net/madVR.zip (v0.86.7)

This new build contains a new "madTPG.exe" test pattern generator application with several configuration options.

Awesome stuff, thanks Madshi!! wink.gif

Will definitely try this out when I get back from my business trip. See if I can get even lower dEs on my TVs. biggrin.gif

Edit:
I see this in your release notes...

* added support for combined 3dlut/VideoLUT file format ("collink -H")

I wasn't aware of a '-H' parameter for collink.exe. What exactly does it do?
Edited by N3W813 - 7/5/13 at 11:59am
post #429 of 1698
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...
post #430 of 1698
Madshi, Graeme, thanks a lot to you guys. You move the HTPC world forward, creating opportunities.
post #431 of 1698
I believe the integrated solution you guys created is nothing short of amazing, can't wait to test it out smile.gif
post #432 of 1698
What are latest recommendation?

What do you think about:
Code:
dispcal -v -dmadvr -t 6500 -gs madvr
dispwin -d2 madvr.cal // Or what? I can't load .cal into madvr?  This would increase measurements quality, isn't it?
dispread -dmadvr
colprof -aX
collink.exe -v -3m  -qh  -et  -Et  -IB  -G  -iaw -a madvr.cal  Rec709.icm  MadVR.icm  3DLUT.icm // In fact I can experiment with this as this doesn't require new measurements :rolleyes:
// disable GPU ramps in madvr... 


madshi, So it's still better to use ("-a")? Correct?
Edited by kasper93 - 7/5/13 at 2:16pm
post #433 of 1698
Replace "dispwin -d2 madvr.cal" with "dispwin -c". And use "dispread -dmadvr -k madvr.cal", and I think Graeme suggests "collink -Ib -ir" instead of "collink -IB -iaw". And yes, using "collink -a" is the best solution for quality.
post #434 of 1698
Ok, thanks.

And I just looked in doc. And should be "dispread -dmadvr -K madvr.cal".

"-k" loads LUT into GPU so same as dispwin.

So:
Code:
dispwin -d2 -c
dispcal -v -dmadvr -t 6500 -gs madvr
targen -v -d3 -G -f2500 -g64 -e16 madvr
dispread -v -dmadvr -K madvr.cal madvr
colprof -v -qh -bl -aX madvr
collink -v -3m  -qh  -et -Et -Ib -G -ir -a madvr.cal Rec709.icm madvr.icm 3dlut.icm
// disable GPU ramps in madvr...

Will give a try tomorrow.
Edited by kasper93 - 7/6/13 at 9:41am
post #435 of 1698
When using the "-dmadvr" parameter, dispread is clever enough to know that "-k" should actually be "-K", so you can use either one. But yes, "-K" is more correct than "-k".
post #436 of 1698
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...
That's great! I'm kinda waiting for the dust to settle on this (though with the holidays coming up I might do some testing), but this was pretty much a prerequisite for me.
post #437 of 1698
FWIW, if you use Overlay mode, the option "-H" is not needed. You can then simply activate the option "Disable GPU gamma ramps" in the madVR settings. v0.86.7 will in that case disable the GPU gamma ramps only when you enter fullscreen exclusive mode. As long as you stay in Overlay mode, madVR will not touch the GPU gamma ramps. Furthermore, when you leave FSE mode, madVR will restore the original GPU gamma ramps. Since Overlay by design doesn't get GPU gamma ramps applied this practically means that you can have all applications calibrated through dispcal, and at the same time you can have video playback perfectly calibrated with a simple 3dlut, too. The end result should be better quality compared to "-H". Of course Overlay comes with its own problems, so it's your decision whether you want to use it or not.

When using normal windowed mode *without* the "collink -H" option, the madVR option "Disable GPU gamma ramps" will clear the GPU gamma ramps as soon as video playback starts, and later restore them when you close the media player. So video playback have correct colors, but other applications will not be calibrated as long as video playback runs.

When using "collink -H", madVR will auto fill the GPU gamma ramps with the dispcal calibration and never clear it.
post #438 of 1698
madshi, Could you add option to prevent display going to sleep mode while using madTPG?
Edited by kasper93 - 7/6/13 at 5:19am
post #439 of 1698
Is it the display which went into sleep mode or the whole PC? Not sure how to prevent that, will have to investigate...
post #440 of 1698
Only display. When using dispcal with internal generator there is no problem.

EDIT:

I would like to report that this workflow (posted few post higher) gave me very nice results. Thanks gwgill and madshi for your work smile.gif
Edited by kasper93 - 7/6/13 at 10:28am
post #441 of 1698
Ok, with the latest software versions and recommendations I've run some more tests to further optimize the parameter set. Here are the results:

(1) Objective: Find out whether using dispcal works better than skipping it.

gamma.jpg - rgb.jpg - cie.jpg <-- use dispcal
gamma.jpg - rgb.jpg - cie.jpg <-- skip dispcal

No contest. Using dispcal works clearly better for me.

(2) Objective: Find out which dispcal gamma parameter works best for my display: "-gs" or "-g1.0" or "-g2.6" or "-G2.4 -f0"?

gamma.jpg - rgb.jpg - cie.jpg <-- dispcal -gs
gamma.jpg - rgb.jpg - cie.jpg <-- dispcal -g1.0
gamma.jpg - rgb.jpg - cie.jpg <-- dispcal -g2.6
gamma.jpg - rgb.jpg - cie.jpg <-- dispcal -G2.4 -f0

"-gs" produces the best RGB balance and primary/secondary correction for my display. Not totally sure about the gamma reponse, though. "-gs" has a rather steep rise near IRE 100.

(3) Objective: Find out which collink gamma parameter works best for my display: "-IB" or "-Ib"?

gamma.jpg - rgb.jpg - cie.jpg <-- collink -IB
gamma.jpg - rgb.jpg - cie.jpg <-- collink -Ib

Gamma response and RGB balance is quite similar. However, primaries and secondaries seem to be nearer to their desired spot when using "-Ib".

(4) Objective: Find out which collink "intent" parameter works best for my display: "-ir" or "-ia" or "-iaw"?

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

Absolute intent seems to work noticeably better for my display than relative intent. There doesn't seem to be much difference between "-ia" and "-iaw", as long as you let dispcal already convert the white point to D65. I guess I'll end up using "-iaw".

(5) Objective: Find out whether there are noticeable differences between the colprof and collink quality parameters:

gamma.jpg - rgb.jpg - cie.jpg <-- colprof/collink -ql
gamma.jpg - rgb.jpg - cie.jpg <-- colprof/collink -qm
gamma.jpg - rgb.jpg - cie.jpg <-- colprof/collink -qh
gamma.jpg - rgb.jpg - cie.jpg <-- colprof/collink -qu

Low and medium quality have some kinks in the gamma response and higher errors in the RGB balance. High quality mostly resolves that. So my recommendation would be to use high quality. Ultra quality brings another small improvements to the gamma response, but the difference is not big. If you've found your optimal parameters and have some time to spare, there's no harm using ultra quality, but whether the small improvement is visible to your eyes is another question.

Finally, here are the settings I've achieved the best results with:
Code:
dispcal -v -dmadvr -qu -gs -t6500 dispcal
targen -v -d3 -G -e16 -g100 -s100 -f5000 dispread
dispread -v -dmadvr -K dispcal.cal dispread
colprof -v -qu -aX dispread
collink -v -qu -G -iaw -Ib -3m -et -Et -a dispcal.cal Rec709.icm dispread.icm 3dlut.icm

This might be a bit overkill, though. I guess I'd recommend the following as the best "bang for the buck":
Code:
dispcal -v -dmadvr -qu -gs -t6500 dispcal
targen -v -d3 -G -g100 -s40 -f3000 dispread
dispread -v -dmadvr -K dispcal.cal dispread
colprof -v -qh -aX dispread
collink -v -qh -G -iaw -Ib -3m -et -Et -a dispcal.cal Rec709.icm dispread.icm 3dlut.icm

Some final comments:

(1) For targen use some extra gray (-g) and single channel (-s) steps to improve gamma response and primary/secondary accuracy.
(2) I strongly recommend to use the madVR test pattern generator. It allows dispcal to work in a higher bitdepth, which should produce better quality. Furthermore using the madVR TPG even speeds dispcal up because less measurements need to be repeated because madVR's higher processing bitdepth often allows dispcal to avoid hitting the error threshold.
(3) dispcal ultra quality ("-qu") is not that much slower than high quality, when using madVR as test pattern generator, so I recommend always using "-qu". It improves the final gamma curve for me. I think dispcal ultra quality with madVR's TPG is just as fast as using dispcal high quality with the Argyll test pattern generator.



@Graeme:

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". 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!
Edited by madshi - 7/7/13 at 6:51am
post #442 of 1698
Quote:
Originally Posted by gwgill View Post

I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with versions that support displaying test patches through MadVR using the "-d madvr" option.

Note that while this then avoids the need for using the -E flag in dispcal and dispread when the display needs video encoding, you need to be careful to setup the Graphics Card VideoLUTs the way you want them if MadVR plays through them, since calibrating and profiling through MadVR doesn't touch the Graphics Card VIdeoLUTs.

So if my display wants 16-235 and gfx card is set to 0-255 I should set madvr to 16-235 while using -dmadvr and ofc no need to use -E in dispcal or dispread?
post #443 of 1698
Correct. The "-E" parameter should not be used with the madVR test pattern generator.
post #444 of 1698
Just released v0.86.8 with some nice improvements to the test pattern generator, and with support for specifying a separate 3dlut file for every source gamut (BT.709, SMPTE-C, EBU/PAL, BT.2020 and DCI-P3):

http://madshi.net/madVR.zip (v.0.86.8)
post #445 of 1698
Madshi, thanks! Can these commands be run in a single command file? Or should one run separate command files for each step?
Also, what if I don't want a BT.1886 gamma and want a simple 2.2/2.4 pure power curve gamma (cause my display's contrast allows it)? What target .icm file should I use?
Just out of interest, is there any use to DCI-P3 gamut conversion? It's just that my projector (Mitsubishi HC5) has a native DCI-P3 gamut but there's no way to "upconvert" a rec709 source, for example, to a DCI-P3 gamut afaik.
post #446 of 1698
Quote:
Originally Posted by Elix View Post

Can these commands be run in a single command file? Or should one run separate command files for each step?

Separate. But you can use a batch file.

Quote:
Originally Posted by Elix View Post

Also, what if I don't want a BT.1886 gamma and want a simple 2.2/2.4 pure power curve gamma (cause my display's contrast allows it)? What target .icm file should I use?

As far as I understand (without having really looked at the specs myself), if your display's black level is perfect black, BT.1886 should produce a true 2.4 pure power curve. So I would think there's no harm using BT.1886 even if your display has a very good contrast ratio. That said, you might want to try both to see which looks better to your eyes. However, I've not actually tested how to use ArgyllCMS to get a pure power curve, so I can't tell you the optimal parameters for that. I guess you'd tell dispcal to calibrate to a pure power curve and then simply remove the "-Ib" parameter from collink - but I'm just guessing here. Personally, I think I'll stick to BT.1886 for all my displays...

Quote:
Originally Posted by Elix View Post

Just out of interest, is there any use to DCI-P3 gamut conversion?

That will only be of use if you actually have native DCI-P3 sources.
post #447 of 1698
I have been using MadVR for some time now, with limited success using the 3DLUT function.
These new developments seem very interesting, but I am finding these strings of characters confusing. Is there a GUI tools that automates this?

I need to profile a colorimeter off my spectro, and generate profiles for HD, NTSC, and PAL, calibrating the display to 2.4 gamma with the highest quality possible.

Can this method of LUT generation correct for nonlinearities in the color response? If I put my TV into wide gamut mode or increase color to about 65/100 it will exceed BT.709 and should support accurate calibration. In the normal colorspace I measure slightly less than BT.709.
post #448 of 1698
Quote:
Originally Posted by Chronoptimist View Post

These new developments seem very interesting, but I am finding these strings of characters confusing. Is there a GUI tools that automates this?
I hear you. There's currently been one nice GUI for it - dispcalGUI - but it's outdated now that ArgyllCMS supports many new features.
Quote:
Originally Posted by Chronoptimist View Post

I need to profile a colorimeter off my spectro, and generate profiles for HD, NTSC, and PAL, calibrating the display to 2.4 gamma with the highest quality possible.
You can make a colorimeter correction file with dispcalGUI. Once you've calibrated and profiled to your target response you can make several 3DLUTs with HD, NTSC, and PAL target primaries and use them in madVR for each source.
Quote:
Originally Posted by Chronoptimist View Post

Can this method of LUT generation correct for nonlinearities in the color response?
Yes, it can. http://www.avsforum.com/t/1471169/madvr-argyllcms#post_23274962 You should be able to get good results using wide gamut color space depending on setting you will use during calibrating, profiling and making a 3DLUT. The rule of thumb is: you CAN tone down luminance and saturation but you CAN'T tone it up.
Edited by Elix - 7/8/13 at 12:08am
post #449 of 1698
Quote:
Originally Posted by Chronoptimist View Post

I am finding these strings of characters confusing. Is there a GUI tools that automates this?

Currently I think it's better to use the ArgyllCMS command line tools with those strings of parameters directly. The "problem" is that there are simply so many options and it's not always clear which option is the "best". It can vary on your display, your calibration goal and other things. It shouldn't be too hard to create a little GUI to automate all this specifically for madVR, but there were so many changes recently that it might make sense for developers to wait until the dust settles before working on such a GUI. So for now I'd recommend that you check the Argyll documentation to understand what purpose those strings of characters have, just to get a basic understanding how it all works. It might cost you and hour or two of reading, but it's not *that* complicated, especially if you already have some knowledge about calibration...

Quote:
Originally Posted by Chronoptimist View Post

If I put my TV into wide gamut mode or increase color to about 65/100 it will exceed BT.709 and should support accurate calibration. In the normal colorspace I measure slightly less than BT.709.

You could try calibrating with your color control set to 100/100, or alternatively with a lower color control value which just slightly exceeds BT.709 for all primaries and secondaries. My best guess is that 100/100 will give you the best results, but it shouldn't harm trying both, just to be safe. ArgyllCMS should be able to correct any problems either way.
post #450 of 1698
Quote:
Originally Posted by madshi View Post

Currently I think it's better to use the ArgyllCMS command line tools with those strings of parameters directly. The "problem" is that there are simply so many options and it's not always clear which option is the "best". It can vary on your display, your calibration goal and other things. It shouldn't be too hard to create a little GUI to automate all this specifically for madVR, but there were so many changes recently that it might make sense for developers to wait until the dust settles before working on such a GUI. So for now I'd recommend that you check the Argyll documentation to understand what purpose those strings of characters have, just to get a basic understanding how it all works. It might cost you and hour or two of reading, but it's not *that* complicated, especially if you already have some knowledge about calibration...
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. I'll see if I can get it working later today though.
Quote:
Originally Posted by madshi View Post

You could try calibrating with your color control set to 100/100, or alternatively with a lower color control value which just slightly exceeds BT.709 for all primaries and secondaries. My best guess is that 100/100 will give you the best results, but it shouldn't harm trying both, just to be safe. ArgyllCMS should be able to correct any problems either way.
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.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS