Any broadcast engineers in the house?

[DDogg]

Does anybody know if there is a filter for Avisynth to correct color and saturation to legal broadcast limits? I am a bit confused on the subject and would appreciate any information and education.

I recently hacked together a short training video for my wife's business. I noticed a few of the colors used in the purple spectrum would not make the trip to ntsc TV. While I can use a commercial program to remedy this, I was hoping there might be a method using avisynth. Any suggestions?

[Boulder]

Would Limiter (included in Avisynth2.5 beta) be of any use in this case? SansGrip's LegalClip has the same functionality for AVS2.0x.

Quote from avisynth.org docs:

Limiter(clip clip, int min_luma, int max_luma, int min_chroma, int max_chroma)

This filter is present in v2.5. The standard known as CCIR-601 defines the range of pixel values considered legal for presenting on a TV. These ranges are 16-236 for the luma component and 16-240 for the chroma component.

Pixels outside this range are known to cause problems with some TV sets, and thus it is best to remove them before encoding if that is your intended display device. By default this filter clips (or "clamps") pixels under 16 to 16 and over 236 (or 240) to 236 (or 240).

[scmccarthy]

While I am not a broadcast engineer and there are some in the house, I am sure there is such a flter. Someone just made one the other day.

Stephen

[DDogg]

The title should have read ..Broadcast engineers or please, anybody else with knowledge on the subject" :)

@Boulder - Thanks very much for the reply and the limiter lead. It looks like that takes care of part of the job. Now if I can figure out the saturation levels....

@scmccarthy - "...I am sure there is such a flter. Someone just made one the other day." Thanks, could you expand on this? Or, perhaps did you mean this as, 'I am sure somebody out there has done one, perhaps very recently'?

\---

As a side comment, I bugs me that much of the pro vid community tends to see avisynth as a rippers tool. I have noticed $1000.00 after effects plugins that do inferior jobs to avisynth in many areas.

[scmccarthy]

@DDogg

Sansgrip's LegalClip, I think that is it. I think is clips the luma to [16..235] and the chroma to [16..240].

Stephen

[DDogg]

Thanks, it looks like LegalClip has been incorporated into 2.5 as Limiter as I note the same descriptive text. I think there are other areas such as sat levels to make a clip broadcast legal. I am going to try to bone up on that so that I can be more coherent although I am having some trouble sorting through all the info out there. Perhaps a kind soul with the proper knowledgebase will post on the subject.

DD

[Boulder]

Glad to be of assistance. I'm sure one of the developers will get you some more precise answers.

And - welcome back:)

[Richard Berg]

I think there are other areas such as sat levels to make a clip broadcast legal.
Clamping the U/V values effectively limits saturation.

[DDogg]

@Boulder - Thanks man, it has been a while for sure.

@Richard Berg - Thanks for the info and all your work on this project.

[sh0dan]

Originally posted by Richard Berg
Clamping the U/V values effectively limits saturation.

Where did you get this? - Since only the clipped values are allowed, it is already completely saturated at these values. Same goes for luma. Clipping is safe - and actually helps compression.

luma = 16 == black, if chroma is 127!

IMO you should always end your script with Limiter() if you are compressing to a YUV destination format.

[Boulder]

sh0dan,

do you think that Limiter should be used twice, right after the line where the source clip is loaded and as the last item in the script? SansGrip suggested using LegalClip this way in some thread.

[Bidoche]

Originally posted by Sh0dan
IMO you should always end your script with Limiter() if you are compressing to a YUV destination format.
Then maybe, we should make the core make an implicit call to Limiter at the end of script in such a case.

[hanfrunz]

Hello friends of legal colors,

are these filters mentioned above only "hard-"clipping or can they be adjusted like the "professional"-hardware legalizers e.g. from Eyeheight see: http://www.eyeheight.com/01november/docs/OL-X%20%20Product%20Manual.doc

Would be very interessting if somebody could code these additional parameters like High/Low Clip Knee, Ring Suppression for better picture quality. I am just just starting in coding avisynth filters, so it could take a while i am able to do something like this ...

By the way is avisynth capable of using 10bit yuy2 videodata?

hanfrunz

[scmccarthy]

@sh0dan&BidocheThen maybe, we should make the core make an implicit call to Limiter at the end of script in such a case. Woa! This only applies to TV. The only clamping needed for PC viewing is [0..255] to avoid wrap around.

My assumption is that DVDs don't really follow the spec correctly and the information clamped off by LegalClip and the default values for Limiter...(That's another thing: there would be no point in limiter having parameters if it were a good idea to invoke it with the default parameters by default.)is useful information, except not on a TV.

When working with digital info, it is not nesessary to follow analog broadcast rules. And I think that even though everyone is supposed to, no one, not even the professional DVD encoders, are doing it. It is up to the DVD *players* to clamp the signal it reads from the disk, isn't it?

I think the picture looks better on a PC that on a TV for a host of reasons, but this might be one of them.

Stephen

[Richard Berg]

Where did you get this?
Perhaps I wasn't clear. What I mean is: limiting saturation to CCIR values is already achieved by clamping chroma to [16, 240]. Of course, videos shouldn't be outside these ranges to begin with, but if they are I was assuring DDogg that Limiter() does everything needed to produce legal video.

[sh0dan]

Originally posted by scmccarthy
@sh0dan&Bidoche Woa! This only applies to TV. The only clamping needed for PC viewing is [0..255] to avoid wrap around.


No - actually PC processing should also obey this limit - I do however agree, that this should not be done by the engine.

Most (if not all) DVD's are in the 16-235 range, the values that are outside this range is most often produced by quantization, and resize fitlering. So MPEG2DEC may very well deliver video that is slightly out of range - as can bicubic and lanczos amplify this effect.

In real life - a "Limiter()" at the end of the script should be enough - most (if not all) AviSynth filters handles these values correctly (but mostly maintains them).

Use "Histogram()" and "ColorYUV(analyze=true)" to see the luma distribution of your material.

Luma scale is 16-235 - also when delivering to XviD/MPEG 1+2 for PC use. Scaling luma beyond this limit will only give wrong "light conditions". It will not saturate, if chroma is not 127, but it'll still be wrong. Maybe "colorYUV(showyuv=true)" will help, if you can interpret it.

YUV(235,127,127) == WHITE == RGB(255,255,255)

[scmccarthy]

@sh0dan

The following quote raises a question regarding the internal greyscale filter:YUV(235,127,127) == WHITE == RGB(255,255,255) I agree here and wish to have thought of it myself, except that all my sources say it should be YUV(235,128,128). The greyscale filter sets Cb and Cr to 127. If one subtracts 128 from Cb and Cr in the YUV --> RGB conversion, that makes 128 the true neutral value, c'est vrai?

I know I sound challenging, but obviously I would like to know of a source that tells you differently, whether I agree with it or not. One must nail down the popular misconceptions on the way to the truth. For one thing, there is no way to know which is which until one looks at both. So it is always my wish that we can all be open minded together. Which, I am sure you are, by the way.

For the other part of the equation, I sometimes toy with defining WHITE == RGB(219,219,219). The argument for this is that multiplying Y by 255/219 actually reduces the quantization levels available. Most likely, I am completely off base and will eventually drop this line entirely, but my point is, there is no need to assume that the header and footer information in Y is irrelevant.

It is safe and simpler to only clip YUV to avoid wrap-around. I am assuming you agree and that's what you meant by this: I do however agree, that this should not be done by the engine.
Stephen

[hanfrunz]

"CCIR Recommendation 601-1 Table 1 (Encoding parameters for the 4:2:2 member of the family" says:

8. Correspondence between video signal levels and quantization levels

-scale: 0-255
-luminance signal: 220 quantization levels with black=16 and peak white=235. The signal level may occasionally excurse level 235
-each colour-difference signal: 225 quantization levels in the centre part of the quantization scale with zero signal corresponding to level 128

9. Code-word usage: Code-words corresponding to quantization levels 0 and 255 are used execlusively for synchronization. Levels 1 to 254 are available to video.

hanfrunz

[scmccarthy]

The signal level may occasionally excurse level 235 I have considered whether this means that the signal beyond 235 is valid or is merely a consession to the fact that head room and foot room is there because it is impossible to stay within the proper limits and to avoid wrap around. I have read 601, 709, and 801.

But obviously levels 0 and 255 are completely legal on the computer. How best to represent the picture on the computer screen when all the specs are geared toward the TV is what I ask myself. Certainly 0 and 255 are not used for synchronization in my little avi files.

I'll quote myself again: Most likely, I am completely off base and will eventually drop this line entirely, but my point is, there is no need to assume that the header and footer information in Y is irrelevant.
Stephen

[Azash]

Wow. I'm looking for the solution to a problem I'm having in transferring my miniDV camcorder material to DVD (to give to parents and for my own storage / viewing on an NTSC television), but much of what I'm seeing in this thread is above my knowledge level at the moment. Perhaps my answer IS here, if someone would care to examine my problem and maybe tell me how it applies to the information above-

In several scenes of my current project, my daughter is playing in the snow. She's wearing a hot-ping snowsuit, but after the conversion, the ping is actually being accented so much that it's causing what appears to be a glowing effect on the television (it's more of a neon pink after the conversion). Likewise, a few areas where my 13 month old son has some bright red toys in the scene, the toys appear to be a bit too bright (though not so obvious as the snowsuit). I'm using the CCE SP Trial encoder, combined with the Canopus DV codec, with some pretty basic settings right now, including using 16-235 for the range. Other than the issues mentioned above, the quality of the output is actually exceptional.

Any clue what I can do to adjust to encoding to reduce the effect I'm seeing?

[scmccarthy]

@azash

The bottom line of this thread is straight forward. Use limiter() when encoding for TV viewing. It conforms the signal to the ITU-R BT.601 recommendation. Well, now someone might suggest that that is not all one must do to make the signal fully compliant. What do I know? But it might solve your problem.

Stephen

[TelemachusMH]

I know this isn't exactly the topic, but isn't DVD2AVI's PC vs TV scale suppost to do this? If not, what does it do?

TelemachusMH

[DDogg]

There might be some useful info here although primarily target at the DV audience.

http://www.sonyusadvcam.com/content/article_39.shtml

http://www.ajavideo.de/technic/colorspacing.html

http://seb.av7.net/reglage/Brightness_and_Contrast.pdf

Ahh, finally found this:
http://www.gimlay.org/~andoh/cg/faq/ColorFAQ.html

Good Score:
http://web.archive.org/web/20020124025939/http://www.dv.com/magazine/2000/0400/luminanceranges0400.html

From the above link:
"Digital definitions
The majority of computer graphics software, including most paint, 3D, and compositing programs, use intuitive definitions: Black is zero percent brightness, with an 8-bit-per-channel RGB color value of 0/0/0; white is 100 percent brightness, with an 8-bit-per-channel RGB color value of 255/255/255. You can't get darker than black or brighter than white. We'll call this system computer luminance, with a range of 0 to 255.

However, many digital video systems use a different set of definitions: Black is just over six percent brightness, with an RGB color value of 16/16/16; white is just over 92 percent brightness, or an RGB color value of 235/235/235 (again, based on 8-bit-per-channel ranges). This system, defined by the ITU-R.BT601 specification, is used by most digital video equipment-in VTRs from DV to D-1 and in digital video connections such as SDI and IEEE 1394/FireWire. We'll call this system 601 luminance, with a range of 16 to 235.

The 601 system allows colors that are darker than black and brighter than white. This is especially important for cameras. If you shoot an object that has a bright spot hotter than legal white, you can later recover the detail in this hot spot. Going darker than broadcast black is also used at times for sync signals, as well as some primitive keying applications such as "superblack," where systems mask or key out areas of an image blacker than black....Much more "

http://www.adamwilt.com/DV-FAQ-editing.html#CodecProblems

[sh0dan]

The link you quote is actually the most misleading. Most of the other links are ok.

There is a significant difference between RGB and YUV colorspace, which your quote gets wrong:

RGB(16,16,16) != BLACK - in any definition.
RGB(235,235,235) != WHITE - in any definition.

However:

RGB(0,0,0) = YUV(16,127,127) = BLACK
RGB(255,255,255) = YUV(235,127,127) = WHITE

This is YUV-scale is true for both DV, MPEG and similar formats, and is widely accepted.

However the issue isn't that big, as long as "superblack" and "superwhite" is passed through the application. When you convert to RGB these values are however mapped to pure black/pure white, and cannot be restored.

The only problem is if any application scales luma wrong - ie. converts RGB to 0-255 luma/chroma - this is clearly wrong. Same goes for the reverse translation (YUV black/white being mapped to non-black/white RGB).

The "colorspacing" link is good explanation - it doesn't mix up RGB/YUV issues.

[scmccarthy]

@DdoggHowever, many digital video systems use a different set of definitions The entire quote is misleading unless you is understood what is meant by a 'digital video sysetm'.

The next paragragh explains that the '601 luminance' is used for internal processing only:Many hardware systems never expose you to the fact that internally, they are using the 601 luminance range. Externally, these systems present you with the computer luminance range. When they decode or decompress a frame for you to use, they automatically stretch 16 down to 0 and 235 up to 255, scaling the values in between as needed and squeezing out the values above or below the 16-to-235 range. Likewise, when they encode or compress a frame to play back later through their systems, they squish 0 up to 16 and 255 down to 235. Avid, Scitex, and Digital Voodoo all have digital video codecs that can do these translations for you (see Figure 1). The Color Spacing page explains why using the same values for luminance between RGB and YUV is good:the level re-mapping is really a gain operation which introduces error This only applies to processing the video, n0t displaying it on your computer screen. RGB 235,235,235 is not white enough and would be wrong, unless a Y value 255 were true white, due to a capturing error. It is unlikely it would really be that far off.

The quote also mentions the one use for preserving the headroom and footroom info:This is especially important for cameras. If you shoot an object that has a bright spot hotter than legal white, you can later recover the detail in this hot spot. Making an adustment in this case would only look good if true white were really higher than legal white. I don't own a camera, so I do not know how someone really does correct that mistake.

Stephen

[DDogg]

I just wanted to contribute some time doing the grunt work of a search on the subject and put the links up as an information resource for the group. One does tend to assumed a reputable source has correct information (yeah, I know about assume:) ).

I wonder if it is a matter of fine interpretation of the wording or if it is truly dead wrong. If so, we need to pull down that particular link so as not to cause any more confusion to the confusion.

[scmccarthy]

@Ddogg

Not to allow any confusion to creep in: the site is 100% right. But bear in mind, the site is discussing editing of DV material. But this thread discussed how to view it on a TV and computer screen. It does not matter what formula you use for color space conversions as long as you use the exact inverse to convert it back again after editing is done. But there is still only one right way to convert 601 YUV to computer RGB for viewing on your computer monitor. I am not contradicting myself. Only follow the difference between intermediate editing and possibly correcting bad white levels of captures and displaying.

DV.com explains how to move betweem hardware video systems like Media 100 and computer software programms like After Effect. Another of your links is about Sony DVCAM and moving from that hardware to Quicktime. Again, the difference is between computer software and stand alone video editing tools.

Stephen

[DDogg]

scmccarthy, thanks for the clarification.

BTW,you mentioned above:
I have read 601, 709, and 801.
Yum, I'll bet that was a real hot page turner. A veritable thrill a minute! :eek:

[scmccarthy]

I helps me verify that the following is accurate:

Below is the aforementioned matrix and its inverse:

Y = ( 0.299R + 0.587G + 0.114B)(219/255) + 16.
Cb = (-0.299R - 0.587G + 0.886B)(112/255) + 128.
Cr = ( 0.701R - 0.587G - 0.114B)(112/255) + 128.

B = (255/219)(Y-16) + (255/112) · .886(Cb-128).
G = (255/219)(Y-16) - (255/112)[((.886·.114)(Cb-128) + (.701·.299)(Cr-128))/.587].
R = (255/219)(Y-16) + (255/112) · .701(Cr-128).

[scmccarthy]

The previous post can be verified in 601, 709 offers an updated and more accurate definition of Y, Y = 0.2126R + 0.7152G + 0.0722B.

801 gave me the color bar colors of 75% luminiosity and 100% saturation in YCbCr.

But the tricky part is knowing your limitations and not misapplying the info. As the saying goes 'a little bit of knowledge is dangerous'. That and wading through the relatively short documents to find the info you are looking for. The newer def. of Y, for instance, can only be used to convert RGB to monochrome RGB, YV12 and YUY2 uses the 601 def. of Y and 601 must be used (and of course is used in all the codecs) to convert it back to RGB, accuracy not withstanding.

Stand alone hardware video editing tools can use their own color space converson formulas: as long as they use the exact inverse of their formulas to return their files back to the standards. For instance, in the matrices in the previous post, 255 is there to stretch the luminosity into the RGB 000->255,255,255 range. Substituting 219 for 255 for both matices will work, as long as you convert back again. It would give an RGB 000->219,219,219 instead of RGB(16,16,16)-->RGB(235,235,235), but the range of luminosity would be the same. That is YV12-->RGB219 and RGB219-->YV12 will leave you with a YV12 file that is OK. There would be no point in stretching the luminosity scale if you plan to save your data back to YV12 anyway. The RGB219 file would not look good displayed on your screen.

I hope I am not just repeating myself, I thought a further expanation might bring us all on the same page.

If someone wants to write a plugin that converts to RGB for processing purposes only, this would be a better approach. And that is why I want the AviSynth developers to understand this. It does not have any bearing on the proper codecs to display mpeg-4 on computer screens and TVs. It is only a good trick for the processing of files.

The previous post was posted prematurely. I did not mean to make two posts back to back, I just hit the wrong key.

Stephen