MadVR - ArgyllCMS - Page 7 - AVS Forum
Forum Jump: 
 57Likes
Reply
 
Thread Tools
post #181 of 2777 Old 05-23-2013, 07:31 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by VerGreeneyes View Post

Well, I'm thinking about this from a perspective of wanting to install the profile, not just using it as a stepping stone to a 3DLUT.
Sure, in that case it's quite appropriate to configure the B2A tables the way you want.
Quote:
Doesn't the Windows Color System default to perceptual intent?
I'm really not sure. It's mostly up to applications to use the profile.
gwgill is offline  
Sponsored Links
Advertisement
 
post #182 of 2777 Old 05-23-2013, 07:41 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by VerGreeneyes View Post

Quote:
Originally Posted by gwgill View Post

Right, but the nature of the device link or 3dlut is per pixel transformation, so there is no scope for image dependent or spatial transformations, so such factors have to reduced to a constant.
Right, yeah. Only something like a media player would be able to take this into account.
I can imagine a dynamic and spatial appearance algorithm being useful in some circumstances such as safety simulations (ie. visibility when driving in a dark tunnel etc.), and in helping to automate some creative applications (ie 3d animation), but I'm not sure it would be of much use for watching video. The reason is that you're not watching original scene images, you're watching images that have been carefully rendered for a TV like viewing environment. So if your actual viewing environment is different to the intended one, it will be a static adjustment that is necessary, since the difference in the viewing conditions is basically static. I guess you might want some change in the adjustment if you want to track things like changes in ambient lighting.
Quote:
I thought that ICCv4 mapped colors to CIECAM02 as an intermediate color space between input and output. Is that what ICCv2 does too, or am I way off?
It's got nothing to do with the ICC. ICC defines a file format. You can create the contents of the file any way you want, including using CIECAM02.
gwgill is offline  
post #183 of 2777 Old 05-23-2013, 04:59 PM - Thread Starter
AVS Special Member
 
N3W813's Avatar
 
Join Date: Feb 2003
Posts: 1,137
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 34
Quote:
Originally Posted by gwgill View Post

Hmm. That's a slightly odd command line - did you really mean to choose absolute colorimetric L*a*b* ?

Not sure, I copied the parameter from Zoyd's guide for creating the 3DLUT for eeColor. What is the default setting? -ir for relative? What is the difference between a, aa, aw, and al? smile.gif

My ArgyllCMS/MadVR 3DLUT Creation Workflow
My Sharp Elite Movie THX AV Mode Settings
--Aug 2011 Set, 2.2 gamma [ link ]
--Nov 2012 Set, 2.2 gamma [ link ]
N3W813 is offline  
post #184 of 2777 Old 05-24-2013, 01:21 AM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 12
Quote:
Originally Posted by gwgill View Post

It could be that the calibration curves are raising the black level:

From my own testing, using collink -a to include a calibration file raises the black level rather significantly even when using -Ib with a linear VideoLUT. While using collink without -a and calibrated VideoLUT potentially doesn't raise black level at all. Playing around with CIECAM02, always results in a non-zero and occasionally significantly elevated black level depending on the source parameters.


I'd suspect this may be because you are not taking into account the effect which madVR dithering and expanding levels from 16-235 + WTW & BTB -> 0-255 has on a 3DLUT outputting a non-zero black and/or BTB information, since nothing gets clipped. In many ways it'd be nice to have an option for the 3DLUT to always map video range Y<=16 Black -> R0-G0-B0, and never have black output values greater than R1-G1-B1 when dithered by madVR with whatever the 3DLUT outputs from video range Y=17.

Quote:
Originally Posted by N3W813 View Post

What is the difference between a, aa, aw, and al? smile.gif

See collink's documentation for a decent description of each.

As far as out-of-gamut clipping is concerned, -i al (Absolute L*a*b*) is by far the worse out of all the Absolute intents on my profiles. Both -i a (Absolute Jab) or -i aw (Absolute Jab w/ white point scaling) gave good results for an absolute intent. The oddball was -i aa (Absolute appearance Jab), which clipped very slightly worse than -i a & -i aw, but had an interesting perceptual twist to how it mapped some colors. Personally if I were going to use an Absolute intent, I would probably stick with -i aw.

Overall for the purpose of madVR 3DLUTs, I've been favoring the -i la (Luminance appearance) intent per an earlier recommendation Graeme Gill made to me because of my gamma woes. Ever since I started creating profiles from larger patch sets, I was able to understand why. This is the only colorimetric intent which attempts to maintain the relative luminance between source colors after collink gamma and gamut correction. At least with my profiles (gamut smaller than Rec709), the nearest-match approach of other colorimetric intents all result in random small to large gamma shifts to colors outside the neutral-axis, without any apparent relationship within a given scene. Overall I don't see much use of -i r (Relative colorimetric) when -i la is available.

I've never really liked -i p (Perceptual) -i ms (Saturation) -i s (Enhanced Saturation) very much, because they are non-colorimetric intents. Perceptual has the best tone smoothness out of all the intents, but otherwise it desaturates colors to match hue. Both of the saturation intents oversaturate colors, making them even more useless than the normal perceptual intent in my subjective view.


tl;dr In my subjective opinion: la > aw > a > ir > aa > p > al > ms > s
ceru likes this.
cyberbeing is offline  
post #185 of 2777 Old 05-24-2013, 05:00 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,715
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 250 Post(s)
Liked: 360
Quote:
Originally Posted by N3W813 View Post

Quote:
Originally Posted by gwgill View Post

Hmm. That's a slightly odd command line - did you really mean to choose absolute colorimetric L*a*b* ?

Not sure, I copied the parameter from Zoyd's guide for creating the 3DLUT for eeColor. What is the default setting? -ir for relative? What is the difference between a, aa, aw, and al? smile.gif

I have since updated it to -ir and after some further testing am moving towards -ila. I'm still having some trouble matching a bt.1886.
zoyd is online now  
post #186 of 2777 Old 05-24-2013, 08:33 AM
Member
 
cfelicio's Avatar
 
Join Date: Jul 2011
Posts: 91
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 12
Quote:
Originally Posted by cyberbeing View Post

I'd suspect this may be because you are not taking into account the effect which madVR dithering and expanding levels from 16-235 + WTW & BTB -> 0-255 has on a 3DLUT outputting a non-zero black and/or BTB information, since nothing gets clipped. In many ways it'd be nice to have an option for the 3DLUT to always map video range Y<=16 Black -> R0-G0-B0, and never have black output values greater than R1-G1-B1 when dithered by madVR with whatever the 3DLUT outputs from video range Y=17.
See collink's documentation for a decent description of each.

I know the 0 255 16 235 has been discussed extensively on this forum, and the general consensus (even from madshi) is that if your TV supports 0 255, use it everywhere (videocard, madvr, tv). But you are stating above that when I set madvr to 0-255, it actually expands the video from 16-235. Wouldn't this result in black bars below 17 flashing during the black test pattern? And since we calibrate to not see them, a black crush as well?

In my own experience, when I have everything set at 0-255, I only get flashing bars from 18 and above, and that tells me that 0-16 is getting compressed? With dithering disabled in madvr there is some banding visible.

If I set everything to 0-255, except madvr (leave it at 16-235), then I get all the bars flashing, and I'd imagine no compression or expansion is taking place, but from what I read this is wrong, and I don't have much experience yet, so not sure how to really measure this stuff. The banding looks better here without dithering.

Very confused biggrin.gif
cfelicio is offline  
post #187 of 2777 Old 05-24-2013, 12:08 PM - Thread Starter
AVS Special Member
 
N3W813's Avatar
 
Join Date: Feb 2003
Posts: 1,137
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 34
Quote:
Originally Posted by cyberbeing View Post

In my subjective opinion: la > aw > a > ir > aa > p > al > ms > s

Quote:
Originally Posted by zoyd View Post

I have since updated it to -ir and after some further testing am moving towards -ila. I'm still having some trouble matching a bt.1886.

Thanks guys. I will try out the different absolute intents this weekend. biggrin.gif

My ArgyllCMS/MadVR 3DLUT Creation Workflow
My Sharp Elite Movie THX AV Mode Settings
--Aug 2011 Set, 2.2 gamma [ link ]
--Nov 2012 Set, 2.2 gamma [ link ]
N3W813 is offline  
post #188 of 2777 Old 05-24-2013, 02:24 PM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 12
Quote:
Originally Posted by cfelicio View Post

the general consensus (even from madshi) is that if your TV supports 0 255, use it everywhere (videocard, madvr, tv).

Optimally, you should indeed have madVR, GPU driver, and Display set to 0-255 fullrange RGB, assuming your display supports it well.

Quote:
Originally Posted by cfelicio View Post

But you are stating above that when I set madvr to 0-255, it actually expands the video from 16-235. Wouldn't this result in black bars below 17 flashing during the black test pattern? And since we calibrate to not see them, a black crush as well?
...
Very confused biggrin.gif

Don't be confused. The AVS HD 709 black clipping test pattern is a specially designed as full-range for checking proper 16-235 -> 0-255 levels expansion. The bars labeled 1-15 are BTB (blacker than black) information outside the valid 16-235 video range, which do not normally exist. That bar labeled 16 actually is video range Y=16 prior to levels expansion. When expansion from 16-235 -> 0-255 occurs, that Y=16 bar should be equal to RGB 0-0-0. If Y=16 is expanded to a value greater than 0, fullrange BTB bars start to become visible, which is normally undesired. If Y=16 is expanded to a value less than 0, video range bars 16 and higher become start to become clipped, which is also undesired.

madVR uses 16-235 3DLUTs, and performs 16-235 -> 0-255 via shaders later in the display chain if set to 0-255 output. This makes it very important to not increase the luminance of RGB 16-16-16 and be careful with RGB 17-17-17 as well, otherwise black will no longer map to RGB 0-0-0 when expanded to 0-255 with dithering. It becomes the job of the 3DLUT to ensure BTB will eventually be clipped by madVR and not visible, which collink doesn't always do. Essentially, the current 16-235 3DLUT setup means that Argyll raising black level to correct the black point, will always have the side effect of making BTB visible. This is why I believe there should be an option to disable black point correction, and ensure video black actually maps to full range black on display.
cfelicio likes this.
cyberbeing is offline  
post #189 of 2777 Old 05-24-2013, 04:39 PM
Member
 
cfelicio's Avatar
 
Join Date: Jul 2011
Posts: 91
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 12
Thanks for taking the time to explain this to me, I think it makes more sense to me now! smile.gif
cfelicio is offline  
post #190 of 2777 Old 05-26-2013, 06:49 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by cyberbeing View Post

From my own testing, using collink -a to include a calibration file raises the black level rather significantly even when using -Ib with a linear VideoLUT. While using collink without -a and calibrated VideoLUT potentially doesn't raise black level at all.
Was that "-a" or "-a display.cal" ?

I think there are currently a few issues with the way the tools deal with setups where the "dispcal -E" is needed (ie. the display pixel values need to be in the 16-235 range to suite the TV). I haven't thought through the implications of the various workflow options - ie., if you create a .cal using "dispcal -E" and then install the .cal file before profiling, the results will be wrong, whereas if the .cal is carried through with "dispread -E -K display.cal" and "collink -a display.cal" and MadVR is set to output 16-235 levels, it should work OK.

I'll see if I can fix this, but the result will still be a bit easy to get wrong - ie. if I change it so that the .cal file when installed converts full range to 16-235 and MadVR images go through the calibration curves, then MadVR will have to be set to output full range, whereas if the .cal is incorporated in the 3dLut MadVR will have to be set to 16-235.

It may be that from a quality point of view it's better that MadVR do the video level conversion (unless the VideoLUTs have better than 8 bit precision), in which case the "collink -a display.cal" workflow with linear VideoLUTs or VideoLUT bypass becomes more desirable.
Quote:
I'd suspect this may be because you are not taking into account the effect which madVR dithering and expanding levels from 16-235 + WTW & BTB -> 0-255 has on a 3DLUT outputting a non-zero black and/or BTB information, since nothing gets clipped.
I'm not sure what you mean. MadVR expects the 3dLUT to be 16-235 encoded input and out, and that's what the "collink -et -Et" does. The values between 0-16 and 235-255 are linearly interpolated to preserve "sync" levels and be representable in a limited resolution cLUT. MadVR will have to clip anything outside 16-235 if it is expanding to 0-255, because anything else (ie. wrapping around) would be ridiculous.
Quote:
In many ways it'd be nice to have an option for the 3DLUT to always map video range Y<=16 Black -> R0-G0-B0, and never have black output values greater than R1-G1-B1 when dithered by madVR with whatever the 3DLUT outputs from video range Y=17.
That may be possible with a 256 resolution cLUT, but not the smaller 65 res. intermediate cLUT. But you can't make arbitrary rules about what happens in the range 16-235 since the very point of calibration and profiling is to deal with the actual behaviour of the display. For instance, it is not unknown for some displays to have a "dead band" near black, where nothing happens as you raise the input value from 0 (or 16 in video range). So proper calibration should map ideal black input (0/16) to the threshold at which the display is just about to start responding, so that the display output is progressive, and that shadow detail is not lost in the "dead band". This may result in a desired calibration curve or 3dLut having a non-zero output at zero input. (> 16 output at 16 input for video encoded levels).
gwgill is offline  
post #191 of 2777 Old 05-29-2013, 11:37 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with the following changes:

Changed BT.1886 black point mapping to bend the neutral axis to the black point over the lower 5% of the visual range, so that the mapping should be less inclined to raise the black level. BT.1886 is now implemented in PCS, allowing for increased flexibility in the input colorspace (ie. xvYCC).

More thoroughly implemented dispcal and dispread -E support. Fixed some issues with scaling to higher bit depths. When .cal files are loaded into the graphics card or converted to a 'vcgt' tags in an ICC profile the calibration now incorporates the Video level encoding into the curve, so that the Graphics card VideoLUTs implement both the Video level encoding and calibration. This keeps the ICC profile self consistent.

Added some future looking support for UHDTV color standard Rec/BT.2020 color profile, and xvYCC encoding support (the latter is not currently usable without a video rendering pipeline that supplies YCbCr into the DeviceLink/3dLut).

Scenarios.html has been updated to reflect all these changes, as well as expanding and clarifying various aspects of Video calibration using ArgyllCMS tools.
gwgill is offline  
post #192 of 2777 Old 05-30-2013, 08:27 AM
Member
 
cfelicio's Avatar
 
Join Date: Jul 2011
Posts: 91
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 12
Thanks Graeme, can't wait to try it out :-)

@N3W813: Do you know if besides black point compensation, any other parameter / command is going to change on the guide? I ask because there was a lot of new info posted by Graeme clarifying the usage, but I'm not knowledgeable enough yet to translate it into the practical usage of the guide!
cfelicio is offline  
post #193 of 2777 Old 05-30-2013, 08:51 AM
Member
 
cfelicio's Avatar
 
Join Date: Jul 2011
Posts: 91
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 12
Quote:
Originally Posted by gwgill View Post

Was that "-a" or "-a display.cal" ?

I think there are currently a few issues with the way the tools deal with setups where the "dispcal -E" is needed (ie. the display pixel values need to be in the 16-235 range to suite the TV). I haven't thought through the implications of the various workflow options - ie., if you create a .cal using "dispcal -E" and then install the .cal file before profiling, the results will be wrong, whereas if the .cal is carried through with "dispread -E -K display.cal" and "collink -a display.cal" and MadVR is set to output 16-235 levels, it should work OK.

Hi Graeme,

What if Madvr is set to 0-255? Would it give wrong results? Like wrong grayscale or crushed blacks / whites?
cfelicio is offline  
post #194 of 2777 Old 05-30-2013, 09:24 AM - Thread Starter
AVS Special Member
 
N3W813's Avatar
 
Join Date: Feb 2003
Posts: 1,137
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 34
Quote:
Originally Posted by gwgill View Post

I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with the following changes:

Changed BT.1886 black point mapping to bend the neutral axis to the black point over the lower 5% of the visual range, so that the mapping should be less inclined to raise the black level. BT.1886 is now implemented in PCS, allowing for increased flexibility in the input colorspace (ie. xvYCC).

More thoroughly implemented dispcal and dispread -E support. Fixed some issues with scaling to higher bit depths. When .cal files are loaded into the graphics card or converted to a 'vcgt' tags in an ICC profile the calibration now incorporates the Video level encoding into the curve, so that the Graphics card VideoLUTs implement both the Video level encoding and calibration. This keeps the ICC profile self consistent.

Added some future looking support for UHDTV color standard Rec/BT.2020 color profile, and xvYCC encoding support (the latter is not currently usable without a video rendering pipeline that supplies YCbCr into the DeviceLink/3dLut).

Scenarios.html has been updated to reflect all these changes, as well as expanding and clarifying various aspects of Video calibration using ArgyllCMS tools.

Thanks Graeme, will test this out. smile.gif
Quote:
Originally Posted by cfelicio View Post

Thanks Graeme, can't wait to try it out :-)

@N3W813: Do you know if besides black point compensation, any other parameter / command is going to change on the guide? I ask because there was a lot of new info posted by Graeme clarifying the usage, but I'm not knowledgeable enough yet to translate it into the practical usage of the guide!

Not sure yet, I will need to test the new binaries first then make the appropriate changes to the workflow.

My ArgyllCMS/MadVR 3DLUT Creation Workflow
My Sharp Elite Movie THX AV Mode Settings
--Aug 2011 Set, 2.2 gamma [ link ]
--Nov 2012 Set, 2.2 gamma [ link ]
N3W813 is offline  
post #195 of 2777 Old 05-30-2013, 11:16 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,715
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 250 Post(s)
Liked: 360
@Graeme:

Is there any advantage when generating 3dluts in specifying the intents (-t or -T) or viewing conditions (-c and -d) during the colprof step?
zoyd is online now  
post #196 of 2777 Old 05-30-2013, 05:46 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by cfelicio View Post

What if Madvr is set to 0-255? Would it give wrong results? Like wrong grayscale or crushed blacks / whites?

With the latest update, if you use dispcal -E (to restrict the test samples to 16-235) and install the resulting calibration curve in the Video Card VideoLUTs, then MadVR should be set to 0-255 since the installed calibration curve will translate that to 16-235.
gwgill is offline  
post #197 of 2777 Old 05-30-2013, 05:53 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by zoyd View Post

@Graeme:

Is there any advantage when generating 3dluts in specifying the intents (-t or -T) or viewing conditions (-c and -d) during the colprof step?
Those options affect the creation of the B2A tables of the display profile. (B2A = PCS/XYZ to Device values, the reverse of the display behavior captured by the A2B table.). If you are using "collink -G" later on, they will have no effect on the resulting link/3dLut, since "-G" directly inverts the A2B table. If you are going to use the display profile independently for other things (ie. in other color management situations where the CMM will be using the B2A tables), then yes, you may want to configure it in a particular way. Which way is a whole discussion, some aspects of which are covered in Scenarios.html in the print and display profiling sections.
gwgill is offline  
post #198 of 2777 Old 05-30-2013, 05:58 PM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,715
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 250 Post(s)
Liked: 360
zoyd is online now  
post #199 of 2777 Old 05-30-2013, 06:55 PM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,715
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 250 Post(s)
Liked: 360
Just tried the new collink with some of the examples from scenarios and had some problems (on eecolor):

  1. collink -v -Ib -c md -dmd -da:18 -G -ila -3e -et -Et -qh Rec709.icm may1.icm 3dlut1
  2. collink -v -ctv -dmd -da:7 -G -ila -3e -et -Et -qh Rec709.icm may1.icm 3dlut2
  3. collink -v -Ib:2.1 -G -ir -3e -et -Et -qh Rec709.icm may1.icm 3dlut3
  4. collink -v -Ib -G -ir -3e -et -Et -qh Rec709.icm may1.icm 3dlut4
  5. collink -v -Ib:2.3 -G -ir -3e -et -Et -qh Rec709.icm may1.icm 3dlut5
  6. collink -v -G -ir -3e -et -Et -qh Rec709_gamma22.icm may1.icm 3dlut6


1,3,4,5 (all using the -Ib switch) had pretty bad artifacts (posterization) in some colors (red appears worst at lower luminance levels). 2 didn't show that but was too washed out for my display. I use 6 in all tests as a baseline and it was fine. I've previously used both the -Ib and -IB switches without any problems at all.

I used the same target measures as I've used before with the colprof command line of: colprof -v -qh -bl -aX may1

The only difference here was the use of -aX instead of -ax compared to previous attempts.

edit:

I just repeated case 5 with an older version of collink and it was perfect, so something's up with the new code.

old code:

new code:
zoyd is online now  
post #200 of 2777 Old 05-31-2013, 05:07 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 119
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 10
Quote:
Originally Posted by zoyd View Post

Just tried the new collink with some of the examples from scenarios and had some problems (on eecolor):

  1. collink -v -Ib -c md -dmd -da:18 -G -ila -3e -et -Et -qh Rec709.icm may1.icm 3dlut1
  2. collink -v -ctv -dmd -da:7 -G -ila -3e -et -Et -qh Rec709.icm may1.icm 3dlut2
  3. collink -v -Ib:2.1 -G -ir -3e -et -Et -qh Rec709.icm may1.icm 3dlut3
  4. collink -v -Ib -G -ir -3e -et -Et -qh Rec709.icm may1.icm 3dlut4
  5. collink -v -Ib:2.3 -G -ir -3e -et -Et -qh Rec709.icm may1.icm 3dlut5
  6. collink -v -G -ir -3e -et -Et -qh Rec709_gamma22.icm may1.icm 3dlut6


1,3,4,5 (all using the -Ib switch) had pretty bad artifacts (posterization) in some colors (red appears worst at lower luminance levels). 2 didn't show that but was too washed out for my display. I use 6 in all tests as a baseline and it was fine. I've previously used both the -Ib and -IB switches without any problems at all.

I used the same target measures as I've used before with the colprof command line of: colprof -v -qh -bl -aX may1

The only difference here was the use of -aX instead of -ax compared to previous attempts.

edit:

I just repeated case 5 with an older version of collink and it was perfect, so something's up with the new code.

old code:

new code:

Yes ... experiencing something similar.
MSL_DK is offline  
post #201 of 2777 Old 05-31-2013, 06:05 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by zoyd View Post

Just tried the new collink with some of the examples from scenarios and had some problems (on eecolor):

1,3,4,5 (all using the -Ib switch) had pretty bad artifacts (posterization) in some colors (red appears worst at lower luminance levels).

Thanks for your report. I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with something that I hope fixes it.
gwgill is offline  
post #202 of 2777 Old 05-31-2013, 07:27 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,715
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 250 Post(s)
Liked: 360
Quote:
Originally Posted by gwgill View Post

Thanks for your report. I've updated http://www.argyllcms.com/Win32_collink_3dlut.zip with something that I hope fixes it.

That helped at higher luminances but the near black levels have alot of hue shifting. btw, your previous code worked just fine on the eecolor, there was no unwanted black level rise and neutral remained neutral. My only problem was that all the bt.1886 options yielded straight-line (or nearly straight) and could not reproduce the correct target luminance for my white/black points.

off


on
zoyd is online now  
post #203 of 2777 Old 05-31-2013, 06:21 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by zoyd View Post

That helped at higher luminances but the near black levels have alot of hue shifting.
I'm struggling to be able reproduce this - my grey wedges look perfect, so I need a source image that demonstrates it.
Quote:
btw, your previous code worked just fine on the eecolor, there was no unwanted black level rise and neutral remained neutral.
Worked perfectly fine in my testing too. Hard to pin things down without concrete examples, and the time to sort through them in detail.
Quote:
My only problem was that all the bt.1886 options yielded straight-line (or nearly straight) and could not reproduce the correct target luminance for my white/black points.
I'm not sure what you mean. The verbose output of collink using -Ib shows the target/expected grey response. Does that at least match what you expect ?
gwgill is offline  
post #204 of 2777 Old 05-31-2013, 06:31 PM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,715
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 250 Post(s)
Liked: 360
I don't see any problems with grey or color ramps either but I can pick it out easily in cable content. That image above is on the GCD disk if you want to use it unless this is something specific to the eecolor lut output.

I will get some more diagnostics on bt.1886 targeting and see if I can sort that out. Right now I'm just profiling to 2.2 and using the display controls to get bt.1886 after the 3dlut is in place.

edit:

The output of collink -v is a series of source and dst white points and black points, all of which are Y=1 (140 cd/m^2) for white and Y=0.003673 (0.53 cd/m^2) for black. I don't see any neutral axis targets. My measured black level in the .ti3 file is 0.025 cd/m^2. How do I interpret?
zoyd is online now  
post #205 of 2777 Old 05-31-2013, 08:22 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by zoyd View Post

The output of collink -v only sources a series of source and dst white points and black points, all of which are Y=1 (140 cd/m^2) for white and Y=0.003673 (0.53 cd/m^2) for black. I don't see any neutral axis targets. My measured black level in the .ti3 file is 0.025 cd/m^2. How do I interpret?
The "bt1886" value is the target output Y as a proportion of maximum Y for the given % video input. So multiply that by the white Y for an absolute expected reading. (Using spotread you'd use "-eb" or "-ew" to avoid having to compute that).
gwgill is offline  
post #206 of 2777 Old 05-31-2013, 10:03 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by zoyd View Post

That image above is on the GCD disk if you want to use it unless this is something specific to the eecolor lut output.
There might be something specific to your profile, command line or eeColor, as the above image looks OK using MadVR using a profile for my CRT with the latest collink.

The odd looking pixels are at or just above zero as far as I can tell (e.g. 23,17,21), so they really are purple in the source (i.e. corrected for black being 16: 7, 1, 5), but typically should be darkened to a considerable degree by the Rec709 linear slope + BT.1886 type power curve to invisibility - i.e. I don't see any hue shifting going on here. The puzzle is why they are being lightened up to the point that the DCT quantization and purple color is visible. But then I'm not sure how your images were created - the almost white parts should be a deep orange.
gwgill is offline  
post #207 of 2777 Old 05-31-2013, 11:22 PM
Member
 
cyberbeing's Avatar
 
Join Date: Apr 2006
Posts: 61
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 12
Quote:
Originally Posted by gwgill View Post

Was that "-a" or "-a display.cal" ?

collink -a display.cal

Quote:
I think there are currently a few issues with the way the tools deal with setups where the "dispcal -E" is needed (ie. the display pixel values need to be in the 16-235 range to suite the TV). I haven't thought through the implications of the various workflow options - ie., if you create a .cal using "dispcal -E" and then install the .cal file before profiling, the results will be wrong, whereas if the .cal is carried through with "dispread -E -K display.cal" and "collink -a display.cal" and MadVR is set to output 16-235 levels, it should work OK.

I'll see if I can fix this, but the result will still be a bit easy to get wrong - ie. if I change it so that the .cal file when installed converts full range to 16-235 and MadVR images go through the calibration curves, then MadVR will have to be set to output full range, whereas if the .cal is incorporated in the 3dLut MadVR will have to be set to 16-235.

I've not been using dispcal -E since my displays natively support 0-255.

It just seemed that even if the 0-255 VideoLUT .cal file mapped 0 = R0-G0-B0, "collink -a display.cal" would raise the black level in the 3DLUT.

If I didn't include "-a display.cal", the black level in the 3DLUT would map to 0 after madVR did 16-235->0-255. And for obvious reasons, since the VideoLUT .cal file had 0 = R0-G0-B0, black level wouldn't be raised at all.

Two cases with ultimatlly identical data sets, handled black level very differently.

Quote:
That may be possible with a 256 resolution cLUT, but not the smaller 65 res.

Last time I tested, collink -r does not allow 256 cLUT resolution only 255. I don't know if that is a bug, or by design. When not using "-G" I've noticed the 255 resolution cLUTs generate very quickly, but quality isn't as good as the default 65 resolution using "-G". Is there any middle ground here to improve the quality of collink cLUT when not using -G? Either way the same issue exists with elevated black level with a 255 cLUT resolution last time I tested this, so I assume "that may be possible" means you'd actually need to make some code changes first.


[Note: This was with the 5-21-2013 builds, I've yet to test the new 5-31-2013 builds]
cyberbeing is offline  
post #208 of 2777 Old 06-01-2013, 03:57 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,715
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 250 Post(s)
Liked: 360
Quote:
Originally Posted by gwgill View Post

The "bt1886" value is the target output Y as a proportion of maximum Y for the given % video input. So multiply that by the white Y for an absolute expected reading. (Using spotread you'd use "-eb" or "-ew" to avoid having to compute that).

ok, I was using a prior collink without the added grayscale targets. Here is what is happening, using the -IB switch produces targets as if the display has a zero black level, in this limit it targets a flat 2.4 gamma for each level and this is what I measure with the LUT active. The chart below has the collink -IB output in the first 5 columns and my calcs in the last three. It should be producing the targets in column 7 to get the desired transfer function.

zoyd is online now  
post #209 of 2777 Old 06-01-2013, 04:44 AM
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,715
Mentioned: 30 Post(s)
Tagged: 0 Thread(s)
Quoted: 250 Post(s)
Liked: 360
Quote:
Originally Posted by gwgill View Post

There might be something specific to your profile, command line or eeColor, as the above image looks OK using MadVR using a profile for my CRT with the latest collink.

The odd looking pixels are at or just above zero as far as I can tell (e.g. 23,17,21), so they really are purple in the source (i.e. corrected for black being 16: 7, 1, 5), but typically should be darkened to a considerable degree by the Rec709 linear slope + BT.1886 type power curve to invisibility - i.e. I don't see any hue shifting going on here. The puzzle is why they are being lightened up to the point that the DCT quantization and purple color is visible. But then I'm not sure how your images were created - the almost white parts should be a deep orange.

The image was extracted from the BD "Tree of Life" but I see it in all sources, BD, DVD, cable, streaming etc. so I'm thinking it must be the eecolor workflow.

Symptoms:
  • Everything was fine prior to may30th release
  • Only seen with -Ib or -IB switch
  • All sources
  • Happens using profiles with both the XYZ cLUT and the Lab cLUT
  • similar (but not as strong) problems using MadVR .3dlut

Here is a zip file containing the results of:

colprof -v -qh -bl -aX basetargets

and

collink -v -IB -G -la -3e -et -Et -qh Rec709.icm basetargets.icm 3DLUT_1.icm


Another snap directly from BD playback:

off


on


edit:

Just fired up madVR with a 3dlut created from the same profile and similar artifacts are created but they are reduced in magnitude with proper levels matching. My video card forces limited range output (16-235) so I did two tests both with madVR set to full range:

1. collink -et -Et -> heavy artifacts like what is shown above
2. collink -en -En -> much reduced but still some evidence in very dark scenes

case 2. is what should be used anyway given that my video card compresses to limited range so that makes sense although it's not perfect. For the eecolor I was working on the assumption that I should be using -et -Et but apparently that isn't right.

So to summarize testing so far:

Minor artifacts remain in near-black areas for both madVR and the eeColor when using full range input/output encoding in the link step. The artifacts occur more often at higher gamma settings (ie -IB vs -Ib). I still don't think full range input/output is correct for the eeColor when using YCbCr video signals and all other link settings that do not use the bt.1886 switch perform perfectly with limited range encoding in the link step.
zoyd is online now  
post #210 of 2777 Old 06-02-2013, 09:07 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 652
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 90 Post(s)
Liked: 81
Quote:
Originally Posted by zoyd View Post


ok, I was using a prior collink without the added grayscale targets. Here is what is happening, using the -IB switch produces targets as if the display has a zero black level, in this limit it targets a flat 2.4 gamma for each level and this is what I measure with the LUT active. The chart below has the collink -IB output in the first 5 columns and my calcs in the last three. It should be producing the targets in column 7 to get the desired transfer function.

Right, but where does your black = 0.022 cd/m^2 come from though ?

The only knowledge that collink has about the display is the profile, and any BT.1886 black offset applied has to be chosen to result in a negligible difference between the black the display is capable of, and the black it produces for zero input to the device link.

So from the profile:

xicclu -ff -ir -px basetargets.icm
0.000000 0.000000 0.000000 [RGB] -> Lut -> 0.000000 0.000000 0.000000 [XYZ]

The profile says the display has a perfect zero black. So that's what collink has to work with. To use anything else would result in a raised black when the black point XYZ if inverted.

ie.

.022/146.5 = .00015

xicclu -fif -ir -px basetargets.icm
0.000145 0.000150 0.000124 [XYZ] -> Lut -> 0.016065 0.015489 0.013713 [RGB]

which is a result that is likely to be 0.022 cd/m^2 higher than the actual black, which is probably not what you want.

So it doesn't matter what you measure as a black point, it's the black point reckoned by the profile that counts, because that's what's used to predict the RGB values needed to achieve the target.

Now why the profile isn't so accurate at the black point, and whether it matters is a different question. 0.022 cd/m^2 is at or below most instruments accurate capabilities though.
gwgill is offline  
Reply Display Calibration

User Tag List

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off