eeColor processor - ArgyllCMS - Page 4 - AVS Forum
Forum Jump: 
 1Likes
Reply
 
Thread Tools
post #91 of 291 Old 05-03-2013, 10:36 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
Not at all, that's a good idea since workflows are different.
zoyd is online now  
Sponsored Links
Advertisement
 
post #92 of 291 Old 05-05-2013, 10:23 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,414
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 16 Post(s)
Liked: 108
Hey guys,

just noticed this thread.

Would love to know how "eeColor + ArgyllCMS" compares to "madVR + ArgyllCMS"? Had anyone had a chance to test that yet? I've read that the eeColor box internally works at 10bit. Not sure if it also outputs 10bit? Or does it dither down to 8bit? madVR internally calculates in 32bit+ floating point, but then dithers down to 8bit (at the moment). So I guess final results could go either way...
madshi is online now  
post #93 of 291 Old 05-05-2013, 10:39 AM
AVS Special Member
 
ConnecTEDDD's Avatar
 
Join Date: Sep 2010
Location: Athens, Greece
Posts: 2,117
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 410
Quote:
Originally Posted by madshi View Post

Hey guys,

just noticed this thread.

Would love to know how "eeColor + ArgyllCMS" compares to "madVR + ArgyllCMS"? Had anyone had a chance to test that yet? I've read that the eeColor box internally works at 10bit. Not sure if it also outputs 10bit? Or does it dither down to 8bit? madVR internally calculates in 32bit+ floating point, but then dithers down to 8bit (at the moment). So I guess final results could go either way...

eeColor features 16bit internal signal processing and it uses different 6 memories of Correction LUT in 10bit per color (30bit in total) resolution, after that it outputs the same bits as is taking at the input.
If you send eeColor 12bit per color signal then at the output you will get 12 bit per color (36bit in total)

Ted's LightSpace CMS Calibration Disk Free Version for Free Calibration Software: LightSpace DPS + CalMAN ColorChecker
S/W: LightSpace CMS, SpaceMan ICC, SpaceMatch DCM, CalMAN 5, CalMAN RGB, ChromaPure, CalPC, ControlCAL
Meters: JETI Specbos 1211, Klein K-10A, i1PRO2, i1PRO, SpectraCAL C6, i1D3, C5
ConnecTEDDD is online now  
post #94 of 291 Old 05-05-2013, 10:46 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,414
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 16 Post(s)
Liked: 108
Quote:
Originally Posted by ConnecTEDDD View Post

eeColor features 16bit internal signal processing and it uses different 6 memories of Correction LUT in 10bit per color (30bit in total) resolution, after that it outputs the same bits as is taking at the input.
If you send eeColor 12bit per color signal then at the output you will get 12 bit per color (36bit in total)

Interesting - thanks! For comparison, madVR uses 16bit per color (48bit in total) LUTs.

So if I feed 8bit (per color) to the eeColor, the output is also 8bit? Hopefully it is dithered down from the internal 16bit processing bitdepth?
madshi is online now  
post #95 of 291 Old 05-05-2013, 11:07 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
Quote:
Originally Posted by madshi View Post

Interesting - thanks! For comparison, madVR uses 16bit per color (48bit in total) LUTs.

So if I feed 8bit (per color) to the eeColor, the output is also 8bit? Hopefully it is dithered down from the internal 16bit processing bitdepth?

yes, 8bit in->8bit out with internal processing at 10 bit/color.
zoyd is online now  
post #96 of 291 Old 05-05-2013, 11:08 AM
AVS Special Member
 
ConnecTEDDD's Avatar
 
Join Date: Sep 2010
Location: Athens, Greece
Posts: 2,117
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 410
Quote:
Originally Posted by madshi View Post

Quote:
Originally Posted by ConnecTEDDD View Post

eeColor features 16bit internal signal processing and it uses different 6 memories of Correction LUT in 10bit per color (30bit in total) resolution, after that it outputs the same bits as is taking at the input.
If you send eeColor 12bit per color signal then at the output you will get 12 bit per color (36bit in total)

Interesting - thanks! For comparison, madVR uses 16bit per color (48bit in total) LUTs.

So if I feed 8bit (per color) to the eeColor, the output is also 8bit? Hopefully it is dithered down from the internal 16bit processing bitdepth?

If you send YCbCr 4:4:4 with 8bit per color, inside the eeColor is converted to RGB for internal processing and for appyling your selected memory LUT and then it's converted to YCbCr 4:4:4 with 8bit per color for the output.

Ted's LightSpace CMS Calibration Disk Free Version for Free Calibration Software: LightSpace DPS + CalMAN ColorChecker
S/W: LightSpace CMS, SpaceMan ICC, SpaceMatch DCM, CalMAN 5, CalMAN RGB, ChromaPure, CalPC, ControlCAL
Meters: JETI Specbos 1211, Klein K-10A, i1PRO2, i1PRO, SpectraCAL C6, i1D3, C5
ConnecTEDDD is online now  
post #97 of 291 Old 05-05-2013, 11:52 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,414
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 16 Post(s)
Liked: 108
Ok, thanks. Does anybody know whether the eeColor dithers the output? I'm asking because converting the processed video to 8bit output without dithering could produce banding/solarization artifacts.
madshi is online now  
post #98 of 291 Old 05-05-2013, 12:12 PM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
Interesting question, do you have any real world examples of 10bit->8bit conversion artifacts? I'll have to ask the eeColor folks if they dither during downsampling.
zoyd is online now  
post #99 of 291 Old 05-05-2013, 01:29 PM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,414
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 16 Post(s)
Liked: 108
Real world examples? No.

But you can use a test pattern to confirm that rounding to 8bit after any kind of high bitdepth processing can produce banding. E.g. scale the madVR test pattern "smallramp.ytp" to fullscreen. If you disable dithering in the madVR settings, you should see some faint vertical banding. The banding goes away if you enable dithering. The test pattern itself is only 8bit, but through (proper) upscaling to fullscreen, the gray ramp becomes higher bitdepth. Rounding that down to 8bit produces banding artifacts. The same thing can theoretically happen with 3dlut processing in the eeColor box, although maybe not as easily as with scaling.

I'm not sure if the eeColor hardware can perform dithering. If not, it might be a good idea to add an option to always output 12bit, if the display supports it.

Edit: Let's consider the following situation:

We have a movie scene with a lot of gray fog in it. Let's say there's a fog area with the 8bit RGB gradient [100,100,100], [101,101,101], [102,102,102] and we feed this into the eeColor box. Let's further say that after 3dlut processing this results in the following 16bit values (represented as floating point values to make it easier to understand): [99.5,99.5,99.5], [100.4,100.4,100.4], [101.4,101.4,101.4]. If the eeColor box does not dither, the final 8bit output will be [100,100,100], [100,100,100], [101,101,101]. This might result in a visible banding step on screen, especially in motion, where banding problems are often more obvious than in still frames.
madshi is online now  
post #100 of 291 Old 05-07-2013, 01:00 PM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
nice example, I'm really not sure what the box does with "in-between" values.
zoyd is online now  
post #101 of 291 Old 05-21-2013, 08:12 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 545
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 68
Quote:
Originally Posted by <^..^>Smokey Joe View Post

Graeme, no offence intended, but unfortunately I had several links of your site open and downloaded the 32 bit version and 64 bit version into a folder, then at the moment I unzipped the 64bit, security essentials was disabled with an error.
After cleaning the pc and reloading security essentials new version I found a "Settingsmodifier " trogan.

Please see Microsoft Security Advisory 2846338 for information on an update that solves this problem.
gwgill is offline  
post #102 of 291 Old 06-02-2013, 05:42 PM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
Decided to calibrate the cal-day mode with native color, I haven't used it in the past due to some weird gamut behavior. This was the starting point:



Unlike starting in custom mode with the primaries aligned properly this LUT took 4500 OFPS patches to get right. 2500 straightened things out but was unable to get the saturations correctly. Measurements took 75 minutes using the D3.

zoyd is online now  
post #103 of 291 Old 06-04-2013, 02:27 PM
AVS Special Member
 
sillysally's Avatar
 
Join Date: Jun 2006
Location: Chicago
Posts: 3,645
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 36 Post(s)
Liked: 249
Has anybody tried to use eecolor pass-through using a Bly Ray 3D movie. Seems eecolor can't pass through 3D.or even using a LUT pre set.

ss
sillysally is offline  
post #104 of 291 Old 06-04-2013, 02:57 PM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
zoyd is online now  
post #105 of 291 Old 06-14-2013, 03:41 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
Now that the bt.1886 mapping is working as expected I've tested a few of the linking options to see what effect they have on grayscale and color. I first measured the relative GS and Color dE between DVD generated patterns via YCbCr vs. PC video card generated patterns, to ensure that the video card was not introducing any shifts. That's shown in the first row of the table and repeated again two days later to assess repeatability/stability. The green filled values indicate I am happy with the results and do not have to separately calibrate the video card to match the DVD generated patterns. The remaining table entries are calculated as the following:

1. Grayscale dE is relative to pre-LUT 2pt. calibrated grayscale
2. Color dE is relative to CIE standards (either rec709 or rec601 depending on LUT being tested)



The yellow fills highlight areas in the GS and color performance that have shift > 2 JND. In general only the low-end of the grayscale saw chromaticity shifts and they were smaller for the link option -Iaw than -Ir. Also, the -IB switch had better low-end grayscale performance than using the gamma_22 source space.

For color performance, the only linking options which generated significant errors relative to standards were the appearance model switches (-c -d) but this is to be expected since they are compensating for how colors appear under different environmental conditions and shifting the gamut to compensate. If you go this route I recommend actually measuring the various parameters for your viewing conditions.
zoyd is online now  
post #106 of 291 Old 06-16-2013, 04:57 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
I played around with abstract look profiles in the 3dLUT workflow and they work quite well. The easiest place to start is by manipulating the neutral axis and creating different gamma shapes. The general steps I followed were:

1. Create a graysteps.ti1 target set of 100 neutral patches.

targen -v -d3 -f0 -g100 graysteps

2. With your 3DLUT loaded measure these patches.

dispread -v graysteps

3. Create a tif image of the graysteps patch set.

printtarg -v -t -s graysteps

4. Edit graysteps.tif in photoshop and adjust curves. Save file as graysteps_adjusted.tif

5. Create simulated measurements file from your new tif image.

scanin -v -c -G2.2 graysteps_adjusted.tif graysteps.cht Rec709_gamma22.icm graysteps_adjusted

6. Use refine to create an abstract look profile that targets your new gamma.

refine -v -c -g graysteps_adjusted.ti3 graysteps.ti3 look.icm

7. Re-run collink using the abstract look profile.

collink -v -qh -aX -G -iaw -p look.icm Rec709_gamma22.icm display.icm 3DLUT_1.icm

Here are some examples:

tif image adjusted with linear ramp below 40% stimulus (pseudo-bt.1886)


tif image adjusted with photoshop linear contrast function


tif image adjusted with photoshop medium contrast function


Of course the last two generate some serious black crush but you get the idea.
zoyd is online now  
post #107 of 291 Old 06-21-2013, 03:59 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
I dug a little deeper into the grey axis response that ArgyllCMS is generating when using bt.1886 targeting vs. no adjustment of the source gamma. The workflow for generating the 3dLUT was:

  • Display calibrated to 2.2 gamma using 2 pt. control
  • 100 grey axis + 16 black patches included in targets
  • colprof -qh -bl -ax
  • collink -qh -G -e3 -et -Et -iaw

Results for source space = Rec709_gamma22.icm

I examined the 3dLUT output file and extracted the grey axis output values. The output modification in % for each channel along the grey axis is plotted. The orange dotted line is video black level 16. The yellow dotted line is the average adjustment of the 3 channels.


In this case where the source and target space video black is zero we see that the modified response is forced back to zero between input level 16 and the next node point which is level 20. This ensures that the target space video black remains unmodified.

Now if we look at the results using the -IB switch we get:


Here you can see the characteristic lightening of stimulus values below 20% and darkening above that the bt.1886 function generates but the black level is not forced back to zero. This is enough to generate a 2 click rise in brightness on my display. The near-black response also shifts to blue due to the separation of the adjustment where red/green track each other below 20% but blue is high enough to generate a visible shift (dE ~ 7). I also measure a blue deficit at 50% but it's not visible (dE ~ 3).

Both of these effects can be dialed out using the 10 pt. and brightness controls and even though they are small adjustments they are in region of the display response that is easily visible without the use of probes. As an alternative to post-lut display tweaking I have tried the following with good results.

I take the response above and alter the grey axis points so that each follows the yellow dotted line and also force video black to remain unmodified.


So far I have not seen any undesired banding effects from this approach and it avoids having to redo the neutral axis calibration post-LUT.
zoyd is online now  
post #108 of 291 Old 06-21-2013, 05:00 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,414
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 16 Post(s)
Liked: 108
Interesting. So it seems that the current ArgyllCMS version produces a small black level raise when using -IB?
madshi is online now  
post #109 of 291 Old 06-21-2013, 05:26 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
yes, I think what is needed is to be able to specify a source space with the same black offset as the one being measured. Then there should be no modification of level 16.
zoyd is online now  
post #110 of 291 Old 06-21-2013, 11:51 AM
AVS Special Member
 
N3W813's Avatar
 
Join Date: Feb 2003
Posts: 1,133
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 26
Quote:
Originally Posted by zoyd View Post


I take the response above and alter the grey axis points so that each follows the yellow dotted line and also force video black to remain unmodified.

So far I have not seen any undesired banding effects from this approach and it avoids having to redo the neutral axis calibration post-LUT.

So where exactly are you altering the grey axis points? The .ti3, .icm, or the 3dlut file? And what changes are you making to the files? 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 #111 of 291 Old 06-21-2013, 01:19 PM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
I read them from the 3dlut text file and write a new file with the modified values. I know this is a hack and Graeme won't like it, but it works for my flow. smile.gif
zoyd is online now  
post #112 of 291 Old 06-24-2013, 12:06 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 545
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 68
Quote:
Originally Posted by madshi View Post

Interesting. So it seems that the current ArgyllCMS version produces a small black level raise when using -IB?
It shouldn't be doing that. The source and destination black points should be matching close enough due to the "bend black" fudge, to ensure that there is no change to the black. Are the relevant files available, so that I can look into it ?
gwgill is offline  
post #113 of 291 Old 06-24-2013, 06:26 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
zoyd is online now  
post #114 of 291 Old 07-04-2013, 03:50 PM
Senior Member
 
avsform1's Avatar
 
Join Date: Jan 2004
Posts: 492
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 21
Those with an eeColor, is alone in the setup or are you using VP (Radiance or Duo) for scaling? I am thinking that a great combination is the Duo and the eeColor?
avsform1 is offline  
post #115 of 291 Old 07-23-2013, 11:32 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
Quote:
Originally Posted by gwgill View Post

It shouldn't be doing that. The source and destination black points should be matching close enough due to the "bend black" fudge, to ensure that there is no change to the black. Are the relevant files available, so that I can look into it ?


Sorry for the delay, here are the profiles used to create the 3dLuts that produce the black level rise shown in the above plot.

colprof -qh -bl -ax june18 -> june18.icm

collink -v -qh -IB -G -3e -et -Et -iaw Rec709.icm june18.icm bt1886target.icm produces a small black offset
(requires resetting brightness control and adjusting stimulus at 10%,20% to remove elevated blue signal)

collink -v -qh -G -3e -et -Et -iaw Rec709_gamma22.icm june18.icm gamma22target.icm produces no black offset

june18.zip 3042k .zip file



p.s. Noticed small bug in latest targen, it reports Black_COLOR_PATCHES "0" for all -B values (but correctly adds the requested number of black patches)
Attached Files
File Type: zip june18.zip (2.97 MB, 3 views)
zoyd is online now  
post #116 of 291 Old 07-24-2013, 01:16 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 545
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 68
Quote:
Originally Posted by zoyd View Post

Sorry for the delay, here are the profiles used to create the 3dLuts that produce the black level rise shown in the above plot.

I'm at a loss to know why you would be seeing anything like that, as the sample data and profile is consistent in showing no significant rise in black level:

xicclu -et -Et bt1886target.icm
0.000000 0.000000 0.000000 [RGB] -> Lut -> 0.018111 0.019080 0.017520 [RGB]

xicclu -ff -ia -pX june18.icm
0.000000 0.000000 0.000000 [RGB] -> Lut -> 0.031776 0.032229 0.048752 [XYZ]
0.018111 0.019080 0.017520 [RGB] -> Lut -> 0.031081 0.031523 0.048718 [XYZ]

The .ti3 black patch values are:

136 0.0000 0.0000 0.0000 0.034660 0.035281 0.044993
249 0.0000 0.0000 0.0000 0.033698 0.035330 0.047997
336 0.0000 0.0000 0.0000 0.033386 0.034227 0.049576
527 0.0000 0.0000 0.0000 0.032809 0.032898 0.051426
556 0.0000 0.0000 0.0000 0.032930 0.034940 0.049151
861 0.0000 0.0000 0.0000 0.032721 0.034087 0.048695
867 0.0000 0.0000 0.0000 0.032449 0.033071 0.050953
1336 0.0000 0.0000 0.0000 0.032188 0.034083 0.052023
1343 0.0000 0.0000 0.0000 0.032635 0.034199 0.048578
1357 0.0000 0.0000 0.0000 0.033030 0.032229 0.048075
1378 0.0000 0.0000 0.0000 0.032193 0.031882 0.050928
1484 0.0000 0.0000 0.0000 0.032797 0.030692 0.053633
1488 0.0000 0.0000 0.0000 0.033219 0.031252 0.051847
1505 0.0000 0.0000 0.0000 0.032497 0.033817 0.050811
1687 0.0000 0.0000 0.0000 0.033048 0.035165 0.046753
1976 0.0000 0.0000 0.0000 0.032409 0.032436 0.055663

for an average of 0.032917 0.033474 0.050069

which all looks pretty close. The profile is very slightly under-estimating the black by something like 0.001, which seems unlikely to be significant.
gwgill is offline  
post #117 of 291 Old 07-24-2013, 06:36 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
Quote:
Originally Posted by gwgill View Post

I'm at a loss to know why you would be seeing anything like that, as the sample data and profile is consistent in showing no significant rise in black level:
...
which all looks pretty close. The profile is very slightly under-estimating the black by something like 0.001, which seems unlikely to be significant.

yes and if you run the forward models for the gamma22 source case without the -IB switch the numbers agree with the -IB case as well:


average measured black point Y=0.049 cd/m^2
bt.1886 forward model black point Y=0.046 cd/m^2
gamma 2.2 forward model black point Y=0.046 cd/m^2

So I also don't understand why the 3dLUTs for the two cases have different values at the video black (16) level:


gamma22target.txt
input 0.0625010 0.0625010 0.0625010
output 0.0689360 0.0653500 0.0632040

black is stable

bt1886target.txt
input 0.0625010 0.0625010 0.0625010
output 0.0780560 0.0788870 0.0775180

black point rise
zoyd is online now  
post #118 of 291 Old 07-24-2013, 07:24 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 545
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 68
Quote:
Originally Posted by zoyd View Post

gamma22target.txt
input 0.0625010 0.0625010 0.0625010
output 0.0689360 0.0653500 0.0632040
Right, but 16/255 = 0.062745, not 0.062501 ?
Quote:
bt1886target.txt
input 0.0625010 0.0625010 0.0625010
output 0.0780560 0.0788870 0.0775180

black point rise
I think this is expected - if you're not using BT.1886 and not using some other black point matching intent, then the gamma22 source will give you a link that clips the shadows. In contrast the BT.1886 matches the black point, so the display RGB will be the threshold value, and the shadows don't get clipped. So the problem is not that the device RGB get raised, but that it is to a point where the display output changes. Perhaps due to the inflection at black, the profile is not quite accurate enough at that critical point. One of the disadvantages of increasing the weighting of the zero measurement is that it may reduce the accuracy nearby - perhaps this is the case at the inflection point ?

june18.icm L*a*b* of neutral axis
gwgill is offline  
post #119 of 291 Old 07-24-2013, 08:12 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,427
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 75 Post(s)
Liked: 299
Quote:
Originally Posted by gwgill View Post

Right, but 16/255 = 0.062745, not 0.062501 ?

The eeColor box levels are in 1/64 (0.0156250) increments starting at 0 so level 16 is the 5th level = 4*0.0156250 = 0.0625
Quote:
I think this is expected - if you're not using BT.1886 and not using some other black point matching intent, then the gamma22 source will give you a link that clips the shadows.

I certainly see this in the gamma22 LUT, it's not clipped to black in the shadows but rather clipped to input values, is that what you mean?
LL
Quote:
In contrast the BT.1886 matches the black point, so the display RGB will be the threshold value, and the shadows don't get clipped. So the problem is not that the device RGB get raised, but that it is to a point where the display output changes. Perhaps due to the inflection at black, the profile is not quite accurate enough at that critical point. One of the disadvantages of increasing the weighting of the zero measurement is that it may reduce the accuracy nearby - perhaps this is the case at the inflection point ?

Does it make sense to force clipping of shadows for this case? I think that is what I did here.
LL

Along those lines the accuracy of the profile is also not sufficient to maintain the display controlled chromaticity, would it make any sense to also constrain the neutral axis in some reasonable way? I chose to use the average RGB shift at each level so that chromaticity was not affected but Y ended up where it should.
zoyd is online now  
post #120 of 291 Old 07-24-2013, 08:26 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 545
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 68
Quote:
Originally Posted by zoyd View Post

The eeColor box levels are in 1/64 (0.0156250) increments starting at 0 so level 16 is the 5th level = 4*0.0156250 = 0.0625
Right, but the level that maps to that node (ie. the level that node 4 represents) is 16/255 = 0.0627451. That's certainly how the ICC device link is set up.
Quote:
I certainly see this in the gamma22 LUT, it's not clipped to black in the shadows but rather clipped to input values, is that what you mean?
Sorry, I'm having trouble parsing that sentence.

What I mean is that it is clipping/darkening the shadows just above black. You can see it in your graph as the spike down to -1.4%.
Quote:
Does it make sense to force clipping of shadows for this case? I think that is what I did here.
LL
I don't think so, no - since it makes the shadow reproduction inaccurate and bumpy.
Quote:
Along those lines the accuracy of the profile is also not sufficient to maintain the display controlled chromaticity, would it make any sense to also constrain the neutral axis in some reasonable way? I chose to use the average RGB shift at each level so that chromaticity was not affected but Y ended up where it should.
No, that doesn't make any sense to me. If you're doing that you are trusting the color accuracy of your native display over the instrument, in which case why bother profiling ?

If profiling is not improving things, then the thing to do is figure out why that is.

The profile seems to be a good fit to the measurement data, and it predicts no noticeable rise in black with a (full scale) RGB of 0.018111 0.019080 0.017520 into it. If it is visible, then the question is why the the profile is being inaccurate at that point.

[ I also can't relate the value I see out of the device link with your graph.

xicclu bt1886target.icm
0.062745 0.062745 0.062745 [RGB] -> Lut -> 0.078299 0.079132 0.077791 [RGB]

100 * 0.079132/0.062745 = + 26% ]
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