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

MadVR - ArgyllCMS - Page 36

post #1051 of 1680
Thread Starter 
Quote:
Originally Posted by MonarchX View Post

So, its not possible to achieve BT.1886 gamma for desktop use with already-existing color space then? My TV is already quite accurate, but it has regular gamma of 2.2. All I want is BT.1886 gamma curve without any other change other than improved RGB WB, but its not necessary. Pure BT.1886 tone curve profile would be good enough.

Then just run a dispcal calibration using BT.1886. After the calibration, you will end up with a .cal file. Then upload the .cal file to your video card's videoLUT.

dispcal.exe -v -d1 -m -Yp -qu -w0.3127,0.329 -G2.4 -f0 -k0 -A4.0 "filename_for_cal"

dispwin.exe filename_for_cal.cal
post #1052 of 1680
Quote:
Originally Posted by VerGreeneyes View Post

I don't know what this does to 'accuracy' since I'm not really sure how to measure that for a 3DLUT, but what do you get if you use both -Ib:2.2 and rec709_gamma22? This has given me perceptually pleasing results, at least.

I don't know how that would measure, never tried it. I think in general -Ib:2.2 is too light in a dim environment , try -IB or -Ib:2.35
post #1053 of 1680
Quote:
Originally Posted by zoyd View Post

I don't know how that would measure, never tried it. I think in general -Ib:2.2 is too light in a dim environment , try -IB or -Ib:2.35
That wasn't really my point, though. I was wondering if you still get black crush with that configuration.
post #1054 of 1680
Quote:
Originally Posted by VerGreeneyes View Post

That wasn't really my point, though. I was wondering if you still get black crush with that configuration.

umm...yeah, you lose everything under 7% input level on my display (mll = 0.05 cd/m^2) and the transfer function is far too high across the board and especially under 30% (average = 2.6)

-Ib:2.2 rec709_gamma22.icm linking option

post #1055 of 1680
Interesting, thank you for testing.
post #1056 of 1680
Quote:
Originally Posted by gwgill View Post


It could come from either process, so it's important to distinguish the source.

I think some of this is my fault - when calibrating for video purposes I failed to note that "dispcal -k0" should probably be used - without the "-k0" dispcal may try and hue correct the black point for displays with very low black levels (ie. CRT's & Plasmas), thereby raising it. This is generally a good thing for desktop use, not so much for video.

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
Code:
targen -v -d3 -e4 -B12 -s0 -g128 -m0 -b0 -V3.0 -N1.0 -c rec709.icm -f2500 -W baselineV4
dispcal -v -d2 -m -y6 -qm -w 0.31271,0.32902 -G2.4 -f0 -k0 -E baselinev4_cal
dispread -v -d2 -y6 -E -K baselinv4_cal.cal baselineV4
colprof -v -qh -bl -aX -V3.0 baselineV4
collink -v -qh -3e -et -Et -G -ia -IB -a baselinev4_cal.cal rec709.icm baselineV4.icm 3DLUT_2.icm

cal.zip 1790k .zip file

edit:

I went through the same sequence but this time just used -g2.2 in the dispcal step to see if doing bt.1886 mapping at that step was the source of the problem and it wasn't. I get the same black point rise and also notice that peak white is reduced(from the dispcal achieved target of 145 cd/m^2 to a final value of 141 cd/m^2. I think there is a bit of a level mismatch or compression/expansion occurring somewhere, either when applying the .cal file to dispread measurements (dispread -K) or when applying the .cal file to the 3dLUT output (collink -a) in combination with -et -Et. In order to realign my display so that input level 16 is truly black and input level 235 is my original white point level, I have to "stretch" the display mapping by lowering brightness 3 clicks and raising contrast 3 clicks. The behavior is very similar to what happens when you mismatch limited vs. full in the source/display chain but at a much lower level, on the order of a couple of digital levels.

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.
Edited by zoyd - 11/22/13 at 9:41am
post #1057 of 1680
Quote:
Originally Posted by zoyd View Post

................dispcal was not used in this process as I wanted to see how well the lut itself would correct residual gray scale errors.


In the past the above link parameters would cause a slight rise in black level that required a 1 or 2 click adjustment at the display, there was no such rise for any of the 3dLUTs tested this time. Gray scale errors for LUT 1 were cut in half from an average dE2000 of 1.7 to 0.85 The BT.1886 curve was reproduced very well.


I confirm, no black rise if you don't use dispcal. This is the workflow I tested:

targen -v -d3 -e4 -B12 -s0 -g128 -m0 -b0 -V3.0 -N1.0 -c rec709.icm -f2500 –W nodispcal
dispwin –v –c
dispread –v –dmadvr –yl –Xccflfamily_07feb11.ccss nodispcal
colprof -v -qh -bl –aX nodispcal
collink –v -3m –qh –et –Et –G –iaw Rec709.icm nodispcal.icm nodispcalLUT.icm

But......now I have a problem similar to dithering artifacts at ultra low levels. I see very small "noise artifacts" in very dark areas (sorry I don't know how to explain). The result gives the impression that there's something faulty...
Edited by Kukulcan - 11/22/13 at 12:59pm
post #1058 of 1680
Quote:
Originally Posted by N3W813 View Post

Then just run a dispcal calibration using BT.1886. After the calibration, you will end up with a .cal file. Then upload the .cal file to your video card's videoLUT.

dispcal.exe -v -d1 -m -Yp -qu -w0.3127,0.329 -G2.4 -f0 -k0 -A4.0 "filename_for_cal"

dispwin.exe filename_for_cal.cal

Thanks! I got it!
Edited by MonarchX - 11/22/13 at 1:27pm
post #1059 of 1680
Oh, so many posts since I was last here smile.gif

I've skimmed over the recent ones and try to answer questions re dispcalGUI.
Quote:
Originally Posted by MonarchX 
You said "It's unlikely that Florian has got around to adding it, and some feedback on whether it is worthwhile as a default would (I'm sure) help in guiding him on how to deal with it" earlier. So, if the new parameter is not added to discpcalGUI for utilization during calibration and profiling, how in the world can I test it through dispcalGUI?
You can always create the testchart outside of dispcalGUI (using targen) like Graeme suggested and then simply select it in the GUI. You don't have to anymore though, I've updated the snapshot.

http://dispcalgui.hoech.net/download/snapshot/dispcalGUI-win32.zip

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).
  • Fixed 3D LUT target profile overwritten by device link preventing changing the source profile.

Note that I have not updated the testcharts with the new options, so you have to create your own if you want to test the effect of adding more black patches/increasing dark region emphasis.

Quote:
Originally Posted by MonarchX 
The only issue left is of course figuring out why pure power gamma 2.2/sRGB Tone curve ends up significantly cutting CR and significantly elevating black point level. I thought that Rec.1886 Tone curve would be much more difficult to calculate than Gamma 2.2/sRGB.
I'd like to know why too smile.gif. I really wouldn't know why this even makes a difference. Contrast ratio should be purely dependant on black/white level, not anything that happens "in between".

Quote:
for the target-generation I use the following line: -v -d3 -e4 -s41 -g121 -m11 -b11 -f0 -p1.0
Regular grids are not something I'd recommend. Not only are they inefficient at sampling the device space, they also risk "resonance" type effects in the model fitting. That's why the tutorial recommends using OFPS (-f) patches for the bulk of the sampling.
Agreed. In this case though, setting -m is actually redundant, if -m and -b are set to the same value the distribution you end up with it will be the body centered cubic grid (the reason I even set -m in dispcalGUI if -b is set is purely for backwards compatibility, it should do no harm though).

Quote:
Originally Posted by gwgill 
I've little idea what Rec.709_Gamma22.icc is - I didn't create it. My recommendation is to use the Rec709.icc supplied with ArgyllCMS.
It's Rec709.icm (same primaries/whitepoint) with a pure power 2.2 gamma (the reason it even exists is because of a suggestion from a user a while back, who said that movie editing/coloring generally takes place in a 2.2 gamma space, and thus there was a need of a source profile with that characteristic. This predates the more sophisticated BT. 1886 mapping option that you later introduced in Argyll CMS).

Quote:
Originally Posted by MonarchX 
Windows cannot read 3DLUTs, but it can read .icm/.icc profiles, which sadly do not contain color gamut data.
Just wanted to add that of course profiles do contain "color gamut data", that is the whole point of them smile.gif Unless you meant that a single device profile (in contrast to device link profiles) do not contain a transform from a preset source space to the space the profile describes (although LUT device profiles can have gamut mapping optimized for a certain source space).

Quote:
Originally Posted by MonarchX 
But do .icc/.icm profiles contain gamma data?
Like Graeme, I'm not sure what you mean. Profiles do by nature model the transfer characteristic of the device they were created for (within limits of the used profile type and measurements), though, which you could call "gamma data" but that's not an accurate/correct description.

Quote:
Originally Posted by MSL_DK 
@fhoech

Can you tell about BPC? I can not find anything about it in Argyll dokumantionen. The reason I ask is that I can not achieve a satisfying result without BPC (raised black levels). Can you tell about the advantages, disadvantages, workflow through Argyll? Thank you.
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. This effect is greater the lighter the actual measured device black was. The main reason I implemented this option was because that's how most commercial display profiling software seems to operate, and for "dumb" matching scenarios it eliminates black crush (at the expense of accuracy like I mentioned). Because I wanted to prevent the actual measured display response being totally lost, the measurement data (TI3) that is embedded in the profile is always the unaltered one, so one can create a profile without BPC from the BPC-enabled one (the way this works in dispcalGUI is by setting the desired profiling options, then selecting "Create profile from measurement data..." in the options menu and finally selecting the existing profile).

Quote:
Originally Posted by madshi 
FWIW, I'll be looking into problems with madTPG in the next couple of days. Currently on my list: (1) Sometimes madTPG doesn't switch to the requested test pattern color (or maybe not fast enough?). (2) 3dlut sometimes isn't turned off when it should be. (3) Dithering pattern seems to be too large (magnified?) somehow. (4) If madTPG can't be found, there can be a crash sometimes. Any other problems I should be looking at?
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).

Quote:
Originally Posted by MonarchX 
The result produced BT.1886 gamma, but blue saturation sweeps were way off.
[...]
So, its not possible to achieve BT.1886 gamma for desktop use with already-existing color space then? My TV is already quite accurate, but it has regular gamma of 2.2. All I want is BT.1886 gamma curve without any other change other than improved RGB WB, but its not necessary. Pure BT.1886 tone curve profile would be good enough.
I can only assume, but to me it looks like the reason why you get those errors in the first place is because the software you use to validate the results (HCFR?) probably makes a different assumption about the transfer characteristic than what the display profile actually recorded. So if the software assumes 2.2 display gamma and the profile recorded something different, it will probably not pass validation for anything else than pure R, G, B and white. What I would be really interested in since you say you get low color errors without any calibration/profile (unless I misunderstood you), is how you go without doing calibration and just creating a profile (thus recording "native" device response).
post #1060 of 1680
Quote:
Originally Posted by MonarchX 
The only issue left is of course figuring out why pure power gamma 2.2/sRGB Tone curve ends up significantly cutting CR and significantly elevating black point level. I thought that Rec.1886 Tone curve would be much more difficult to calculate than Gamma 2.2/sRGB.
Btw, I'd really be interested in taking a look at those different profiles and calibrations. Could you share them?
Quote:
Originally Posted by bmw525i 
I have tested setting "BLACK_POINT_CORRECTION" and the RGB-values for 0.0 input in my .cal file to "0.0" (although I don't really know what that BPC stands for, but there was a "black" in it so I set it to 0 rolleyes.gif )

-> the result is, that I get perfect blacks after profiling and 3D LUT creation and the gamma-curve fits to the BT1886 standard when verifying the results in HCFR. What I don't know is if I lost some shades of grey/dark colors or whatever else could possibly happen. I don't know how to test for that either...
Hmm. Setting measured values to 0, that's basically cheating (like I mentioned above for black point compensation...) smile.gif But if the values were already close to zero, it probably does not have a noticeable negative effect, altough it will mean the black point will not be hue corrected if black point correction was used (altough I think if a profile created on top of that altered calibration is used in a transform it may still alter black point hue somewhat depending on source profile).
post #1061 of 1680
Boy, I wish I could understand exactly what is going on here.

I was actually using updated CalMAN v5 to test the results of .icc profiles. I found out that when I test a BT.1886 profile using power 2.2 for gamma in CalMAN v5, saturation sweep results stay identical to my own calibration (when no profile is used), but as soon as I set BT.1886 for gamma in CalMAN v5, some saturation reading results are a bit off, but blue is way off, going from dE<3 to dE of 4.5. That happens with and without a profile. So, apparently, CalMAN v5 or the BT.1886 standard requires different color space for blue to be accurate. The rest of the colors also change their dEs with BT.1886, but only slightly, not like blue. I figured since BT.1886 gamma is so low 0-10% IRE, which is also the darkest IRE and black is located in the blue part of the CIE chart, then that's why CalMAN wants a different colorspace.

Device link profile vs. single device profile - I did not know there was a difference. Is this related to DDC/ADC? My Samsung HDTV over HDMI is not recognized/supported in CalMAN v5 for DDC... but in service menu it does have ADC stuff... Maybe since I use it as a monitor, I should use DVI cable. My other monitor uses DVI cable and is detected for DDC. But if I use DVI and PC Mode for this TV, I will lose ALL colorspace adjustments I made and get much lower CR. PC Mode ignores TV colorspace with this set. If it is not DDC related, then how do I make a device link?

I think this whole time I was applying single device profile, which like you said, does not have the ability to transform current colorspace into profile colorspace. I do have a videocard LUT, to which information can be uploaded for use in most applications, except for games (almost all games reset 1D LUT no matter what you do).

So, you're saying that there is a way for me to create a single device profile, which will not transform current colorspace into profile colorspace, and yet there is a way to do it somehow? Through my videocard LUT?

I also have this monitor, which does support ADC and is recognized in CalMAN v5. It has those internal ADS controls and one of them is 100% empty and it says 3DLUT. Does that mean I can upload a 3D LUT into my monitor? Is that a device LINK?
Edited by MonarchX - 11/22/13 at 1:54pm
post #1062 of 1680
Quote:
Originally Posted by MonarchX View Post

Device link profile vs. single device profile - I did not know there was a difference. Is this related to DDC/ADC?
No, that is totally unrelated.
Quote:
Originally Posted by MonarchX View Post

I think this whole time I was applying single device profile
Probably. In a dispcalGUI workflow, if you did not create a 3D LUT, then you have a (display) device profile. If you did create a 3D LUT, you have an additional device link profile (the device link and 3D LUT basically do the same thing).
Quote:
Originally Posted by MonarchX View Post

which like you said, does not have the ability to transform current colorspace into profile colorspace.
I think there may be a misunderstanding. Both device profiles and device link profiles can be used in a color transform. The difference is, if using device profiles, you need to use two profiles: Source and target. So, e.g. if you wanted to simulate Rec 709, you would use a Rec 709 (device) profile as source and a display device profile as target.
A device link profile (this also applies to 3D LUTs) is basically such a transform baked into a single file.
Quote:
Originally Posted by MonarchX View Post

I do have a videocard LUT, to which information can be uploaded for use in most applications, except for games (,pst reset 1D LUT no matter what you do).
Yes, and this videoLUT is one-dimensional, so can only correct whitepoint/blackpoint/grayscale/transfer curve (gamma), but not the gamut.
Quote:
Originally Posted by MonarchX View Post

So, you're saying that there is a way for me to create a single device profile, which will not transform current colorspace into profile colorspace, and yet there is a way to do it somehow? Through my videocard LUT?
No, I meant you can create a device profile (also a device link profile) without doing calibration. (e.g. reset the videoLUT to linear and then just measure the display as-is. In dispcalGUI this is done using the "just profile" button and then enabling "use linear calibration" when asked).
Quote:
Originally Posted by MonarchX View Post

I also have this monitor, which does support ADC and is recognized in CalMAN v5. It has those internal ADS controls and one of them is 100% empty and it says 3DLUT. Does that mean I can upload a 3D LUT into my monitor? Is that a device LINK?
There are some displays that support internal 3D LUTs, but it is not possible to utilize this functionality using Argyll CMS/dispcalGUI (unless you have a software that can somehow convert a device link and upload it into the monitor hardware, but I have no clue if such a tool exists or if CalMAN can do that).
post #1063 of 1680
Quote:
Originally Posted by Kukulcan View Post


But......now I have a problem similar to dithering artifacts at ultra low levels. I see very small "noise artifacts" in very dark areas (sorry I don't know how to explain). The result gives the impression that there's something faulty...

I've looked at very dark scenes from Blade Runner with and without my most recent 3dLUT active in madVR and see no signs of any blocking or artifacts. I can also compare it by running madVR(no 3dLUT) through the eeColor box with the same 3dLUT active and the images are identical. So what you are seeing is due to:

1. The source itself
2. A different playback setting/processing within madVR
3. madTPG

btw, your collink options are not optimal for video use (collink –v -3m –qh –et –Et –G –iaw Rec709.icm nodispcal.icm nodispcalLUT.icm)
you need to include -IB or -Ib2.x (or one of the -ila CIECAM02 appearance models) to get a proper end-to-end transfer function. What you have there will have an effective gamma of just under 2 which should looked washed out in most circumstances. This could also accentuate low level artifacts in the source so re-link the profiles using -IB and see how that performs.


edit:

I ran the same process steps through madTPG and it looks fine, no blocking artifacts, black point aligned with pre-LUT display setting.
Edited by zoyd - 11/22/13 at 5:36pm
post #1064 of 1680
Quote:
Originally Posted by fhoech View Post

Btw, I'd really be interested in taking a look at those different profiles and calibrations. Could you share them?
Hmm. Setting measured values to 0, that's basically cheating (like I mentioned above for black point compensation...) smile.gif But if the values were already close to zero, it probably does not have a noticeable negative effect, altough it will mean the black point will not be hue corrected if black point correction was used (altough I think if a profile created on top of that altered calibration is used in a transform it may still alter black point hue somewhat depending on source profile).

I will share one as soon as I make it. Should I upload in a .zip file here?
post #1065 of 1680
Quote:
Originally Posted by MonarchX View Post

I will share one as soon as I make it. Should I upload in a .zip file here?
Sure, that will do. *edit* Btw, the older files where you got problematic results (e.g. reduced CR with gamma 2.2/sRGB calibration) are no longer around? Or did you solve that problem?
Edited by fhoech - 11/22/13 at 2:14pm
post #1066 of 1680
Quote:
Originally Posted by fhoech View Post

Oh, so many posts since I was last here smile.gif

I can only assume, but to me it looks like the reason why you get those errors in the first place is because the software you use to validate the results (HCFR?) probably makes a different assumption about the transfer characteristic than what the display profile actually recorded.

HCFR is centered around real-time display adjustments, it shows you whats going on while you adjust your display. It has rather limited "verification" capabilities compared to something like ArgylCMS and was heavily weighted towards DVD patterns in the past. As for the verification patterns it does support (primary and secondary saturation sequences and a standard set of Gretag-MacBeth ColorChecker triplets) the user has the option of calculating targets based on a pure power law transfer function of his/her choice or using the average exponent calculated from the most recent gray scale sequence.
post #1067 of 1680
Quote:
Originally Posted by zoyd View Post

[...] the user has the option of calculating targets based on a pure power law transfer function of his/her choice or using the average exponent calculated from the most recent gray scale sequence.
I see. Thanks for the explanation! I haven't looked at HCFR in a long time, I wasn't aware that it could use the measured grayscale for target calculation.
post #1068 of 1680
But ultimately, there is no way to use a device link profile / 3D LUT to view Windows desktop content or Windows Media Center content. I thought that a device profile can be installed for my device (monitor/HDTV) and a device link profile can be forced into my videcard LUT, but videocard LUT is 1D, not 3D, so its not possible.

I'm going to e-mail Gabe Newell and ask him to intergrate 3D LUT utilization into his upcoming SteamOS. It would be a huge blow to MS.

Outside of madVR, what else can use 3D LUT files or device link profiles?
post #1069 of 1680
Quote:
Originally Posted by zoyd View Post

Download one from http://dispcalgui.hoech.net/colorimetercorrections/ , it's a plain text file

I have a Samsung CCFL LCD HDTV TV from 2009. I found a file from the link above for plain SAMSUNG and the files are for my i1Display Pro colorimeter! Does that mean I should use those files as correction files for calibrating my HDTV? I currently use X-Rite's CCFL correction file...
post #1070 of 1680
Personally I would stick with ccss based corrections instead of someone else's matrix correction unless you can quantitatively identify some advantage to do otherwise, which in my opinion is not possible.
post #1071 of 1680
Quote:
Originally Posted by MonarchX 
But ultimately, there is no way to use a device link profile / 3D LUT to view Windows desktop content or Windows Media Center content.
Yes, the Windows desktop and media player don't have the capability to use display profiles or 3D LUTs for color correction.
There are some default Windows applications that make (limited) use of display profiles, like Windows Photo Viewer (but which can't use XYZ LUT profiles, if such a profile contains shaper + matrix components, then it will use that instead of the LUT, which is unfortunate to say the least).
Some 3rd-party apps (like MPC-HC) do support playing back video color-corrected with a display profile.
Quote:
Originally Posted by MonarchX 
I'm going to e-mail Gabe Newell and ask him to intergrate 3D LUT utilization into his upcoming SteamOS. It would be a huge blow to MS.
Not sure that's going to happen, although it would be nice (actually full desktop color management using device profiles is currently available under Linux when using the Compiz window manager and the CompICC plugin, and I think there are plans for full desktop colormanagement in Wayland, the potential successor to the X11 display server). If given the choice, I'd opt for device (link) profile support instead, it does the same thing but in a more standardized form.
Quote:
Originally Posted by MonarchX 
Outside of madVR, what else can use 3D LUT files or device link profiles?
For example, Argyll CMS cctiff utility can be used to convert images and can use device and device link profiles. In the print world, there are also many specialised tools and color servers that can use device links, mainly to convert images and PDF files.
In the video world, color grading software makes use of a variety of different 3D LUT formats, some of which you can create with dispcalGUI.
post #1072 of 1680
Quote:
Originally Posted by MonarchX View Post

I have a Samsung CCFL LCD HDTV TV from 2009. I found a file from the link above for plain SAMSUNG and the files are for my i1Display Pro colorimeter! Does that mean I should use those files as correction files for calibrating my HDTV? I currently use X-Rite's CCFL correction file...
Keep in mind those are user-supplied files, so there's no guarantee the file name/description matches the actual file contents. Generally I would strongly advise against using a colorimeter correction that does only denote the manufacturer, but not the actual display model (this is especially problematic for TVs, since the original model name is taken from the EDID, but a lot of TVs seem to only have the manufacturer with a suffix, e.g. "Phillips TV" or "Samsung TV"). And l agree with Zoyd, given the choice of user-supplied correction or generic CCSS, I'd stick with the CCSS file unless you can somehow quantify if the one has improved accuracy over the other.
post #1073 of 1680
I haven't realize there are xrite .edr/.ccss for i1d3/colormunki display until I read mention about ccss.

How critical are these corrections? Just a question in general for some knowledge as I am going to redo them with the corrections anyways. I haven't able to good result even with 2500 patches testchart.
post #1074 of 1680
Quote:
Originally Posted by baii View Post

I haven't realize there are xrite .edr/.ccss for i1d3/colormunki display until I read mention about ccss.

How critical are these corrections? Just a question in general for some knowledge as I am going to redo them with the corrections anyways. I haven't able to good result even with 2500 patches testchart.

It can be pretty significant depending on the display type you have. For plasmas an uncorrected probe can have average gray scale error of 5 dE2000.
post #1075 of 1680
Quote:
Originally Posted by zoyd View Post

btw, your collink options are not optimal for video use (collink –v -3m –qh –et –Et –G –iaw Rec709.icm nodispcal.icm nodispcalLUT.icm)
you need to include -IB or -Ib2.x

Sorry zoyd, I included -IB, I only forgot to report it here in my previous post. I also repeated a second time the whole process, but using this time the Argyll pattern generator....issue still present!

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?

These are the command options used for the second picture:

targen -v -d3 -e4 -B12 -s0 -g128 -m0 -b0 -V3.0 -N1.5 -c rec709.icm -f2500 nodispcal
dispwin –v –c
dispread –v –d1 -yl –Xccflfamily_07feb11.ccss nodispcal
colprof -v -qh -bl –aX nodispcal
collink –v -3m –qh –et –Et –G -IB –iaw Rec709.icm nodispcal.icm nodispcalLUT.icm
post #1076 of 1680
edit:
I just realized that -ia and -iaw break bright whites, in that they turn blue. -ir works, however I get huge grey scale errors with these.


I have no idea how that can even happen, seeing that my gpu outputs 16-235. Obviously madvr is scaling 255->235, otherwise this wouldn't be possible.
The graphs below where measured using -iaw.

I would like to skip dispcal as it always raises the black level for me, and also not do hardware calibration before hand, because it raises some issues in levels <10% on my TV. With profiling alone I managed to get pretty good color accuracy and also a pretty good looking greyscale >50%, below that however the errors get bigger, the darker the steps are.

This is what I used as patterns:
Code:
cmd /c bin\targen.exe -v -d3 -e4 -B12 -s0 -g128 -m0 -b0 -V1.5 -N1.0 -c rec709.icm -f1000 -W "madVR 2013-11-23 0.3127x 0.329y Rec. 1886 M-S XYZLUT+MTX" > logs\Create.Pattern.Chart.log

What can I do to improve the greyscale? Will a higher number of OFPS patches help, or are those mainly for color (which is very good already)? Should I increase the -g parameter?

Greyscale Before:

Greyscale After:

Gamma Before:

Gamma After:

Color Before:

Color After:

Edited by monvo - 11/23/13 at 6:35am
post #1077 of 1680
Quote:
Originally Posted by Kukulcan View Post


Why dark areas are so strange and faulty? Don't you get anything like that?

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.
post #1078 of 1680
Quote:
Originally Posted by monvo View Post

edit:

I have no idea how that can even happen, seeing that my gpu outputs 16-235. Obviously madvr is scaling 255->235, otherwise this wouldn't be possible.
The graphs below where measured using -iaw.

If your GPU only sends video levels 16-235 then madVR has to be set at 0-255 or you will get the wrong levels. I know it's counter-intuitive but that's the way it is. In the same way HCFR has to set to 0-255. In that scenario you will not get above white levels, madVR/HCFR 255->video card scales to 235. If you send 16-235 from HCFR the gray scale will not be correct.
Quote:
I would like to skip dispcal as it always raises the black level for me, and also not do hardware calibration before hand, because it raises some issues in levels <10% on my TV. With profiling alone I managed to get pretty good color accuracy and also a pretty good looking greyscale >50%, below that however the errors get bigger, the darker the steps are.

This works very well for me, I set the display at native, warm 2, gamma 0 and get great end results without the use of dispcal.
Edited by zoyd - 11/23/13 at 7:49am
post #1079 of 1680
Quote:
Originally Posted by zoyd View Post

If your GPU only sends video levels 16-235 then madVR has to be set at 0-255 or you will get the wrong levels. I know it's counter-intuitive but that's the way it is. In the same way HCFR has to set to 0-255. In that scenario you will not get above white levels, madVR/HCFR 255->video card scales to 235.
This works very well for me, I set the display at native, warm 2, gamma 0 and get great end results without the use of dispcal.
I know that, that's what I'm doing. Without a 3dlut or with -ir everything is capped at 235. The levels are definitely set correctly throughout. That's why I'm saying, that the 3dlut has to be scaling 255->235, otherwise madvr and the gpu wouldn't pass it through.
post #1080 of 1680
Quote:
Originally Posted by monvo View Post

I know that, that's what I'm doing. Without a 3dlut or with -ir everything is capped at 235. The levels are definitely set correctly throughout.

That's strange, I've used both -ia and -iaw without problems. What are the rest of your command lines?
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration
AVS › AVS Forum › Display Devices › Display Calibration › MadVR - ArgyllCMS