MadVR - ArgyllCMS - Page 52 - AVS Forum
Forum Jump: 
 15Likes
Reply
 
Thread Tools
post #1531 of 2421 Old 03-01-2014, 11:03 AM
Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 159
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 22 Post(s)
Liked: 32
Slightly offtopic, but I have always admired the smooth gamut mapping provided by the Argyll created 3D LUTs, which I never could quite achieve using a "normal" XYZLUT display profile.
So I wondered, could a similar methodology as employed by Argyll's collink (generating the 3D LUT gamut mapping by inverting the display profile A2B "device to PCS" tables) be used to generate a similar result with a regular ICC profile workflow? The answer seems to be "yes" smile.gif

Basically I've implemented A2B table inversion using xicclu, and added that functionality to dispcalGUI. In the latest development snapshot, you'll notice a new checkbox "Smooth B2A tables" along with a selector for the cLUT table size, as well as a new menu item in the options menu to re-generate the B2A table of existing profiles. It will only re-generate the colorimetric B2A table, and not touch any perceptual or saturation mapping you may have chosen for profile creation.
This seems to improve the smoothness of the colorimetric B2A gamut mapping quite a bit. I've added an example to the changelog in the snapshot ReadMe.

I've started to use 0install ("Zero Install") to roll out development snapshots, and added a wiki page with a how-to for people interested in trying it out. Comments welcome smile.gif
fhoech is offline  
Sponsored Links
Advertisement
 
post #1532 of 2421 Old 03-02-2014, 01:31 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
@Graeme,

there seems to be a problem with WTW (and possibly BTB) handling. Basically it seems that in some cases ArgyllCMS extrapolates the calibration in such a way that some WTW colors are moved back into the visible/valid range. This then results in WTW bars still being visible in WTW test patterns, even if the display is setup to hide WTW. I think this is not an easy problem to solve, though, because some users might want some WTW data to still be visible, so extrapolating the calibration to the WTW area does make some sense. However, the normal/usual configuration is to have WTW hidden from view, so I think there might have to be an option for ArgyllCMS which defines how to handle WTW data. E.g. like this:

(1) Calibrate WTW data, too.

In this case ArgyllCMS should apply calibration to WTW data, by extrapolating the calibration. And probably we want the gamma response to be continuous, so probably a side effect of this option would be that some WTW colors could potentially be moved back into the valid range.

(2) "Clip" WTW data.

I guess there are 2 ways to do this. The simple way would be to do a straight 1:1 passthrough for all BTB & WTW pixels. The more complicated way would be to still extrapolate the calibration, so that BTB & WTW are calibrated, too. However, ArgyllCMS would have to make sure that all BTB/WTW pixels stay BTB/WTW. This could become difficult, especially if you want to have different values for every color (no flat areas). So I guess maybe the simple passthrough solution would be preferred? I'm not sure how to treat pixels which are "partially" in the WTW area, though. E.g. an RGB pixel [230, 240, 230]. What to do with that pixel?

I think no user wants BTB to be visible. So probably a straight 1:1 passthrough should always be used for BTB. No extrapolation of the calibration needed here. But for WTW the situation is different. Some calibrators like to leave at least a part of WTW visible.

Thoughts?
madshi is offline  
post #1533 of 2421 Old 03-02-2014, 03:59 AM
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

@Graeme,


(1) Calibrate WTW data, too.

In this case ArgyllCMS should apply calibration to WTW data, by extrapolating the calibration. And probably we want the gamma response to be continuous, so probably a side effect of this option would be that some WTW colors could potentially be moved back into the valid range.

Could you also directly include this region in the process by allowing test points up to 254,254,254 in conjunction with the -E switch?
zoyd is online now  
post #1534 of 2421 Old 03-03-2014, 04:18 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 544
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by madshi View Post

@Graeme,

there seems to be a problem with WTW (and possibly BTB) handling. Basically it seems that in some cases ArgyllCMS extrapolates the calibration in such a way that some WTW colors are moved back into the visible/valid range. This then results in WTW bars still being visible in WTW test patterns, even if the display is setup to hide WTW.
Can you mail me an example ? ie. .ti3 file + collink options.

Any value over the 235/255 should stay over 235/255 after passing through the cLUT, and any value less than 16/255 stays less than 16/255.

It's always possible I've got a bug though.
Quote:
I think this is not an easy problem to solve, though, because some users might want some WTW data to still be visible, so extrapolating the calibration to the WTW area does make some sense. However, the normal/usual configuration is to have WTW hidden from view, so I think there might have to be an option for ArgyllCMS which defines how to handle WTW data.
The current handling was in direct response to user requests to extrapolate the mapping beyond white. Prior to that it used to linearly interpolate from the encoding limit to 255/255
Quote:
E.g. like this:

(1) Calibrate WTW data, too.

In this case ArgyllCMS should apply calibration to WTW data, by extrapolating the calibration. And probably we want the gamma response to be continuous, so probably a side effect of this option would be that some WTW colors could potentially be moved back into the valid range.
That's what currently happens. I don't think that any values will go back into their visible range once above/below the encoding limit.
Quote:
(2) "Clip" WTW data.

I guess there are 2 ways to do this. The simple way would be to do a straight 1:1 passthrough for all BTB & WTW pixels. The more complicated way would be to still extrapolate the calibration, so that BTB & WTW are calibrated, too. However, ArgyllCMS would have to make sure that all BTB/WTW pixels stay BTB/WTW. This could become difficult, especially if you want to have different values for every color (no flat areas). So I guess maybe the simple passthrough solution would be preferred? I'm not sure how to treat pixels which are "partially" in the WTW area, though. E.g. an RGB pixel [230, 240, 230]. What to do with that pixel?
I think by definition, if you clip it's got to be per component, just like with extrapolation, it's per component. That's because the encoding limits are per component.
Quote:

I think no user wants BTB to be visible. So probably a straight 1:1 passthrough should always be used for BTB. No extrapolation of the calibration needed here.
It really shouldn't make much difference, although I think that extrapolating leaves less room for surprises, since we're talking about sparse interpolated cLUT grids, and you can't always manage thing so that the encoding limit lands exactly on a grid point.
gwgill is offline  
post #1535 of 2421 Old 03-03-2014, 04:35 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
@Graeme,

thanks for looking into this. My post was a reaction to this user report in the doom9 madVR forum thread:

http://forum.doom9.org/showpost.php?p=1671430&postcount=24165

There's a RAR download link in that post which contains several files. I'm not sure if all the files you need are in there. If not, please let me know, then I'll ask the user to provide the missing information. Here's the direct RAR download link:

https://dl.dropboxusercontent.com/u/93831976/Yellow%20Bars.rar
madshi is offline  
post #1536 of 2421 Old 03-03-2014, 05:00 AM
AVS Special Member
 
Elix's Avatar
 
Join Date: Jun 2011
Location: Dungeon, Pillar of Eyes
Posts: 1,161
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 23
Quote:
Originally Posted by fhoech View Post

I've started to use 0install ("Zero Install") to roll out development snapshots, and added a wiki page with a how-to for people interested in trying it out. Comments welcome smile.gif
Florian, you're the man! This new algorithm produced the best 3DLUT yet for my color-deficient DLP projector (Optoma GT760). The picture now is so smoooooth! I will post some graphs and pictures later but for now I just wanted to say - thanks! That inversed B2A method works great.

Oh, and 0install is nice too.

P.S. Of course credit also goes to Graeme.
Elix is offline  
post #1537 of 2421 Old 03-03-2014, 05:52 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 544
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by madshi View Post

@Graeme,

thanks for looking into this. My post was a reaction to this user report in the doom9 madVR forum thread:

http://forum.doom9.org/showpost.php?p=1671430&postcount=24165
Ah yes, Mister MonarchX, who doesn't seem to appreciate help.
Quote:
There's a RAR download link in that post which contains several files. I'm not sure if all the files you need are in there. If not, please let me know, then I'll ask the user to provide the missing information. Here's the direct RAR download link:

https://dl.dropboxusercontent.com/u/93831976/Yellow%20Bars.rar

Nope, no .ti3, no linking details, no point investigating the end result when I can't see how it was arrived at.
gwgill is offline  
post #1538 of 2421 Old 03-03-2014, 06:31 AM
Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 159
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 22 Post(s)
Liked: 32
Quote:
Originally Posted by Elix View Post

Florian, you're the man! This new algorithm produced the best 3DLUT yet for my color-deficient DLP projector (Optoma GT760). The picture now is so smoooooth!

Hmm. I'm doubting it's because of my change, which shouldn't affect 3D LUT creation at all smile.gif If it does, it may be a bug that I should fix.
Quote:
Oh, and 0install is nice too.
I like it because it makes it very easy for me to release development snapshots - it's just one archive I need to create, and two XML files I need to change (and that can even be automated).
fhoech is offline  
post #1539 of 2421 Old 03-03-2014, 07:07 AM
Newbie
 
Asmodian's Avatar
 
Join Date: Mar 2014
Posts: 6
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10

I am actually having a very similar problem with the collink option "-a" vs "-H".

 

If I apply the .cal file with -a I get yellowish whites (vs 255) up to 252.  If I use -H everything looks perfect.  This is using madVR in windowed or full screen exclusive mode, Nvidia GTX Titan, LED IPS (Overlord X270OC), and an i1display pro.

 

Here is the collection of files (.ti3 etc) I used and got along with the batch file I ran:

 

noLUT.7z

The 3DLUT incase you want it.

 

Please let me know if you need anything else.

 

I didn't notice this at first because I usually use madVR in overlay mode which I understand clips brighter than white in this situation.  I would be very grateful if could take a look, having Argyllcms + madVR is wonderful for my HTPC. :)

Asmodian is offline  
post #1540 of 2421 Old 03-03-2014, 07:31 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 gwgill View Post

no .ti3, no linking details, no point investigating the end result when I can't see how it was arrived at.

You can find the details in Asmodian's post (one above this), he has the same problem.
madshi is offline  
post #1541 of 2421 Old 03-03-2014, 08:22 AM
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 Asmodian View Post

I am actually having a very similar problem with the collink option "-a" vs "-H".

One thing I notice in your nolut measurements is that you have a very high white level (250 cd/m^2) and that the blue channel luminance has very poor scaling. I suspect this has something to do with the appearance of yellow, which is essentially blue clipping, in your wtw range.

zoyd is online now  
post #1542 of 2421 Old 03-03-2014, 08:39 AM
Newbie
 
Asmodian's Avatar
 
Join Date: Mar 2014
Posts: 6
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10

I see, so it is not really an issue, it is only that color correction breaks down above white?  This makes sense as it is not possible to increase blue to go whiter than white with a correct white.  I suppose the ramps included by -H are clipping whiter than white?

 

Thanks :)

Asmodian is offline  
post #1543 of 2421 Old 03-03-2014, 08:48 AM
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 Asmodian View Post

I see, so it is not really an issue, it is only that color correction breaks down above white?  This makes sense as it is not possible to increase blue to go whiter than white with a correct white.  I suppose the ramps included by -H are clipping whiter than white?

Thanks smile.gif

Yes, I suspect it is a display limitation and not the 3DLUT, but I don't know why -a gives different wtw behavior vs. -H.
zoyd is online now  
post #1544 of 2421 Old 03-03-2014, 09:08 AM
Newbie
 
Asmodian's Avatar
 
Join Date: Mar 2014
Posts: 6
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10

Actually I think -H has to clip wtw.  If desktop 255:255:255 white is my correct white point then there is no way for madVR to output any color wtw.  I see how it is a feature to allow wtw display when using only a 3DLUT, only on my display it goes so yellow it looks odd.

Asmodian is offline  
post #1545 of 2421 Old 03-03-2014, 09:20 AM
Senior Member
 
mightyhuhn's Avatar
 
Join Date: Nov 2013
Posts: 343
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 73 Post(s)
Liked: 47

i get "pink" bars up to 237 on 3-whiteClipping.mp4.my display got a white point of d6500 0.2 - 0.3 delta before calibration with 280 cm^2.

 

does this mean my calibration is not working or is this a display limitation too?

mightyhuhn is offline  
post #1546 of 2421 Old 03-03-2014, 09:25 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 zoyd View Post

Yes, I suspect it is a display limitation and not the 3DLUT

I don't think so. Let's look at some numbers:

WTW test pattern, bar 240:

encoded YCbCr value: F0 80 80 -> 240 128 128
TV RGB without 3dlut: F0 F0 F0 -> 240 240 240
TV RGB Asmodian 3dlut: F0 E9 D9 -> 240 233 217

So it's pretty clear that the white bar 240, which before 3dlut processing is completely (all 3 components) in the WTW area, after 3dlut processing moves back into the visible range, and very noticeably so. This is clearly not as intended and needs to be fixed, IMHO.
madshi is offline  
post #1547 of 2421 Old 03-03-2014, 12:13 PM
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

I don't think so. Let's look at some numbers:

WTW test pattern, bar 240:

encoded YCbCr value: F0 80 80 -> 240 128 128
TV RGB without 3dlut: F0 F0 F0 -> 240 240 240
TV RGB Asmodian 3dlut: F0 E9 D9 -> 240 233 217

So it's pretty clear that the white bar 240, which before 3dlut processing is completely (all 3 components) in the WTW area, after 3dlut processing moves back into the visible range, and very noticeably so. This is clearly not as intended and needs to be fixed, IMHO.

I think something about the native behavior of the display's blue channel causes the extrapolation to fail and generate that 217 which will cause a 240,240,240 input to look yellow. It doesn't move anything back into the visible range, it just gets the wrong correction for that input. Extrapolation may not be a good idea if this type of thing is common.

edit:

I should have read Graeme's response above where he states output values should not range below wtw if they start out above, so that does appear to be unintended regardless of what's going on with display native response.
zoyd is online now  
post #1548 of 2421 Old 03-04-2014, 11:44 AM
AVS Special Member
 
Elix's Avatar
 
Join Date: Jun 2011
Location: Dungeon, Pillar of Eyes
Posts: 1,161
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 23
Quote:
Originally Posted by fhoech View Post

Hmm. I'm doubting it's because of my change, which shouldn't affect 3D LUT creation at all smile.gif
Yes, you must be right. I might've done everything right this time is all.

My Optoma GT760 is quite color-deficient:


Yet 3DLUT-corrected images look very good. Greens are fixed especially well. On the comparison photos I made you can clearly see that: http://screenshotcomparison.com/comparison/65322/picture:4

One thing though, my gamma is a little bit low: 2.12 average. I chose BT1886 absolute gamma during calibration.


I have a question. If I haven't done calibrate & profile but just profile, can I make a calibration curve out of that profile curve above?
Elix is offline  
post #1549 of 2421 Old 03-05-2014, 05:17 PM
Newbie
 
Asmodian's Avatar
 
Join Date: Mar 2014
Posts: 6
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by madshi View Post


I don't think so. Let's look at some numbers:

WTW test pattern, bar 240:

encoded YCbCr value: F0 80 80 -> 240 128 128
TV RGB without 3dlut: F0 F0 F0 -> 240 240 240
TV RGB Asmodian 3dlut: F0 E9 D9 -> 240 233 217

So it's pretty clear that the white bar 240, which before 3dlut processing is completely (all 3 components) in the WTW area, after 3dlut processing moves back into the visible range, and very noticeably so. This is clearly not as intended and needs to be fixed, IMHO.

I have been thinking about this issue some more and I was wondering what encoded YCbCr value: EB 80 80 -> 235 128 128 looked like after my "TV RGB Asmodian 3dlut"?  If all values were less than 240, 233, 217 wouldn't that mean 240 233 217 was actually outside visible range if I was clipping wtw?

 

Maybe there really isn't anything to improve and an option to clip wtw/btb when using a TV range 3DLUT would be helpful for those of us with displays whose native behavior is bad enough extrapolated wtw display looks funny?

 

Edit: Though I have been using a similar 3DLUT (collink -a) with the new madVR (v0.87.5) for a bit now and because none of my content has much in the way of wtw I am happy with the way it is now.  At least as far as I can tell, I will leave it to others better able to tell if something unintended is going on with wtw display. :o 

Asmodian is offline  
post #1550 of 2421 Old 03-06-2014, 12:16 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
Quote:
Originally Posted by Asmodian View Post

I have been thinking about this issue some more and I was wondering what encoded YCbCr value: EB 80 80 -> 235 128 128 looked like after my "TV RGB Asmodian 3dlut"?  If all values were less than 240, 233, 217 wouldn't that mean 240 233 217 was actually outside visible range if I was clipping wtw?

I don't think so. But let's wait for Graeme to analyze this.
madshi is offline  
post #1551 of 2421 Old 03-06-2014, 12:23 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
The latest madVR build v0.87.6 now offers several dithering algorithms. Older builds used random dithering, which worked alright, but was quite noisy. The new build now has several options. However, for single-colored test patterns "ordered dithering" seems to work best, so that is what madTPG will always use now. Which means that it doesn't matter which dithering algorithm you select in the madVR settings, madTPG will overwrite your choice and always use ordered dithering. There are however 2 additional options which affect every algorithm and madTPG will honor your wishes for these 2 options:

(1) "use colored noise": Using multi-colored noise means that the noise will use more shades of different colors to achieve a smoother result. This option lowers luma noise but slightly increases chroma noise.

(2) "change dither for every frame": This option results in madVR/TPG using a different dither pattern for every rendered video frame, which means that the dither dots are dancing around quite a bit. Enabling this option hides the dither pattern nicely, but results in some temporal noise.

Now it would be great if you guys could run a few tests to find out how these options should ideally be set for madTPG. Maybe if we can find a clearly best option set, I can enforce those for madTPG, to protect users from using suboptimal options. Feedback welcome!
ConnecTEDDD likes this.
madshi is offline  
post #1552 of 2421 Old 03-07-2014, 12:08 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Is there someone who can tell what is happening with cyan and yellow? Cyan is way off with 3DLUT

.chc files for HCFR is attached.

Workflow
Code:
targen -v -d3 -G -e4 -B8 -g40 -s20 -f2500 -V1.3 -N0.75 -c C:\Argyll_V1.6.3\ref\Rec709.icm mvr
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss mvr
colprof -v -qh -bl -ax mvr
collink -v -qh -3m -et -Et -G -IB -ia -w  C:\Argyll_V1.6.3\ref\rec709.icm mvr.icm 3DLUT_madVR.icm

Argyll ti1 + ti3 + icm
ti1ti3icm.zip 406k .zip file

Without 3DLUT (Pattern Intensity 75%)
75_u_3dlut.zip 3k .zip file



Without 3DLUT (Pattern Intensity 100%)
100_u_3dlut.zip 3k .zip file



With 3DLUT (Pattern Intensity 75%)
75.zip 3k .zip file



With 3DLUT (Pattern Intensity 100%)
100.zip 3k .zip file

Attached Files
File Type: zip 75_u_3dlut.zip (3.2 KB, 2 views)
File Type: zip 100_u_3dlut.zip (3.2 KB, 2 views)
File Type: zip 75.zip (3.2 KB, 2 views)
File Type: zip 100.zip (3.2 KB, 4 views)
File Type: zip ti1ti3icm.zip (405.7 KB, 2 views)
MSL_DK is offline  
post #1553 of 2421 Old 03-07-2014, 02:27 PM
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
You seem to have an uncooperative gamut, I would give it one more try but use your measured profile (mvr.icm) to precondition and up the patch count to 3k or 4k.
zoyd is online now  
post #1554 of 2421 Old 03-07-2014, 09:32 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 544
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by MSL_DK View Post

Is there someone who can tell what is happening with cyan and yellow? Cyan is way off with 3DLUT
From the look of it you aren't actually using the 3DLut. The plots look almost identical.
gwgill is offline  
post #1555 of 2421 Old 03-08-2014, 03:30 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by zoyd View Post

You seem to have an uncooperative gamut, I would give it one more try but use your measured profile (mvr.icm) to precondition and up the patch count to 3k or 4k.

Like this?
Code:
targen -v -d3 -G -e4 -B8 -g40 -s20 -f4000 -V1.3 -N0.75 -c C:\Argyll_V1.6.3\ref\Rec709.icm mvr_PASS_1
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss mvr_PASS_1
colprof -v -qh -bl -ax mvr_PASS_1

targen -v -d3 -G -e4 -B8 -g40 -s20 -f4000 -V1.3 -N0.75 -c mvr_PASS_1.icm mvr_PASS_2
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss mvr_PASS_2
colprof -v -qh -bl -ax mvr_PASS_2
collink -v -qh -3m -et -Et -G -IB -ia -w  C:\Argyll_V1.6.3\ref\rec709.icm mvr_PASS_2.icm 3DLUT_madVR.icm

Quote:
Originally Posted by gwgill View Post

From the look of it you aren't actually using the 3DLut. The plots look almost identical.

How this?

With 3DLUT




Without 3DLUT

MSL_DK is offline  
post #1556 of 2421 Old 03-08-2014, 03:40 AM
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 MSL_DK View Post

Like this?

You can skip step 1 and just use your prior mvr.icm in step 2.
Code:

targen -v -d3 -G -e4 -B8 -g40 -s20 -f4000 -V1.3 -N0.75 -c mvr.icm mvr_PASS_2
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss mvr_PASS_2
colprof -v -qh -bl -ax mvr_PASS_2
collink -v -qh -3m -et -Et -G -IB -ia -w  C:\Argyll_V1.6.3\ref\rec709.icm mvr_PASS_2.icm 3DLUT_madVR.icm
zoyd is online now  
post #1557 of 2421 Old 03-08-2014, 04:04 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by zoyd View Post

You can skip step 1 and just use your prior mvr.icm in step 2.
Code:

targen -v -d3 -G -e4 -B8 -g40 -s20 -f4000 -V1.3 -N0.75 -c mvr.icm mvr_PASS_2
dispread -v -dmadvr -c1 -Yp -yn -X WLEDFamily_07Feb11.ccss mvr_PASS_2
colprof -v -qh -bl -ax mvr_PASS_2
collink -v -qh -3m -et -Et -G -IB -ia -w  C:\Argyll_V1.6.3\ref\rec709.icm mvr_PASS_2.icm 3DLUT_madVR.icm

Thanks a lot. i'll give it a try tonight.

But i think i have to start over and set my samsung to native instead of auto. I don't quite understand what that setting does relative to profiling with argyll.
MSL_DK is offline  
post #1558 of 2421 Old 03-08-2014, 04:07 AM
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 MSL_DK View Post

Thanks a lot. i'll give it a try tonight.

But i think i have to start over and set my samsung to native instead of auto. I don't quite understand what that setting does relative to profiling with argyll.

Use native, it gives you a larger volume to work with. You do not need 4000 patches to do the first run, 1500 would be fine.
zoyd is online now  
post #1559 of 2421 Old 03-08-2014, 06:42 AM
Member
 
MSL_DK's Avatar
 
Join Date: Nov 2011
Location: Denmark
Posts: 116
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by zoyd View Post

Use native, it gives you a larger volume to work with. You do not need 4000 patches to do the first run, 1500 would be fine.

Ok. I think i have misunderstood native versus auto ... I thought this were wider (auto)




Than this (native)




Another thing ... looking on the gamma plot, would it be better to calibrate to 20% and 80% than 20% and 100% and profile, or does it have no effect on gamma?

Using your recommendation i get this result



MSL_DK is offline  
post #1560 of 2421 Old 03-08-2014, 07:05 AM
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 MSL_DK View Post

Ok. I think i have misunderstood native versus auto ... I thought this were wider (auto)

Usually it's the other way around but you are right, your green primary in auto is more saturated than native.
Quote:
Another thing ... looking on the gamma plot, would it be better to calibrate to 20% and 80% than 20% and 100% and profile, or does it have no effect on gamma?

no, stick to 100% for white balance calibration, gamma is adjusted through the linking process.
Quote:
Using your recommendation i get this result

Looks better. smile.gif
zoyd is online now  
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