MadVR - ArgyllCMS - Page 10 - AVS Forum
Forum Jump: 
 15Likes
Reply
 
Thread Tools
post #271 of 2412 Old 06-11-2013, 05:04 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by MSL_DK View Post


To be absolutely sure? wink.gif Like this?

GFX: Full RGB
madVR: 0-255
TV: 0-255

dispcal.exe -E
dispread.exe -E
collink.exe -et -Et
No, that won't work. For full range, don't use -E in dispcal and dispread.

You need -e & -E in collink because MadVR is using TV levels - it has nothing to do with what the display etc. are doing.

[ This is all explained in the documentation - see "5) Signal encoding" in the "Creating Video Calibration 3DLuts" section of scenarios.html. ]
gwgill is offline  
Sponsored Links
Advertisement
 
post #272 of 2412 Old 06-11-2013, 05:22 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by berga0d View Post


I'm afraid I poorly explained what I'm experiencing: if I use perceptual or relative mappings (p, pa, r), the picture loses the reds and tends to green. This is normal because both perceptual and relative mappings map the input white point (D65) to my native (terrible) WP. As the projector is the only light source eyes can adapt to it a little after a while, but the problem it's still there.

What I want is to avoid this mapping: I can do this only using the absolute (a) intent. Results are great, all colors are now correct and look exactly the same between a good screen and the projector. However there is a con: brights reds are crushed to max red, because absolute intent clip values outside the output gamut. (Still better than white point mapping).

Is there a way to configure argyll perceptual mapping to smoothly compress the input gamut ignoring white point?

OK, in that case, use displcal to target either D65 (-t 6500) or a compromise white point between D65 and the native white point of your display (using dispcal -w). You could try averaging the x,y of D65 and your native white point as a place to start, although something on the illuminant locus (ie. the closest daylight color temperature of your displays native white point ?) is typically best in terms of ease of adaptation.

Then use one of the white point relative gamut mappings that you are happy with.
gwgill is offline  
post #273 of 2412 Old 06-11-2013, 05:23 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 gwgill View Post

No, the two things are not connected. One is when ArgyllCMS is driving the display, and the other is when MadVR is driving the display.

ArgyllCMS is driving the display when it is creating calibration curves (dispcal) and profiling (dispread). Use -E here if the TV is limited range, and nothing else is doing the conversion.

I just don't see when this would be the case, if my TV is set for limited range it is because the video card is also set for limited range, the two are always in sync to avoid this scenario. Shouldn't both ArgyllCMS and madVR be set so as not to do any scaling of input/output levels when the video card and display are level synchronized? For ArgyllCMS that would mean don't use -E and for madVR I think it means leave output levels set to 0-255 regardless of whether the GPU/display are both 16-235 (preserves btb/wtw) or 0-255 (expanded).


I've verified the following settings work flawlessly in my set-up:

1. Video card and display set to 16-235
2. dispcal and dispread do not use the -E switch
3. collink uses -et and -Et
4. madVR set to 0-255 output

if I set madVR to 16-235 the black level is raised.
zoyd is online now  
post #274 of 2412 Old 06-11-2013, 10:30 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by zoyd View Post

Quote:
Originally Posted by gwgill View Post

Use -E here if the TV is limited range, and nothing else is doing the conversion.

I just don't see when this would be the case, if my TV is set for limited range it is because the video card is also set for limited range, the two are always in sync to avoid this scenario.
Sure, but I can only respond to what I'm told, and the feedback I got was that some people had setups where the full range graphics card output gets fed into a TV range display. The fact that MadVR also includes an allowance for this possibility supports this as a requirement.
Quote:
Shouldn't both ArgyllCMS and madVR be set so as not to do any scaling of input/output levels when the video card and display are level synchronized?
Yes. But these options are for the situation in which this is not the case.
gwgill is offline  
post #275 of 2412 Old 06-11-2013, 11:17 PM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,413
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 108
Quote:
Originally Posted by zoyd View Post

I don't consider the GPU driver setting of 16-235 as "misconfigured"

It is not misconfigured in the sense that you will get proper levels for black & white with this configuration. *However*, if you tell the GPU to output 16-235, it will take madVR's video rendering, stretch it from 0-255 to 16-235 behind madVR's back, and usually will *not* use dithering for this. If you stretch 0-255 to 16-235 in 8bit without using dithering, you'll end up with banding artifacts. Because of that although setting the GPU to 16-235 output may give you correct levels, I still strongly advice against it, for quality reasons.

It is possible that newer GPUs do the stretch in higher bitdepth and then output DeepColor. I've not tested this. But as long as output is 8bit, you'll get banding artifacts for sure. If the output is DeepColor, maybe you'll get lucky, or maybe not...

Quote:
Originally Posted by zoyd View Post

in fact this is forced by some drivers when connect via HDMI.

ATI and Intel usually have a switch, I believe. NVidia does not, but for NVidia madVR ships with a "madNvLevelsTweaker" tool which allows you to force 0-255 output even via HDMI. So as far as I'm aware you can force the GPU to output 0-255 with all ATI, NVidia and Intel GPUs. Of course there might be buggy drivers sometimes which may prevent that, but that's another story...

Quote:
Originally Posted by zoyd View Post

I do however think it's essential that the GPU output levels are matched to the display input levels, otherwise you are asking for big trouble.

The easiest solution is to have *everything* set to 0-255. Then there are no problems, no misunderstands and everything will look correct, without banding problems.

The problem starts if your display doesn't support 0-255. In that case you can either set the GPU itself to 16-235, or you can set madVR to 16-235. If you set the GPU to 16-235, you may get banding artifacts (see above). If you set madVR to 16-235, playback quality with madVR should still be "perfect". However, games, photos, Windows desktop etc will have black crush. If you only use your HTPC for madVR video playback, the latter problem doesn't matter much, so I'd still recommend to set the GPU to 0-255 and madVR to 16-235 in that case. If you need your HTPC for games, photos etc, too, then obviously you're in some sort of trouble.

Quote:
Originally Posted by zoyd View Post

So under that assumption what matters is if madVR does any scaling of either input or output levels. My reading of your comments regarding btb/wtw tells me that you do not scale the input levels but that you assume that black is at level 16 and white is at level 235 and you only do look-up modifications to that range. What do you do with output levels when set for 16-235 or 0-255? If one of those cases means you also don't scale the output then we have an identical usage scenario to the eeColor box which also does no scaling

The eeColor box has a different logic: It doesn't even know/care whether the input/output is TV or PC levels. It's your own responsibility to load the correct 3dlut into the eeColor box, matching the levels you feed in (and get out). madVR is very different in that the 3dlut always has to be video levels and madVR does all necessary adjustments for fullrange vs limited range content, and also for 0-255 or 16-235 output.

In any case, as I said before, all of this trouble will go away, if we use madVR as a test pattern generator. Because in that case dispcal, dispread and HCFR will simply send madVR test pattern values in the 0..1 range (0 = black, 1 = white) and madVR will automatically show the test pattern in the correct output levels, without needing any special switches in dispcal, dispread or HCFR (as long as your GPU and madVR levels settings are setup correctly before starting calibration/profiling). However, if you set madVR to 0-255 and your GPU to 16-235, this may once again result in banding problems. Meaning testpatterns will have the correct black/white levels, but since the GPU stretches them from 0-255 to 16-235 with a very simple algorithm, the test pattern color might not be as exact as you'd like. This might actually result in accuracy problems for the calibration.

P.S: This is a problem you might be facing today: If you have your GPU set to 16-235, your test patterns (regardless of which software is creating/showing them) might be inaccurate because the GPU is stretching them without dithering. For example if you show a test pattern with PC levels 4,4,4 the correct TV levels output would be 19.435,19.435,19.435. The GPU will likely round this down to 19,19,19. So the meter will measure 19,19,19 instead of 19.435,19.435,19.435. This will introduce accuracy problems into your measurements. If you set your GPU to 0..255 and madVR to 16-235, madVR will actually output 19.435,19.435,19.435 (by use of dithering).
zoyd likes this.
madshi is online now  
post #276 of 2412 Old 06-12-2013, 12:21 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 gwgill View Post

No, that won't work. For full range, don't use -E in dispcal and dispread.

You need -e & -E in collink because MadVR is using TV levels - it has nothing to do with what the display etc. are doing.

[ This is all explained in the documentation - see "5) Signal encoding" in the "Creating Video Calibration 3DLuts" section of scenarios.html. ]

Like this?

collink.exe -eX -Et

It's a great documentation you have molded together, but there's a lot of reading on a hot summer day smile.gif

I am somewhat confused as to collink and -e -E, due to your example here:
Quote:
MadVR

V 0.66+ of MadVR converts from the media colorspace to the 3dLut input space automatically with the type of source being played. Satisfactory results can probably be obtained by building just a Rec709 HD 3dLut, but purists will want to build 3dLut's optimized for each different type of source, and manually select between the 3dLut as needed:

collink -v -3m -et -Et -Ib -G -ir Rec709.icm TV.icm HD.icm
MSL_DK is offline  
post #277 of 2412 Old 06-12-2013, 12:26 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,413
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 108
What makes you think you should use "-eX -Et"? You should use "-et -Et".
madshi is online now  
post #278 of 2412 Old 06-12-2013, 12:32 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 madshi View Post

What makes you think you should use "-eX -Et"? You should use "-et -Et".

Due to this in collink ... I am somewhat confused ;-)
Code:
The -e flag applies a Video encoding to the input. See below and -E for the list of encodings.

     x                xvYCC Rec601 YCbCr Rec709 Prims. SD (16-235,240)/255 "TV" levels
     X                xvYCC Rec709 YCbCr Rec709 Prims. HD (16-235,240)/255 "TV" levels

When xvYCC is chosen, the encoding is either a Rec601 YCbCr or Rec709 YCbCr with extended range Cb and Cr values, and a hard coded Rec709 source colorspace, corresponding to the xvYCC specifications. The source profile provided to collink is used to define the source gamut for gamut mapping, and also the space that any BT.1886 processing will be performed in. For instance, if the xvYCC is being used to encode a larger gamut such as UHD Rec2020, or Digital Cinema SMPTE431, then the corresponding ICC profile should be provided as the source profile.

The -E flag applies a Video encoding to the output. The possible encoding are:

     n                normal RGB 0..1 full range levels (default)
     t                RGB (16-235)/255 "TV" levels
     6                Rec601 YCbCr SD (16-235,240)/255 "TV" levels
     7                Rec709 1125/60Hz YCbCr HD (16-235,240)/255 "TV" levels
     5                Rec709 1250/50Hz YCbCr HD (16-235,240)/255 "TV" levels
     2                Rec2020 YCbCr UHD (16-235,240)/255 "TV" levels
     C                Rec2020 Constant Luminance YCbCr UHD (16-235,240)/255 "TV" levels
MSL_DK is offline  
post #279 of 2412 Old 06-12-2013, 01:09 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 gwgill View Post

That looks right for a full range output system. Can you be more specific about what the problem is ?

I can try ... When I add "dispwin.exe SAM.cal" I get images without contrast and too bright. If I instead install "sam.icm" it looks better.

When I write too bright and without contrast, it is not just a little but a lot. It looks terrible.
MSL_DK is offline  
post #280 of 2412 Old 06-12-2013, 04: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 madshi View Post

It is not misconfigured in the sense that you will get proper levels for black & white with this configuration. *However*, if you tell the GPU to output 16-235, it will take madVR's video rendering, stretch it from 0-255 to 16-235 behind madVR's back, and usually will *not* use dithering for this. If you stretch 0-255 to 16-235 in 8bit without using dithering, you'll end up with banding artifacts. Because of that although setting the GPU to 16-235 output may give you correct levels, I still strongly advice against it, for quality reasons.

It is possible that newer GPUs do the stretch in higher bitdepth and then output DeepColor. I've not tested this. But as long as output is 8bit, you'll get banding artifacts for sure. If the output is DeepColor, maybe you'll get lucky, or maybe not...
ATI and Intel usually have a switch, I believe. NVidia does not, but for NVidia madVR ships with a "madNvLevelsTweaker" tool which allows you to force 0-255 output even via HDMI. So as far as I'm aware you can force the GPU to output 0-255 with all ATI, NVidia and Intel GPUs. Of course there might be buggy drivers sometimes which may prevent that, but that's another story...
The easiest solution is to have *everything* set to 0-255. Then there are no problems, no misunderstands and everything will look correct, without banding problems.

Thanks for that great explanation, I'm "on the same page" now. My video processor is an Intel HD Graphics 3000 and does have the limited/full-range switch but always outputs 16-235 regardless of it's setting. I'll try the tweaker to see if I can force full range.
zoyd is online now  
post #281 of 2412 Old 06-12-2013, 04:40 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by MSL_DK View Post


Like this?

collink.exe -eX -Et
You wouldn't use -eX with MadVR, since it sends RGB into the 3dLUT.
Quote:

I am somewhat confused as to collink and -e -E, due to your example here:
Quote:
MadVR

V 0.66+ of MadVR converts from the media colorspace to the 3dLut input space automatically with the type of source being played. Satisfactory results can probably be obtained by building just a Rec709 HD 3dLut, but purists will want to build 3dLut's optimized for each different type of source, and manually select between the 3dLut as needed:

collink -v -3m -et -Et -Ib -G -ir Rec709.icm TV.icm HD.icm

You'll have to be more specific about what you find confusing about it, because it works as stated.
gwgill is offline  
post #282 of 2412 Old 06-12-2013, 04:43 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by MSL_DK View Post

Due to this in collink ... I am somewhat confused ;-)
Code:
The -e flag applies a Video encoding to the input. See below and -E for the list of encodings.

Note it says "see below and -E.." so x, X, n, t, 6, 7, 5, 2, c" are options for -e, while "n, t, 6, 7, 5, 2, c" are options for -E.
gwgill is offline  
post #283 of 2412 Old 06-12-2013, 04:44 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by MSL_DK View Post


I can try ... When I add "dispwin.exe SAM.cal" I get images without contrast and too bright. If I instead install "sam.icm" it looks better.

When I write too bright and without contrast, it is not just a little but a lot. It looks terrible.
I'd have to be able to take a look at the various files involved to figure out what's going on.
gwgill is offline  
post #284 of 2412 Old 06-12-2013, 05:13 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 gwgill View Post

I'd have to be able to take a look at the various files involved to figure out what's going on.

here you go
MSL_DK is offline  
post #285 of 2412 Old 06-12-2013, 05:28 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,413
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 108
Quote:
Originally Posted by zoyd View Post

My video processor is an Intel HD Graphics 3000 and does have the limited/full-range switch but always outputs 16-235 regardless of it's setting. I'll try the tweaker to see if I can force full range.

The tweaker definitely only works for NVidia because it sets an NVidia specific registry value.

I've heard that with some Intel drivers the levels switch works, but it's labeled wrong, so the "0-255" option gives you 16-235 in reality and the "16-235" option gives you 0-255. Have you tried that? Are you already on the latest driver?
madshi is online now  
post #286 of 2412 Old 06-12-2013, 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 madshi View Post

The tweaker definitely only works for NVidia because it sets an NVidia specific registry value.

I've heard that with some Intel drivers the levels switch works, but it's labeled wrong, so the "0-255" option gives you 16-235 in reality and the "16-235" option gives you 0-255. Have you tried that? Are you already on the latest driver?


Will try to update the driver because it's definitely stuck on TV level output. So to clarify how madVR handles the cLUT, do you apply node point 0 to input level 16 and node point 256 to input level 235 thereby leaving 0-15 and 236-255 alone?
zoyd is online now  
post #287 of 2412 Old 06-12-2013, 08:58 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,413
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 108
No, the 3dlut has black at 16 and white at 235. So madVR feeds black at 16 and white at 235 into the 3dlut. Both 3dlut input and output are video levels (16-235). Nevertheless the 3dlut has a dimension of 0-255, for proper BTB/WTW handling. Meaning that BTB and WTW are running through the 3dlut just fine and should stay undamaged. Which would not be possible with a PC levels 3dlut.
madshi is online now  
post #288 of 2412 Old 06-12-2013, 09:07 AM
Member
 
cfelicio's Avatar
 
Join Date: Jul 2011
Posts: 88
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by madshi View Post

No, the 3dlut has black at 16 and white at 235. So madVR feeds black at 16 and white at 235 into the 3dlut. Both 3dlut input and output are video levels (16-235). Nevertheless the 3dlut has a dimension of 0-255, for proper BTB/WTW handling. Meaning that BTB and WTW are running through the 3dlut just fine and should stay undamaged. Which would not be possible with a PC levels 3dlut.

But at the same time, that means these levels are not calibrated properly? I ask because when I tried to do a calibration only using the 3dlut (my display temp was around 7100k), and I ran the AVSHD Contrast Pattern (showing WTW), since my 255 was not calibrated, it was still showing at 7100K, while the rest was at the calibrated D65 (around 6500k), thus making me believe it was incorrect, but in reality everything had a yellow cast as the point of reference was 7100k.

In real life this should not be a problem as no movie will be displaying 255, but I ended up pre-calibrating my TV to 6500k using HCFR to avoid the issue with the test patterns.

Shouldn't be better to have the whole 0-255 covered by the 3dlut? Or would it cause more banding? I'm no expert, but curious about this! smile.gif
cfelicio is offline  
post #289 of 2412 Old 06-12-2013, 10:45 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,413
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 108
Quote:
Originally Posted by cfelicio View Post

But at the same time, that means these levels are not calibrated properly? I ask because when I tried to do a calibration only using the 3dlut (my display temp was around 7100k), and I ran the AVSHD Contrast Pattern (showing WTW), since my 255 was not calibrated, it was still showing at 7100K, while the rest was at the calibrated D65 (around 6500k), thus making me believe it was incorrect, but in reality everything had a yellow cast as the point of reference was 7100k.

In real life this should not be a problem as no movie will be displaying 255, but I ended up pre-calibrating my TV to 6500k using HCFR to avoid the issue with the test patterns.

Shouldn't be better to have the whole 0-255 covered by the 3dlut? Or would it cause more banding? I'm no expert, but curious about this! smile.gif

That's a question for Graeme.

I'm wondering, though, why your display shows WTW in the first place? It should normally be set so that BTB & WTW is not visible. Although there is some debate going on about whether WTW should be clipped completely or only partially.
madshi is online now  
post #290 of 2412 Old 06-12-2013, 10: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

That's a question for Graeme.

I'm wondering, though, why your display shows WTW in the first place? It should normally be set so that BTB & WTW is not visible. Although there is some debate going on about whether WTW should be clipped completely or only partially.

On my display with RGB input, WTW/BTB is always clipped even with full range input. The only way to get BTB/WTW is with YCbCr input and in that case I calibrate to clip BTB at 16 of course and allow up to about 240 on the other end. Many display's gray scale will fall apart if you push contrast so hard that it clips at 235.
zoyd is online now  
post #291 of 2412 Old 06-12-2013, 11:35 AM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by cfelicio View Post

test patterns.

Shouldn't be better to have the whole 0-255 covered by the 3dlut? Or would it cause more banding? I'm no expert, but curious about this! smile.gif
0 and 255 are reserved for sync., so they have to be passed through unchanged. No properly encoded digital signal should fall outside 16-235.

The color correction is only defined over the device range (16-235 in the case of TV encoded), so there is no definition of how to map outside that range anyway. To extend it to 0 and 255 would mean extrapolating in some way. From my experience with scanner and camera profiling, such extrapolation is rather unreliable.

Driving a TV encoded display to 0 and 255 and expecting to figure out what the set is doing with those signals in all cases, is also asking a lot. They have a perfect right to sulk, and not display anything at all, because they are being fed sync. at times that don't correspond to the non-image area !
gwgill is offline  
post #292 of 2412 Old 06-12-2013, 11:51 AM
Member
 
cfelicio's Avatar
 
Join Date: Jul 2011
Posts: 88
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by gwgill View Post

0 and 255 are reserved for sync., so they have to be passed through unchanged. No properly encoded digital signal should fall outside 16-235.

The color correction is only defined over the device range (16-235 in the case of TV encoded), so there is no definition of how to map outside that range anyway. To extend it to 0 and 255 would mean extrapolating in some way. From my experience with scanner and camera profiling, such extrapolation is rather unreliable.

Driving a TV encoded display to 0 and 255 and expecting to figure out what the set is doing with those signals in all cases, is also asking a lot. They have a perfect right to sulk, and not display anything at all, because they are being fed sync. at times that don't correspond to the non-image area !

Thanks for the explanation. I think the color cast is just a minor thing, and after I pre-calibrated my display to be closer to D65, it was not an issue anymore :-)
cfelicio is offline  
post #293 of 2412 Old 06-12-2013, 01:37 PM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,413
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 108
Quote:
Originally Posted by gwgill View Post

0 and 255 are reserved for sync

We're talking about digital RGB transport via HDMI here. When using fullrange, 0 is black and 255 is white, so these values *can't* be used as sync. If they aren't used as sync with RGB fullrange, then I doubt they're used for sync with RGB video levels. At least it wouldn't make any sense to me.

Quote:
Originally Posted by gwgill View Post

No properly encoded digital signal should fall outside 16-235.

In theory that's right. But in real life that's not always the case. Many DVDs and Blu-Rays after YCbCr -> RGB conversion end up with data slightly below BTB or slightly above WTW once in a while. This can be caused by scaling / edge enhancement during encoding. Or it can also easily be caused by chroma upscaling in the playback chain. There was a longer thread here in the forum talking about this. The thread also mentioned that while DVDs and Blu-Rays usually seem to stay near to the 16-235 range, TV broadcasts *sometimes* go up to 250 or so.
madshi is online now  
post #294 of 2412 Old 06-12-2013, 03:05 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


In theory that's right. But in real life that's not always the case. Many DVDs and Blu-Rays after YCbCr -> RGB conversion end up with data slightly below BTB or slightly above WTW once in a while. This can be caused by scaling / edge enhancement during encoding. Or it can also easily be caused by chroma upscaling in the playback chain. There was a longer thread here in the forum talking about this. The thread also mentioned that while DVDs and Blu-Rays usually seem to stay near to the 16-235 range, TV broadcasts *sometimes* go up to 250 or so.

You can actually test this and I've done so by loading dummy values like [.9,.9,0] at level [240,240,240] in the eeColor and indeed some blown out sports broadcasts with white uniforms will contain purple pixels (YCbCr only). It's of dubious value to me to allow these values through without clipping but current generation digital displays are set-up to do it anyway. Adjusting contrast such that one channel doesn't clip before another usually ends up allowing for discrete values up to 254 to be visible in test patterns.
zoyd is online now  
post #295 of 2412 Old 06-12-2013, 04:39 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by madshi View Post

We're talking about digital RGB transport via HDMI here. When using fullrange, 0 is black and 255 is white, so these values *can't* be used as sync. If they aren't used as sync with RGB fullrange, then I doubt they're used for sync with RGB video levels. At least it wouldn't make any sense to me.
Be that as it may, the video encoding standards reserve these values for sync, even for xvYCC.
Quote:
In theory that's right. But in real life that's not always the case. Many DVDs and Blu-Rays after YCbCr -> RGB conversion end up with data slightly below BTB or slightly above WTW once in a while. This can be caused by scaling / edge enhancement during encoding. Or it can also easily be caused by chroma upscaling in the playback chain. There was a longer thread here in the forum talking about this. The thread also mentioned that while DVDs and Blu-Rays usually seem to stay near to the 16-235 range, TV broadcasts *sometimes* go up to 250 or so.
They are outside specification, and take the risk that various transmission, storage and display systems may modify or throw those values away.
gwgill is offline  
post #296 of 2412 Old 06-12-2013, 04:58 PM
Advanced Member
 
gwgill's Avatar
 
Join Date: Jan 2013
Location: Melbourne, Australia
Posts: 542
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 68
Quote:
Originally Posted by gwgill View Post


The color correction is only defined over the device range (16-235 in the case of TV encoded), so there is no definition of how to map outside that range anyway. To extend it to 0 and 255 would mean extrapolating in some way. From my experience with scanner and camera profiling, such extrapolation is rather unreliable.
The other option is to change it to clip out of range values, and only map the very end cLUT values 1:1. I'm rather tempted to do that, since the output will then be far more predictable and color managed for most of the out of range input.
gwgill is offline  
post #297 of 2412 Old 06-12-2013, 05:56 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 zoyd View Post



I've verified the following settings work flawlessly in my set-up:

1. Video card and display set to 16-235
2. dispcal and dispread do not use the -E switch
3. collink uses -et and -Et
4. madVR set to 0-255 output

Two configurations appear to give identical results and the correct black point mapping for video card and display set to limited range RGB:

As above with
collink -et -Et
madVR set to 0-255 output

and

collink -et -En
madVR set to 16-235 output

Unfortunately I can't test the video card at full range because the driver won't allow it. After updating the Intel HD driver the option to switch ranges was removed.
zoyd is online now  
post #298 of 2412 Old 06-12-2013, 11:23 PM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,413
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 108
Quote:
Originally Posted by gwgill View Post

Be that as it may, the video encoding standards reserve these values for sync, even for xvYCC.

Which encoding standard is that? I've just searched the h264 spec for "sync" and then for "255" and I can't find anything related to this.

Quote:
Originally Posted by gwgill View Post

The other option is to change it to clip out of range values, and only map the very end cLUT values 1:1. I'm rather tempted to do that, since the output will then be far more predictable and color managed for most of the out of range input.

If you decide to implement clipping, could you please add an option to turn clipping off? Thanks!
madshi is online now  
post #299 of 2412 Old 06-13-2013, 03:36 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
The display needs something to sync on so 0 (blanking) is reserved for horizontal sync and 255 (sync) is reserved for vertical, independent of the transport encoding.

Also, for my display and probably many others, preserving BTB/WTW in the RGB flow is actually incorrect because the display compresses full range RGB back to limited prior to display (it actually goes back to YCbCr internally and then limited RGB for display). WTW, if it exists, can only be properly displayed when transported in YCbCr to the display.
zoyd is online now  
post #300 of 2412 Old 06-13-2013, 03:39 AM
AVS Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,413
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 13 Post(s)
Liked: 108
Then please tell me how fullrange RGB transport works where 0 is clearly black?
madshi 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