If you mean Y' 0-255 (ie. full range video), and assuming you have usable data in that region (many cameras record usable data Y>235 , but rarely Y<16 - it's not clipped it will be displayed , but will barely be visible depending on the TV's calibration. The ITU specs purposely specifiy the range Y' 16-235 to allow for broadcast overshoot and undershoot. If you open up any professional BD or DVD (e.g. from Hollywood) and look in a waveform monitor, you will often see overshoots (but rarely undershoots) . In my experience, your average TV out of the box will barely show anything beyond that range - as expected (more on the white side than black) ; but some models are calibrated incorrectly out of the box.
HDMI Capture Problem SOLVED - AviSynth RULES!
- Thread starter Ralph B
- Start date
If you mean Y' 0-255 (ie. full range video), and assuming you have usable data in that region (many cameras record usable data Y>235 , but rarely Y<16 - it's not clipped it will be displayed , but will barely be visible depending on the TV's calibration. The ITU specs purposely specifiy the range Y' 16-235 to allow for broadcast overshoot and undershoot. If you open up any professional BD or DVD (e.g. from Hollywood) and look in a waveform monitor, you will often see overshoots (but rarely undershoots) . In my experience, your average TV out of the box will barely show anything beyond that range - as expected (more on the white side than black) ; but some models are calibrated incorrectly out of the box.
So you're saying that 16-235 is something of an advisory range and not a hard limit? If that's the case, then it's safe to do all your post work full range, 0-255, and know that it's going to be carried through to the end user. Now, whether the end user's TV is setup correctly, well, that's their problem. Yes?
Yes, it's not a hard limit.
BUT if you have full range Y' 0-255 data, you have to adjust it to Y' 16-235 on final export to delivery to make it legal or it won't look right on 99.9% of setups . Full range Y' data displayed with a standard RGB conversion looks wrong. Full range Y' data displayed with full range RGB conversion looks correct.
Note there are displays that support full range, but these are quite rare. Full range done correctly gives many benefits ,including less banding because there are more gradations. In fact, flash supports full range flag, if you use your own flash (not something like youtube or vimeo which re-encode). But full range isn't a convential way of doing things, not recommended. If you want I can post some examples
Be careful when you use the term "0-255", you have to specify if you mean Y' 0-255 or RGB 0,0,0-255,255,255 . Most programs (when using filters) work in RGB , not Y'CbCr.
Many programs convert to RGB using a hard limit (e.g. if you take a screenshot, Y'CbCr is converted to RGB like this : Y' [16,235] => RGB [0,255] , so Y' <16 and Y' >235 is clipped) .
Some programs and hardware that do ITU Rec.709/601 conversions don't clip the data, they clamp the data. The distinction is important. In the latter, the data is still there but just "squished" (all the values Y' >235 , Y",16 are just squished within the range Y' 16-235, instead of completely eliminated) . This is why some programs don't strictly follow these guidelines. For example, sony vegas will use "studio RGB" using Rec.709 coefficients - this means Y' 0-255 gets "mapped" to RGB 0-255. A strict ITU Rec. 709/601 conversion would "map" Y' 16-235 to RGB 0-255
But some programs allow you to access Y' values before that RGB conversion - in that case that Y' data can preserved . The order is important
The other way to access all the data is to do a full range RGB conversion (ie. Y' [0-255] => RGB [0,255] ) .
We've only been talking about Y' , but this affects CbCr too - Rec601/709 conversions specify CbCr in the 16-240 range, not the 16-235 range. So chroma is also clipped unless your program can access CbCr before the RGB conversion , or you do a full range RGB conversion
Last edited:
What setups are you refering to?
What do you mean by "standard RGB conversion"?
Please do.
Understood.
What programs would that be?
Where would you do that, avisynth?
What are the practical applications where this comes into play?
martinbeek
Active member
Just for illustration of the detail blurring, i've made two screendumps of a part of a frame of Ninja footage and the same frame after AviSynth. 200% enlarged in photoshop, gamma adjusted.
Cheers,
Martin
Ninja:
Avisynth:
Ps. Ninja = ProResHQ, AviSynth = DNxHD
Cheers,
Martin
Ninja:
Avisynth:
Ps. Ninja = ProResHQ, AviSynth = DNxHD
Last edited:
I mean any delivery setup. 99.9% of your regular TV , blu ray, DVD, 99.9% of your internet, PC monitors, broadcast monitors. Basically everything
All displays work in RGB. You're not viewing Y'CbCr directly - that data has to be upsampled and converted to RGB for display. 99.9% will use ITU Rec.709 for HD content, some will mistakenly use Rec601, but the black and white point will be the same. (The colors will be shifted slightly).
Standard range "legal" video decoded by standard matrix means Y' 16-235 => RGB 0,0,0 - 255,255,255 . Thus "black" is displayed at RGB 0,0,0 , white at RGB 255,255,255 . The black level in the video was Y'16 and white Y'235. Virtually all equipment is calibrated to display Y' 16 as black and Y'235 as white. If your video has set Y' 0 as black and Y' 255 as white it won't decode it properly because the wrong RGB conversion is performed (most equipment can't handle or dispaly full range video correctly). So your blacks will be crushed, and whites will be blown. In order to display full range video correctly, you need to decode with a full range matrix ie.. Y' [0,255] => RGB [0,255] . Very few equimpent or support full range, and of those that do, very few acknowledge the flags in a video stream (the switch has to be done manually). Flash is the only one I'm aware of that accepts full range flag in the video stream
I can't figure out how to get blip.tv embedded, you'll have to click on the links . You might not be able to see the "banding" depending on the quality or bit depth of your display. These are contrived examples, but just to illustrate the point that full range is possible
The first is your "regular" example. Normal range video , decoded with normal range RGB conversion. The 2nd is full range video decoded with full range RGB (flag in the video stream tells the flash player to decode to RGB using full range) . Both are regular 8-bit h.264 , and this is non dithered . Because black to white has 0-255 steps or gradations, there is less visible banding and posterization than a black to white of 16-235 "steps" . It's the same idea (but worse than) 10-bit video, where there are 0-1023 "steps" in full range 10-bit
http://www.blip.tv/file/4409086
http://www.blip.tv/file/4409087
Examples: I think FCP can do this, if it "sees" the data in Y'CbCr (it looks like DNxHD doesn't work for it) . PP CS5 can with the "YUV" labelled filters. And of course avisynth
In avisynth you can specify the matrix and the range
e.g.
ConvertToRGB(matrix="PC.709")
"PC" range matrices are full range , "Rec" matrices are standard range. There are other options you can use - other coefficients you can use (other than BT709/601) if you use the colormatrix() filter, and other types of sampling for the RGB conversion (in avisynth 2.6, e.g. if you recall Grgur chose spline36 in one of the chroma fix scripts, you might choose bilinear for softer, or lanczos for sharper etc...) . The sampling algorithm affects how the chroma is upscaled to RGB. Sharper algorithms have more aliasing, softer algorithms have less aliasing but more blurring . Have a look at the documenation for the full list
This comes into play all the time in practical applications. Just search for "chroma clipping" the AF100 subforum there were a few lively discussions there. Chroma clips before luminance in many cameras. The canon dslr's do this too with the red channel. So if you're monitoring exposure with zebras or waveform monitor, you might think you're safe, but in fact one of the channels are clipped. The end result is not only less color information available, but the relative imbalance causes certain ugly unnatural looking "color hues" in highlight areas.
(I'm talking about RGB here because the camera sensor and everything before recording actually works in RGB, but you can see this in CbCr in the recorded media as well). So by either using a full range RGB conversion ,or if your application can access CbCr before the RGB conversion - you can preserve some of that data CbCr <16, and >240 , similar to how you can preserve the luminance data Y' <16, Y'>235
Last edited:
Cosimo Bullo
Veteran
It seems the weird histogram crunching Barry was talking about goes away in jpeg mode. Can anyone else confirm?
Not sure what's going on there, the blurring of the hair of the leaves it's probably partly due to that version of chroma fix shift, but the grain pattern in the background of those screenshots doesn't even look like it's even the same frame
Some of it might be Quicktime or FCP issues and RGB conversion
Some of it might be DNxHD compression, but I'm getting different results.
I didn't use GrgurMG's chromafix, the one I used was
FixBrokenChromaUpsampling()
ConvertToYV12()
Here are screenshots you can examine in photoshop or whatever program. You will notice even the grain pattern is the same, but slightly less in some areas (now those are compression losses) . The biggest difference is the lack of chroma aliasing. It's very prevalent in the blue channel in the ProRes shot. At quick glance of the RGB composite you might miss the aliasing, especially in motion
http://www.mediafire.com/?2rhr9ik5yo5nqce
Thanks, very informative post.
Now to apply this to the GH2's HDMI output, here's a histogram of a raw HDMI capture opened directly in VirtualDub.
And here's a histogram of the same file passed through Avisynth with this script:
aviSource("__vid__")
ConvertToRGB(matrix="PC.709")
Now my question is, which one is real? Which one is displaying what's actually on the raw file?
Yes, I confirm. Not sure what it means, or if there's any practical value to it, but the histogram does not change when you're recording in MJPEG mode.
Neither.
You're converting to RGB , and possibly incorrecty if the signal is interlaced (there is an interlaced=true and interlaced=false switch in ConvertToRGB() ), and if you do the conversion incorrectly, you will get CUE (chroma upsampling error). But the HDMI signal is screwed up to begin with, so .....
So the HDMI signal is Y'CbCr 4:2:2, if you convert it to RGB, it isn't exactly what's on the "raw" file. It's an RGB representation of what's on the "raw" file
A full range matrix means you see all of the data - if you had data in Y' <16, and Y'> 235 , those would not be clipped if you converted to RGB (i.e. you can salvage super brights and super darks)
Neither, the way you have it setup
That is a histogram, looking at RGB. Strictly speaking, luminance Y' refers to Y'CbCr and the "raw" file is Y'CbCr . So the luminace values reported by that filter will change depending on how you did the RGB conversion - you can see that this is true in your 2 screenshots.
So the "True" value is the one read from the original file, not the RGB representation of it.
Background info: Usually any filter used in vdub causes a RGB conversion . That conversion uses Rec601 if you let vdub do the RGB conversion. A rec601 conversion will shift the colors slightly (incorrect for HD). When you use video=>full processing mode in vdub this also does RGB conversion with the default settings. You bypass color space conversions in vdub by using video=>fast recompress . This way you keep the same "color space" or "color model" . Now some newer beta versions of vdub handle things slightly differently, you have different options for input and output color depths/spaces, but basically it still works the same. So in your first example, the file directly input, is actually converted to RGB by vdub, not the native Y'CbCr , because you are using "full processing mode" when using a filter. This is one of the the reasons why many users prefer to use avisynth for everything including filtering (you have more control). And if you need to use vdub filters, do the RGB conversion in avisynth , you have more control. For example, vdub doesn't do interlaced YV12 chroma sampling correctly. Anyways, there are a few more bugs/quirks in vdub, I won't get into them all here - the point is you're not accurately accessing the luminance
If you've recorded a YUY2 4:2:2 format (eg. ut video codec 422) , then you can use avisynth's histogram() or videoscope() . Histogram() will be on the side so you can use turnright() turnleft() . The "Brown" areas are "illegal" ie. Y'<16, Y'>235. It will show up as yellow if you have "illegal" excursions. This "classic" version of the histogram is actually a wave form monitor (x -axis isn't 0-255). If want the histogram version with the x-axis showing 0-255, use histogram("levels") - this will also show CbCr histogram
e.g.
AVISource("YUY2.avi")
TurnRight()
Histogram()
TurnLeft()
or
AVISource("YUY2.avi")
Videoscope("bottom")
Videoscope only accepts YUY2 input (so not YV12), but the wave form tracing is probably more what you're used to
If you haven't already, AvspMod is a great tool to view and edit scripts. Push F5 to preview. It has programmable sliders, macros , you can compare script versions in different tabs (hit number keys to swap)
But if you're looking for a realtime monitoring of the live HDMI feed, I don't think any of these will give what you want
Last edited:
not the version of banding you're talking about
there are 3 different types of banding that people are mixing up
1) from poor compression (e.g. vimeo or youtube) , lack of pre processing & dithering - increased range , better pre processing , and using a better encoder will help with this kind
2) the lowlight fixed pattern noise , like vertical or horizontal streaks - increased range won't help with this
3) bad sensor issue - I don't know what this is, but it's not from 8-bit compression. An example is the chem trails video - not much will help with this type either. The amount of grain you need to "cover it up" effectively is too enormous to be practical. To be effective for distribution you would require much higher bitrates as well
Last edited:
You can correctly apply the term "posterization" to #1 as well. Macroblocks assigned high quantizers from the encoder cause the same effect. The difference in #3 is the HDMI recording with high bitrates doesn't eliminate or improve the issue, so this indicates some problem upstream (maybe sensor, maybe in camera processing ?)
Someone in one of the threads said Panasonic is aware of the issue (#3)
I don't think Panasonic will do anything about the 5D 24fps
martinbeek
Active member
martinbeek
Active member
PDR. I'd a look at those images. I assume you didn't do any postprocessing on them? I can't believe my eyes. I see a totally different result; in my case the footage is worlds apart. Color al different, gamma issues, blurry. Even without the chroma fix, i'm looking at something totally different here.
As far as i know i use the same script, same batchscript and same codec as you. What program did you load the footage into to make the framegrabs?
Martin.
No other processing other than choosing the matrix . I took the screenshots of frame #0 from avspmod, using Rec709 matrix for the Y'CbCr=>RGB conversion . Everything else was the same, except for the chroma fix part of the script. If you use the one I used , there is no vertical shift (at least not a large one), so that eliminates shifting as the cause for what you're seeing as "blurring"
Even if I take the screenshots through QT player (ie. open up the DNxHD footage in QT and export a screenshot), the pattern of the grain is the same.
http://www.mediafire.com/?ybe6qqolnytly2q#2
You may or may not see a gamma difference depending on if your application reads the embedded color profile tag, but the small details are the same. Even if you ignore gamma issues, your screenshots look different: background grain looks like it was taken a different frame #
The only other thing I can think of is you might be using the proxy bitrate for DNxHD (not the 175Mb/s version). Make sure the ffmpeg command line was entered correctly