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

MadVR - ArgyllCMS - Page 37

post #1081 of 1689
Quote:
Originally Posted by zoyd View Post

That's strange, I've used both -ia and -iaw without problems. What are the rest of your command lines?
Code:
targen.exe -v -d3 -e4 -B12 -s0 -g128 -m0 -b0 -V1.5 -N1.0 -c rec709.icm -f1000 -W "baseline" > logs\Create.Pattern.Chart.log
dispread.exe -v2 -dmadvr -c1 -Yp -y7 "baseline" 
colprof -v -qh -bl -aX -V1.5 "baseline"
collink -v -qh -3m -et -Et -G -iaw -IB rec709.icm "baseline.icm" 3DLUT_1iaw.icm > logs\collinkiaw.log
collink -v -qh -3m -et -Et -G -ir -IB rec709.icm "baseline.icm" 3DLUT_1ir.icm > logs\collinkir.log
collink -v -qh -3m -et -Et -G -ia -IB rec709.icm "baseline.icm" 3DLUT_1ia.icm > logs\collinkia.log

I know it has worked very well for you, I've been using your commandlines from the last page where you did the test.

I'm guessing that only the "-g 128" parameter does anything for the greyscale. So it should help upping that one, right? I don't have the fastest meter, so I can't test every scenario.
post #1082 of 1689
Quote:
Originally Posted by monvo View Post


I know it has worked very well for you, I've been using your commandlines from the last page where you did the test.

I'm guessing that only the "-g 128" parameter does anything for the greyscale. So it should help upping that one, right? I don't have the fastest meter, so I can't test every scenario.

The -N1.0 helps the most compared to previous versions. No, those look fine, there is something else going on. Are you measuring gray scale through madVR or regular HCFR internal patterns and are you sure it's set to 0-255? Are you positive you don't have any calibration loaded to the video card? (dispwin -v -c -d) Is the same meter correction -y7 used in HCFR?
post #1083 of 1689
Quote:
Originally Posted by zoyd View Post

The -N1.0 helps the most compared to previous versions. No, those look fine, there is something else going on. Are you measuring gray scale through madVR or regular HCFR internal patterns and are you sure it's set to 0-255? Are you positive you don't have any calibration loaded to the video card? (dispwin -v -c -d) Is the same meter correction -y7 used in HCFR?
I'm measuring through madVR, otherwise the 3dlut wouldn't be applied. I'm absolutely 100% sure it's set to 0-255, I'm always also using the black test pattern to see if the black level is raised. If it was set incorrectly, all the bars would flash. The meter correction is the same. There is no calibration loaded into the card, and even if there was, madVR would disable it. Also a calibration loaded into the card wouldn't explain the bars above 235, as they don't appear if I disable the 3dlut or use the -ir lut..
post #1084 of 1689
Quote:
Originally Posted by madshi View Post

(2) 3dlut sometimes isn't turned off when it should be.

just for your info, my madTPG 3dLUT toggle sistematically fails to actually switch on/off the 3dlut. In order to make the toggle work, I have to push the toggle, close madTPG and reopen it, and only at that moment the 3dlut toggle both appears and is actually in the requested state.
post #1085 of 1689
Main info/notes:
Measurements and calibration were done in a dark environment, using fullscreen for patterns.
Colorimeter - i1Display Pro with the latest drivers and the latest i1Profiler 1.5.0 and display type correction files installed. Integration time - 0.2sec.
Software - Windows 7 SP1, HCFR 3.1.0.3, CalMAN v5, X-Rite CCFL correction file, ArgyllCMS 1.6.2 (32bit), dispcalGUI 1.5.7.6, madVR 0.8.6.11.
TV - Samsung LN40B550K CCFL S-PVA LCD 1080p HDTV from 2009 with specified CR of 3000:1, connected to PC via HDMI.
Refresh rate/resolution - set to 23/24Hz, which activated 48Hz mode, 1080p, overscan turned off.
Calibrated Rec.709 HDTV standard settings using service menu (without 3D LUTs) - Brightness @ 49, Contrast @ 77, Gamma @ -1.
PC - self-built, Intel i7 3770K (4.4Ghz), 8Gb RAM, 256Gb SSD, GeForce GTX 680 - HDMI to HDMI connection to TV.

Please see thorough description of the attached archived files below:

dispcalGUI main window:
Used the default madVR dispcalGUI profile settings with sRGB tone curve (which was also a default setting) in both cases.

dispcalGUI 3D LUT creation window:
1. Used sRGB for source profile. "Apply Calibration (vcgt)" was ticked. "Apply BT.1886 gamma mapping" was not ticked. "Absolute colorimetric and white point scaling" was chosen.
2. Used Rec709_Gamma22 for source profile. "Apply calibration (vcgt)" was ticked. "Apply BT.1886 gamma mapping" was not ticked. "Absolute colorimetric and white point scaling" was chosen.

New Calibration Results:
1. The resulting madVR 3D LUT had incorrect, but accurate BT.1886 curve. RGB WB, luminance, colorchecker/saturation sweeps were very accurate.Contrast ratio was dramatically reduced from ~1900/1800:1 to ~700/500:1. Black level point was dramatically increased. Odd artifacts were present in the darkest/black scenes, some blacks were crushed. - very unhappy with results mad.gif
2. The resulting madVR 3D LUT had correct and accurate 2.2 gamma curve. RGB WB, luminance, gamma, colorchecker/saturation sweeps were very accurate.Contrast ratio was dramatically reduced from ~1900/1800:1 to ~700/500:1. Black level point was dramatically increased. Odd artifacts were present in the darkest/black scenes, some blacks were crushed. - very unhappy with results mad.gif
***To get to my original/real black level point and contrast ratio - I had to reduce TV brightness by 12 clicks (from 49 to 37) and was unable to find a contrast and gamma setting to offset brightness decrease. In the end, I was unable to achieve accurate results - gamma and luminance were way off, odd artifacts in dark/black scenes were present, only RGB WB was semi-accurate. Reducing brightness to achieve the lowest black level point made many colorchecker/saturation sweeps highly inaccurate.

Old (Current/Best) Calibration Results:
BT.1886 profile - used default madVR dispcalGUI profile settings with Rec.1886 tone curve in main dispcalGUI window and used Rec709 for source profile in dispcalGUI 3D LUT creation window. "Apply calibrations (vcgt)" was ticked. "Apply BT.1886 gamma mapping" was ticked, 2.4 Absolute was chosen. Black level point was slightly raised. Contrast ratio was slightly reduced from ~1900/1800:1 to ~ 1700/1600:1. RGB WB, gamma, luminance, colorchecker/saturation sweeps were very accurate. No artifacts were noticed, no blacks were crushed - very happy with results biggrin.gif.
***To get to my original/real black level point and contrast ratio - TV brightness was reduced from original 49 to 47, contrast was raised from original 77 to 82 to offset brightness decrease. The results remained very accurate and contrast ratio increased to 1950:1!!!

HCFR Results (included in the attachment):
Original - original results without application of any profiles or LUTs, using native HCFR generator (madVR generator produced the same results).
BT1886 - using default madVR dispcalGUI profile settings with BT.1886 tone curve without lowering of TV brightness after 3D LUT creation.
BT1886_Correct (currently used to watch films) - using default madVR dispcalGUI profile settings with BT.1886 tone curve with lowering of TV brightness after 3D LUT creation to achieve the original black level point.
sRGB-Rec709g22 - using default madVR dispcalGUI profile settings with sRGB tone curve and Rec709_Gamma22 for source profile, without lowering TV brightness.
sRGB-sRGB - using default madVR dispcalGUI profile setting with sRGB tone curve and sRGB for source profile, without lowering TV brightness.

Almost all profile and 3D LUT-related files were included, except for the actual 3D LUTs and ICC/.icm profiles because AVS Forums wouldn't let me upload/post them, probably because they were too large in size (~100Mb each 3D LUT, ~1.6Mb each ICC profile):

dispcalGUI_Testing.zip 1070k .zip file

Unfortunately I did not keep my old bad sRGB/Gamma 2.2 profiles, but the new ones have identical problems.
I really hope this helps someone fix something. I think I am done calibrating and measuring for today...

P.S.
I have to turn off Windows Firewall service each time I want to calibrate using Argyll and dispcalGUI because Windows Firewall window pops up each and every time I try to calibrate. It asks me if I want to allow whichever .exe to use public/private connections. I always allow but it keeps on asking each time... very annoying!
Edited by MonarchX - 11/23/13 at 4:26pm
post #1086 of 1689
Quote:
Originally Posted by zoyd View Post

I see it, those are quantization artifacts similar to banding. There were some issues like that earlier but Graeme cleaned them up, maybe you have found an exception. I'n not sure if -N1.5 might be a problem, the documentation states valid settings of 0 - 1.0 so maybe it's ignored. I would also stick with V2.0 and not V3.0, I tried 3.0 and started getting a reduction in overall average dE because the gamut filling was getting too concentrated in the darker regions.

Thanks zoyd, I made some tests with the N1.0 and V2.0. Every time I changed only the rendering intents. Below the result, all LUT created without dispcal and using -Ib:2.2

i r no quantization but native white 8500K
i aa no quantization but native white 8500K
i aw quantization problem white ok 6500k
i a quantization problem white ok 6500k
i al no quantization white ok 6500K

so i al seems good, anyway it's still far from being accurate with regard to gamma. The most accurate results still come from the my old LUTs that use dispcal.

Maybe the problem could also be the fact that I'm trying to profile a display that, without calibration curves applied, is very far from the target
post #1087 of 1689
Quote:
Originally Posted by Kukulcan View Post


Maybe the problem could also be the fact that I'm trying to profile a display that, without calibration curves applied, is very far from the target

From your tests above that certainly seems to be the case when trying to map your native white point. Can you start with the display set at a warmer color temperature, either via display controls or calibrated video card?
post #1088 of 1689
Quote:
Originally Posted by zoyd View Post

Can you start with the display set at a warmer color temperature, either via display controls or calibrated video card?

I will try "normal" temperature, now it's set on cold1. These results are from a 7 years old Samsung 26 inch LCD TV (used as a pc display). I chose cold1 some time ago because it seemed to be the "nativest" condition of the panel, so the idea was to use that in order to reduce to minimun the intervention of TV electronics, and it did pay out in terms of DeltaE.

Consider that I don't care much of the PQ on this panel, I have a Planar vpr, but for running all these tests...you know...a vpr requires darkening, it consumes the lamp.... But maybe using this bad TV panel for testing it's not wise, it behaves too bad at very low level.
It's time to test this workflow on the Planar, I'll let you know in the following days.
post #1089 of 1689
Quote:
Originally Posted by Kukulcan View Post

I will try "normal" temperature, now it's set on cold1. These results are from a 7 years old Samsung 26 inch LCD TV (used as a pc display). I chose cold1 some time ago because it seemed to be the "nativest" condition of the panel, so the idea was to use that in order to reduce to minimun the intervention of TV electronics, and it did pay out in terms of DeltaE.

Consider that I don't care much of the PQ on this panel, I have a Planar vpr, but for running all these tests...you know...a vpr requires darkening, it consumes the lamp.... But maybe using this bad TV panel for testing it's not wise, it behaves too bad at very low level.
It's time to test this workflow on the Planar, I'll let you know in the following days.

yes, at this level you need good quality source and a good quality display to make relevant judgements on performance.
post #1090 of 1689
Quote:
Originally Posted by zoyd View Post

Incorporating dispcal into the process did raise black level in the attached calibration from 0.05 cd/m^2 to 0.08 cd/m^2
I have created a modified version of dispcal that works a bit harder to keep the black point from rising due to measurement inaccuracy and/or the convergence rate of the itterations here: http://www.argyllcms.com/dispcal_win32.zip and here for Win64: http://www.argyllcms.com/dispcal_win64.zip. When you get a chance, perhaps you could see if this is an improvement.
Quote:
One other test I performed was to load the calibration to the video card and the measured black point was just fine but the peak was at the reduced 141 cd/m^2. Perhaps that is required to get the white point in-gamut. When I check the ti3 output of dispread the whitepoint is 145.482208. I don't understand that since I expect dispread -K to yield the same result as if I had actually loaded the calibration.
Yes, keeping it in gamut is one reason for the white level to drop. I have had several similar reports of brightness changes due to dispcal, but I've never been able to track them down. Attempts to reproduce on my CRT have been confounded by brightness inconsistency in the display itself.
post #1091 of 1689
Quote:
Originally Posted by fhoech View Post

Notable changes from the last snapshot:
  • Added dark region emphasis controls to testchart editor (Argyll CMS 1.6.2).
  • Added black patches amount control to testchart editor (Argyll CMS 1.6). Previously this was hard-wired to 4 (which is still the default).
Note that I'd recommend setting some dark region emphasis rather than increasing the number of black patches, as it is a more comprehensive way of improving black point accuracy.
post #1092 of 1689
Quote:
Originally Posted by gwgill View Post

Attempts to reproduce on my CRT have been confounded by brightness inconsistency in the display itself.

I'm curious, what CRT (or CRTs) do you work with?
post #1093 of 1689
Quote:
Originally Posted by Kukulcan View Post

Anyway I post here 2 screenshots which are better than any word...

3dLUT created using dispcal , no issue





3dLUT created without dispcal please enlarge the picture and look at the corners areas



Why dark areas are so strange and faulty? Don't you get anything like that?
There could be many reasons, but the primary reason I recommend calibration and profiling is that calibration has much finer control over the transfer curve and neutral axis than profiling. Calibration only has to worry about the neutral axis, so a few hundred test points can quite comprehensively explore the device behaviour. Even 10000 points for profiling fills the 3D space fairly sparsely, and similar resolution arguments apply to the resulting 1D and 3D tables.

If your display is quite well behaved by default, then calibration may not make any difference. If it is more poorly behaved, then it can correct things which profiling will struggle with.
post #1094 of 1689
Quote:
Originally Posted by MonarchX View Post

P.S.
I have to turn off Windows Firewall service each time I want to calibrate using Argyll and dispcalGUI because Windows Firewall window pops up each and every time I try to calibrate. It asks me if I want to allow whichever .exe to use public/private connections. I always allow but it keeps on asking each time... very annoying!
ArgyllCMS doesn't do anything related to the network unless you are using "-dweb" as a display device.

Note that MadTPG does attempt to connect over the network, so perhaps this is what's triggering your firewall warning.
post #1095 of 1689
Quote:
Originally Posted by spacediver View Post

Quote:
Originally Posted by gwgill View Post

Attempts to reproduce on my CRT have been confounded by brightness inconsistency in the display itself.

I'm curious, what CRT (or CRTs) do you work with?
My workstation display a Hitachi CM2112ME T.
post #1096 of 1689
So, I spent hours making that huge reply/post about tone curves other BT.1886 heavily reducing contrast ratio and drastically raising black level point because I was asked to provide files and details...

Could someone explain why BT.1886 tone curve results are good and sRGB/Gamma 2.2 results are crap? Do attached files show why this happens??? I get a feeling my effort will be ignored... not that its anywhere as important and worthy as Argyll/dispcalGUI development....

When people refer to dispcal, are they referring to dispcal.exe or dispcalGUI?
post #1097 of 1689
Quote:
Originally Posted by gwgill View Post

My workstation display a Hitachi CM2112ME T.


thanks, hard to find info about it, except that it's 20 inches. Nice to see someone else still using them though smile.gif
post #1098 of 1689
Quote:
Originally Posted by gwgill View Post

I have created a modified version of dispcal that works a bit harder to keep the black point from rising due to measurement inaccuracy and/or the convergence rate of the itterations here: http://www.argyllcms.com/dispcal_win32.zip and here for Win64: http://www.argyllcms.com/dispcal_win64.zip. When you get a chance, perhaps you could see if this is an improvement.

There was an improvement but still a small rise, interestingly it's worse via madVR than the eeColorbox. I repeated all the black measurements several times to make sure they were stable. I did notice it spent quite a bit longer during the dark patch measurements. The calibration file was included in both LUTs via -a

1. Original black = 0.048 cd/m^2
2. Load calibration into video card and remeasure shows no change, 0.048 cd/m^2
3. eeColorbox LUT measured 0.062 cd/m^2 and was the same for both the -B and -b:2.4 mappings.
4. madVR LUT measured 0.069 cd/m^2.
5. remeasured without LUT = 0.048 cd/m^2
Edited by zoyd - 11/24/13 at 8:03pm
post #1099 of 1689
Quote:
Originally Posted by MonarchX View Post

When people refer to dispcal, are they referring to dispcal.exe or dispcalGUI?
dispcal.exe. I guess that is a bit confusing, since dispcalGUI might be more appropriately called ArgyllGUI smile.gif (it uses dispcal.exe during calibration and colprof.exe during profiling, and some other tools from ArgyllCMS as well)
Quote:
Originally Posted by zoyd View Post

1. Original black = 0.048 cd/m^2
2. Load calibration into video card and remeasure shows no change, 0.048 cd/m^2
So you're saying the dispcal.exe generated calibration doesn't raise the black point by itself, but it does raise it for the profile / 3DLUT if you use it during the colprof.exe step? In that case I wouldn't expect a fix in dispcal.exe to help (though perhaps it will help calibrate my monitor, for which I've had to supply very specialized settings in the past in order to avoid raising the black level in the dispcal generated curves).
Edited by VerGreeneyes - 11/25/13 at 12:25am
post #1100 of 1689
Quote:
Originally Posted by zoyd View Post

There was an improvement but still a small rise, interestingly it's worse via madVR than the eeColorbox. I repeated all the black measurements several times to make sure they were stable. I did notice it spent quite a bit longer during the dark patch measurements. The calibration file was included in both LUTs via -a

1. Original black = 0.048 cd/m^2
2. Load calibration into video card and remeasure shows no change, 0.048 cd/m^2
So that bit looks good.
Quote:
3. eeColorbox LUT measured 0.062 cd/m^2 and was the same for both the -B and -b:2.4 mappings.
4. madVR LUT measured 0.069 cd/m^2.
5. remeasured without LUT = 0.048 cd/m^2
My best guess is that this is due to the mismatch between the 65 res grid vs. TV encoding (ie. 16/255 != 4/64). One way of confirming this is to generate a full 256 res 3dLUT for MadVR - ie. use "collink -r 256...".

Assuming this is the explanation, I've added a special case correction for the black point when TV encoding is used for input and output and the grid resolution is 65 (ie. the MadVR and eeColor case) that attempts to correct for this interpolation error at the black point.
The Win executables are here http://www.argyllcms.com/vidtools_win32.zip and here http://www.argyllcms.com/vidtools_win64.zip.

[ I haven't attempted to add same correction for other video encoding types at this stage though. ]
post #1101 of 1689
Quote:
Originally Posted by gwgill View Post


I've added a special case correction for the black point when TV encoding is used for input and output and the grid resolution is 65 (ie. the MadVR and eeColor case) that attempts to correct for this interpolation error at the black point.
The Win executables are here http://www.argyllcms.com/vidtools_win32.zip and here http://www.argyllcms.com/vidtools_win64.zip.

I tried the new collink above, but it made no difference. Please note that I tried only the new collink, no new dispcal, I used the previous measuremets. The options below:
(new)collink -v -3m -qh -et -Et -G -IB -iaw -a last.cal rec709.icm last.icm lastlut.icm

Black measured (repeated and stable):

display default 0.103 cd/m2
only .cal loaded (old dispcal!) 0.105 cd/m2
3DLUT 0.117 cd/m2
same black measurements for new and old collink

Anyway Zoyd report looks very encouraging. Here it looks the first time that dispcal haven't risen black level. Maybe the new executables must be tried in conjunction in order to make also collink work good, I don't know....
Edited by Kukulcan - 11/25/13 at 2:59am
post #1102 of 1689
Quote:
Originally Posted by gwgill View Post


My best guess is that this is due to the mismatch between the 65 res grid vs. TV encoding (ie. 16/255 != 4/64). One way of confirming this is to generate a full 256 res 3dLUT for MadVR - ie. use "collink -r 256...".

Assuming this is the explanation, I've added a special case correction for the black point when TV encoding is used for input and output and the grid resolution is 65 (ie. the MadVR and eeColor case) that attempts to correct for this interpolation error at the black point.
The Win executables are here http://www.argyllcms.com/vidtools_win32.zip and here http://www.argyllcms.com/vidtools_win64.zip.

[ I haven't attempted to add same correction for other video encoding types at this stage though. ]

I didn't test the new dispcal but using the old dispcal results with new collink went in the wrong direction, although both eeColor and madVR now report the same thing:

no lut black level => 0.48 cd/m^2
madVR => 0.082 cd/m^2
eeColor => 0.082 cd/m^2

I can retest with new dispcal in the flow if you think that will matter.
Edited by zoyd - 11/25/13 at 3:53pm
post #1103 of 1689
I wanted to confirm that the error is not in dispcal.exe.

When I used dispcalGUI madVR BT.1886 target profile with Rec709 source profile and with application of BT.1886 gamma curve during 3D LUT creation, the end result raised my black level point only slightly.

When I used dispcalGUI madVR BT.1886 target profile with Rec709/Rec709_Gamma22 source profile and without application of BT.1886 gamma curve during 3D LUT creation, the end result raised my black point significantly.

So, the issue is not with dispcal.exe. Calibration is fine, but profiling is where the issue resides. For some reason, no matter what settings you choose for calibration, profiling with anything other than Rec709 + BT.1886 results in significantly raised black level points.

I don't understand why you think that it has something to do with 16/255 TV encoding. madVR plays 16-235 encoded content 100% accurately when 0-255 is selected in madVR settings and TV + videocard are forced to 0-255. It will display black level 16 to be black level 1 in 0-255 environment.

Is it not weird that simple application of BT.1886 gamma curve during 3D LUT creation resolves black level point issue? Maybe not completely, but results are acceptable.
post #1104 of 1689
Quote:
Originally Posted by zoyd View Post

I didn't test the new dispcal but using the old dispcal results with new collink went in the wrong direction, although both eeColor and madVR now report the same thing:

no lut black level => 0.48 cd/m^2
I presume you mean 0.048 cd/m^2
Quote:
madVR => 0.082 cd/m^2
eeColor => 0.082 cd/m^2
That a disappointment, but perhaps the fact that it changed indicates that I'm looking in the right area.

The version you tried was a bit of a hack - I've updated the two executable with a more comprehensive implementation, so I'd be interested if they work properly.
post #1105 of 1689
Quote:
Originally Posted by MonarchX View Post

I wanted to confirm that the error is not in dispcal.exe.

When I used dispcalGUI madVR BT.1886 target profile with Rec709 source profile and with application of BT.1886 gamma curve during 3D LUT creation, the end result raised my black level point only slightly.
Sorry, I'm not sure what you mean by "madVR BT.1886 target profile". You mean your TV profile ?
Quote:
When I used dispcalGUI madVR BT.1886 target profile with Rec709/Rec709_Gamma22 source profile and without application of BT.1886 gamma curve during 3D LUT creation, the end result raised my black point significantly.
I'm not sure exactly what is happening in the case you mention since I don't know the exact options you used, but it could be that if you are not using an intent that explicitly maps the black point that the gamut clipping is raising the black. Typically this is because clipping aims to minimize the delta E between the source points and the equivalent in-gamut destination points, and minimum delta E may well be a lighter color with less hue/saturation error. Do you see the same behavior if you use "-ila" ?
Quote:
I don't understand why you think that it has something to do with 16/255 TV encoding. madVR plays 16-235 encoded content 100% accurately when 0-255 is selected in madVR settings and TV + videocard are forced to 0-255. It will display black level 16 to be black level 1 in 0-255 environment.
You have to understand how a 3dLut works. It's an interpolation grid and output values are only exactly defined at the grid point, everything else is interpolated. Having the input space TV encoded (16..235/255) shifts the incoming black from a grid point (0,0,0) somewhere into the 3dLut. If the grid spacing was such that the black lands on a grid point, all would be well, but this can't be the case due to the TV encoding range and the finite grid resolution. The closest we can get with just a 3dLut is a grid res. of 65 (which is what the eeColor hardware supports). 16/255 = 0.062745098 while the nearest grid point is 4/64 = 0.0625. That means that if the cell the black point lands in is not a 1:1 mapping, then the black will be shifted by the interpolation process, with it's value depending on the other grid values that make up the cell it is in. For instance, if the next corner at 5/64 maps 0.078125 to a value of 0.15, then the black input of 0.062745098 will get interpolated to 0.063872548, so the black is raised. If the 3dLut was a bit more sophisticated (ie., like an ICC device link), then there are other ways of addressing this issue, by making use of the per channel input curves to remap the black value to land exactly on a grid point. Instead I'm trying to tweak the black point interpolation cell values to correct the error at black, at the expense of increased error in any values adjacent to the cell.
post #1106 of 1689
Quote:
Originally Posted by gwgill View Post

I presume you mean 0.048 cd/m^2
That a disappointment, but perhaps the fact that it changed indicates that I'm looking in the right area.

The version you tried was a bit of a hack - I've updated the two executable with a more comprehensive implementation, so I'd be interested if they work properly.

yes, sorry, 0.048. I'll test the new stuff shortly. Is is necessary to rerun dispcal or can I use the calibrations I've already got?
post #1107 of 1689
Quote:
Originally Posted by zoyd View Post

Is is necessary to rerun dispcal or can I use the calibrations I've already got?
You can use the calibration you made with the V1.6.3_beta dispcal I first made available (it hasn't changed with the collink updates).
post #1108 of 1689
Quote:
Originally Posted by gwgill View Post

You can use the calibration you made with the V1.6.3_beta dispcal I first made available (it hasn't changed with the collink updates).

ok, I'm getting pretty much the same answer as yesterday using collink V1.6.3_beta (timestamp is 11-26 12:07 pm)

Both madVR and eeColor black level = 0.089 cd/m^2 (from 0.048 cd/m^2), I tested both -IB and -Ib:2.4 with the same results.


Other notes:

In order to get a stable black using dispcal only for calibration I need to use -g2.2. Using -G2.4 -f0 raises black slightly to 0.059 cd/m^2. Adding -k0 to either makes no difference.

edit:
If I use -H instead of -a in collink for madVR black level is reduced to 0.058 cd/m^2
Edited by zoyd - 11/25/13 at 7:20pm
post #1109 of 1689
Quote:
Originally Posted by zoyd View Post

ok, I'm getting pretty much the same answer as yesterday using collink V1.6.3_beta (timestamp is 11-26 12:07 pm)

Both madVR and eeColor black level = 0.089 cd/m^2 (from 0.048 cd/m^2), I tested both -IB and -Ib:2.4 with the same results.
Sorry, no idea then. It all seems to work perfectly for my system. I'd need to have your .ti3, TV profile & .cal file to investigate any further.
Quote:
In order to get a stable black using dispcal only for calibration I need to use -g2.2. Using -G2.4 -f0 raises black slightly to 0.059 cd/m^2. Adding -k0 to either makes no difference.
I'd need a disprof -v3 trace to be able to figure anything out.
Quote:
If I use -H instead of -a in collink for madVR black level is reduced to 0.058 cd/m^2
Sounds strange. The behavior should be indistinguishable.
post #1110 of 1689
Quote:
Originally Posted by gwgill View Post

Sorry, no idea then. It all seems to work perfectly for my system. I'd need to have your .ti3, TV profile & .cal file to investigate any further.

ok, thanks for taking a look, it'd be nice to have the calibration baked in as it does improve the gray scale. The other two items I don't really care about. The other thing I can test tomorrow is a 0-255 flow because the eeColor box will handle that, and that should tell us if this is related to TV encoding levels.
Code:
targen -v -d3 -e4 -B8 -b0 -s0 -g64 -m0 -V2.0 -N1.0 -c rec709.icm -f1000 -W final
dispcal -v -d2 -m -y5 -ql -w 0.31271,0.32902 -g2.2 -k0 -E final_calkog22
dispread -v -d2 -y6 -E -K final_calkog22.cal final
colprof -v -qh -bl -aX -V2.0 final
collink -v -qh -3e -et -Et -G -ia -IB -a final_calkog22.cal rec709.icm final.icm 3DLUT_3.icm

blacktests.zip 1685k .zip file
Edited by zoyd - 11/25/13 at 8:01pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS