eeColor processor - ArgyllCMS - Page 7 - AVS Forum
Forum Jump: 
 3Likes
Reply
 
Thread Tools
post #181 of 296 Old 05-04-2014, 03:42 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,446
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 312
Quote:
Originally Posted by heyskip View Post

Zoyd, and others

What settings would I need to change in your workflow if I wanted to use Ycbcr4:4:4 in my device chain. I have Nvidia Titan -> DVDO Duo -> eeColour -> Pioneer 600m.

No changes needed.
Quote:
Also what is the best way to stop the black level being altered by the lut. I have started removing the 4 black patches from my patch sets and that seems to improve it. Is there anything else I can do.

This might be due to your probe reading 0 for black, the next version of ArgyllCMS will allow user entered black levels which might help.
Quote:
Im also a little confused about the lut to eecolour transfer process. When do you need to transfer the files

first1dred.txt
first1dgreen.txt
first1dblue.txt
second1dred.txt
second1dgreen.txt
second1dblue.txt

I take it they are only needed when using RGB 0-255 end to end in your device chain. Or is there other instances where they will be required. And do you have to rename the created files ie. 3DLUT_2-first1dblue.txt to be the same as above and replace them or do you leave the name and copy them to the "default" folder so you can have different files for each lut slot.

yes, only needed if the eecolor will see 0-255 levels and you name them exactly as above, first rename the original in the default folder for safekeeping.
Quote:
Concerning gamma, is there any way to enter a value for display black level. When measured with the iD3 it results in 0 and this would change the BT1886 curve.

Next version.
Quote:
Should I calibrate the video card as you mentioned in OP or should I leave it. The luts I produce will be used to correct a few sources so what would be the best approach in this instance.

Test the video card output against your dvd player and DUO (if you can) and if they are all consistent with each other, say below 1 dE then you don't have to worry about it. If there are large differences then you have to decide how to proceed based on those results.
zoyd is online now  
Sponsored Links
Advertisement
 
post #182 of 296 Old 05-04-2014, 02:01 PM
Member
 
heyskip's Avatar
 
Join Date: Jan 2008
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Thanks for the info zoyd. I will have another crack at it tonight.
heyskip is online now  
post #183 of 296 Old 05-04-2014, 10:46 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 586
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 42 Post(s)
Liked: 74
Quote:
Originally Posted by DrFaxe View Post

but I have a question too. I wanted to set a delay before the patch reading to allow the display to stabilize.
Argyll set automatically a delay of 280ms which is too short,
How do you know this is too short ?
For an i1d3 or i1pro this delay is the measured update delay + a margin.
Quote:
so I used the
set ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=700
command to get 0.7s delay. But argyll still use automatic mode for the deleay.
How did you determine it wasn't using 700msec ?
gwgill is online now  
post #184 of 296 Old 05-05-2014, 02:23 AM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Quote:
Originally Posted by gwgill View Post

How do you know this is too short ?
For an i1d3 or i1pro this delay is the measured update delay + a margin.

As my display (Panasonic VT60 Plasma) suffers a little of IR respectively afterglow I found a 0.7s delay does not contaminate the readings.
With a shorter delay (<0.5s) the readings at the end of long profiling sessions are a little off. At least I found this with other software solutions.

Quote:
Originally Posted by gwgill View Post

How did you determine it wasn't using 700msec ?

After I used the "set ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=700" command and started dispread the feedback from the software showed following:
"Measured display update delay of xx msec, using delay of 280 msec". I just expected something like "using delay of 700 msec".

This was my first try with argyll and I followed straight Zoyd's workflow.
Really appreciate Your comments and help.

Thanks!!
DrFaxe is offline  
post #185 of 296 Old 05-05-2014, 04:07 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 586
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 42 Post(s)
Liked: 74
Quote:
Originally Posted by DrFaxe View Post

As my display (Panasonic VT60 Plasma) suffers a little of IR respectively afterglow I found a 0.7s delay does not contaminate the readings.
With a shorter delay (<0.5s) the readings at the end of long profiling sessions are a little off. At least I found this with other software solutions.
From feedback from Zoyd I added an exponential settling time delay that depends on the change in RGB values to make some allowance for that effect (that's why targen sorts the values to minimize any extra delay). It may not be long enough for your Plasma I suppose, but it might be worth your while to run two small measurement sets, one using the default delay, and the second using a 1 second delay, and check the delta E between them, just to see if any extra delay is necessary.
Quote:
After I used the "set ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=700" command and started dispread the feedback from the software showed following:
"Measured display update delay of xx msec, using delay of 280 msec". I just expected something like "using delay of 700 msec".
Hmm. There is one message if diagnostic level 2 is turned on (-D2), and I will add another if the measured delay gets overridden by the minumum delay, but the best way to check with the current version would be to set a very large value (say 10000 msec) so that it is obvious (ie. I expect that the ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS override is working.)
gwgill is online now  
post #186 of 296 Old 05-05-2014, 04:54 AM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Quote:
Originally Posted by gwgill View Post

From feedback from Zoyd I added an exponential settling time delay that depends on the change in RGB values to make some allowance for that effect (that's why targen sorts the values to minimize any extra delay). It may not be long enough for your Plasma I suppose, but it might be worth your while to run two small measurement sets, one using the default delay, and the second using a 1 second delay, and check the delta E between them, just to see if any extra delay is necessary.

that's what I did with the other software solution, changed the delay, compared the results and found 0.7s a sweet spot for my display.
But the patch sets from targen are more plasma friendly as it cycles dark / light quite well. Maybe I can reduce the delay further.
So I repeat the tests with argyll comparing the default delay to several fixed delays.

Quote:
Originally Posted by gwgill View Post

Hmm. There is one message if diagnostic level 2 is turned on (-D2), and I will add another if the measured delay gets overridden by the minumum delay, but the best way to check with the current version would be to set a very large value (say 10000 msec) so that it is obvious (ie. I expect that the ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS override is working.)

good point. Will check the delay setting with the large value. Thanks.

BTW: How can I set the delay back to automatic mode? "set ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=auto" ? can't find this in the documentation.
DrFaxe is offline  
post #187 of 296 Old 05-05-2014, 06:19 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 586
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 42 Post(s)
Liked: 74
Quote:
Originally Posted by DrFaxe View Post

BTW: How can I set the delay back to automatic mode? "set ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=auto" ? can't find this in the documentation.
On MSWin CMD "set ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=". On UNIX like shells, "unset ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS"
gwgill is online now  
post #188 of 296 Old 05-05-2014, 06:40 AM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Quote:
Originally Posted by gwgill View Post

On MSWin CMD "set ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=". On UNIX like shells, "unset ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS"

Thank You, Sir! Windows system here.

As a Plasma owner I'm very interested how the drift compensation works. Is it based on the readings of the 100% white patches only?
Could You please roughly explain how this is working.
DrFaxe is offline  
post #189 of 296 Old 05-05-2014, 08:17 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 586
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 42 Post(s)
Liked: 74
Quote:
Originally Posted by DrFaxe View Post

As a Plasma owner I'm very interested how the drift compensation works. Is it based on the readings of the 100% white patches only?
Could You please roughly explain how this is working.

Black compensation is intended to assist for instruments that have poor black stability, such as the i1pro Rev A-D. It works on the assumption that in such cases the display black stability is better than the instruments.

White compensation was intended to address the problem of LCD backlight drift. It works on the assumption that since the backlight is filtered by the LCD, any change in backlight level has a proportionate effect on all display levels. That this is of some benefit for Plasma displays is interesting.

Both types of compensation work by periodically inserting extra black and/or white test patches during the measurement sequence, the values then being used to adjust the surrounding measurement values. Naturally this increases the overall measurement time, particularly when dark patches are added.

If you're using a meter with good black stability (such as the i1d3), then I would suspect that black compensation would be of little benefit.

Both types of compensation bring risks of making some situations worse, so should only be used when they are of benefit.
gwgill is online now  
post #190 of 296 Old 05-05-2014, 08:47 AM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Thanks a lot for the explanation.
Quote:
Originally Posted by gwgill View Post

White compensation was intended to address the problem of LCD backlight drift. It works on the assumption that since the backlight is filtered by the LCD, any change in backlight level has a proportionate effect on all display levels. That this is of some benefit for Plasma displays is interesting.

Well, to be honest I yet don't know if the white compensation is a benefit for plasma, but I tend to believe Zoyd in this point, as his guide shows following:

Quote:
Originally Posted by zoyd View Post

dispread -v -d2 -yr -E -X d3.ccmx -Iw display
[measures targets from .ti1 file and writes .ti3 file]

-E Output video levels (needed when video card is full range but display expects limited range) otherwise remove
-Iw White drift compensation (useful for plasma panel fatigue)

and he also showed the drift of the VT60. Looking at the graph, it only can get better. smile.gif


Quote:
Originally Posted by gwgill View Post

Both types of compensation work by periodically inserting extra black and/or white test patches during the measurement sequence, the values then being used to adjust the surrounding measurement values. Naturally this increases the overall measurement time, particularly when dark patches are added.

I have noticed that targen distribute the white patches not even. Would it not be useful for best white compensation performance to distribute the white patches even in the set?

e.g. patch set with 1000 patches and 5 white patches. So for ideal the white patches should be at # 1, 250, 500, 750, 1000.
DrFaxe is offline  
post #191 of 296 Old 05-05-2014, 09:34 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,446
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 312
Quote:
Originally Posted by DrFaxe View Post

Thanks a lot for the explanation.
Well, to be honest I yet don't know if the white compensation is a benefit for plasma, but I tend to believe Zoyd in this point, as his guide shows following:
and he also showed the drift of the VT60.

I can't claim it's universally true for all plasmas, but it has improved the profile repeatability and colprof statistics on the two I've had access to data with (Samsung and Panny VT60). The -Iw switch will inject white measurements in addition to the profile patches at fixed intervals (I don't know what the interval is though).
zoyd is online now  
post #192 of 296 Old 05-05-2014, 11:15 AM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Thanks for clarification, Zoyd. Sounds promising for my display.
DrFaxe is offline  
post #193 of 296 Old 05-05-2014, 03:29 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 586
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 42 Post(s)
Liked: 74
Quote:
Originally Posted by zoyd View Post

(I don't know what the interval is though).
Typically every 40 patches.
gwgill is online now  
post #194 of 296 Old 05-07-2014, 02:38 AM
Member
 
heyskip's Avatar
 
Join Date: Jan 2008
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I think what was throwing me before was what is shown in this screenshot.



Am I right in thinking the madVR TPG background should be black when set to 0%. Nvidia settings set to YCbCr444 and madVR TPG set to 16-235. If I set it to 0-255 its black but that doesn't seem right and messes up my luts.

In the meantime ive been using the default DispcalGUI TPG and that seems to work really well once I set the patch size up. The background is definately black with that TPG when using the same settings as shown above.

Are there any important advantages to using madVR TPG over the default one. And is the behavior in the picture normal.
heyskip is online now  
post #195 of 296 Old 05-07-2014, 03:33 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,446
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 312
Quote:
Originally Posted by heyskip View Post

I think what was throwing me before was what is shown in this screenshot.

Am I right in thinking the madVR TPG background should be black when set to 0%. Nvidia settings set to YCbCr444 and madVR TPG set to 16-235. If I set it to 0-255 its black but that doesn't seem right and messes up my luts.

In the meantime ive been using the default DispcalGUI TPG and that seems to work really well once I set the patch size up. The background is definately black with that TPG when using the same settings as shown above.

Are there any important advantages to using madVR TPG over the default one. And is the behavior in the picture normal.

The video card is scaling in YCC mode so you need to send it 0-255. The advantage of madTPG is being able to set background level (for plasma) and you get madVR's dithering which is needed if you have a < 8 bit display.
zoyd is online now  
post #196 of 296 Old 05-07-2014, 07:21 AM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Quote:
Originally Posted by gwgill View Post

Hmm. There is one message if diagnostic level 2 is turned on (-D2), and I will add another if the measured delay gets overridden by the minumum delay, but the best way to check with the current version would be to set a very large value (say 10000 msec) so that it is obvious (ie. I expect that the ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS override is working.)

to give a feedback, I've tested the delay with a large value and it is working, no matter if dispread still indicates from the feedback that it is using auto mode.

Quote:
Originally Posted by zoyd View Post

The -Iw switch will inject white measurements in addition to the profile patches at fixed intervals (I don't know what the interval is though).

Did some further testings with and without the -Iw switch. I can clearly see that white patches are introduced in addition every ~40 patches. Shouldn't I find the results of these extra white patches in the .ti3 file? I used a set of 500 patches and both .ti3 files (with and without -Iw switch) contain 500 results.
DrFaxe is offline  
post #197 of 296 Old 05-07-2014, 07:30 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 586
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 42 Post(s)
Liked: 74
Quote:
Originally Posted by DrFaxe View Post

I can clearly see that white patches are introduced in addition every ~40 patches. Shouldn't I find the results of these extra white patches in the .ti3 file?

Definitely not - they are inserted by the measurement process, and the results then used by the measurement process to correct the other readings.

The extra white patches aren't in the data set being measured.
gwgill is online now  
post #198 of 296 Old 05-07-2014, 10:11 AM
AVS Special Member
 
sillysally's Avatar
 
Join Date: Jun 2006
Location: Chicago
Posts: 3,712
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 72 Post(s)
Liked: 262
Quote:
Originally Posted by zoyd View Post

The video card is scaling in YCC mode so you need to send it 0-255. The advantage of madTPG is being able to set background level (for plasma) and you get madVR's dithering which is needed if you have a < 8 bit display.

When using the PC for pattern generation to the display via HDMI, using 4:4:4. Are you saying to set the video card to 0-255 (PC) rather than 16-235:(Video). ??

In my case I am using LS.

ss
sillysally is offline  
post #199 of 296 Old 05-07-2014, 10:18 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,446
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 312
Quote:
Originally Posted by sillysally View Post

When using the PC for pattern generation to the display via HDMI, using 4:4:4. Are you saying to set the video card to 0-255 (PC) rather than 16-235:(Video). ??

In my case I am using LS.

ss

No, the case I was referring to was a video card which has a YCC out capability in which scaling to video levels is done by the card. In this case the software pattern generator has to send PC levels otherwise you get double scaling.
zoyd is online now  
post #200 of 296 Old 05-07-2014, 11:11 AM
AVS Special Member
 
sillysally's Avatar
 
Join Date: Jun 2006
Location: Chicago
Posts: 3,712
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 72 Post(s)
Liked: 262
Quote:
Originally Posted by zoyd View Post

No, the case I was referring to was a video card which has a YCC out capability in which scaling to video levels is done by the card. In this case the software pattern generator has to send PC levels otherwise you get double scaling.

I also have a nvidia video card that shows the same setup window as above. So yes my video card also has YCC capability.
You probably know that LS also video scales when you make a LUT from the profile before sending to eecolor. I was using YCC but that screwed up my profiles and showed they were already video scaled when I convert them.

btw, is there anyway to pre set the window size when I drag and drop the window from my laptap to my display. ?
I have to re-size the pattern window, like you would re-size a window on your desktop.

ss
sillysally is offline  
post #201 of 296 Old 05-07-2014, 11:43 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,446
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 312
Quote:
Originally Posted by sillysally View Post

I also have a nvidia video card that shows the same setup window as above. So yes my video card also has YCC capability.
You probably know that LS also video scales when you make a LUT from the profile before sending to eecolor. I was using YCC but that screwed up my profiles and showed they were already video scaled when I convert them.

I don't trust my video card to get the RGB->YCC conversion correct so I run all my Argyll LUTs with the HDMI out on the video card set to RGB 0-255 (pass-through).
zoyd is online now  
post #202 of 296 Old 05-07-2014, 08:38 PM
Member
 
heyskip's Avatar
 
Join Date: Jan 2008
Posts: 26
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Ok, so even though I've been trying to educate myself on this, I'm now thoroughly confused.

If I set MadTPG to RGB 0-255 -> Nvidia to RGB 0-255 -> DVDO Duo to output YCbCr4:4:4 . This should work correctly?

If I set MadTPG to RGB 0-255 -> Nvidia to YCbCr4:4:4 -> DVDO Duo to output YCbCr4:4:4 . This should also work correctly but has the GPU doing the conversion (not desirable)

With the eecolour box after the Duo is it seeing 16-235 or 0-255 levels?

I thought YCbCr444 was limited to 16-235 and to avoid errors this would have to be maintained throughout the chain. Is this where I am going wrong.
heyskip is online now  
post #203 of 296 Old 05-08-2014, 01:38 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,443
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 37 Post(s)
Liked: 116
Output levels (PC vs. TV) is a notoriously difficult problem with HTPCs. Yes, YCbCr output is almost always 16-235, so by letting your GPU output YCbCr, at least the desktop and normal Windows applications should have correct levels. If you setup the video renderer to output 0-255 video playback should have correct levels, too. However, this setup results in everyone (including video rendering) to render in RGB, and the GPU driver/hardware will as the very last step convert the final RGB output to YCbCr behind the back of Windows. To my best knowledge most GPUs do the RGB -> YCbCr conversion without using dithering, which is a very low quality conversion and can/will result in a quality loss, maybe even a significant one, but I haven't seen any hard numbers about that yet.

PCs usually "think" in RGB. Everything is rendered that way. All applications, even video renderers usually end up in RGB at some point. And that's "ok", as long as all the conversions are done correctly and with appropriate dithering. IMHO you'll get the best quality by letting your HTPC output RGB. Whether you aim for 0-255 or 16-235 RGB output is your own choice. Both is possible and both should work just fine. If you want your HTPC to output 0-255, everything is relatively simple: You configure the GPU to RGB 0-255, and set madVR to 0-255, too. You may have to *force* your GPU to do 0-255. For that madVR comes with a "madLevelsTweaker" tool which can force 0-255 RGB output for NVidia and Intel GPUs, when using HDMI out. AMD users have an option for this in the GPU control panel. If you want your HTPC to output 16-235, there are 2 ways to achieve that:

(1) Configure the GPU to output 16-235 RGB. Tell madVR to do 0-255. This has the advantage that everything (desktop, Windows application, video rendering) has the proper 16-235 output levels. But again the conversion is done by the GPU behind the back of Windows, usually without using dithering. So this is usually a low quality setup.
(2) Configure the GPU to output 0-255 RGB. Tell madVR to output 16-235. This way all conversions are done by madVR with highest quality dithering. The disadvantage of this solution is that you get 16-235 levels for video playback, but 0-255 levels for the desktop and applications. Which may bother you or not, depending on whether you use the HTPC only for video playback or also for other things.

Because both of these options (1) and (2) have their own disadvantages, I usually recommend to let your HTPC output 0-255 RGB. This delivers high quality and correct levels for both video playback and desktop/applications.


All of the above just decides what your HTPC outputs. What the DVDO Duo and the eeColor box do with that, I cannot answer. Maybe someone else can.
madshi is offline  
post #204 of 296 Old 05-08-2014, 02:32 AM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Hello,

the graphics card output discussion brings up some questions on my side too.

All my video devices are set to YCbCr444 and TV input to limited. Video chain is: source -> HDMI matrix -> eeColor -> TV
As a pattern generator I use the Intel HD3000 graphics card of my computer.

According to Zoyd and madshi the most accurate setup for the graphics card is RGB 0-255.

To verify if the graphics card out matches to my BD player using HCFR, I have to set the pattern generator of HCFR to 16-235. Doing this I compare RGB 16-235 with YCbCr444.
Will this be valid? As this is no apple to apple comparison.

When using argyll for profiling and as a pattern generator I have to use the -E switch for dispread, that argyll scales to 16-235. So basicly the same question, will the profile performed with RGB 16-235 work for my video devices with YCbCr444?

Any advices for my setup?


@Graeme
thanks for the explanation, now I understand how the drift compensation is working.
DrFaxe is offline  
post #205 of 296 Old 05-08-2014, 11:59 AM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,446
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 312
Quote:
Originally Posted by heyskip View Post

Ok, so even though I've been trying to educate myself on this, I'm now thoroughly confused.

If I set MadTPG to RGB 0-255 -> Nvidia to RGB 0-255 -> DVDO Duo to output YCbCr4:4:4 . This should work correctly?

If I set MadTPG to RGB 0-255 -> Nvidia to YCbCr4:4:4 -> DVDO Duo to output YCbCr4:4:4 . This should also work correctly but has the GPU doing the conversion (not desirable)

That's right, both configurations can be used for profiling but the first is preferred to avoid any scaling at the video card.
Quote:
With the eecolour box after the Duo is it seeing 16-235 or 0-255 levels?

The eecolor sees all levels but 0-15 are below black and 236-254 are above white (255 is sync) in this configuration.
Quote:
I thought YCbCr444 was limited to 16-235 and to avoid errors this would have to be maintained throughout the chain. Is this where I am going wrong.

No, YCC only sets black at 16 and white at 235, the other levels are still allowed. If in the above flow (Nvidia to RGB 0-255) you playback material with madVR set to 16-235 you will preserve btb and wtw through the system.
Quote:
Originally Posted by madshi View Post

All of the above just decides what your HTPC outputs. What the DVDO Duo and the eeColor box do with that, I cannot answer. Maybe someone else can.

The eecolor does not do any scaling, that's why after you profile you must use the -et -Et switches to scale the results into the 16-235 range if you want to use it for YCC playback. That scaling has to be done no matter what your profiling flow looks like.
Quote:
Originally Posted by DrFaxe View Post

Hello,

the graphics card output discussion brings up some questions on my side too.

All my video devices are set to YCbCr444 and TV input to limited. Video chain is: source -> HDMI matrix -> eeColor -> TV
As a pattern generator I use the Intel HD3000 graphics card of my computer.

According to Zoyd and madshi the most accurate setup for the graphics card is RGB 0-255.

To verify if the graphics card out matches to my BD player using HCFR, I have to set the pattern generator of HCFR to 16-235. Doing this I compare RGB 16-235 with YCbCr444.
Will this be valid? As this is no apple to apple comparison.

When using argyll for profiling and as a pattern generator I have to use the -E switch for dispread, that argyll scales to 16-235. So basicly the same question, will the profile performed with RGB 16-235 work for my video devices with YCbCr444?

Yes, as long as you have the black and white points set correctly in your profiling flow it doesn't matter how many conversions are done and where. The results are always scaled to right range for use in the eecolor. You still have to verify if YCC playback from your primary source (BD for example) matches colorimetrically the RGB (or YCC) output of your video card using test patterns but that's a different issue.
zoyd is online now  
post #206 of 296 Old 05-09-2014, 02:53 PM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Quote:
Originally Posted by gwgill View Post

From feedback from Zoyd I added an exponential settling time delay that depends on the change in RGB values to make some allowance for that effect (that's why targen sorts the values to minimize any extra delay). It may not be long enough for your Plasma I suppose, but it might be worth your while to run two small measurement sets, one using the default delay, and the second using a 1 second delay, and check the delta E between them, just to see if any extra delay is necessary.

I spend hours of reading and testing to figure out how to get a delta E report from a .ti3 file to verify if readings are stable respectively delay is OK, but without success.
Could You please provide informations how to do that?
DrFaxe is offline  
post #207 of 296 Old 05-09-2014, 03:43 PM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,446
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 312
A good indication of the stability of a test set are the statistics that colprof generates when fitting the profile. This can be checked after the fact with:

Code:
profcheck -k measures.ti3 measures.icm

If the avg and stdev of the fit is < 1 then the test set is probably stable. Outliers will show up as a max value that is significantly larger than 3x stdev + avg.
DrFaxe likes this.
zoyd is online now  
post #208 of 296 Old 05-09-2014, 05:28 PM
Member
 
DrFaxe's Avatar
 
Join Date: Nov 2012
Posts: 192
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 76
Thanks a lot for the infos and especially for Your patience.

I already saw this after generating the icm profile. So with max=4.8, avg=0.195 and RMS= 0.315 I can assume the readings to be stable.
But I would be interested too how many outliers the set contains and where they are located. I'm wondering if there is an option to show a more detailed statistic, something like the measurement report of dispcalgui, which shows the dE of each patch.
DrFaxe is offline  
post #209 of 296 Old 05-09-2014, 05:34 PM - Thread Starter
AVS Special Member
 
zoyd's Avatar
 
Join Date: Sep 2006
Location: Planet Dog
Posts: 4,446
Mentioned: 9 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 312
zoyd is online now  
post #210 of 296 Old 05-10-2014, 01:08 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 586
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 42 Post(s)
Liked: 74
Quote:
Originally Posted by DrFaxe View Post


I spend hours of reading and testing to figure out how to get a delta E report from a .ti3 file to verify if readings are stable respectively delay is OK, but without success.
Could You please provide informations how to do that?

Simply run colverify on the two .ti3 files. See here for details, and here for an example.
DrFaxe likes this.
gwgill 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