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

MadVR - ArgyllCMS - Page 39

post #1141 of 1680
Quote:
Originally Posted by zoyd View Post

I am talking about what I measure using just dispcal to calibrate the video card+display, also this was not through madVR so as to isolate each step. This way you can see which operations on the input values might be problematic.
Stop there

Now run
dispwin -v dispcal.cal
dispcal -v -dmadvr -r

This will report your black and white levels with the calibration loaded to quickly check if they have changed. If you do this through madVR the "disable gamma ramps" has to be unchecked. I would test it both with and without madVR in the loop and with/without the switch -k0 in dispcal.

OK, will do and report!
I think I am getting a hang of this, going back and forth between logs, commands, what they do, how its used, its like a little language to learn.

From dispcalGUI, I managed to get these commands:
dispcal.exe -v2 -dmadvr -c1 -yn -X ".ccss name" -qh -m "-w0.3127,0.329" -G2.4 -f0 -k0 -A4.0 ".cal name"
dispwin.exe -dmadvr -s ".cal name"
dispread.exe -v -dmadvr -c1 -yn -X ".ccss name" -k ".cal name" ".ti1 name"
collink.exe -v -qh -G -iaw -3m -et -Et -IB:2.4 -a ".cal name" "ref .icm name" ".icm name" ".3dlut/.icm name"

I couldn't figure out if dispcalGUI was using the targen.exe and the colprof.exe files. targen is needed to make a testchart, but dispcalGUI already has one pre-made - madVR.icm but its not a .ti1 file so I am not sure what the command would be... Will dispread.exe read an .icm file?
The old target.exe command in the guide was
targen.exe -v -d3 -G -s40 -g128 -f2000 ".ti1 name" but it can't be right because dispcalGUI is now using -f1399 and there were parameters recently added (n1.5) which some said improved things and others said it made no difference or even made things worse.
The old command for colprof.exe was
colprof.exe -v -qh -bl -aX ".ti3 name" but again, it is related to the pattern file, which is now supposedly pre-made by dispcalGUI and exists in madVR.icm file.

I also lost track of the best files to use with all the Argyll versions and updates. I was downloading all the latest files like dispcal.exe and collink.exe but I think some provided results worse than before.
Could you please enlighten me as to which exact dispcal.exe and collink.exe (or any other updated files) provided the best results for black levels?
Could you also let me know which new targen.exe and colprof.exe parameters/commands I should use for the best results in madVR or if I should just stick with dispcalGUI pre-made madVR.icm pattern file?
Edited by MonarchX - 11/27/13 at 7:52am
post #1142 of 1680
Original:
Black - 0.056
CR - 1750:1

Old command with G.24
dispwin.exe -v -c
dispcal.exe -v -dmadvr -Yp -qh -m -G2.4 -w 0.3127,0.3290 "dispcal.cal"
dispwin -v dispcal.cal
dispcal -v -dmadvr -r

Black - 0.079
CR - 1150:1

Now testing dispcalGUI command with G2.4
dispcal.exe -v2 -dmadvr -c1 -yn -X CCFLFamily_07Feb11.ccss -qh -m "-w0.3127,0.329" -G2.4 -f0 -k0 -A4.0 "dispcal.cal"
post #1143 of 1680
I would concentrate on getting a flow that works from the command line first and not worry about the gui. Once you have that you can figure out which settings in the gui can reproduce your confirmed-to-work command lines and branch out from there. The current beta version of dispcal and collink 1.6.3beta (-v will tell you) should be used although I expect Graeme will have an update to colprof and/or collink that addresses the non-montonic issue that moves the black point around.
post #1144 of 1680
Yes, but I am getting much better results using commands from the GUI than using commands from the old guide.

dispcalGUI command with G2.4
dispcal.exe -v2 -dmadvr -c1 -yn -X CCFLFamily_07Feb11.ccss -qh -m "-w0.3127,0.329" -G2.4 -f0 -k0 -A4.0 "dispcal.cal"
Black - 0.585
CR - 1650:1

A slight rise in blacks and slight CR reduction!
The old command produced much worse results!

This is why I wish to know the targen.exe and colprof.exe commands that dispcalGUI is using or whether I need to use them at all with madVR.icm testchart.

I am certain that using -g2.2 will not produce a black level rise, but I will test it anyway.

I was using dispcal.exe 1.6.3 beta.
post #1145 of 1680
I think there's already much which Graeme can take care of... He has always suspected that the issue comes from the target profile. So MonarchX, I wouldn't put so much effort in testing issues already well-known, let's wait patiently that Graeme finds what's wrong in colprof.
I just posted my tests since there was an unusual behaviour(for me, probably it's normal for Graeme given the option used), but it's not necessary that you add further confirmations that the actual workflow rises black level.

If Graeme adds some fixes in the following days, and you want to contribute to testing I again strongly encourage you to use only DOS commands otherwise your efforts will probably be useless, for reasons that have been already told to you several times.
post #1146 of 1680
Quote:
Originally Posted by fhoech View Post

If by BPC you mean "black point compensation" option present in dispcalGUI in contrast to the "black point correction" option (they are very different things, black point correction is an Argyll CMS option that corrects black point hue, while black point compensation as implemented in dispcalGUI I'll describe here briefly):

I'll be frank, what black point compensation in dispcalGUI does is it will take the characterization measurements and then blatantly lie about them by mapping the actual measured black XYZ values to 0, scaling all other values accordingly. This has the effect that when a profile created with that option enabled is used in a transform with a source profile that has "perfect" zero black, black crush is avoided even in "dumb" matching scenarios (ie. when there is no other more sophisticated gamut mapping used, like the gamut mapping options involving a source profile when creating a LUT profile, or the BT.1886 option when creating a 3D LUT). This of course reduces the profile accuracy somewhat, with the error introduced by BPC being zero at white, and then progressively increasing towards black....

Thank you for your detailed explanation smile.gif
post #1147 of 1680
I've also been in the process of testing the new collink / dispcal with the following result:

dispwin.exe -v -c
dispcal.exe -v -Yp -r

Black level = 0.0276 cd/m^2
50% level = 28.83 cd/m^2
White level = 131.06 cd/m^2
Aprox. gamma = 2.18
Contrast ratio = 4749:1

***************************************

dispwin.exe -v -c
dispcal.exe -v -Yp -dmadvr -r

Black level = 0.0275 cd/m^2
50% level = 28.28 cd/m^2
White level = 130.99 cd/m^2
Aprox. gamma = 2.21
Contrast ratio = 4758:1

****************************************
****************************************

dispcal.exe -v -dmadvr -Yp -yn -X WLEDFamily_07Feb11.ccss -qh -m -g2.2 -k0 -w 0.3127,0.3290 "dispcal"
dispwin.exe -v dispcal.cal
dispcal.exe -v -Yp -r

Black level = 0.0276 cd/m^2
50% level = 29.26 cd/m^2
White level = 128.33 cd/m^2
Aprox. gamma = 2.13
Contrast ratio = 4657:1

****************************************

dispcal.exe -v -dmadvr -Yp -yn -X WLEDFamily_07Feb11.ccss -qh -m -g2.2 -k0 -w 0.3127,0.3290 "dispcal"
dispwin.exe -v dispcal.cal
dispcal.exe -v -Yp -dmadvr -r

Black level = 0.0276 cd/m^2
50% level = 29.00 cd/m^2
White level = 129.51 cd/m^2
Aprox. gamma = 2.16
Contrast ratio = 4698:1

****************************************

dispcal.exe -v -dmadvr -Yp -yn -X WLEDFamily_07Feb11.ccss -qh -m -g2.2 -k0 -w 0.3127,0.3290 "dispcal"
targen.exe -v -d3 -G -B8 -s40 -g128 -f2000 -V2.0 -N1.0 "MadVR"
dispread.exe -v -dmadvr -Yp -yn -X WLEDFamily_07Feb11.ccss -K dispcal.cal "MadVR"
colprof.exe -v -qh -bl -aX -V2.0 "MadVR"
collink.exe -v -3m -qh -et -Et -Ib:2.2 -G -a dispcal.cal -iaw Rec709.icm MadVR.icm 3DLUT.icm
dispcal.exe -v -Yp -dmadvr -r

Black level = 0.0287 cd/m^2
50% level = 28.41 cd/m^2
White level = 128.46 cd/m^2
Aprox. gamma = 2.18
Contrast ratio = 4476:1
Edited by MSL_DK - 11/27/13 at 9:30am
post #1148 of 1680
Quote:
Originally Posted by Kukulcan View Post

I think there's already much which Graeme can take care of... He has always suspected that the issue comes from the target profile. So MonarchX, I wouldn't put so much effort in testing issues already well-known, let's wait patiently that Graeme finds what's wrong in colprof.
I just posted my tests since there was an unusual behaviour(for me, probably it's normal for Graeme given the option used), but it's not necessary that you add further confirmations that the actual workflow rises black level.

If Graeme adds some fixes in the following days, and you want to contribute to testing I again strongly encourage you to use only DOS commands otherwise your efforts will probably be useless, for reasons that have been already told to you several times.

... and I have been using only DOS commands for each and every step. I was taking those commands from dispcalGUI log file, but I still used separate DOS... I won't report what is already confirmed.

So far I know for a fact that using DOS commands from the old guide is a bad idea as the results raise black level and cut CR way more than the "slight rise" we are talking about right now. Following that DOS command guide is a bad idea because it is too oudated. There should be a note or something that dispcalGUI is not using the same commands as the original guide and the commands used in dispcalGUI should be provided. I want to know what it is that dispcalGUI does differently that produces better results, so I start whichever dispcalGUI process, cancel it, and look in the log file. I also wish to make it easier for those new to this to understand and learn the DOS commands and be able to contribute without repeating my steps and posting "So, I used the commands in the guide and I got this terrible result". Why put others through it? This software will be better of if more people test it. Providing dispcalGUI DOS commands may bring light as to where the bugs/issues are.

I went further and found out that commands that dispcalGUI uses for creation of its madVR test chart are:
targen.exe -v -d3 -e4 -B4 -s33 -g97 -m9 -b9 -f0 -p1.0 "ti1. name"

However, I also see people including a reference file into targen commands, such as targen -v -d3 -e4 -B8 -b0 -s0 -g64 -m0 -V2.0 -N1.0 -c rec709.icm -f1000 -W final and wonder if I should do the same when running madVR test chart targen.exe -v -d3 -e4 -B4 -s33 -g97 -m9 -b9 madVR.icm -f0 -p1.0 "ti1. name" ???

I know colprof has issues, but where is the harm in knowing which colprof commands dispcalGUI is using? I just can't figure it out because I cancel dispcalGUI processes to save time. I won't be reporting bad results until it is fixed.
post #1149 of 1680
Quote:
Originally Posted by MonarchX View Post

Following that DOS command guide is a bad idea because it is too oudated.

Frankly ... What do you know about this? What conditions do you have to conclude this? Think you need to give Graeme time instead!!!
post #1150 of 1680
So here's a new test build:

http://madshi.net/madVRanotherTestBuild1.rar (overwrite the official build with the files from this rar)

The changes for calibration are the following:

(1) fixed: ArgyllCMS/HCFR disabling the 3dlut didn't work
(2) fixed: dithering was not setup correctly, resulting in blocking artifacts
(3) madVR doesn't dither, anymore, when the requested test pattern color doesn't need dithering
(4) added new calibration API which allows ArgyllCMS/HCFR to ask the madVR output levels setting (TV, PC, custom)
(5) added madHcNet64.dll to allow madTPG automation from 64bit versions of ArgyllCMS/HCFR
(6) maybe fixed (not sure): madTPG sometimes failed to update to a newly requested test pattern color

The fixes are all in madVR.ax, so no need for a new madTPG.exe, just in case you're wondering.
post #1151 of 1680
Quote:
Originally Posted by fhoech View Post

If possible, add 5) it seems the video LUTs are not reset to linear during characterization measurements if not using the videoLUT for actual calibration (imho they should also be reset in that case, atleast this is how Argyll's dispread behaves with the -K option if not using madVR).

I'm not sure exactly what you mean? madTPG does not automatically reset video LUTs during measurements. It's the job of the calibration software (ArgyllCMS or HCFR) to ask madVR to reset the video LUTs if that is needed for measurements. There is a madTPG API for that purpose. So this might be something that should be implemented in Argyll? But I'm not really sure what you mean, so I could be wrong.
post #1152 of 1680
Thread Starter 
Quote:
Originally Posted by madshi View Post

So here's a new test build:

http://madshi.net/madVRanotherTestBuild1.rar (overwrite the official build with the files from this rar)

The changes for calibration are the following:

(1) fixed: ArgyllCMS/HCFR disabling the 3dlut didn't work
(2) fixed: dithering was not setup correctly, resulting in blocking artifacts
(3) madVR doesn't dither, anymore, when the requested test pattern color doesn't need dithering
(4) added new calibration API which allows ArgyllCMS/HCFR to ask the madVR output levels setting (TV, PC, custom)
(5) added madHcNet64.dll to allow madTPG automation from 64bit versions of ArgyllCMS/HCFR
(6) maybe fixed (not sure): madTPG sometimes failed to update to a newly requested test pattern color

The fixes are all in madVR.ax, so no need for a new madTPG.exe, just in case you're wondering.

Thanks Madshi for the test build. Will find some time to test over the weekend. wink.gif

Hopefully, Graeme will have a test build fix for the black issue soon so I can test both at the same time. WAF decreases dramatically when I spend hours calibrating the TV instead of watching it. tongue.gif

Happy Thanksgiving to everyone, especially to Graeme, Florian, Madshi, and Zoyd. smile.gif
post #1153 of 1680
I', following this thread and really hope we can reach a solution for this raise in black levels. For my Dell U2410, which already comes from factory with very poor contrast, using a .3dlut just kills the little that is left of the Black Levels frown.gif This is so important for computer users, since most LCDs doesn't have very good blacks!
post #1154 of 1680
I used the -np function with IB2.2 and finally got the profile I was dying to get, but it had one issue - @ 10% IRE gamma was at 2.6 and then down to flat gamma from 20% IRE to 100% IRE. I realize -np is only for experimental purposes, but is this 2.6 gamma at low end a proper result? Is there a way to set to 2.2? Everything else is perfect!!!

I am not sure what the problem is with BT.1886 gamma curve anymore, I am not getting a black rise with colprof when using the following:

dispwin.exe -v -c
dispcal.exe -v2 -dmadvr -c1 -yn -X CCFLFamily_07Feb11.ccss -qh -m "-w0.3127,0.329" -G2.4 -f0 -k0 -A4.0 "dispcal"
targen.exe -v -d3 -e4 -B4 -s33 -g97 -m9 -b9 -f0 -p1.0 ".ti1 name"
dispwin.exe -dmadvr -s dispcal.cal
dispread.exe -v -dmadvr -c1 -yn -X CCFLFamily_07Feb11.ccss -k dispcal.cal ".ti1 name"
colprof.exe -v -qh -bl -aX ".ti3 name"
collink.exe -v -qh -G -iaw -3m -et -Et -IB:2.4 -a dispcal.cal Rec709.icm ".icm name" ".3dlut name"

I had a slight reduction on contrast ratio but the black level xyz coordinates ended up being the same before 3D LUT and after 3D LUT.
Edited by MonarchX - 11/27/13 at 12:56pm
post #1155 of 1680
Quote:
Originally Posted by madshi View Post

So here's a new test build:

http://madshi.net/madVRanotherTestBuild1.rar (overwrite the official build with the files from this rar)

The changes for calibration are the following:

(1) fixed: ArgyllCMS/HCFR disabling the 3dlut didn't work
(2) fixed: dithering was not setup correctly, resulting in blocking artifacts
(3) madVR doesn't dither, anymore, when the requested test pattern color doesn't need dithering
(4) added new calibration API which allows ArgyllCMS/HCFR to ask the madVR output levels setting (TV, PC, custom)
(5) added madHcNet64.dll to allow madTPG automation from 64bit versions of ArgyllCMS/HCFR
(6) maybe fixed (not sure): madTPG sometimes failed to update to a newly requested test pattern color

The fixes are all in madVR.ax, so no need for a new madTPG.exe, just in case you're wondering.

Is this to be used separately/specifically for ArgyllCMS/HCFR or should/could it be applied to the actual madVR installation/directory used by MPC-HC for madVR location?

Is there a downside to using high de-banding settings instead of low? It works real good, but in some scenes it makes the image a bit flatter.
Edited by MonarchX - 11/27/13 at 2:58pm
post #1156 of 1680
Quote:
Originally Posted by MonarchX View Post

Is this to be used separately/specifically for ArgyllCMS/HCFR or should/could it be applied to the actual madVR installation/directory used by MPC-HC for madVR location?
You should overwrite the files in your madVR installation directory with the ones from the archive, but note that madshi already posted an updated build in this post with a bugfix for video playback with the OSD on. Shouldn't affect the calibration side of things I would imagine.
post #1157 of 1680
Thanks!

I guess this version can be used with ArgyllCMS 64bit? That won't speed up colorimeter speed times, but hopefully some computation will be faster.
Edited by MonarchX - 11/27/13 at 5:44pm
post #1158 of 1680
Quote:
Originally Posted by madshi View Post

So here's a new test build:

http://madshi.net/madVRanotherTestBuild1.rar (overwrite the official build with the files from this rar)

The changes for calibration are the following:

(1) fixed: ArgyllCMS/HCFR disabling the 3dlut didn't work
(2) fixed: dithering was not setup correctly, resulting in blocking artifacts
(3) madVR doesn't dither, anymore, when the requested test pattern color doesn't need dithering
(4) added new calibration API which allows ArgyllCMS/HCFR to ask the madVR output levels setting (TV, PC, custom)
(5) added madHcNet64.dll to allow madTPG automation from 64bit versions of ArgyllCMS/HCFR
(6) maybe fixed (not sure): madTPG sometimes failed to update to a newly requested test pattern color

The fixes are all in madVR.ax, so no need for a new madTPG.exe, just in case you're wondering.

Thanks!

(1) was working for HCFR before, still working with test build. smile.gif

I also added the disable video LUT function but it has some strange behavior.

1. Load calibration file to video card via dispwin
2. madVR disable GPU gamma ramps is not checked, calibrate this display using external 3dLUTs is checked
3. Run pattern with madVR_SetDeviceGammaRamp(NULL) and madVR_Disable3dlut()
4. madVR properly removes gamma ramps and disables 3dlut but does not restore the gamma tables on disconnect. Does HCFR need to restore them?

2nd test

1. Load calibration file to video card via dispwin
2. madVR disable GPU gamma ramps is not checked, calibrate this display using external 3dLUTs is checked
3. Run pattern with only madVR_Disable3dlut()
4. madVR properly leaves gamma ramps alone and disables 3dlut but only until disconnect, then linear ramps are loaded.
5. Reload calibration file.
6. Run pattern without disabled the 3dlut or the video lut.
7. This time the gamma ramps survive a disconnect and stick.
post #1159 of 1680
Graeme: Out of curiosity, do you generally keep the development source up-to-date with these speculative fixes? I ask because I've gotten into a habit of compiling my own builds (I've played with some parameters, like the size of the LUT for LUT-based ICC profiles, and the fit goals for matrix-based ones).
post #1160 of 1680
Quote:
Originally Posted by VerGreeneyes View Post

Graeme: Out of curiosity, do you generally keep the development source up-to-date with these speculative fixes? I ask because I've gotten into a habit of compiling my own builds (I've played with some parameters, like the size of the LUT for LUT-based ICC profiles, and the fit goals for matrix-based ones).
It's a bit variable, but yes, I've been in the habit of updating when I make some beta test binaries available. The date on the devsrc .zip should give some indication if it's contemporary with the executable, and typically there will be a note in the log.txt file too.
post #1161 of 1680
Cool, thanks.

By the way, to everyone here: Since we're mostly calibrating and profiling for Rec.709 content, wouldn't it make more sense to calibrate with |dispcal -g709| (as opposed to with |dispcal -gs|)? The Rec.709 and sRGB specs both have a linear segment at the start of their transfer functions, but the Rec.709 one is a bit steeper. I don't know if this would be good for desktop use, but for the purposes of creating a Rec.709 specific 3DLUT perhaps it would match up better. Though having said that, the effective gamma of Rec.709 is also lower than the -Ib:2.2 we use right now. Maybe this could be accounted for by setting the ambient light factor to the sRGB encoding value of 64 lux? That is, |dispcal -g709 -a64|.
Edited by VerGreeneyes - 11/27/13 at 9:57pm
post #1162 of 1680
Quote:
Originally Posted by VerGreeneyes View Post

Cool, thanks.

By the way, to everyone here: Since we're mostly calibrating and profiling for Rec.709 content, wouldn't it make more sense to calibrate with |dispcal -g709| (as opposed to with |dispcal -gs|)? The Rec.709 and sRGB specs both have a linear segment at the start of their transfer functions, but the Rec.709 one is a bit steeper. I don't know if this would be good for desktop use, but for the purposes of creating a Rec.709 specific 3DLUT perhaps it would match up better. Though having said that, the effective gamma of Rec.709 is also lower than the -Ib:2.2 we use right now.

You can certainly do that if you want, and the linear segment makes it suitable for subsequent profiling (I'll change the tutorial to mention that). Rec709 is an encoding standard, not a display standard, hence the difference in effective gamma between it and BT.1886.
post #1163 of 1680
Quote:
Originally Posted by gwgill View Post

Rec709 is an encoding standard, not a display standard, hence the difference in effective gamma between it and BT.1886.
Would using |dispcal -g709 -a64| (64 lux as per sRGB) make it do the appropriate adjustment to an effective gamma of 2.2? I know that sounds like confusing two concepts, but I'd basically like to set the per-channel curves up to be as close to what collink will aim for (with -Ib:2.2) as possible.
post #1164 of 1680
Quote:
Originally Posted by VerGreeneyes View Post

Would using |dispcal -g709 -a64| (64 lux as per sRGB) make it do the appropriate adjustment to an effective gamma of 2.2? I know that sounds like confusing two concepts, but I'd basically like to set the per-channel curves up to be as close to what collink will aim for (with -Ib:2.2) as possible.
Yes, it should help.
post #1165 of 1680
Excellent! By the way, this is the workflow I intend to test:
Code:
dispcal -m -v3 -dmadvr -qu -w 0.312713,0.329016 -g709 -a64 -k0 -H -Ibw calibration
targen -v3 -d3 -G -e4 -B8 -s16 -g64 -V2 -N1 -c Rec709.icm -f1000 patches_pass1
dispread -v3 -dmadvr -K calibration.cal -H -Ibw patches_pass1
colprof -v3 -Zp -qu -ax -S Rec709.icm -O pass1.icm patches_pass1
targen -v3 -d3 -G -e8 -B16 -s32 -g128 -V2 -N1 -c pass1.icm -f3000 patches_pass2
dispread -v3 -dmadvr -K calibration.cal -H -Ibw patches_pass2
colprof -v3 -Zp -qu -ax -S Rec709.icm -O final.icm patches_pass2
collink -v3 -3m -qu -G -Ib:2.2 -ip -et -Et Rec709.icm final.icm 3DLUT.icm
Note that some of the parameters are carried over from past experiments (e.g. using perceptual intent for the 3DLUT), and I'll probably experiment with them a bit more once I have some measurements.
Edited by VerGreeneyes - 11/27/13 at 10:43pm
post #1166 of 1680
OK, here's an update to targen and colprof that I'm hoping addresses the problem of non-monotonicity in the profile near black causing raised black in the 3dLut.

It took two days of investigation and trials, and I found no single "smoking gun", just a collection of smaller things that add up to undesirable behavior.

targen has been altered to also scale the single channel, grey wedge, regular grid and body centered grid distribution acording to the -V flag as well as the full spread patches. This is to address the issue that including such fixed patten patches can tend to "push out" the full spread patches, while not actually populating the black end in enough detail to pin down the higher density grid values in the profile.

colprof has had a number of tweaks made to it:

It's recommended that the colprof -V parameter be used less aggressively, i.e. -V1.6 rather than -V2.0, and the default value carried over from targen will be automatically adjusted by colprof to make this the case.

The grid spacing adjustment made by the -V parameter has been changed to be a "power like curve" rather than a litteral power curve, to reduce the very high gradient this introduced near black. This was spacing the grids very closely, meaning that there were few measured data points landing in the cells, leaving their values at the mercy of the smoothness constraint, which is what was causing the overshoot.

The adjustment of the smoothness constraint to allow for variable grid spacing has been fine tuned to (hopefully) perform in a more nuanced manner, and reduce the degree of such overshoot.

You can try running the new colprof on an existing .ti3 file and it should work somewhat better, but for full effect the whole targen/dispread/colprof sequence would be desirable.

MSWin updates at http://www.argyllcms.com/vidtools_win32.zip and http://www.argyllcms.com/vidtools_win64.zip.
post #1167 of 1680
Quote:
Originally Posted by zoyd View Post

I also added the disable video LUT function but it has some strange behavior.

1. Load calibration file to video card via dispwin
2. madVR disable GPU gamma ramps is not checked, calibrate this display using external 3dLUTs is checked
3. Run pattern with madVR_SetDeviceGammaRamp(NULL) and madVR_Disable3dlut()
4. madVR properly removes gamma ramps and disables 3dlut but does not restore the gamma tables on disconnect. Does HCFR need to restore them?

madVR *should* automatically restore the gamma ramps to the original state. However, there are 2 things to note:

(1) madVR doesn't notice (or care) if you modify the gamma ramps while madTPG/madVR is already running. So make sure you set the gamma ramps to the desired value *before* you start madTPG/madVR. Otherwise madTPG will restore the gamma ramps that were installed before you started madTPG.

(2) There may be a delay of a couple of seconds before madTPG/madVR restores the original gamma ramps. This is done intentionally to avoid having the screen blink due to gamma ramps being changed back and forth multiple times.

Quote:
Originally Posted by zoyd View Post

1. Load calibration file to video card via dispwin
2. madVR disable GPU gamma ramps is not checked, calibrate this display using external 3dLUTs is checked
3. Run pattern with only madVR_Disable3dlut()
4. madVR properly leaves gamma ramps alone and disables 3dlut but only until disconnect, then linear ramps are loaded.
5. Reload calibration file.
6. Run pattern without disabled the 3dlut or the video lut.
7. This time the gamma ramps survive a disconnect and stick.

Same caveats as above. Did you perform step 1. before or after you started madTPG?
post #1168 of 1680
Quote:
Originally Posted by gwgill View Post

OK, here's an update to targen and colprof that I'm hoping addresses the problem of non-monotonicity in the profile near black causing raised black in the 3dLut.

It took two days of investigation and trials, and I found no single "smoking gun", just a collection of smaller things that add up to undesirable behavior.

Well, there was significant improvement and it's near-perfect in my setup.

Pre-cal/lut

Current calibration response:
Black level = 0.0290 cd/m^2
50% level = 33.52 cd/m^2
White level = 149.63 cd/m^2
Aprox. gamma = 2.16
Contrast ratio = 5157:1
White chromaticity coordinates 0.3132, 0.3213

Post cal
Code:
dispcal -v3 -d2 -y5 -m -qm   -G2.4 -f0 -w 0.31271,0.32902 cal2
Current calibration response:
Black level = 0.0304 cd/m^2
50% level = 30.30 cd/m^2
White level = 145.88 cd/m^2
Aprox. gamma = 2.27
Contrast ratio = 4803:1
White chromaticity coordinates 0.3121, 0.3291

Post cal+3dLUT
Code:
targen -v -V1.6 -N1.0 -G -e4 -B8 -s0 -g64 -m0 -b0 -f1500 -c Rec709.icm -d3 112813
dispread -v -d2 -y6 -K cal2.cal 112813
colprof -v -qh -bl -aX -V1.6 112813
collink -v -qh -3e -et -Et -G -ia -IB -a cal2.cal Rec709.icm 112813.icm 3DLUT_2.icm
Current calibration response:
Black level = 0.0407 cd/m^2
50% level = 30.02 cd/m^2
White level = 145.00 cd/m^2
Aprox. gamma = 2.27
Contrast ratio = 3559:1
White chromaticity coordinates 0.3128, 0.3307

So the entire chain generates a 0.012 cd/m^2 (0.003 ftL) mismatch between display black point and a black input level, I consider this an amazing achievement.
post #1169 of 1680
Quote:
Originally Posted by madshi View Post


Same caveats as above. Did you perform step 1. before or after you started madTPG?

Thank you madshi, I thought I had loaded them prior to start-up but it turns out I hadn't, now working as expected.
post #1170 of 1680
Sorry Zoyd, are there differences between the 1,2,3...IRE levels post cal and post LUT? I mean...0,01 cd/m2 of more luminance for black is not very relevant, but if the higher value were the floor on which the higher greys are calculated, the effect of that increase would be more visible just because greys just above would result to be much higher than 0,01. It's because of the way BT1886 calculates the whole tone curve (or am I wrong)?

Now since I see in your measures same 50% levels for post cal and post LUT, I'd answer no...no effect on higher greys. And that would be great! Is it clear my point? Can you confirm that it's only the black risen and not all the greys above?
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS