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

MadVR - ArgyllCMS - Page 31

post #901 of 1680
Quote:
One more update, after further testing the above does produce good gray scale and color correction if the scaling switches to collink are -et -En. TV scale input, normal scale output. Normally for the eeColor box they are -et -Et.

Yes, forgot to mention this.
Quote:
However, even though the calibration works this way a strange side effect of this method is that level 235 gets stretched to 255 and boosts peak output at the display while black stays where it should.

Hmm in my eeColor test LUT created with my workaround above everything below 16 gets lifted to 16, and everything above 235 gets clipped to 235, while the -E -K generated LUT scales smoothly from 0-16 and 235-255. Is that what you meant?

A way to work around this, based on my workaround above, when building the 3D LUT, don't apply calibration via the checkbox, but instead specify an additional collink argument -a filename.cal. But this has the same drawback as your original workaround, you have to manually change the filename when recalibrating...
I guess the real solution is to wait for an dispread update that fixes the underlying problems of double scaling with -E -k respective implicit scaling not working.
post #902 of 1680
Quote:
Originally Posted by fhoech View Post

Hmm in my eeColor test LUT created with my workaround above everything below 16 gets lifted to 16, and everything above 235 gets clipped to 235, while the -E -K generated LUT scales smoothly from 0-16 and 235-255. Is that what you meant?

yes regarding black but 235 gets mapped to something higher in this flow. Peak white when up at the display ~20%.
Quote:
A way to work around this, based on my workaround above, when building the 3D LUT, don't apply calibration via the checkbox, but instead specify an additional collink argument -a filename.cal. But this has the same drawback as your original workaround, you have to manually change the filename when recalibrating...
I guess the real solution is to wait for an dispread update that fixes the underlying problems of double scaling with -E -k respective implicit scaling not working.

How is that different from checking vcgt?
Code:
Command line:
  collink.exe
    -v
    -qh
    -G
    -ia
    -3e
    -et
    -Et
    -a
    "REPEATER 2013-10-27 0.3127x 0.329y 2.2 (absolute) M-S XYZLUT+MTX.cal"
    Rec601_525_60_Gamma235.icm
    "REPEATER 2013-10-27 0.3127x 0.329y 2.2 (absolute) M-S XYZLUT+MTX.icm"
    3DLUT_6.icm

I've re-done everything using a manually entered -K filename.cal and get great results so I will stick with that. Thanks for the help!

Two small requests:
  1. It would be nice to be able to specify -K over -k even after dispread gets fixed.
  2. Have additional command line parameters become active without restarting the program.
post #903 of 1680
Quote:
Originally Posted by zoyd View Post

yes regarding black but 235 gets mapped to something higher in this flow. Peak white when up at the display ~20%.
That's definitely not what I'm seeing in the generated 3D LUT, where the peak value is 235 (actually 0.917983 * 255 = 234.085665 in my case).
Quote:
Originally Posted by zoyd View Post

How is that different from checking vcgt?
It's very different in the actual calibration values that get applied. If you use my original workaround (the "no additional commandline parameters for dispread" / "use and embed current calibration" flow), the values from the videoLUT will be used, which will already be scaled to 16-234, while with -K or -a original.cal the values will be from 0-255 and there will just be keyword in the cal file telling that this is meant to be used with TV output encoding. That's the reason why the uplifting from 0-16 to 16 / clipping to 235 happens when using the former.
Quote:
Originally Posted by zoyd View Post

  1. It would be nice to be able to specify -K over -k even after dispread gets fixed.
  2. Have additional command line parameters become active without restarting the program.
  1. I'll see what I can do.
  2. This is already the case smile.gif
post #904 of 1680
Quote:
Originally Posted by fhoech View Post


It's very different in the actual calibration values that get applied.

This is where I'm confused, the documentation states:

-a file.cal Apply calibration curves to link output and append linear

Are you saying this behaves differently depending on what's in the videoLUT? I assumed it takes the values from the file not the videoLUT.
post #905 of 1680
To explain it, if the message "the current calibration curves are going to be used" is shown in dispcalGUI (when "current" is selected under settings), it is to be taken literally: The actual videoLUT contents are saved (using dispwin -s), and then used. And the videoLUT contents when a cal file that was created by dispcal -E was loaded last, is the scaled values. So the collink -a behavior is always the same, just the contents of the used file are different.
post #906 of 1680
That all makes sense now, thanks. I am going to stick with the linear gamma tables workflow so I think that means an additional request that checking vgct when linear tables are loading skips the dispwin -s step and uses the existing .cal file. Or can I already do that by not having "current" selected?
post #907 of 1680
Quote:
Or can I already do that by not having "current" selected?
Exactly. If there is a cal file selected under settings, or the selected profile has an accompanying cal file, you'll also see the message "the calibration file < x> is going to be used" as a confirmation when clicking "profile only".
post #908 of 1680
Guys i will appreciate if somebody respond this PQ related questions.

1. l have a dilemma with my Panny TV, what you would use if have to select one of this following settings.

A. My Plasma can do RGB 4:4:4 BUT only with video black levels (16-235) in this mode you have to activate the 1080P Pure Direct in order to turn off the 4:2:2 internal downsampling, note that its for use the TV as a PC monitor for video, youtube anime etc, PC Games and desktop will look crushed because the GPU its outputting Full RGB 0-255 levels, the funny thing its that for PC gaming in this TV RGB 4:4:4 should be a Must.

B. an the second, l can get proper Full RGB PC level in the TV if l activate the DVI Complete settings, but, if a do this, the 1080p Pure Direct mode is grayed out and everything that the tv display will be downsample to 4:2:2, this settings allows proper color in Desktop web and gaming, but everything its turn down to 4:2:2 , my questions its if this will be worts to PQ, especially if i wanna do some gaming in the plasma.

Note that if l stay with 4:4:4 i have to put tv levels in madvr settings in order to get good color reproduction, the GPU will always output PC Levels.

l hope you cant help me wtih this setting dilemma.
post #909 of 1680
Quote:
1. It would be nice to be able to specify -K over -k even after dispread gets fixed.
It's now possible (new option in the options menu).
http://dispcalgui.hoech.net/download/snapshot/dispcalGUI-win32.zip
post #910 of 1680
Sorry but the new switch did not work for me in either dry run or real mode. I checked both embed calibration curves and use linear instead boxes and it still runs with -k. "use linear instead" comes up as unchecked on next try.
post #911 of 1680
smile.gif that's not the option I meant. What you're looking for is the menu item "do not use video card gamma table to apply calibration" in the options menu, which when checked is the equivalent of -K.
post #912 of 1680
biggrin.gif ok, got it. Works fine and thanks!
post #913 of 1680
Thread Starter 
Here is my latest calibration with MadVR 3DLUT on my Sharp Elite. Great results. I will be replacing the first post with instructions for the new workflow using DispcalGUI.

3DLUT options
BT.1886, 2.4 Absolute, Absolute colorimetric with white point scaling

post #914 of 1680
Quote:
Originally Posted by N3W813 View Post

Here is my latest calibration with MadVR 3DLUT on my Sharp Elite. Great results. I will be replacing the first post with instructions for the new workflow using DispcalGUI.

3DLUT options
BT.1886, 2.4 Absolute, Absolute colorimetric with white point scaling


Looking forward to the new work flow. I hope it has become a little bit more easier to do it.
post #915 of 1680
Quote:
Originally Posted by N3W813 View Post

Here is my latest calibration with MadVR 3DLUT on my Sharp Elite. Great results. I will be replacing the first post with instructions for the new workflow using DispcalGUI.

3DLUT options
BT.1886, 2.4 Absolute, Absolute colorimetric with white point scaling

Could use precise your Dispcalgui settings regarding testchart and other common options ? Thanks wink.gif
post #916 of 1680

Hi guys, so I've got that Sammy TV with an A-MVA panel, its very limited built-in gamma curves don't do the trick and there's no 10 points RGB white point balance so I'm gonna try my luck running Argyll with a nice BT.1886 curve using "dispcal -v -yl -t6500 -f0 -G2.4 -qm test".

 

When using "dispcal -r -yl -v", it can reach 3500:1 CR but to achieve this figure I have to set its contrast value to 100, problem is that whites look quite crushed. Stock is 95 but then I find the 3K:1 CR too low to my taste.

 

What I did before with a TV that had no R/G/B offset/gain settings at all was to find its OSD settings that would provide the highest CR using that dispcal commandline and then run an ArgyllCMS calibration on top of it. Does that make sense?

 

So I plan on using an 8bit CLUT .cal file for the windows desktop, check "disable gamma ramps" in mVR and feed it a nice 16bit 3DLUT built from Argyll so it'll be dithered to 12bit by mVR, what would be the easiest way to do that please?

 

I'm still using this gamut mapping PS script with automatic profiles based on resolution & frame rate in PotPlayer but I guess I might look into letting mVR take care of that later, I would rather do it one step at a time for now :) 

post #917 of 1680
Thread Starter 
Quote:
Originally Posted by Coxwell View Post

Could use precise your Dispcalgui settings regarding testchart and other common options ? Thanks wink.gif

I have updated the first post with instructions using DispcalGUI to create the madVR 3DLUT.

Here are the testchart settings I used to tame my Sharp Elite, 4000 total patches smile.gif

post #918 of 1680
I have an issue since I started to try this procedure: black floor raises a bit (eg. 0,013 without 3DLUT, up to 0,015 with).
I noticed both with a LCD screen and a DLP vpr. The DLP clearly shows the issue since if you go very close to the screen, you can see the dithering (the way color wheeled DLP create the shades of grays).
So it's the "smoking gun" that proves that the 3DLUT raises the black level.
It happens both with dispcalGUI and DOS commands. I also set "-k0.0 -A4.0" just to be sure that there's no black hue correction, but no way, it always happens.
I have then to lower a little bit the brightness in the vpr in order to get back the perfect black floor, but of course this raises a bit the full gamma curve, especially at low IRE.
has someone had a similar issue?
post #919 of 1680
Quote:
Originally Posted by N3W813 View Post

I have updated the first post with instructions using DispcalGUI to create the madVR 3DLUT.

Here are the testchart settings I used to tame my Sharp Elite, 4000 total patches smile.gif


DId you get more effective results using thist testchart than the one you put 1 or 2 pages ago (using approximately 10000 patches ?)
post #920 of 1680
Thread Starter 
Quote:
Originally Posted by Kukulcan View Post

I have an issue since I started to try this procedure: black floor raises a bit (eg. 0,013 without 3DLUT, up to 0,015 with).

Yes, my black has also been raised from 0.0134 to 0.0145 fL with 3DLUT enabled. Like you said, you can lower brightness until black is lowered to the initial value but you will raise the gamma at the low end a bit. I think you will just have to pick your poison for now until Graeme can research into why black is raised slightly.

On my Sharp Elite, after calibration and implementing the 3DLUT, I turn on Local Dimming which lowers black to a level not measurable by my meter so the slightly raised black has no visible effect on the quality of the video.
Quote:
Originally Posted by Coxwell View Post

DId you get more effective results using thist testchart than the one you put 1 or 2 pages ago (using approximately 10000 patches ?)

I wouldn't say 'more' effective; I would say equally as good results. But 4000 vs 10000 patches means a reduction of about 110 minutes from the total process. In my calibration sessions, it takes an additional 15 minutes to read 1000 patches using the i1D3 meter. There is also additional processing time when running colprof.exe to generate the icm from such a large pattern set.

Please keep in mind the pattern set I used is specific to the Sharp Elite. Better behaved sets can achieve good results with a much lower quantity patterns set.
post #921 of 1680
Why is the gamma recommended at 2.4 rather than 2.2?
post #922 of 1680
I am looking at this BT.1886 gamma curve but I am unsure if I should use it... Does it really look better than regular 2.22 gamma curve? I actually have service menu hardware controls that allow me to change the shape of gamma curve but not like a 10pt system, more like a 6pt system... I found it accidentally.

Besides, I doubt games use BT.1886 curve for a standard...
post #923 of 1680
@N3W813 why on earth did you remove perfectly fine work-flow? Not everyone want to use GUI and with raw command line commands you have more insight what actually is going on. And more important, previous work-flow was proven to be valid, new one is just whatever. Not saying it's wrong, but you know...
post #924 of 1680
Thread Starter 
Quote:
Originally Posted by kasper93 View Post

@N3W813 why on earth did you remove perfectly fine work-flow? Not everyone want to use GUI and with raw command line commands you have more insight what actually is going on. And more important, previous work-flow was proven to be valid, new one is just whatever. Not saying it's wrong, but you know...

Not removed, it's still there, just moved to post #2. wink.gif What do you mean the new one is 'whatever'? It is exactly the same as the commandline workflow but through a GUI. confused.gif You can easily verify this through the DispcalGUI log files. It will log the exact commandline used during the process.
Quote:
Originally Posted by MonarchX View Post

I am looking at this BT.1886 gamma curve but I am unsure if I should use it... Does it really look better than regular 2.22 gamma curve? I actually have service menu hardware controls that allow me to change the shape of gamma curve but not like a 10pt system, more like a 6pt system... I found it accidentally.

Besides, I doubt games use BT.1886 curve for a standard...

Graeme choose to implement the BT1886 curve to the creation of the 3DLUT using collink.exe. It has been previously requested that a power curve option be added but he refused. You can search though previous posts to find his justification.

The workflow does not apply the videoLUT settings to the video card. It is only applied to the 3DLUT. Therefore, the BT.1886 curve will not be applied to the desktop so it will not affect your games. The calibration and profile will ONLY correct video sources played through madVR.
Edited by N3W813 - 11/13/13 at 12:17pm
post #925 of 1680
@N3W813: Oh, I'm terribly sorry. Didn't notice second post. I was on my mobile phone and missed that. And about the GUI if it's the same it's fine, but I just like command line better because I actually know what's going on before and not after in the log. But still if it's exact the same it's fine ") Good work.

EDIT: But in fact it can't be the same because current dispcalgui uses gpu videolut which is not recommended in 3dlut creation for madVR. Few post higher is an version which support that, but you didn't cover this in guide. So GUI work-flow is worse than command line smile.gif
Edited by kasper93 - 11/13/13 at 12:29pm
post #926 of 1680
Thread Starter 
Quote:
Originally Posted by kasper93 View Post

EDIT: But in fact it can't be the same because current dispcalgui uses gpu videolut which is not recommended in 3dlut creation for madVR. Few post higher is an version which support that, but you didn't cover this in guide. So GUI work-flow is worse than command line smile.gif

Why is integrating the videolut in the 3DLUT not recommended?

In my commandline workflow the command for collink.exe is...
Code:
collink.exe  -v  -3m  -qh  -et  -Et  -Ib:2.2  -G  -a dispcal.cal  -iaw  Rec709.icm  MadVR.icm  3DLUT.icm

...which applies the calibration file (dispcal.cal) obtained from running dispcal.exe. This is exactly the same as enabling the 'Apply calibration (vcgt)' option in the Create 3DLUT menu in DispcalGUI.
post #927 of 1680
I thought about
Code:
dispread.exe  -v  -dmadvr  -Yp  -K dispcal.cal  "MadVR"

Current dispcalGUI will load dispcal.cal to GPU videolut which is not recommended because it has lower processing quality than madVR. Hence -K parameter... Look at #909 post. I don't have time to test it right now, so I might be wrong. But take a look at Zoyd posts, everything is in there smile.gif
Edited by kasper93 - 11/13/13 at 12:55pm
post #928 of 1680
Quote:
Originally Posted by N3W813 View Post

Graeme choose to implement the BT1886 curve to the creation of the 3DLUT using collink.exe. It has been previously requested that a power curve option be added but he refused. You can search though previous posts to find his justification.
You don't have to use BT1886 if you don't want to - simply don't set those options. There is no other override for the input space transfer curve characteristic though, although you have the choice of the input profile and the gamut mapping options to control the nature of the space being emulated. If you don't do something about matching the input to output black point, you are likely to clip them thereby loosing shadow detail. The BT1886 option is one way of making a viewing conditions adjustment and matching the black points - besides which it is the video reproduction standard, for use in concert with the established video encoding standards such as Rec709 etc.
post #929 of 1680
Quote:
Originally Posted by N3W813 View Post

Yes, my black has also been raised from 0.0134 to 0.0145 fL with 3DLUT enabled. Like you said, you can lower brightness until black is lowered to the initial value but you will raise the gamma at the low end a bit. I think you will just have to pick your poison for now until Graeme can research into why black is raised slightly.

I've looked into this sort of thing a number or times, and as far as I can determine, it seems to a result of profile inaccuracy. Plasma displays in particular seem to have an extremely low black point, and both the instrument and profile accuracy are a challenge.

[Technically what happens is that RGB 0,0,0 is looked up in the forward table, and then that CIE/Jab value is reverse looked up, and arrives at a non-zero RGB value. This is expected when the display has a "dead band" at zero. If the profile is not sufficiently accurate, then there may be a slight error from the true device black value. By normal display standards we are talking about a very, very small error - the above it is 0.004 cd/m^2, way below the expected accuracy of the instrument. Compared to a full scale of (say) 100 cd/m^2, that's an inaccuracy of 0.004%! It's miraculous that it is so small. I'm not clear under what circumstances it will be visible, other than observing the display in pitch dark with a black raster. Or am I underestimating how dark some scenes can get ?]

In the short term, you can try the following: Add more black test points using "targen -B". Try adding a lot more - 20, 50, 100, depending on your chart size. This not only gives you more of an average value, it increases the weighting of that point in the profile fitting.
Try different models, shaper+matrix, Lab cLut, XYZ cLut. One of these may better fit your particular display than the others.

In the long term I'm planning on adding a "dynamic range" factor to targen and colprof, that allows emphasizing the accuracy of the darker regions of the device behavior, with an aim to improving accuracy there.

Another possibility would be for me to add another option to collink analogous to the -f/F flags, that forces the black point. I'm reluctant to do this because the whole purpose is to not make assumptions about the device behavior, but to measure it. Forcing the black to map device 0,0,0 -> 0,0,0 makes the assumption that device 0,0,0 really is the device black point. I've seen a number of examples where this isn't true (one is right in front of me at the moment!) and a calibration/profiling systems that ignores this possibility is not doing its job. The consequences of using such a flag wrongly would be to clip the blacks and loose shadow detail. Implementation is complicated/problematic too when there are input and output one dimensional curves.
post #930 of 1680
@Graeme

Don't know if you caught the discussion a couple pages back but Florian and I had trouble with the dispread -k and -K switches not implicitly using -E.
Edited by zoyd - 11/13/13 at 5:36pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS