Well, VHS capturing Mostly cartoons, having some questions:)

[sanlyn]

Right. There are dozens of ColorYUV combinations (hundreds?). You read the ColorYUV documentation in Avisynth to get an idea what the parameters do, although just using it is hands-on really the only way to see what can be done.

Look at the two images I just posted, of the girl and the guy. In the original (top image), luma in the the capture was almost just right -- which is tough to do with VHS because it's so variable from scene to scene. The colors were complicated, so I had to do that in RGB. But if you check the darkest parts in YUV before going to RGB, you'll see the back of the guy's hair is just about RGB 9 or so, and furniture in the background has details that are just beginning to disappear in the dark. I raised luma just a matter of a few points (ColorYUV(off_y=4)), which was just enough to bring a little more detail out of the darkest stuff and keep shadows from looking gummed up.

In the movie, the scene is a dimly lighted interior, so I didn't want to make the darks too bright. Ruins the mood, y'know (picky, picky).

[zerowalker]

So the Blackness is allright?
But the Brighness isn´t correct?

Cause it´s probably White Crush, cause i have set the settings so it´s withing the TV Range 16-235 (or something?).

But White Crush (if you don´t know), does like it sounds, it crushed the Whiteness, preventing it from "Bleeding" away colors and details.
I am not sure exactly how it works, just that it prevents whiteness from eliminating details.

Right now i haven´t found the Perfect setting, so it´s currently a bit to high whiteness in the areas where it needs to be crushed.


And for the 3DNR, if what you are saying is correct, the 3DNR is not needed

But just in case, i will upload a clip later with motion and stuff, with 3DNR on and off, so we can see what it does(well we probably know already;P).

[sanlyn]

I wasn't referring to luma range, but to colors. The histogram I posted is an RGB histogram from VirtualDub. Overall luminance is at the top, followed downward by Red, Green, Blue. Overall luma was OK. Red and Blue were stretched across the right and its brightest values (at the far right-hand edge) would have crushed (washed out) significant detail if any had been there. As I said, with anime it usually doesn't matter. But I have seen plenty of anime with blown-out highlights. In the RGB histogram, the left-hand edge has a few peaks, but those are from your black borders. Black borders will always lie against the left-hand edge (darkest colors or luma) of a histogram.

3D-DNR doesn't address the kind of damage I showed. It deals more with chroma noise and luminance noise. I couldn't find a video example of that noise, but I did find a still-photo site with examples of that same noise as it appears in digital cameras and still photos. But it also occurs in video (especially in tape), and it's the same kind of noise. http://www.cambridgeincolour.com/tutorials/image-noise-2.htm . The "bristling' or simmering and dancing, streaking grain you see in your clip is chroma and luminance noise.

[zerowalker]

Overall lume was OK

How can it be improved?

Red and Blue were stretch across the right and would have been crushed (washed out) significant detail if any had been there.

Not sure how i can solve Chroma problems, can you conclude if this is in the Tape or in the Capture (as the tape is a bit like it is, wasn´t really a good sample).

D-DNR doesn't address the kind of damage I showed. It deals more with chroma noise and luminance noise.

Oh, you mean like tha noise you get if you Film in a dark room?

[sanlyn]

Yes, like noise in dark images, but it exists in brighter areas as well. It's easier to see in dark areas.

The source of out-of-range luma or color could be in the source or in the capture, or both. Using ColorYUV, the "cont" (contrast) paramter for Y, U or V channels controls this to a large extent. ColorYUV(cont_v=20) will increase contrast of the V channel (red). ColorYUV(cont_v=-20) is a negative value and will decrease the V channel contrast. Increasing contrast will shrink (draw in) the color values from each end toward the middle. Increasing contrast will expand the color outward at each end.

Decrease contrast = -->>---->---->|<----<-----<<--

Increase contrast = <<----<------<|>------>----->>

ColorYUV is explained in Avisynth's documentation: http://avisynth.org/mediawiki/ColorYUV

[zerowalker]

I see, well if it can´t be solved Capture wise, ColorYUV is the only way to go, i have been using it a bit, but i will need to learn it more properly

Here is another capture btw, same place, 3DNR off, TBC on, Chroma AGC on (it makes it much more saturated, though i think it´s Oversaturated, please judge). And i notice that if i disable the Comb Filter completely (Chroma part is active on S-video), i get the PAL lines back, though i don´t know if it´s Good or Bad, i didn´t see anything else change, so not sure if it´s just removing the lines, or if it´s bluring and the lines just happen to be removed in the process.

[jagabo]

See the RGB cube inside the YCbCr (YUV) cube about 1/3 the way down this page:

http://software.intel.com/sites/products/documentation/hpc/ipp/ippi/ippi_ch6/ch6_color_models.html

Many YUV colors fall outside the legal RGB range. Some basic rules:

Y should be between 16 and 235
U and V should be between 16 and 240

But even if all three of those are true there are still YUV values that fall outside the RGB cube. Many of those are the highly saturated colors (lots of U and V) with high intensity (Y).

You should learn to use the VideoScope() filter. Also, if you don't have it, get CSamp. It's great for reading RGB values off the screen.

CSamp on top of VirtualDub displaying your video and VideoScope():


I cropped away the black borders to concentrate on the actual picture. Note that the Y graph (on the bottom) is nowhere being too low or too high. It's easily between about 40 and 160. In all likelihood the contrast should be stretched to bring the darkest areas down near 16 and the brightest areas up near 235. But you can't judge by a single shot. You need to examine the entire video (unless you plan to adjust shot-by-shot).

[jagabo]

One way to check for illegal YUV values is to convert the video from YUV to RGB, back to YUV and then subtract from the original. Illegal YUV combinations will not survive the conversion intact:

AviSource("ds003.avi")
ColorYUV(off_y=-35, gain_y=150) # brighten it up to create illegal colors

diff = Subtract(last, ConvertToRGB(last).ConvertToYUY2()).Levels(112,1,144,0,255)

return(StackHorizontal(last, diff)).VideoScope("bottom")

Levels() is used here to accentuate the differences.



Anywhere that's not medium grey has illegal colors.

[sanlyn]

I see, well if it can´t be solved Capture wise, ColorYUV is the only way to go, i have been using it a bit, but i will need to learn it more properly

It can be solved at least partially during capture. Some capture devices have brightness/contrast/saturation controls. Some also have "Tint" controls, most of which are useless and do more harm than good. VirtualDub capture can also hook into some of these image controls. Often, it's a headache to set up. But a video with serious problems sometimes needs that headache.

ColorYUV and Tweak aren't difficult once you start using them. Jagabo has good advice: learn to use histograms and vectorscopes. etc. They can save you a ton of trouble later.

Here is another capture btw, same place, 3DNR off, TBC on, Chroma AGC on (it makes it much more saturated, though i think it´s Oversaturated, please judge). And i notice that if i disable the Comb Filter completely (Chroma part is active on S-video), i get the PAL lines back, though i don´t know if it´s Good or Bad, i didn´t see anything else change, so not sure if it´s just removing the lines, or if it´s bluring and the lines just happen to be removed in the process.

I see the AGC causing luma fluctuations in the clip. I'd leave it off. AGC causes more problems than it cures, and once its effects are in a video it's impossible to fix.

I'm not familiar with the comb filter you mention, but if it's cleaning up some disturbances I'd keep it on.

[jagabo]

i notice that if i disable the Comb Filter completely (Chroma part is active on S-video), i get the PAL lines back

I noticed the hanover bars on your last clip.

[zerowalker]

One way to check for illegal YUV values is to convert the video from YUV to RGB, back to YUV and then subtract from the original. Illegal YUV combinations will not survive the conversion intact:

Will be using this, sounds very neat!

It can be solved at least partially during capture. Some capture devices have brightness/contrast/saturation controls.

I do have many options, or well many and many:

Brightness
Contrast
Hue
Color
Color U
Color V

I normal things, like Xbox DVD etc, i can let it Auto tweak the colors and contrast with one of those color bars pictures. But that can´t be done on VCR, cause i don´t think i can Capture while it´s showed on a DVD and the colors will be the "same".

I see the AGC causing luma fluctuations in the clip. I'd leave it off. AGC causes more problems than it cures, and once its effects are in a video it's impossible to fix.

Yeah i thought i would cause problems, but i gave it a try, as it looked more "cartoonish" but as you have seen it causes High Saturation, which will cause problems. Meaning i will have it Off.

I noticed the hanover bars on your last clip.

Yes they appear with the Comb Filter OFF, if i have it by Default or Chroma (Default is Chroma if S-video is chosen) it will remove them. I don´t know if it removes only them or if there is a side effect though:S

will recapture that area with Comb filter Off and on Chroma, with AGC off, as it only messes up the video.


Then later i will have to tune my capture settings to prevent wrong YUV colors, i can probably use Histogram and Pause it and tweak around.

[zerowalker]

Here is a more "Realistic" sample, i now have the settings on default (Brightness etc).

Now, i have use the script to see illegal colors, but sadly, i don´t know how to fix it within the capture settings, as i don´t know, what U V range is.
I know that Y should be from 16-235, not higher or lower, but i dont know anything about the others, so i can´t play around with those Hue settings.

[jagabo]

U and V need to be between 16 and 240. But just knowing that doesn't help much -- not all combinations of Y, U, and V within their respective ranges are legal.

If you're going to be filtering, you don't need to worry too much about whether the values are 100 percent legal. You can correct them later. As long as they aren't crushed at the bottom or top.

Your last cap has luma crushed at Y=16. Notice there is nothing below Y=16 and there is a solid line right at Y=16:

Y:


U:


V:

[zerowalker]

Your last cap has luma crushed at Y=16. Notice there is nothing below Y=16 and there is a solid line right at Y=16:

Don´t see the solid line, you mean the white noise stuff below, they just stop at the edge on both right and left doesn´t it?

But here i did an adjustment, does this have legal Y?

EDIT:

Oh do you mean at the bottom of the white noise?
If so, then i totally see it.

[jagabo]

Your last cap has luma crushed at Y=16. Notice there is nothing below Y=16 and there is a solid line right at Y=16:

Don´t see the solid line, you mean the white noise stuff below, they just stop at the edge on both right and left doesn´t it?

But here i did an adjustment, does this have legal Y?

EDIT:

Oh do you mean at the bottom of the white noise?
If so, then i totally see it.

I guess "solid line" is a bit of an overstatement. The bright horizontal line segments at Y=16:



The implication of those bright lines is that parts of the picture went below Y=16 but the capture card or settings crushed them up to 16.

By the way, I cropped away the black borders to make sure we were looking at the picture content, not the black borders.

ds004.avi only has a tiny amount of crushed blacks at Y=16.

[zerowalker]

Yeah i see it clearly now, i thought it was on the Left to Right, but then saw that it was Top to Bottom.


But i wonder, does All devices use the same YUV ranges?

Meaning, can i use Xbox in PAL and tune my capture settings there, and it will be the same with the VCR?
Or can the ranges differ?

[jagabo]

But i wonder, does All devices use the same YUV ranges?

In theory, yes.

Meaning, can i use Xbox in PAL and tune my capture settings there, and it will be the same with the VCR?

In reality, No. Especially with VHS, devices differ quite a bit. For VHS, each tape, even each recording, may vary significantly from the spec.

[sanlyn]

You did a little better with Y levels, just needed a tiny nudge upward, maybe 10 points. The scene itself has a very odd color balance; contrast looks too thin, which would lead you to expect a "bright" image. Yet it looks rather grim. But here is an image that might let you understand what is meant by "crushed" darks:

(original, frame 64 of ds004)

[Attachment 13613 - Click to enlarge]

Look at the darkest colors to get idea of suppressed shadow detail. Try the young man in the dark suit, standing behind the two older adults. What color is his suit? Blue? well, not really blue because there's some other color in there. Red? Hard to tell? It sure is, because lume itself is creeping into crush territory and red is depressed down there. The other problem can be seen from the hospital sheets and gowns. Shouldn't they be white? Maybe this hospital has cyan sheets and clothing (blue+green). Look at the older woman's hair; is it blue? (As a matter of fact, it's mostly blue). It's a little hvague to indentify hair and skin color here, because there is so much blue in the picture.


[Attachment 13614 - Click to enlarge]

Start with ColorYUV(off_y=10), or off_y=15. "off" is an offset that shoves y to the right, into the brighter area, here by 10 or 15 points. Work with other colors later, as off_y will usually bring other colors up with it.

The rest is fiddling with colors in YUV and RGB. The young man is wearing a brown suit (and now you can see the detail of his lapels). The young woman's hair is red. This pretty much has to be the case, because if the sheets are made white, and gowns white, and the shadows in the garments are closer to gray, and the old woman's hair is gray, and the blacks are really shades of black, then the other colors fall into place.

[jagabo]

TV white is RGB=255, Y=235. TV Black is RGB=0, Y=16. Y<16 is "blacker than black" and should appear on TV the same shade of black as Y=16. Y>235 should be the same brightness as Y=235 on TV, though in practice it often shows brighter. In any case the upper end isn't critical like the bottom end.

There's no reason to believe that particular shot wasn't intended to be dark and bluish. I wouldn't judge colors by one shot, but by the balance of the entire recording.

[sanlyn]

True, I'm guessing from the objects in the image. You have to watch the whole movie. The best part is when the Green Bunnies come marching down the orange street. No, I don't think so. Unless that's a dream sequence, this doesn't look like a movie i could watch without getting seriously irritated. In any case, the black levels in the top image are dark enough to look vague and murky. If this was the director's intention, leave everything as-is. I'll try to find an illustrative graphic that looks more like something from life.

So PC white is 255, TV white is 255. ...When Avisynth converts PC range to TV range, it actually converts RGB 0-255 to .... 0-255? I understood the valid NTSC/PAL chroma range to be 16-240, and 16-235 for luma. Do we have new names for that color and luma range? Would you really feed a 16-235 signal to your TV and expect it to show up as 0-255? I had a CRT that could do the 0-255 thing (you see the difference between RGB 235, RGB 240, RGB 245, and RGB 250, and RGB 255. My Sony LCD can't do that: the brightest I've seen on it is RGB 238, and the darkest was RGB 15. So, I'm not sure what we can call the color range we're trying to illustrate, but colors that run up to 255 and start climbing the right-hand walls will be wash-out when encoded and when shown on TV. Colors below RGB 16 can be a bit edgy, but start looking rather dank and dingy by RGB 8 or 10. Below that, your monitor might or might not be able to display anything meaningfully detailed (some can, some can't), but by RGB o you're definitely not going to be reading any fine newsprint. Below RGB 0, the furnituire and everything else disappears. That's on a PC, y'see. On a TV, above 235 and below 16 you're just burning electricity for no discernible purpose.

So let's back up. I don't agree that TV's display RGB 235 as 255. They display it as 235. Above 235, you got nothing. I don't agree that TV's display RGB 16 as 0. They display it as RGB 16. Below 16, you got nothin'.

So now we are going to have to roll around with the names again, I guess. What is NTSC white? What is PAL white? What is NTSC zero? What is PAL zero. If I want to advise someone to stay within a certain ange for valid colors in an RGB\PC environment, what are the names and values I should give those chroma and luma limits? Avisynth refers to 16-235 by "TV" range. Avisynth refers to 0-255 as "PC" range. These are the same terms used in docs for ColorYUV, Tweak, SmoothAdjust, and a bunch of other guys.

So, what's the names for this week? Jeez.

[poisondeathray]

So let's back up. I don't agree that TV's display RGB 235 as 255. They display it as 235. Above 235, you got nothing. I don't agree that TV's display RGB 16 as 0. They display it as RGB 16. Below 16, you got nothin'.

That's true. And this sounds stupid, but RGB is RGB. If you feed an RGB signal, you are using.... RGB.

But the confusion only occurs when you do Y'CbCr<=>RGB conversions. That's what the "matrix" in avisynth refers to . If you want to see the math equations used for converting back & forth, look here
http://en.wikipedia.org/wiki/YCbCr

And that's the problem... No common end delivery format uses RGB. They all use Y'CbCr

What is NTSC white? What is PAL white? What is NTSC zero? What is PAL zero.

Always, "legal" video is 16 < Y' < 235 , 16 < CbCr <240 . "black" is Y' 16. "white" is Y'235. It's the same for PAL/NTSC. Notice RGB is never mentioned. RGB isn't a common method used to store or transmit video. Those areas <16 , >235 are for undershoot and overshoot and small excursions are allowed.

Avisynth refers to 16-235 by "TV" range. Avisynth refers to 0-255 as "PC" range.

These usually refer to the matrix (again this is only when doing Y'CbCr<=>RGB conversions and the most common source of confusion). But you should always specify whether you are referring to Y' values or RGB values to avoid confusion

But that statement above could just as easily refer to 16-235 Y' being legal TV range. 0-255 RGB is "PC range" . T

In avisynth matrices (which a Y'CbCr <=> RGB conversion is occurring):
Rec matrix means RGB 0,0,0 <=> Y' 16 CbCr 16 ; and RGB 255,255,255 <=> Y' 235 CbCr 240

PC matrix means RGB 0,0,0 <=> Y' 0 CbCr 0 ; and RGB 255,255,255 <=> Y' 255 CbCr 255

If I want to advise someone to stay within a certain ange for valid colors in an RGB\PC environment, what are the names and values I should give those chroma and luma limits?

Luma and chroma only refer to Y'CbCr, not RGB. The bottom line is you need to end up with Y'CbCr values between those "legal" values listed above (small excursions allowed into headroom and footroom territory) . But how do you get to/from RGB to Y'CbCr? This is why you can't give any detailed advice unless you know what their workflow is - because different programs do RGB<=>Y'CbCr conversions slightly differntly. For example avisynth's "PC or Full Range" conversion is very similar to "Studio RGB" used in broadcast and other programs, but the numbers are slightly off. They should be using vectorscope, waveform monitor to monitor "legal" values within those programs - the reason being they have to know what colorspace and coversions are being done within that program. In avisynth you can see approximate "legal" Y'CbCr values with coloryuv(analyze=true) , Y' with histogram() [ which is really a Y waveform monitor] , or with videoscope() on YUY2 data . RGB values aren't very useful to monitor for these purposes - The bottom line is Y' 16-235 CbCr 16-240 (with excursions)

[sanlyn]

OK, that I understand (and further clarification is appreciated, from you and jagabo alike). I've been looking at those formulas for a while now. But someone who is new to working with light and color on a computer finds it difficult to relate YUV source with what shows up as RGB on a PC monitor (or RGB on a TV, for that matter). What I'm trying to get across is that video source (in some form of YUV) and PC graphics (some form of RGB) are similar in some ways but very different in others. Because of the differences, one should work within limits that keep those differences from blowing up everything. If you try to stay within the boundaries that are shown in histograms, waveforms, vectorscopes, etc., and suit your methods and numbers to what you're working with (video for PC, video for TV, still photo, printing, etc.), the results should encode optimally and display on PC and TV without major problems. The safe range for any display can be graphically viewed with any of several types of 'scopes and 'grams. Exceeding the marked boundaries and smashing against the extreme borders of those 'scopes and 'grams should be avoided.

The two images I displayed may or not be appropriately levelled or colored for whatever the video's original purpose might be. But the principles demonstrated, in this case, intended to show how improving the darkest levels in YUV can avoid certain display problems and can change/improve/enhance the results. In other words: here are symptoms of some problems, and here is one of several ways to fix it.

[poisondeathray]

If you try to stay within the boundaries that are shown in histograms, waveforms, vectorscopes, etc., and suit your methods and numbers to what you're working with (video for PC, video for TV, still photo, printing, etc.), the results should encode optimally and display on PC and TV without major problems

Exactly. All you can do is try keep it legal .

But in real world, there are so many combinations of display calibration, graphics card settings, renderer, etc... that it's almost futile. You have no control over how end user has things set up. That' s why there are so many threads about why things are too dark, or too bright , or washed out - and most of the time it's just a display setting issue

Yes, there are defined standards by ITU, and the precise standards are well defined in various documents and books, but even within "pro" workflows, there are so many quirks and variables. e.g. Quicktime and mac bugs (the dreaded gamma shift bug), Vegas' "Studio RGB" vs "Computer RGB" , many many more. Certain types of Y'CbCr video are handled differently by certain programs (even though the Y'CbCr levels are the same, because it uses a different compression scheme, or maybe exact same video in a different wrapper it might be interpreted entirely differently !). So it's difficult to give any advice unless you know the software and exact workflow being used . There are simply too many variables. The only generic safe thing to say is keep it legal (which of course isn't very helpful).

[sanlyn]

Yes, "keep it legal" is a bit vague -- like a lot of this stuff. But I guess that's where you have to start. Monitor calibration is something else. I just have to trust my XRite and EyeOne colorimeter. It's working so far, thank heaven for that at least.

[poisondeathray]

Yes, display calibration is different can of worms, and is the very last point of discrepancies, but there are multiple points before that can cause a completely different set of results.

Even waveform monitors, RGB histograms etc - which are objective - are meaningless unless you have them set up correctly, and interpret them correctly. They can show different results with the exact same video.

[zerowalker]

Woah that was much discussion there about RGB and YUV ranges!

Yes, "keep it legal" is a bit vague -- like a lot of this stuff. But I guess that's where you have to start. Monitor calibration is something else.

I am not doing Monitor calibration, but capture calibration.
And well i was going to use my Xbox to play a calibration (you know, color bars etc) and then go after that, so atleast the YUV ranges should all be "correct", but if the Tapes themself differ, then it´s well, the tape?

I know that analogue isn´t liek Digital (Right or Wrong so to say), but it should be easier to maitain the legan ranges, as from my previous tests, Xbox and VCR etc, have the same YUV ranges in the Y range atelast, both get crushed at the same settings etc.

So maybe colors are the same when it comes to the crush stuff?
Except for tape disorder and the fact that VHS doesn´t allow True Black and Perfect Colors etc.

[sanlyn]

As you've stated, various sources differ in themselves, and they'll differ by player. You do what you can with capture settings -- although exact correction scene by scene is rarely possible, especially with VHS. During capture you set up a "safe" range to keep from seriously losing anything. You can always tweak later, and it's often necessary.

Monitor calibration doesn't affect histograms. It's an important element, but don't get into a panic about it until you learn a little more about gamma, contrast, and all that endless garbage. Monitors are calibrated in order to display images accurately., i.e., to add or subtract as little as possible from what is in an image when it displays for you. A minitor is calibrated (adjusted) to display according to accepted standard for accuracy in grayscale, saturation, gamma, contrast, etc. You can't adjust a monitor to "look good" on every TV or monitor in the world. That's not possible. You have no control of how people set their displays. What you do control is how well your own gear can match commonly used standards (perfection isn't possible!). Calibration software and hardware designed for PC's follows those standards.

[zerowalker]

During capture you set up a "safe" range to keep from seriously losing anything

Exactly, that´s what i want to do by calibrating, so i can choose those "safe" ranges, as the default have crushed lumas and stuff, doesn´t matter what player, it´s just, well wrong settings or something.

Then the White Crush is what makes Bright placed look gloomy, i have very very hard time tweaking this, as i don´t know where it´s supposed to be. I only tweaked it so that a certain picture which totally "Whitened" the image so much that you barely saw anything got good. It´s adjusting automaticly while playing, and by default, it can´t handle fast changes to white, it takes a long time for it to adjust, so i changed it a bit, don´t know if it´s to harsh though.


But Monitor Calibration isn´t perfect as you can´t display all the colors correctly with consumer grade monitors atleast.
Maybe with 10bit and OLED/PLS stuff, we are starting to come to the srgb, and eventually NTSC (not the video format), but it´s not close, as 10 bit monitors aren´t well known for consumers, and aren´t usable to the consumers without special graphic card or hacked drivers.

[sanlyn]

During capture you set up a "safe" range to keep from seriously losing anything

Exactly, that´s what i want to do by calibrating, so i can choose those "safe" ranges, as the default have crushed lumas and stuff, doesn´t matter what player, it´s just, well wrong settings or something.

It's possible that a capture device is too dark at its default settings, so some adjustment might be needed. However, every input source will have its own problems as well. So you'd have to make a quick check with each source. You likely can't use exactly the same settings for every source. It's not that your capture has changed; it's that your source changes.

Then the White Crush is what makes Bright placed look gloomy,

White crush wouldn't mean your video is too dark. It usually means contrast is too high (the brights are too bright). Black crush occurs at the opposite end of the spectrum: dark colors are too dark.

i have very very hard time tweaking this, as i don´t know where it´s supposed to be. I only tweaked it so that a certain picture which totally "Whitened" the image so much that you barely saw anything got good. It´s adjusting automaticly while playing, and by default, it can´t handle fast changes to white, it takes a long time for it to adjust, so i changed it a bit, don´t know if it´s to harsh though.

AGC should never be used during capture. A big problem. There's no way to fix its effects after capture.

You should learn to read histograms. You can also "eyeball" the captured image, but histograms are easier and more precise. How To Use Histograms shows examples. The histograms shown are RGB types, but the principles can be observed with various histogram styles in Avisynth and VirtualDub. There are also photos that show how various problems appear.

But Monitor Calibration isn´t perfect as you can´t display all the colors correctly with consumer grade monitors atleast.
Maybe with 10bit and OLED/PLS stuff, we are starting to come to the srgb, and eventually NTSC (not the video format), but it´s not close, as 10 bit monitors aren´t well known for consumers, and aren´t usable to the consumers without special graphic card or hacked drivers.

OLED is probably quite accurate. Currently there are couple of 60-inch OLED TV's available for about $8000 USD. There are also smaller pro-level "video monitors" for computers that cost about the same (and more). But most people use consumer LCD's calibrated with affordable software and hardware designed for that purpose. A 10-bit monitor that displays expanded NTSC or PAL colorspace requires re-learning all over again, not to mention a pro-level graphics card ($1500 USD and up) that can handle it. In any case, OLED's and pro monitors also have to be calibrated using software/hardware similar to that used in consumer units, but at 5 to 10 times the price.

But most normal human beings and many pros use good quality LCD's calibrated with something like XRite software and EyeOne colorimeters, which are popular with a great many users worldwide.
Here's one at work on a Dell consumer LCD: http://www.tftcentral.co.uk/reviews/eye_one_display2.htm . Such a typical setup might not be perfect, but it's 'way ahead of a poorly adjusted unit.

http://www.lagom.nl/lcd-test/

[zerowalker]

However, every input source will have its own problems as well. So you'd have to make a quick check with each source.

Yes i know, will try to check it out, but i am pretty confident that the Luma levels has been the same in the captures.

AGC should never be used during capture

I am talking about the White Crush there, are you telling me i should have it disabled?

currently there are couple of 60-inch OLED TV's available for about $8000 USD

I don´t see the problem? ;P

But most normal human beings and many pros use good quality LCD's calibrated with something like XRite software and EyeOne colorimeters, which are popular with a great many users worldwide.

So you recommend me to check out those and try to calibrate my screen?
How come it isn´t "Perfect" from the start?