MadVR - ArgyllCMS - Page 106 - AVS | Home Theater Discussions And Reviews
Forum Jump: 
 121Likes
Reply
Thread Tools
post #3151 of 3164 Unread Yesterday, 11:00 AM
Member
 
Join Date: Nov 2014
Posts: 93
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 73 Post(s)
Liked: 3
Quote:
Originally Posted by zoyd View Post
ok - then the 679 patch profile just doesn't give as accurate a location of the blue primary.

So you could stick with the larger profile you already have, or try another one of that size and use this one as a preconditioning profile. I noticed your peak white is pretty bright, do you intend this for a daytime viewing mode? If so, you might try out different gamma targets to see what works best in your environment.
Yes, I found that the OLED behaves a bit different than plasma or LCD...I notice that PQ is improved with a higher Y. On one hand the calibration controls only work with contrast at 100 (or very close to it), on the other RGB values on all IREs get closer to 100% with a higher Y and get apart with a lower Y. Specially with blue on low IREs. If I go for a 130cd/m2 or lower White Y the blue on IRE 5 and 10 are much more unaligned.

I don't know if it's a common trait of OLED or just my set. But it helps the calibration to have a higher than normal Y. The funny thing is that I don't find it uncomfortable (my previous set was calibrated to 130cd/m2, so I was used to that kind of level). It might have to do with how the APL works and with the pure blacks. It's really something amazing at night to not be able to distinguish where are the borders of content from TV border or the rest of the wall. The movie seems to be hovering in the air...

Quote:
Originally Posted by fhoech View Post
And the correction used (none for the V3 679, custom OLED for the V4 2527 patches profile), which would explain the gamut differences.
Yes. you're right. I have to try to create one LUT using correction and one without and compare the differences. I find it very odd that the version without correction actually produces better results.
Pepelegal is online now  
Sponsored Links
Advertisement
 
post #3152 of 3164 Unread Yesterday, 11:33 AM
AVS Special Member
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 5,380
Mentioned: 57 Post(s)
Tagged: 0 Thread(s)
Quoted: 665 Post(s)
Liked: 546
Quote:
Originally Posted by fhoech View Post

I'd still say don't use it without good reason. The default mode is slightly more accurate as Zoyd had briefly tested. Of course, if you want to play around with it, I'm not stopping you, but as you already get good results you're probably not going to gain anything.
Just to follow up, the one test I did comparing the two gamut mapping modes is shown below. The dotted line is the alternate "PCS-to-device" mode that requires the high resolution tables.

fhoech likes this.
zoyd is online now  
post #3153 of 3164 Unread Yesterday, 12:01 PM
Senior Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 404
Mentioned: 14 Post(s)
Tagged: 0 Thread(s)
Quoted: 151 Post(s)
Liked: 95
Quote:
Originally Posted by Pepelegal View Post
Yes. you're right. I have to try to create one LUT using correction and one without and compare the differences. I find it very odd that the version without correction actually produces better results.
The one without correction just has a blue closer to the rec. 709 blue, doesn't necessarily mean it's better (unless you trust the uncorrected i1D3 readings more than the corrected ones). I undid the correction matrix from the V4 measurements, and the uncorrected V4 gamut is extremely similar in shape to the V3 gamut (dotted line is V3, colored is V4 with correction undone).
Attached Thumbnails
Click image for larger version

Name:	Gamut V4 invcorr vs V3.png
Views:	25
Size:	41.7 KB
ID:	627913  
Pepelegal likes this.

Last edited by fhoech; Yesterday at 12:21 PM. Reason: Wording
fhoech is online now  
post #3154 of 3164 Unread Yesterday, 04:55 PM
Member
 
baii's Avatar
 
Join Date: Jul 2013
Posts: 22
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 10
I find the spectral correction (ccfl or rgb led for my case) for i1d3 only really affect the calibrated target whitepoint only.
If I verify a spectral corrected color profile w.o using a correction,vice versa, I see huge delta e in whitepoint but not in the color test patches.
baii is offline  
post #3155 of 3164 Unread Today, 04:27 AM
Member
 
Join Date: Nov 2014
Posts: 93
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 73 Post(s)
Liked: 3
Yesterday I created a new LUT using the same parameters (with the correction file enabled) with 994 patches but the result was for some reason very bad with lots of artefacts... I ended up deleting it as V3 and V4 created previously were much better.

One situation I'm getting is when the process of creation the LUT ends, it now hangs on the "Generating gamut views" and I need to cancel to close DCG. Sometimes I get the popup to choose to install the 3DLUT (which I always do) and view the profile, but not always.

After the bad result with that LUT, I spent some time doing a full calibration using the 20points controls and aligning the gamma curve for the Wide Gamut option.

I then configured DCG with a new calibration file for the i1d3 and did a profile only (with the same parameters I posted before and that worked well with V3). I choose for test pattern the "Massive Testchart for Rec709" with a small change to just use 80 neutral patches (instead of the default 140) - 2486 total patches.

I choose this large test pattern because I wanted to let it run unmanned overnight, so that was a way to minimize the time the TV is left displaying the last grey pattern until morning.

So, this morning, I found DCG hanged again in the "Generating Gamut Views" (a believe on "iccgamut.exe" command) but no popup to install the 3DLUT (log file ends with that command).

So, because (I believe) I canceled the process (I had no other choice), I don't have the .3DLUT file and I can't check in madVR how were the results. The only information I have of the profile is that peak err = 1.744424, avg err = 0.340880, RMS = 0.403823 which is a bit worse than the previous V3 with peak err = 1.613902, avg err = 0.311188, RMS = 0.383008

The .icm also seems similar to the ones of previous created LUTs.

Here is the link for the V5 project : LINK

Is there any way to generate the 3DLUT using the existing information ?

Thank you,
Pepelegal is online now  
post #3156 of 3164 Unread Today, 04:40 AM
Member
 
Join Date: Nov 2014
Posts: 93
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 73 Post(s)
Liked: 3
I think I found the way to generate the 3DLUT file.
I dropped the .icm on DCG, unchecked the "create 3D LUT after profiling" and clicked on "Create 3D LUT" button.

It's filling the LUT table right now...
Pepelegal is online now  
post #3157 of 3164 Unread Today, 06:14 AM
Senior Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 404
Mentioned: 14 Post(s)
Tagged: 0 Thread(s)
Quoted: 151 Post(s)
Liked: 95
Quote:
Originally Posted by Pepelegal View Post
I then configured DCG with a new calibration file for the i1d3 and did a profile only (with the same parameters I posted before and that worked well with V3). I choose for test pattern the "Massive Testchart for Rec709" with a small change to just use 80 neutral patches (instead of the default 140) - 2486 total patches.
That's a reasoanble way to do it. Just as a note, none of the default testcharts go over 121 grayscale steps, and there's a reason for that too: When using 20% dark region emphasis (like most of the "optimized for ..." patchsets), the maximum number of grayscale steps that'll still round to different RGB levels when quantized to 8 bits is 129 (assuming full range RGB encoding).

Quote:
Originally Posted by Pepelegal View Post
So, this morning, I found DCG hanged again in the "Generating Gamut Views" (a believe on "iccgamut.exe" command) but no popup to install the 3DLUT (log file ends with that command).
Seems like Argyll 1.7b isn't working right on your system (keep in mind it's a personal build of in-development beta code). I'd recommend going back to 1.6.3 for the time being.

Quote:
Originally Posted by Pepelegal View Post
I think I found the way to generate the 3DLUT file.
I dropped the .icm on DCG, unchecked the "create 3D LUT after profiling" and clicked on "Create 3D LUT" button.
Yes, you did this the right way.
fhoech is online now  
post #3158 of 3164 Unread Today, 07:44 AM
AVS Special Member
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 5,380
Mentioned: 57 Post(s)
Tagged: 0 Thread(s)
Quoted: 665 Post(s)
Liked: 546
I ran a profile only sequence using AUTO targets and it worked flawlessly - I'm really impressed with the functionality and performance of DCG. I was interested in how the 154 target preconditioner + auto targen settings performed compared to my typical choices.

Results of previous 2500 patch set using a 2500 patch preconditioning profile:

Code:
% < 1.5% < 1.0
      99.8667      97.6000
dE00 avg,stdev,max,worst 10%
      0.37704436      0.22404800       1.5180518      0.86936644
Grayscale avg,stdev,max
      0.39472615      0.22042243       1.1321318
Red ramp avg,stdev,max
      0.36715921      0.22067996       1.0229049
Green ramp avg,stdev,max
      0.34363367      0.32186486       1.5180518
Blue ramp avg,stdev,max
      0.27777325      0.31259952       1.4135966

Results of AUTO targen with total 2661 patches:

Code:
% < 1.5% < 1.0
      99.8667      97.7333
dE00 avg,stdev,max,worst 10%
      0.36758927      0.22620677       1.5419512      0.86988927
Grayscale avg,stdev,max
      0.42411560      0.23800477       1.0835316
Red ramp avg,stdev,max
      0.38564623      0.20958563       1.1055526
Green ramp avg,stdev,max
      0.36779837      0.19635333      0.75162999
Blue ramp avg,stdev,max
      0.24217088      0.22392966       1.0053001
And the histograms, auto targen in green:



A slight edge to the auto mode. The primary differences with my typical selection is that the auto mode has a higher density of single axis patches (41 vs. 20), higher density of neutral axis (121 vs. 50) and uses a dark region emphasis of 1.6 vs. no emphasis.

If we look at dark region patches [L* < 15] there are also some minor improvements:

Auto mode = green squares
fhoech likes this.
zoyd is online now  
post #3159 of 3164 Unread Today, 08:01 AM
Senior Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 404
Mentioned: 14 Post(s)
Tagged: 0 Thread(s)
Quoted: 151 Post(s)
Liked: 95
Quote:
Originally Posted by zoyd View Post
I ran a profile only sequence using AUTO targets and it worked flawlessly - I'm really impressed with the functionality and performance of DCG. I was interested in how the 154 target preconditioner + auto targen settings performed compared to my typical choices.
Thanks for testing this (and I really appreciate the time and effort you put into these tests ). So it seems my choice of targen and preconditioning parameters work well, atleast on the display tested (I based most of the parameters roughly on what Graeme recommends in his excellent Argyll "Scenarios" guide, aswell as the targen parameters used in the first post of this thread). My hope is that this allows people to tap into the power of Argyll's sophisticated patch generator, with little configuration effort in DCG.

Last edited by fhoech; Today at 08:04 AM.
fhoech is online now  
post #3160 of 3164 Unread Today, 08:20 AM
AVS Special Member
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 5,380
Mentioned: 57 Post(s)
Tagged: 0 Thread(s)
Quoted: 665 Post(s)
Liked: 546
Quote:
Originally Posted by fhoech View Post
My hope is that this allows people to tap into the power of Argyll's sophisticated patch generator, with little configuration effort in DCG.
Well you've done a great job at streamlining the whole process and your behind-the-scenes choices are good ones. Another tidbit out of the last round of testing was a comparison between relative and absolute with white point scaling linking. Even though my display was pre-calibrated to D65 at 100% the -iaw switch performed better.

Relative linking
Code:
% < 1.5% < 1.0
      99.6000      96.0000
dE00 avg,stdev,max,worst 10%
      0.41226702      0.26387419       1.7096775      0.99160210
Grayscale avg,stdev,max
      0.59467771      0.34061948       1.4649735
Red ramp avg,stdev,max
      0.42744775      0.21403045       1.0441158
Green ramp avg,stdev,max
      0.35370066      0.21686359      0.76892840
Blue ramp avg,stdev,max
      0.32615412      0.24309381       1.2243409
Relative in green:
zoyd is online now  
post #3161 of 3164 Unread Today, 08:36 AM
Senior Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 404
Mentioned: 14 Post(s)
Tagged: 0 Thread(s)
Quoted: 151 Post(s)
Liked: 95
Quote:
Originally Posted by zoyd View Post
Even though my display was pre-calibrated to D65 at 100% the -iaw switch performed better.
Interesting. Up to now, I basically went with Graeme's recommendation of relative colorimetric for the defaults in DCG, but with this result, I'm thinking of changing the default to abcol + wtpt scaling. Worst case I can think of right now is it performs as well as relcol, and best case is it performs better like in your case, and I currently can't think of any harm it could do. Will probably change the defaults in the next DCG snapshot update.
Pepelegal likes this.
fhoech is online now  
post #3162 of 3164 Unread Today, 09:36 AM
Member
 
Join Date: Nov 2014
Posts: 93
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 73 Post(s)
Liked: 3
Quote:
Originally Posted by fhoech View Post

That's a reasoanble way to do it. Just as a note, none of the default testcharts go over 121 grayscale steps, and there's a reason for that too: When using 20% dark region emphasis (like most of the "optimized for ..." patchsets), the maximum number of grayscale steps that'll still round to different RGB levels when quantized to 8 bits is 129 (assuming full range RGB encoding).
You're right. It's was my mistake, the original Massive test chart had only 120 patches on neutral, which I reduced to 80.

The maximum number of grayscale steps on 8 bits, shouldn't be 255? I'm sure I'm seeing this wrong, but grayscale is formed by a common value on all R,G and B (ie: 10,10,10 ; 16,16,16 ; 20,20,20 ....so on through 255,255,255). This should get 255 levels of grayscale.

But I guess the 129 has to do with the "20% optimized for"...

Quote:
Originally Posted by fhoech View Post
Seems like Argyll 1.7b isn't working right on your system (keep in mind it's a personal build of in-development beta code). I'd recommend going back to 1.6.3 for the time being.
I know. No problem with that, but I can't use Argyll 1.6.3 because of the problem with madTPG set window size
Pepelegal is online now  
post #3163 of 3164 Unread Today, 09:50 AM
Senior Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 404
Mentioned: 14 Post(s)
Tagged: 0 Thread(s)
Quoted: 151 Post(s)
Liked: 95
Quote:
Originally Posted by Pepelegal View Post
The maximum number of grayscale steps on 8 bits, shouldn't be 255? I'm sure I'm seeing this wrong, but grayscale is formed by a common value on all R,G and B (ie: 10,10,10 ; 16,16,16 ; 20,20,20 ....so on through 255,255,255). This should get 255 levels of grayscale.
There's the achievable number of digital levels, and the distribution of test points along the gray axis. You're right that the max number of achievable (not necessarily discernable, especially near black) digital levels in 8-bit is 255.
But when distributing test points, using dark region emphasis causes compression of the values at the low end (and expansion at the high end). Also, it would probably challenge the repeatability of display + instrument if you would use the full 255 test values along the gray axis even if not using dark region emphasis.

Quote:
Originally Posted by Pepelegal View Post
I know. No problem with that, but I can't use Argyll 1.6.3 because of the problem with madTPG set window size
When using Argyll CMS 1.6.3, it'll only influence patch size if using a perfectly black background in madTPG (because DCG 2.9.x graps the background level off of madTP, and then adds the respective dispcal/dispread -F parameter so the background level can be kept at the user set value). It should help to set background level slightly higher than zero (e.g. 1%) in madTPG before starting DCG.
fhoech is online now  
post #3164 of 3164 Unread Today, 09:59 AM
Member
 
Join Date: Nov 2014
Posts: 93
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 73 Post(s)
Liked: 3
Quote:
Originally Posted by fhoech View Post
There's the achievable number of digital levels, and the distribution of test points along the gray axis. You're right that the max number of achievable (not necessarily discernable, especially near black) digital levels in 8-bit is 255.
But when distributing test points, using dark region emphasis causes compression of the values at the low end (and expansion at the high end). Also, it would probably challenge the repeatability of display + instrument if you would use the full 255 test values along the gray axis even if not using dark region emphasis.
yes, I see your point.

Quote:
Originally Posted by fhoech View Post
When using Argyll CMS 1.6.3, it'll only influence patch size if using a perfectly black background in madTPG (because DCG 2.9.x graps the background level off of madTP, and then adds the respective dispcal/dispread -F parameter so the background level can be kept at the user set value). It should help to set background level slightly higher than zero (e.g. 1%) in madTPG before starting DCG.
Ok, I will try that.

Thank you fhoech
Pepelegal is online now  
Sponsored Links
Advertisement
 
Reply Display Calibration



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