View Full Version : FAQ: How to correct luminance levels
clsid
23rd December 2008, 17:38
Wrong levels is a common playback problem. It is a subject that gets discussed over and over again. The purpose of this topic is to centralize the collective knowledge of the Doom9 community regarding this subject. Everyone please share you knowledge. I'll update the information below to include your wisdom.
What are luminance levels?
Digital video is typically encoded in a YUV (http://msdn.microsoft.com/en-us/library/bb530104(VS.85).aspx) format. YUV is a family of color spaces (YV12, YUY2, etc), that encode color information (chroma) separately from brightness information (luma).
There are two standards for the encoding of luma. For standard-definition TV the standard is BT.601. For high-definition TV the standard is BT.709.
Luma values fall in a range. Unfortunately this range is not always the same. There are two commonly used ranges: 0-255 (aka PC levels) and 16-235 (aka TV levels).
When converting a YUV colorspace to RGB, the correct standard (BT.601 or BT.709) must be used and the correct range (TV or PC levels) must be used.
The above is not always done correctly. It can go wrong with certain combinations of video renderers, video resolutions, and graphics driver settings.
How can I see if the level is wrong?
The video looks washed out and the colors are not vivid. Black is displayed as dark gray. White is displayed as light gray.
The opposite is also possible, but more rare. In that case dark colors are displayed too dark, and light colors are displayed too bright.
Which combinations give wrong levels?
Many factors play a role, so it is not possible to give a list of combinations that always gives wrong levels for everyone. In general, just trust your eyes.
Levels are usually wrong when using the VMR-9 or EVR CP renderers. For most people only when playing low resolution videos.
How can I correct the levels?
The methods below assume that you are outputting the video to a PC monitor or LCD TV, meaning a device that needs full range luminance (0-255). If you are using a CRT TV, then read the comments at methods 2 and 3.
Method #1: Adjusting graphics driver settings
NVIDIA
Since version 177.84, the NVIDIA drivers have an option for configuring the luma range.
You can find the option here:
NVIDIA Control Panel -> Video & Television -> Adjust video color settings -> Select "With the NVIDIA settings" -> Advanced tab -> Set Dynamic Range to "Full (0-255)".
screenshot (http://img254.imageshack.us/img254/5002/sshot1pr2.jpg)
ATI
The ATI driver requires a Registry tweak. With the tweak applied, the driver will convert TV levels to PC levels for SD resolution video. It already does that by default for HD video.
Several ATI driver tweaks can be found here:
http://www.avsforum.com/avs-vb/showpost.php?p=11622510&postcount=2011
Te UseBT601CSC setting is the one related to luminance levels.
Note: the tweak only works with driver version 9.1 and older. ATI removed it in 9.2 and newer.
Method #2: Convert to RGB32 with ffdshow
Forcing ffdshow to output RGB32 can help prevent luminance level issues. Downside of this method is that doing this conversion in software increases CPU usage.
To force RGB32 output in ffdshow, you should uncheck all colorspaces except RGB32 on the Output page in ffdshow configuration. It is also recommended to enable "High quality YV12 to RGB conversion".
There are additional options on the RGB conversion page. Recent versions of ffdshow will automatically use the correct settings, so you don't need to worry about them.
If you are outputting to a CRT TV or projector (or any other device that expects TV levels as input), then you need to adjust the setting under Output levels on the RGB conversion page. It is configured by default to output to a computer monitor. LCD TVs usually expect PC levels, just like a computer monitor. Some TVs have an option to choose between Full and Reduced range.
Tip: the Profiles/Presets feature in ffdshow can be used to create different sets of settings. You can even auto-load profiles based on conditions like resolution of video format. You could for example create a profile specifically for HD resolution video, and use the 'standard' profile for low resolution videos.
Method #3: Levels filter in ffdshow video decoder
ffdshow has a special filter for adjusting (luminance) levels. To correct wrong luminance levels for a PC monitor or LCD TV you usually need to convert to PC levels. To correct wrong levels for a CRT TV, you usually need to convert to TV levels.
To convert from TV levels to PC levels use 16-235 as input range and 0-255 as output range. To convert from PC levels to TV levels use 0-255 as input range and 16-235 as output range.
Method #4: Pixelshader in Media Player Classic
A pixelshader is a small program that runs on your graphics card and processes some graphic data. In this case each frame of your video.
Media Player Classic has a special pixelshader called "16-235 -> 0-255" for converting TV levels to PC levels. This shader only adjusts luma values.
There also is a shader called "BT.601 -> BT.709". That one adjusts chroma values.
Some requirements for the pixelshaders in MPC:
- You need to use a compatible video renderer: VMR-7 (renderless), VMR-9 (renderless), or EVR Custom Presenter.
- Surface setting must be set to "3D surfaces".
- It requires some DirectX components that are not included with a default Windows installation. Run the DirectX Web Installer (http://www.microsoft.com/downloads/details.aspx?FamilyId=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displaylang=en) to get the required DirectX updates.
Method #5: Use AviSynth script in ffdshow video decoder
Adjusting levels or conversion to RGB32 can also be done though an AviSynth script in ffdshow. This is for advanced users. Seach the AviSynth subforum if you want to learn more about writing AviSynth scripts.
Method #6: Monitor settings
Some monitors can be calibrated to assume a certain luminance level as input.
Method #7: Resize in software
If wrong levels occur only with SD video resolutions and not with high resolutions, then another solution would be to resize the video in software. For example ffdshow can be used for resizing the video.
Test files
Here are some nice test clips to test your setup:
Test clips (http://forum.doom9.org/showthread.php?p=1230259#post1230259)
(thanks to littleD for making them)
Some more advanced test clips can be found here:
http://www.avsforum.com/avs-vb/showthread.php?t=948496
(get the MP4 ones)
kutjong
24th December 2008, 00:06
You can't use MPC shaders with Haali Renderer, and you won't even need that for levels conversion since both colorspace and luma range settings are available in the renderer's properties.
HR also has auto setting for colorspace in which it assumes BT.601 for everything w<1280 & h<720 and BT.709 for the opposite.
Anima123
24th December 2008, 11:08
Haali's renderer is also based on shaders, thus it will need the corresponding DirectX components to make it work right. I'd like to know how to get those components added with Windows Server 2008 64 bit.
clsid
24th December 2008, 14:11
Run the DirectX web installer.
Kado
24th December 2008, 19:28
@kutjong
Not everybody (like me) uses Haali renderer. I use EVR CP because I prefer to use DXVA on supported videos, also seems like that with Haali renderer the subtitles resolution is limited to 1024x768 using MPC-HC. Nvidia has provided a way on the nvidia control panel to change the luma range so you don't have to use the shaders. Also that other shader for YV12 blockiness is not needed (at least for me) if I provide YV12 color space to the GPU.
This is a nice tutorial to elucidate the more novice people, thanks clsid.
And Merry Xmas everyone! :)
clsid
24th December 2008, 20:03
The tutorial is still a work in progress.
Kado, could you (or somebody else) with a NVIDIA card post some more details about that option? The name of the option, its location in the control panel, etc. Also which driver versions have that option (I remember reading that it was recently added). Then I will add that info to the tutorial.
With ATI cards and EVR CP, the levels are only wrong for SD video. So I am planning to add a second version of the levels shader to MPC, one that only processes SD video. Does anyone know what parameters the ATI driver uses to determine whether video is HD or not? Is it simply "height >= 720", or does it also check the width?
clsid
24th December 2008, 22:13
it's just vrm7 and 9 that **** it up. Don't use those and problem solved.
Not true. EVR CP has problems as well.
It sometimes is not possible to use other renderers. For example DXVA requires using VMR/EVR renderers.
Mangix
24th December 2008, 22:22
Kado, could you (or somebody else) with a NVIDIA card post some more details about that option? The name of the option, its location in the control panel, etc. Also which driver versions have that option (I remember reading that it was recently added). Then I will add that info to the tutorial.
http://img254.imageshack.us/img254/5002/sshot1pr2.jpg
screenshot should explain itself. the option has an effect over VMR9 and EVR to my knowledge. haven't tested it with VMR7 or Overlay(colors are always wrong with overlay on my system).
also, i believe driver version 177.84 introduced this option. the version in the screenshot is 180.84.
ACrowley
26th December 2008, 12:56
You can fix the TV-PC Levels on a ATI Card (Avivo capable GPUs=Radeon 2xxx,3xxx4xxx) constantly.
"The "UseBT601CSC"="1" driver expands SD levels, the same way as HD is expanded automatically by the drivers, giving you 0-255, aka PC levels."
Just use DXVAChecker. Goto Processor Device/Rightclick/Open Video Acceleration Settings /and enable "Use BT601"
Now you have always PC Levels
Or you can add the Registry Entry by yourslef in :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{F332569B-6A9D-4078-8CF4-7E76147F726B}\0001\UMD\DXVA
Just add
UseBT601CSC= 1
clsid
26th December 2008, 14:48
Doesn't the registry key differ on different computers?
cca
26th December 2008, 16:59
Doesn't the registry key differ on different computers?
That is correct, a tool like DXVAchecker is a better option to change the registry setting than manually change the registry.
Yong
26th December 2008, 18:16
Just ran a quick test on vmr7/9/evr on windows xp + cat 8.12, only VMR7 windowed mode give me correct level without tweaking anything.
How about method 7, resize video? eg resize if video vertical resolution is smaller than 720 by using ffdshow.
clsid
26th December 2008, 20:40
Just ran a quick test on vmr7/9/evr on windows xp + cat 8.12, only VMR7 windowed mode give me correct level without tweaking anything.
How about method 7, resize video? eg resize if video vertical resolution is smaller than 720 by using ffdshow.
Are the levels wrong for both SD and HD video?
littleD
27th December 2008, 11:20
There is nothing advanced in Method #5: Use AviSynth script in ffdshow video decoder.
Just paste ConvertToRGB32(matrix="rec601") for SD or ConvertToRGB32(matrix="rec709") for HD in ffdshow's avisynth configuration. For switching between them, best option is to save all presets in one directory (thouse will be avs scripts).
Of course, avisyth must be installed.
Yong
27th December 2008, 16:07
Are the levels wrong for both SD and HD video?
Nope, only SD, the renderers will show correct level as long as the output video width is bigger than 720.
Btw i think using DXVAchecker to enable "UseBT601CSC" really works for me, but user might have to re-enable it again if re/install newer version of catalyst.
cca
27th December 2008, 16:58
Nope, only SD, the renderers will show correct level as long as the output video width is bigger than 720.
Btw i think using DXVAchecker to enable "UseBT601CSC" really works for me, but user might have to re-enable it again if re/install newer version of catalyst.
Regarding this, I enabled it one time and never again needed to re-enable it, but it may be different in other Windows version.
littleD
31st December 2008, 15:30
I converted test videos from http://www.geocities.com/anothrosko/vtc.html to TV levels in both HD and SD resolution, so anyone can set correct config based on them. I hope you will enjoy it ;)
Please confirm if they really have correct levels.
cbemoore
4th January 2009, 16:41
I converted test videos from http://www.geocities.com/anothrosko/vtc.html to TV levels in both HD and SD resolution, so anyone can set correct config based on them. I hope you will enjoy it ;)
Please confirm if they really have correct levels.
Now I'm really confused!
Using the original videos in the link you provided, my black levels are too dark (everything below 26 is BTB) and my white levels are perfect (everything above 235 is WTW).
But using your converted test videos, my black levels are pretty close (everything below 12 is BTB) and my white levels are too dark (I can see everything up to 255, so I have no WTW). I get identical results with both your HD and SD versions.
So which of the test patterns are correct? And how should I calibrate my screen?
littleD
4th January 2009, 21:28
Please read again hints at clip videos on that site. They apply to my converted videos. The author just picked wrong level range - PC, i used common - TV.
In Ideal case u should see all bars on clips, except the maximum and minimum. If u cant see bars above 235 on white or hardly see any black bars, then u should change config.
And do not bother clips from site. Use my clips as reference.
littleD
4th January 2009, 21:35
For calibrating the screen use gamma correction.
Gamma for crt is about 2.2 - 2.5
chros
6th January 2009, 16:29
Is there any registry entry for Nvidia cards for the "full range"?
Because my setup doesn't want to save this setting ...
I have find that there are values which are saved under:
HKEY_CURRENT_USER\Software\NVIDIA Corporation\NVControlPanel\RegisteredServers\Video_TVServer\AdjustVideoColorSettings\Gpu:0_Head:0
HKEY_CURRENT_USER\Software\NVIDIA Corporation\NVControlPanel\RegisteredServers\Video_TVServer\AdjustVideoColorSettings\Gpu:0_Head:1
I've got only 2 values:
AdjustVideoColorSettingsLastSelectedGammaState
AdjustVideoColorSettingsLastSelectedRGBLockStatus
Can someone see which value correspond to this?
Thanks
Setup: fresh WinXP SP3, latest whql driver, 9600GT
tetsuo55
6th January 2009, 18:56
I hope we can find a complete solution to the problem:
-The target is always going to be RGB32
We need to find a way to (as losslessly as possible) convert from Any colorspace, using the correct luminance and RGB primaries to RGB32.
This should result in the best possible image.
On top of this it has to be possible to convert to specified target RGB primaries (for those users that know the actual primaries of their display)
This can be a set-and-forget type of thing because the system mentioned first is already taking care of all the different colorspaces
madshi
6th January 2009, 20:45
Good thread!
A little bit of nitpicking, though:
Which combinations give wrong levels?
Many factors play a role, so it is not possible to give a list of combinations that always gives wrong levels for everyone. Below is an (incomplete) list of situations in which wrong levels are likely to occur. But in general, just trust your eyes.
Windows Vista + EVR CP + SD video + ATI
Windows Vista + EVR CP + SD video + NVIDIA
Windows XP + VMR-7 (renderless) + SD video + ATI
Windows XP + VMR-9 (windowed) + SD video + ATI
Windows XP + VMR-9 (renderless) + SD video + ATI
Windows XP + EVR + SD video + ATI
Windows XP + EVR CP + SD video + ATI
(if you have additions to this list, then please post them)
Ehm. This is from the point of view of people who need PC levels. For me ATI SD levels are correct, while ATI HD levels are wrong.
How can I correct the levels?
Method #1: Adjusting graphics driver settings
ATI
The ATI driver requires a Registry tweak. With the tweak applied, the driver will convert TV levels to PC levels for SD resolution video. It already does that by default for HD video.
That is not "how can I correct the levels", unless you consider PC levels to be always correct and video levels to be always incorrect. This is just "how can I make SD and HD behave identical with ATI". Correcting the levels for people like me who need video levels is not possible at all through adjusting ATI driver settings.
tetsuo55
6th January 2009, 21:03
What is the correct/accurate way to convert 16-235 to 0-255
1. Stretch 16 to 0 and 235 to 255 and evenly stretch everything in between?
2. Pad the 0-16 and 2-35 with 0's or BTB/WTW ?
which of these 2 will result in the best image on a 0-255 display?
mark0077
6th January 2009, 22:40
Has to be stretched from 16-235 to 0-255 because 16 was intended to be interpreted as pure black, and 235 interpreted as pure white.
In the PC, 0 is interpreted as pure black, 255 as pure white. All inbetween values must be stretched evenly as the 16 is mapped to 0, and 235 mapped to 255.
madshi
6th January 2009, 22:41
What is the correct/accurate way to convert 16-235 to 0-255
1. Stretch 16 to 0 and 235 to 255 and evenly stretch everything in between?
2. Pad the 0-16 and 2-35 with 0's or BTB/WTW ?
which of these 2 will result in the best image on a 0-255 display?
If you have a 0-255 display (e.g. typical computer monitor) then you should stretch everything to 0-255, or else the image will be washed out. I'd suggest using ffdshow's YUV -> RGB32HQ conversion to do the YUV -> RGB conversion. Just make sure you configure it correctly. The ffdshow controls are named a bit strangely (IMHO).
tetsuo55
7th January 2009, 10:42
Okay so we stretch
this looks to me like a VERY lossy conversion
We have 37 extra steps which we spread over 256 spaces.
Does this currently happen as losslessly as possible?
Is it possible to do the conversion with a <2% loss of detail?
mark0077
7th January 2009, 10:51
I would love to know also. In my case it might be better to send 16-235 to my TV and let it use its 10bit color to better expand the values.
Would be nice to know how Windows 8-bit per color handles this, anyone done the maths?
tetsuo55
7th January 2009, 11:08
According to this article:
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm
We can convert colorspace, luminance and RGB primaries in 1 calculation.
As every calculation will be lossy there are several choices.
The article states that "3D perceptual intent with black point compensation" conversion will result in the visably most accurate result(but mathematicaly wrong).
Its like a PSY-optical
Also because we will be converting from a smaller colorspace to a bigger one it should be near-lossless even with perceptual intent
mark0077
7th January 2009, 11:15
Very intersting, thanks for that. Althought the colorspace we are converting into is bigger, I think the bit depth we are limited to might have an impact on how much of that bigger colorspace we can use. Would be nice to get some figures on how many percent off perfect it can be with 32big rgb.
With my limited understanding of all of this I was thinking that if most new flat panels use rgb pixels anyways wouldn't they be doing this conversion anyways, or wouldn't the hardware dvd player in the living room be doing this conversion too... So there is no real disadvantage to doing this conversion to rgb on the pc vs other ways of watching the content right? The conversion to rgb has to happen anyways.
I wonder if nvidia's conversion is done using perceptual conversion vs ffdshows conversion done using a more mathematically correct way of converting? This is the only explanation I can give for the differences in the quality results I am seeing on my machine with nvidias yv12 to rgb32 and yuy2 to rgb looking better than ffdshows rgb32hq.
tetsuo55
7th January 2009, 11:19
Your display expects a certain colorspace/luminance level.
Only if your display knows this will be different will it apply any conversion.
i have a 1080P panel, and using the scart port will result in the scart 601 signal being converted to 709, but i am not 100% sure this really happens.
The target colorspace will vary(especially with windows7).
Currently with XP/Vista the target colorspace should be 32bit ICCv4 sRGB(based on 8 bits per color)
However my videocard operates at 10bits per color and applies dithering for 8bit panels.
My Display is also 10bit so i'm not sure how this factors in.
Theoretically we could convert in as many bits as we wanted to reduce rounding errors, and then dither back to 8bit
With my limited understanding of all of this I was thinking that if most new flat panels use rgb pixels anyways wouldn't they be doing this conversion anyways, or wouldn't the hardware dvd player in the living room be doing this conversion too... So there is no real disadvantage to doing this conversion to rgb on the pc vs other ways of watching the content right? The conversion to rgb has to happen anyways.
The conversion from ANY > RGB is going to happen at some point in the chain.
And if we do not convert the luminance level it will be used as is and be interpreted as 0-255
mark0077
7th January 2009, 11:27
So I wonder is there any way to use the 32bits available in xp / vista at the moment to send 10bit r, g, and b = 30bits, pad with 2bits to get to 32...
What is the 4th 8-bits used for nowadays.... alpha.... is this necessary?
madshi
7th January 2009, 11:33
Okay so we stretch
this looks to me like a VERY lossy conversion
We have 37 extra steps which we spread over 256 spaces.
Does this currently happen as losslessly as possible?
Is it possible to do the conversion with a <2% loss of detail?
Well, it all depends a little. If you do "YCbCr -> RGB (video levels)" conversion first and then stretch "RGB (video levels) -> RGB (PC levels)" then I'd expect a hit on image quality. But if you go directly from "YCbCr -> RGB (PC levels)" then there should be no problem because when doing "YCbCr -> integer RGB (any levels)" conversion there's always rounding or dithering involved, anyway. What we absolutely should avoid is multiple conversions after another. I'd expect that ffdshow converts YCbCr to RGB in one step, regardless of whether you convert to video levels or PC levels. So I don't expect any disadvantage for displays who need PC levels. Well, except that you lose BTB and WTW, of course... Actually spreading to PC levels could be ever so slightly better because you have a range of 0-255 for every color, while with video levels you only have a range of 16-235 for every color. So with PC levels you have slightly more graduations per color. Of course ideally if the display supports more than 8bit, we should go to 10bit RGB output with Windows 7. That should solve any potential banding problems...
mark0077
7th January 2009, 11:38
It would be good to hear some input from the ffdshow developers on the conversion techniques used in rgb32hq.
So tempting to try Windows 7 Beta if i could (legally) get a copy of it. Not sure if the nvidia drivers are setup for 10bit color yet, or what gfx cards support it. I wonder are there any tests that could really show off the difference between 8-bit and 10-bit, would be nice to be sure 10-bits is being used from Windows all the way through to your 10-bit display.
madshi
7th January 2009, 11:40
So I wonder is there any way to use the 32bits available in xp / vista at the moment to send 10bit r, g, and b
No.
32bit RGB = 8bit per color, plus 8bit alpha channel (or unused)
What is the 4th 8-bits used for nowadays.... alpha.... is this necessary?
"Necessary" is a relative term. It's useful for some things. But the main purpose of 32bit graphics mode is that 24bit is an odd number for computers. So 32bit mode is usually faster than 24bit with exactly the same image quality. Windows (up to Vista) doesn't have support for outputting any more than 8bit RGB per channel. That is supposed to change with Windows 7, finally...
tetsuo55
7th January 2009, 11:45
Here is a imho very good article/test on colorspace conversions.
It really points out all the problems we are facing eventhough its intended for printing.
http://www.luminous-landscape.com/reviews/accessories/fancy_graphics.shtml
The article even more clearly shows that the entire source>target conversion can be done in 1 go.
@madshi:
Ffdshow does multiple conversions if the source is not YV12
non-YV12 to YV12 for all internal stuff, then from YV12 to RGB if you tell it to do so (otherwise the renderer or videocard will do it for you)
madshi
7th January 2009, 11:56
Ffdshow does multiple conversions if the source is not YV12
non-YV12 to YV12 for all internal stuff, then from YV12 to RGB if you tell it to do so
Convertion from non-YV12 to YV12 doesn't sound that dangerous to me. After all it's all some sort of YCbCr, isn't it?
tetsuo55
7th January 2009, 11:58
Convertion from non-YV12 to YV12 doesn't sound that dangerous to me. After all it's all some sort of YCbCr, isn't it?
Is it really?
According to the internets every conversion is lossly in either color, luminance or both
tetsuo55
7th January 2009, 15:08
Okay things seem to be more complicated and less complicated at the same time.
The luminance level range can vary even within the same sample!
The standards allow for different ranges in the luma and the chroma channels.
Accurate conversion requires a level check for both chroma and luma, and the expansion needs to be adjusted accordingly for each.
There are 3 possible conversions:
601 PAL to full range RGB
601 NTSC to full range RGB
709 to full range RGB(709 uses the sRGB colorspace, HD formats allow for full-range video)
The level test will reveal if the 709 conversion is really needed.
The only time you do not have to convert is when your videocard is capable of working in YCbCr colorspace and also outputs this unconverted. Otherwise you will always be converting.
mark0077
7th January 2009, 15:14
Would that mean there are 6 "standard" combinations of outputs that might be imagined in ffdshow. Like the following 6 combinations?
601 PAL full range to full range RGB
601 NTSC full range to full range RGB
709 full range to full range RGB
601 PAL standard to full range RGB
601 NTSC standard to full range RGB
709 standard to full range RGB
whereas at the moment there is only 4
601 full range to full range RGB
709 full range to full range RGB
601 standard to full range RGB
709 standard to full range RGB
Do i understand correctly?
clsid
7th January 2009, 15:19
@madshi
I have adjusted to first post to mention what to do in case of a CRT TV (method 2 and 3). Please correct me if I wrote anything wrong.
tetsuo55
7th January 2009, 15:20
I'm suggesting autodetection in fact.
Officially there is no such thing as full range 601, however every low resolution FRAPS video is in fact full range.
This is why the conversion needs to test both the chroma and the luma for ranges.
More info here:
http://en.wikipedia.org/wiki/YCbCr
But you understand correctly that we are missing the pal/ntsc difference in 601.
Also, i believe this has not been discussed before but:
Monitors and HDTV displays are all calibrated to sRGB/709.
However both pal and ntsc SD and broadcast signals live in slightly different colorspaces that do not fit in sRGB/709, so the conversion will result in either clipping or distortion of a small portion of the colors
leeperry
7th January 2009, 15:23
every low resolution FRAPS video is in fact full range.
because games are full range in the first place.
you understand correctly that we are missing the pal/ntsc difference in 601.
SD uses REC.601 coeffs for RGB conversion, whatever PAL or NTSC.
it's the gamut that is different, depending on the mastering but the YCbrCr>RGB coeffs are identical in both cases...just like REC.709 for HD.
madshi
7th January 2009, 15:25
I have adjusted to first post to mention what to do in case of a CRT TV (method 2 and 3). Please correct me if I wrote anything wrong.
Reads fine to me now - thanks!
mark0077
7th January 2009, 15:26
This is excellent. So I have just calibrated my new Samsung Series 9 using settings from a guy on another forum, and I think he calibrated it with the target 709. I have my new TV set to accept input as full range.
If this type of auto detection could be done for all of the combinations you talked about, what way should our displays be calibrated? Does any calibration technique incorporate all of the standards like 601 and 709?
tetsuo55
7th January 2009, 15:28
because games are full range in the first place.
SD uses REC.601 coeffs for RGB conversion, whatever PAL or NTSC.
it's the gamut that is different, depending on the mastering but the YCbrCr>RGB coeffs are identical in both cases...just like REC709 for HD.
Yes thats true, but we need to correct the gamut as the display will be sRGB not PAL/NTSC, seeing as the gamut conversion can be incorporated in the YCbrCr>RGB as a slight offset we should do so.
This is not needed for REC709 because the gamut already matches sRGB.
This is excellent. So I have just calibrated my new Samsung Series 9 using settings from a guy on another forum, and I think he calibrated it with the target 709. I have my new TV set to accept input as full range.
If this type of auto detection could be done for all of the combinations you talked about, what way should our displays be calibrated? Does any calibration technique incorporate all of the standards like 601 and 709?
the default target should be sRGB/709.
This is the factory setting for all digital 720p capable displays and all monitors
mark0077
7th January 2009, 15:38
709 is the way to go then, thanks! Maybe you should present your findings / suggestions to an ffdshow developer. I am sure they would be delighted to read about the PAL/NTSC 601 aswell as the different methods for colorspace conversion. :D
tetsuo55
7th January 2009, 15:44
I'm not sure the story is finished yet.
I want to get some more feedback first.
-----------
Complete (automated) Colorspace, gamut and level conversion for digital video:
#check luma and chrome for clipping to determin the used levels for either
Adjust expansion parameters accordingly
#check if the video is SD or HD
if resolution is XXX or higher = HD
else SD
# in case of SD check for PAL/NTSC
If framerate is not 25/50 assume NTSC ?
((not sure how to handle 24fps))
((might also want to check resolutions))
-in case of HD use 709 conversion
-In case of PAL-SD use 601-PAL conversion
-In case of NTSC-SD use 601-NTSC conversion
The entire process leads to a single formula (not multiple conversions)
To reduce rounding errors a higher bitdepth can be used(like 16) for the processing.
NOTES:
-This method preserves all BTB/WTW data for those non-standard videos that contain them.
-HD video can contain full-range without breaking spec.
-This conversion is valid for all PC based systems, even if the videocard supports 16-235 it will do this conversion(or re-convert) itself resulting in crushed blacks
I will have to find the exact primaries for NTSC/PAL they where posted here on doom9 or at the avsforum
leeperry
7th January 2009, 19:00
Yes thats true, but we need to correct the gamut as the display will be sRGB not PAL/NTSC, seeing as the gamut conversion can be incorporated in the YCbrCr>RGB as a slight offset we should do so.
This is not needed for REC709 because the gamut already matches sRGB.
the default target should be sRGB/709.
This is the factory setting for all digital 720p capable displays and all monitors
well most big LCD screen/LCD projectors have wide gamuts, and hardly any display has a perfect sRGB gamut....and you need to measure the primaries coordinates with a colorimeter in order to fix them.
also european/russian/continental chinese BD's are either 23.976/24fps but they use the EBU gamut :p
I don't think you can let ffdshow make wild guesses on the gamut.
madshi
7th January 2009, 19:17
Complete (automated) Colorspace, gamut and level conversion for digital video:
#check luma and chrome for clipping to determin the used levels for either
Adjust expansion parameters accordingly
I'm not sure if you can reliably detect this in every frame of every movie. What if this algorithm sometimes gives us wrong results? Then black / white level will fluctuate in the middle of the movie. I don't like the idea of doing this automatically, unless we find a solution which is 100% fail safe.
NOTES:
-This method preserves all BTB/WTW data for those non-standard videos that contain them.
BTB/WTW is not "non-standard". A DVD may officially contain BTB and WTW information. Of course the DVD makers must live with the fact that a properly calibrated TV will supress most of the BTB/WTW information. But this doesn't make the use of BTB/WTW illegal or non-standard.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.