TMPGEnc - "Output YUV data as Basic YCbCr not CCIR601&q

[ChachiFace]

After reading this post:

https://www.videohelp.com/forum/viewtopic.php?t=176980

I did a test and compared 2 files of the same footage: one with the option enabled and the other without. I found that the one that had the option enabled had darker blacks and brighter whites. The same footage that did not have the option enabled looked okay, if I hadn't tried this I would not have noticed the difference. I compared both samples on a TV. My questions are:

Are you hurting the quality if you use the "Output YUV data as Basic YCbCr not CCIR601" option when you don't need to?

How do you know when you need to use this option and when you don't? Is this just something that you have to visually look at?

My sources were:

.avi file captured with a datavideo dac-100 using Adobe Premiere 6 LE. I then encoded as .m2v and .wav using TMPGEnc Plus. I'm not sure if I need to use this option or not but would like to know that if I decide to use it in the future that I'm not 'hurting' anything if I really don't need to use it.

ChachiFace

[adam]

You have to set this option correctly or else, yes you will degrade quality. Depending on your source, you either want this checked or unchecked.

With a source in the 16-235 luminence range, you want to enable this setting.

With a source in the 0-255 luminence range, you want to disable this setting.

The problem is knowing what your original source is, and knowing if it has changed at any time before getting to the encoder. See the 0-255 range is what a pc uses, so even with 16-235 sources many codecs will stretch out this scale without you knowing it.

Most sources are going to be 16-235 already. If its stored in YUV format than its definitely in this range, because that's all this format supports. If its RGB, its still going to 16-235 if you either got it off the tv, or if it was in a format ready for tv, ie: VHS, DVD, laserdisk, etc...

If it was created on or intended to be played on a pc, then its probably in the 0-255 range. Also non-dv camcorder sources will also be in the 0-255 range. DV is always shot in 16-235, though some codecs can change this once you get to the computer.

As for what any codecs you might be using will do to your source, much of this info is readily available on the internet. For instance the Canopus DV codec is known to compress the luminence scale down to 16-235 (don't ask me why.) If you aren't sure what is happening to your source, you can run a histogram before encoding. Check to see if any values roll off the sides or if they reach the very outer edges. If so its in the 0-255 range, and should be compressed back to 16-235. If the values consistently roll off just a little bit from the edges, then its in 16-235.

The good news is that once you find out what happens to your source using that particular set of programs/codecs, then you know the result will always be the same. So in your case, your source is obviously 16-235 since it was captured from the tv. I assume you frameserved to TMPGenc from Premiere? If so then good, you cut out the need for any intermediate codecs so you know nothing about your source was changed. Since its still in the 16-235 range, you want to keep it that way since that is what a tv requires. By enabling the "Output YUV data as Basic YCbCr not CCIR601" you have done just that, and have preserved the full range of your luminence values. That is why you get "true" black and white, or in other words the blackest blacks and the whitest whites that your tv can display.

If you had not enabled this option, then TMPGenc would have further compressed the lumince values, despite the fact that the necessary compression was obviously done when the footage was originally mastered for broadcast. As a result, you would have compressed your colors down moreso then they needed to be, and so you do not get the full range of colors that your tv supports.

Generally speaking, the "Output YUV data as Basic YCbCr not CCIR601" option should be CHECKED more often than it should be unchecked. I don't know why the default is unchecked, I suppose its just to be safe. Overcompressing your lumince scale is bad, but undercompressing it is REALLY bad.

[SaSi]

Adam,

does this setting have to do with NTSC? I am not certain on this, but I've read somewhere about NTSC encoding and the luminance range "shrinking", also connected with "safe" luminance values for NTSC.

Should one assume that the best thing to do for PAL is to disable it 0 i.e. allow the full 0~255 range?

[adam]

From what I have read, yes PAL tv's do support the full luminence range so you would want to keep it 0-255. You damn PAL people are spoiled I tell you. You get full colors and ours are Never The Same Color.

But, I'm guessing that was just a typo in your post. If you wanted to keep the full 0-255 range then you would want to CHECK this option. If unchecked, it compresses the luminence ranges. If checked it leaves them as is.

[SaSi]

You damn PAL people are spoiled I tell you. You get full colors and ours are Never The Same Color.

But, I'm guessing that was just a typo in your post. If you wanted to keep the full 0-255 range then you would want to CHECK this option. If unchecked, it compresses the luminence ranges. If checked it leaves them as is.

Yes, it was a typo - partly - and confusion on the enable/disable setting - mainly.

And, yes, I guess we PAL people are spoiled. No drop frames every (I forget) to try and simulate the irregular frame rate, no requirement for an AC3 or LPCM audio track on the DVD for compliance, and more scan lines - 576 vs 480.

But I think NTSC countries had color TV before we PAL countries invented them, so that's a compensation.

Is HDTV going to change all this? Or will MPEG streams use the same frame rate by 2 and a different frame size from PAL?

[nimco]

Adam,

I know maybe this is not right topic for it but could please share your experience and explain what are correct Luminance Level settings for CCE for 0-255 and 16-235 luminance range material. For RGB and YUY2 color space. I edit DV (16-235 luma range) in Vegas Video and frame serve it through PluginPac Frame Server to CCE. Which box should I check 0-255 or 16-235 if I do not want to compress RGB luminance range and mpeg is intended to be played on TV?
And finally I still do not understand what is correct way to deal with the field order flag setting for DV bff interlaced material:
1. Uncheck "Upper Field First" and after encoding change field order flag in Restream.
Or
2. Check "Upper Field First" and do not do nothing else?

Thanks,

Nimco

[adam]

Basically, you set CCE to the opposite of what your source is. If your source is 0-255, then set CCE to 16-235. If its 16-235 set CCE to 0-255.

YUY2 will always be 16-235, so 0-255 would be the correct setting to use in CCE, though logically it shouldn't matter because since it is never stored in the RGB colorspace, there is no reason why the luminence range should change. But just to be safe, stick to 0-255.

For RGB sources, you have to know the ranges of your source and set the encoder accordingly. There is no other way. This requires knowing what the luminence range of your source is but more importantly knowing what all the intermediate codecs/applications are doing to it before it reaches your encoder.

If you are using 16-235 sources and frameserving directly to CCE, then you should have 0-255 set.

1. Uncheck "Upper Field First" and after encoding change field order flag in Restream.
Or
2. Check "Upper Field First" and do not do nothing else?

Either of those will work, but out of the two I'd select #2. CCE's method of reversing field order is a bit strange. It crops the top scan line. So now all your even lines have become odd and vice versa, effectively changing the field order. This won't really hurt anything unless you have customized your avisynth scripts for particular purposes (resize to mod2 etc...) but still, I don't like the idea of just throwing out a scan line.

There is a 3rd way which you can implement if you use avisynth, however. Read the "3.1.1 Create an AviSynth script" section in this very well written FAQ. http://forum.doom9.org/showthread.php?s=&threadid=60392

In fact, I recommend you read the entire FAQ, it outlines some very good ways to process your DV footage to DVD.

[nimco]

Adam, thanks for your so completed and precision answer.
Now I know exactly how to set those things in CCE.

Just the last few questions.
I frame serve my DV avi to Vegas Video, and just after editing I frame serve an avi to CCE. I assume that I cannot use a line "DoubleWeave.SelectOdd()" at the end of AVS script. So, I use "method" #1. After that I have BFF flagged mpeg with the bottom first field order.
Does the BFF mpeg meat a DVD spec. as well as those Hollywood-made DVDs with the TFF?

Is it available to check a luminance level on the mpeg file, something what Avisynth does by a Histogram function?

I am just curious, some people have found that:


"CCE encodes incorrectly long avi files, longer than 30 min (more than 2GB in mpeg)"

Do you have any comments on that?

Thank you for your time.

[FulciLives]

OK I am somewhat confused here.

I capture using PICVideo MJPEG using YUY2

I often create an AviSynth AVS script using Convolution3D as a noise filter. Sometimes I use DeComb for IVTC. Otherwise those are really the only two filters I play with for the most part.

I load the AVI into VirtualDubMod by selecting the AVS file. I perform by editing (trim the start and end and cut out commercials if it is from TV) then frameserve into TMPGEnc Plus 2.5 and encode to MPEG-2 DVD compliant.

Now I've noticed that when I DO NOT check the option for Output YUV data as Basic YCbCr not CCIR601 that the video looks fine to me but when I DO CHECK the option the video is overall darker with less detail in the dark sections (as they are much darker) and there is also a loss of detail in the extreme white areas because as they seem to be overlybright as if oversaturated. I should point out that I'm comparing the clips by loading the encoded M2V in VirtualDub (the MPEG/AC3 mod). I actually open the VirtualDub mod mentioned twice and load each M2V and click back and forth to compare.

So in my situation which is correct? I did notice that in one movie I encoded where I did NOT check the option that there were some (almost impossible to see) blockiness in the extreme dark areas of the image but that was a VHS capture so I don't know if that has anything to do with the OPTION we are talking about or just because it isn't a very "clean" source and the MPEG-2 encoder had trouble encoding it.

Anyways I'm confused so please help

- John "FulciLives" Coleman

[adam]

nimco sorry I somehow misplaced this thread

If you change the field order after encodign than it is now top field first, which is what it should be. I'm not sure if bottom field is prohibited or not.

There are lots of different things that can run histograms, and that is the only way I know of to check your luminence level. Find a scene which appears to have true black and true white. Run a histogram on it and see if your graph reaches the very edges of the screen. If so its in the 0-255 range. If it falls a little short, than its probably 16-235. You may need to test a few scenes to be sure.

Regarding CCE's encoding of large avi files which are longer than 30 mins and larger than 2 gigs...I do it all the time with no problems. I personally have never heard of anyone having problems.

[adam]

FulciLives

0-255 is what a pc uses. 16-235 is what a tv uses. If you compress to 16-235 than it will look funny on a pc monitor if played back in that range, ie: most software players will stretch it to 0-255 at playback, but if played in Vdub then it won't look right. For a proper test you are going to have to burn a sample and view it on your tv.

There may be a bug with TMPGenc in regard to this setting. I personally don't use TMPGenc for much of anything these days. I just know what CCIR601 and Basic YCbCr are and I know how this setting should work. My experience with TMPGenc is that sometimes you just have to wing it, so I guess just set this option according to what looks best to you.

If you want to run some tests to determine whether you are overcompressing your luminence scale, then use a letterboxed source. Crop about half of the top and bottom borders off and add new borders over this part. The new borders will be true black. If you have overcompressed your luminence ranges than the borders which you left will appear grayer than the added black bars. It makes for a good comparison.

Some DVDs will have that THX certification test on it. These usually have a color bar pic that you can also use. If you have overcompressed your ranges than a certain box will fade into the background and not be visible.

[Bondiablo]

just to confuse things a little further, not all NTSC sources will be 16-235 or 7.5 IRE. japan uses NTSC but 0 IRE 0-255.

[nimco]

Adam, thanks again.

And a another one problem:
What do you do with the CCE encoder Timecode Setting (in the CCE Encoder setting window) do you set it to 00:00:00:00 or keep it at default 01:00:00:00 ?
I have seen many opinions on the forums about that.
What does it really do for the encoding process?

I appreciate for your inputs.

[adam]

I don't know much about the time code other than that it is just a number assigned to the first frame which the decoder uses to keep the time of the playback. I assume it is similar to the timecode that DV uses, and is just used to maintain sync and possibly to determine the time listed in the counter display.

The CCE manual says not to use a timecode of 0 because this has a special meaning to CCE. I have never gotten an explanation about what that is supposed to mean, and 0 doesn't seem to give me any problems either during encoding or at playback. But since the default is 1 I just leave it at that. I see no difference either way. This may be a question for Custom Technology's tech support.

[lordsmurf]

My understanding of this option, as it relates to captured footage from broadcast/VHS/etc NTSC-USA sources, is that is should be UNCHECKED.

Checking it expands the range from 16-235 to 0-255. The darks become darker, and the whites whiter. This often hurts VHS transfers, with extreme dark areas and high washouts in bright areas.

If your goal is to add contrast to a slightly muddy VHS transfer, this will accomplish that goal quite nicely, and without adding oodles of time by using the actual contrast filters.

When it comes to digital source, you've got to know what you're dealing with.

Adam you wrote some interesting stuff, but I gotta tell you, that wasn't an easy read. I'm still a bit lost in some of your words. Then again, maybe I'm just too tired to be reading right now.

[FulciLives]

My understanding of this option, as it relates to captured footage from broadcast/VHS/etc NTSC-USA sources, is that is should be UNCHECKED.

Checking it expands the range from 16-235 to 0-255. The darks become darker, and the whites whiter. This often hurts VHS transfers, with extreme dark areas and high washouts in bright areas.

OK now I'm REALLY confused. What you are saying seems to go along with my AVI captures using my AverTV Stereo PCI capture card and using the PICVideo MJPEG codec. When the option is NOT checked it looks more or less normal but with the option CHECKED then the darks are extra dark and the whites are extra white ... almost oversaturated. Doing two clips (one not checked and one checked) this affect you mentioned is VERY noticeable ESPECIALLY on the computer screen.

HOWEVER ... when I burned it to a DVD-R (I didn't use a DVD-RW since my two DVD players choke on DVD-RW discs) I noticed that the difference was less pronounced and that the clip where I did CHECK the option seemed to look better in that the dark areas were truely dark whereas the clip where I did NOT CHECK the option had SOME (very few but SOME) black areas that had pixelization.

So like I said now I'm really confused hehehe

- John "FulciLives" Coleman

P.S.
Please note that the test clip I mention above (where I encoded it twice once with and without the option checked) was a VHS capture run through an AviSynth script using Convolution3D and DeComb for IVTC. So it could be the pixelization is due to a poor quality source or perhaps a side effect of the Convolution3D filter. However I will say that this is one of the better quality pre-records that I have ... in short about as good as a VHS source can get.

[FulciLives]

You have to set this option correctly or else, yes you will degrade quality. Depending on your source, you either want this checked or unchecked.

With a source in the 16-235 luminence range, you want to enable this setting.

With a source in the 0-255 luminence range, you want to disable this setting.

My understanding of this option, as it relates to captured footage from broadcast/VHS/etc NTSC-USA sources, is that is should be UNCHECKED.

Checking it expands the range from 16-235 to 0-255. The darks become darker, and the whites whiter. This often hurts VHS transfers, with extreme dark areas and high washouts in bright areas.

Does anyone notice that these two comments are the opposite of each other?

ARRRRRRRRRRRGGGGGGGGGHHHHHHHHHHHHHHH (frustration)

This is too damn confusing

- John "FulciLives" Coleman

[adam]

You can't just say this option should or shouldn't be checked with VHS captures. It all depends on how you are capturing and how that source is being fed into the encoder.

Your luminence range can easily be converted from one to the other by your capture codec or intermediate software. The only way to use this setting properly is to know what your ranges are when they reach the encoder.

If you have a 16-235 source than the last thing you want to do is instruct the encoder to encode to CCIR601 (unchecked.) This will compress the luminence ranges further than they need to be, and you have just lost dynamic range to your colors. By checking this option, it will simply leave the values the way they are...at least this is what should happen. Again, I really don't trust TMPGenc much anymore.

Once again, if intended playback is on a tv, then 16-235 source should be encoded in the 0-255 range and a 0-255 source should be encoded in the 16-235 range. I will try to find this website where I got alot of my data, it explains this much better than I can.

FulciLives your test seems to go right along with what I have been saying. Your source is apparantly 16-235 and by checking this option in TMPGenc you have preserved the full range of your luminence levels. Its supposed to look bad on a pc, its been formatted for the television.

[dinobike]

yes, i want an answewr too!!

Í've been using dvd2svcd and cce with color conversion to rgb32 ( i supose is something near as in the TMPGenc).
Do i have to enable this for making svcds?

[lordsmurf]

My understanding is as follows:

How does the tv play into all this? That has the 16-235 value as I recall.

We have ranges of 0-255 and 16-235
The tv only shows 16-235. The computer 0-255.

My videos are always a little off on my monitor, but just right on my tv set. I chalk that up to the different values in the two display devices (excluding contrast/bright adjustments).

When you tick the option in TMPGEnc, you're changing to the other format. If it is left alone, nothing is changed. I may be wrong here (with it being on way unchecked or one way checked, always), but this makes no difference in the info I supply down below. Either way.

If your 16-235 source is changed to 0-255, the colors are spread apart to look good on the computer. 0=black, 255=white (or vice versa, makes no difference in the explanation).

If you play this back on the tv, you'll get black for everything from 0-16, even if it wasn't black. The same happens for 235-255. You'll get whites for everything, even if it was only supposed to be a light color.

RGB = 0-255
YCrCb (YUV) = 16-235

I don't what the hell CCIR601 is as referred to by TMPGEnc. I thought that was the tv standard.

I pulled this quote from a video site online:
"In CCIR601, analog component signals(Y,Cb,Cr) are sampled by 4:2:2."

4:2:0 is the DVD standard. Haven't compared/looked at this yet.

YCrCb is defined as being another way to say YUV, and Y is luma which is mostly green, Cr is chroma that is mostly red hence the R, Cb is the chroma that is mostly blue hence the B. RGB for TV, though still not RGB. In YUV, the colors overlap into each other, the signals are just MOSTLY one color, not pure one color like RGB. It was described a while back by a friend as being Y the signal with CrCb being the tints. Probably not so much, but it gets the point across.

Given my results from ticking and unticking the option in TMPGEnc, I'd be likely to believe my own thoughts at the moment, independent of my understandings of the definitions of the principles that make this shit all work.

In this one situation, don't confuse me with the facts... I just want to know what works. Why can come later.

I have used the Descale CCIR filter in TMPGEnc as a contrast filter that worked better than contrast. Source was VHS video captured in MPEG2 format on an ATI card. Only came in useful on two ocassions. Other times it would make a mess. Same type of source.

Simply using the "Output YUV data as Basic YCbCr not CCIR601" option had the same effect, just a bit milder. Source was VHS video captured in MPEG2 format on an ATI card.

Given all this, I've determind that the words used in "Output YUV data as Basic YCbCr not CCIR601" don't mean squat. YUV=YCrCb. CCIR601 is the format of video, which includes YUV/YCrCb. So what the hell does this thing mean anyway?

If it is supposed to denote the changing of 0-255 to 16-235, then why doesn't it just say it?

As far as Japan being 0-255, I'd believe it. I've got some Japanese NTSC videos that look horrid on tv. The whites are TOO white (washout of light colors) and the dark browns are pure black. This was because the 0-16 range and 235-255 range was made all black or all white on the tv set. This makes sense.

And from my tests, I'd say the setting in TMPGEnc is 16-235 by default. It was made for MPEG afterall, and the VCD/DVD setting templates and settings leads me to believe they knew we'd be shooting for tv output.

Now adam, I'd love to hear what you have to say abouta ll this. But I'd rather you just post links to where you've found your information. I have a hard time following what you're trying to say (you fit right in as a lawyer, all that legal mumbo-jumbo confuses the hell out of me). Mod or not, we're all still learning here. And you've lost some of your credibility with me because of your consistent statements of "CCE is 4x faster than TMPGEnc", which I know for a fact is baloney. Not a personal attack, but if you seem to have a good source of info on this topic, please share that rather than trying to re-explain things yet again. We're all confused here, to one extent or another.

[Conquest10]

As far as Japan being 0-255, I'd believe it. I've got some Japanese NTSC videos that look horrid on tv. The whites are TOO white (washout of light colors) and the dark browns are pure black. This was because the 0-16 range and 235-255 range was made all black or all white on the tv set. This makes sense.

I know what you mean. I got this Japanese movie thats subbed and its impossible to read. The subs blend in to the background whenever there are light colors on the screen.

[DJRumpy]

I agree that the setting should have been simply labled as either 0-255 or 16-235. In either case, when checked it will essentially leave your color range 'as is'. If your video's color range is 16-235, this would be the best option to retain the luminance range 'as-is'. Unchecked it compresses your luminance range down into the 16-235 range, since it assumes your source has a 0-255 luminance range.

If your source is 0-255, then uncheck this option. Your colors will be compressed into the CCIR601 compatible luminance range, retaining as much color/luminance information as possible.

If your source is 16-235, leave it checked. This will avoid any luminance compression.

Unchecked = 16-235
Checked = 0-255

I'll try to describe this is simple terms, and please keep in mind that these are only examples (Adam, please correct me if I get any of this wrong, as your more versed in this than anyone else I know ). Imagine in your mind, a white string (your input video), cut into 10 pieces. Now image you have 8 cups to place the 10 strings into (cups being equivlent to the luminance range of your output video). The rules of the game: all the string pieces must be placed into a cup, with no cup holding more than one piece of string.

Example 1:
Ideally, the strings would be tied together to form one string again, and then recut into 8 equal pieces, to better fit into the 8 available cups. This is the equivelent of 'compressing' them to fit. This is a good thing when you have too many string pieces to fit into the available cups (i.e lumiance range).

Example 2:
Now, the same situation, but this time we have 8 pieces of white string, and 8 cups. Instead of simply putting the 8 pieces of string into the cups, we pull or more string (black string this time), cut two additional pieces to make ten pieces, and then repeat the steps in the first example (I never said we were sane in our examples ). This is a bad thing.

Example 3:
Next example. Assume we have 8 pieces of string (219 Luminance), and 10 cups (255 luminance scale). Following our rules, we simply take the 8 pieces of string, putting a string in each of the middle 8 cups, and not using the two end cups. Nothing lost..this is a good thing.

Example 4: 10 pieces of white string. 8 cups. You simply throw away two of the strings, and place the 8 remaining strings in the cup. This is a bad thing.

In example 1, what your doing is the equivelent of taking a 255 luminance scale video, and compressing it into a 219 luminance range (235-16=219). This is a good thing, assuming your source video is indeed using a 255 luminance scale. It's a necessary evil to compress the 255 luminance range into something that will display properly on your NTSC television.

In example 2, what your doing is is the equivelent of a 219 luminance scale video, being compressed even further, to fit into a 219 luminance range. This is a bad thing. Adding the extra string doesn't make sense, plus we've introduce a string color that doesn't belong with our white string. This would cause 'sparkles' in your video, where the dark areas have been compressed to much, making dark areas light enough to be visible. This is due to the shifting effect the compression has, where all colors on the scale are shifted towards the middle of the scale to make them fit (i.e 0 is shifted up towards 128 and 255 is shifted down towards 128). If a color was 16 on the luminance scale (16 being true black for a 219 luminance scale), and we compressedit even further, this color might then be 25 on the luminance scale, it would be lighter than true 'black', and it would be visible on the screen. This is what can cause your shadows to 'sparkle' with macroblock type effects.

In Example 3, your doing the equivelent of taking a 219 luminance scale video, and placing it into a 255 luminance range. This is a good thing. The video luminance scale of 219 will easily fit into the 255 luminance range, with no 'compression' necessary, and hence, no artifacts introduced as a result.

In example 4, if you thew away 2 of the strings, it would be the equivelent of leaving the encoded video 'as is' with a 255 luminance range (0-255), but displaying it on a tv capable of displaying only 219 luminance levels (bad thing). When this was displayed on your television, it would simply chop off any luminance detail below 16, displaying it as black. It would display anything above the 235 luminance scale as white.

[lordsmurf]

Are we all sure that TMPGEnc assumes 0-255 is the source?

Again, my tests show that CHECKING this option when re-encoding my captured ATI MPEG files (which I am pretty sure are disc-ready with all the proper modes such as 16-235), the results show too much white a black, compressing the lights to white and darks to black.

All my AVI caps are run through MainConcept or Procoder from Premiere. So while I'm still trying to comprehend this TMPGEnc option and color scale and luma range info, luckily Premiere and the plugin encoders don't make me think about that.

DJRumpy, wouldn't my MPEG re-encode tests go against your examples? Specifically, the #2 one?

And when we discuss luma range, are we not in fact also just using "luma range conversion" as a synonym for "RGB to YUV" conversion? I'm under the impression 0-255 is RGB. And 16-235 is YUV (a.k.a. YCrCb).

I'm gonna run another round of tests here next week to confirm my previous findings, and I'll expand more onto some other various sources. I think 5 minutes from several sources, author in TMPGENC DVD, and burned to DVD-RW will suffice.

The things I see missing and/or misstated from your examples is this one: If you take the 219 luma, and as you suggests TMPGEnc does - assume it was 255, then squeeze it into the 219, you now have 219 with missing black/white data (as the true 219 luma is now occupying the approximate 32-210 area). This would result in a muddy image. We'll call this example #5 for the sake of labeling it.

That being said, I've seen that muddy image on the unchecked option. But then again, that was because the original VHS source was muddy too (or so I believe it to be, as seen on the tv set). Checking the option seems to have actually expanded the 219 into 255. It made more of the lighters white and more of the darkers black, as it should have been, and all being done without the long times caused by contrast filters.

In #5, luckily, most DVD players overstate the darks anyhow (especially cheap ones) and those with better chips and circuits can expand the black levels and have built-in gamma correction of the image (which will essentially correct user errors made at encode, often even seen in professionally-released movies).

So will we, or worse yet - can we, actually even notice if we screw up when we convert the color space? Given the diversity of the playback equipment.

And again, how does TMPGEnc really work? Does it really compress or decompress the luma range? Or does it merely chop and add? This would make a difference too.

And then there's this:



This screen cap leads me to believe that ENABLING the option will change the range from 8-235 (the assumed TMPGEnc range) to 0-255. It further adds that this is suggested since DV is already in the 0-255 playback range.

So how does DV work? DV knowledge currently in my head (which could be wrong since I don't own a DV camera) is that it was shot as a 0-255 file but only uses the 16-235 range for the data. Since I can't find any quick facts on this, I'm off to research land.

In closing (for now), I have one quick question for TMPGEnc... what kind of crazy range is 8-235?

[DJRumpy]

Feeling verbose aren't you You must be like me...a quick typer.

The things I see missing and/or misstated from your examples is this one: If you take the 219 luma, and as you suggests TMPGEnc does - assume it was 255, then squeeze it into the 219, you now have 219 with missing black/white data (as the true 219 luma is now occupying the approximate 32-210 area). This would result in a muddy image. We'll call this example #5 for the sake of labeling it.

That being said, I've seen that muddy image on the unchecked option.

TMPGenc has to assume it's 255, as the setting is designed to convert 255 to 219 on the luminance scale. I wouldn't call it muddy though. I'd say 'lacking in contrast' would be a better description. Remeber that leaving it unchecked compresses the image from 0-255 to 16-235, hence the muddy image. Checking it will output YCbCr (0-255), leaving you luminance scale 'as-is'. Your describing example #2 when you talk about leaving it unchecked. Source luminance 219, output luminance set to 219. No need to add another example.

So will we, or worse yet - can we, actually even notice if we screw up when we convert the color space? Given the diversity of the playback equipment.

For the most part, no. I've never noticed the washed out whites. I have noticed the 'sparkles' in dark areas as a result of luminance compression though.

This screen cap leads me to believe that ENABLING the option will change the range from 8-235 (the assumed TMPGEnc range) to 0-255. It further adds that this is suggested since DV is already in the 0-255 playback range.

Correct, but 'change' isn't the correct word. If your color range is already 255, no change would take place. If your color range is 16-235, it will fit within the 0-255 luminance range without being changed. 0-15 and 236-255 would simply be black and white since no data exists at those luminance levels. I have no idea why he placed his DV comments there. I always heard that DV used 0-255, not 16-235 (CCIR601). I'm guessing the language barrier may be the cause again.

Let me know what you find on the DV question.

[lordsmurf]

Feeling verbose aren't you You must be like me...a quick typer.

More like my brain's thoughts being put into words. Yeah, quick typist, about 80 wpm.

If your color range is 16-235, it will fit within the 0-255 luminance range without being changed. 0-15 and 236-255 would simply be black and white since no data exists at those luminance levels.

This statements leads me to believe that regardless of the checking or unchecking of this option, when using 16-235 source, it won't make any difference. If it adds just black and white to the unfilled ends of the luma range, then nothing is changed. This would make it a cut/add option and not a squeezing effect.

I would hope that is the only cut/add. The preferred method of converting 0-255 would be to compress the luma into the 16-235 values. Not chop off 0-15 and 236-255.

Remeber that leaving it unchecked compresses the image from 0-255 to 16-235, hence the muddy image.

Are we absolutely positive? Because that would seem to go against the pop-up info when you hover your mouse over the TMPGEnc option.

Muddy is a photographic term used to describe a lack of black and whites. Typically a lack of contrast. Just to clarify my use for you.

As suggested, moving from 0-255 to 16-235 without recompression will make it muddy. This would imply that the color space is not augmented, but merely chopped off. Now THAT sucks. You're essentially losing data rather than having it recompressed into the new smaller environment.

Imagine your body. And we're in the future. I want to put you in a small suitcase for transport. (Again, insane analogy, but it works.) We could simply chop off your arms to make you fit (move to 16-235 from 0-255 without conversion). But the preferred method would be to use a shrink ray. Nothing would be lost, but you would simply be made to fit within the confines of the new environment. Chopping off your arms is permanent, and loses quality.

I was under the impression that the shrink ray was what was done when the option was CHECKED. It's an advanced function only needed when converting RGB 0-255 material for use with the tv output, which is a given considering TMPGEnc was invented solely for VCD and now SVCD and DVD output onto a tv set.

Then again, this is from Japan, which uses both values. So which one did he start with? Can we find out?

output YCbCr (0-255),
16-235 (CCIR601).

I'm so confused that I"m drooling. Well, not really. But still, this makes no sense to me.

Isn't YUV = YCrCb = 16-235 ?
Inversely, isn't RGB = 0-255 ?

And isn't CCIR601 merely the format of tv, which includes YUV (which uses the 16-235 range of luma) as the preferred colorspace? And YUV is essentially the same as YCrCb? YUV is essentially the tv flavor of RGB, but at a different white/black value (the luma range), due to the mechanics and electronics factors of what makes a tv work like a tv.

[adam]

And you've lost some of your credibility with me because of your consistent statements of "CCE is 4x faster than TMPGEnc", which I know for a fact is baloney.

Either you are thinking of someone else or your bias has gotten the better of you. I have never said this and quite frankly I cannot recall anyone ever saying this. CCE is about twice as fast as TMPGenc at comparable settings. If you disagree than I am sorry but you are wrong, and I have no choice but to question whether you have ever even used CCE. This has been objectively proven on numerous occasions, and admitted by the author of TMPGenc. If I lose credibity in your eyes for making this statement, then you should find a new forum to post in because I can assure you that the vast majority of users on this board would say the exact same thing. If you have issues with something I post, bring it up at the appropriate time and place, namely in THAT thread. You are very off topic here. I have no desire to discuss this further since the benchmarks speak for themselves.

http://web.archive.org/web/20020220124253/www.dv.com/magazine/2000/0400/luminanceranges0400.html

That is the source I was referring to. Unfortunately its no longer available as far as I can tell. It was an archived article from dv.com and they have recently made them non-public. It says you have to register, but then it won't let you. If you can find a way in, please let me know. I really wish this article were still available. It gave examples of different sources showing how they should be encoded, stating that a 16-235 source should be encoded in the 0-255 range, so as to not compress the luma any further.

http://jehoo.netian.com/tech%20brief/brief%203/dvcontents/dv-14.html

Here is the site where I originally found the link above. It paraphrases some of what that article said, but it is not nearly as in depth. Still it outlines the general idea well.

http://forum.doom9.org/showthread.php?s=&threadid=28815&highlight=illumination

Here is a good post on the subject. Not authority, just a good read. We seemed to come to a consensus regarding this issue in this thread.

http://www.parallab.uib.no/SGI_bookshelves/SGI_Developer/books/DMediaDev_PG/sgi_html/ch02.html
Here is another good description of CCIR61 and colorspaces generally.

Anytime there is a colorspace conversion your luminence levels can be affected. TMPGenc only accepts RGB input and when encoding to mpeg it only supports YUV output. This constitutes a colorspace conversion, and thus we must ensure that our levels are controlled. I think we both agree on this so far. You are correct in that most of the time when we talk about this we are referring to a conversion from RGB to YUV, but as long as the source is RGB the luminence ranges can be adjusted even if you are not encoding to YUV. Many codecs can either stretch or compress the luminence range and so can some NLE's. Just because your source originally came from the tv, that does not mean its still 16-235 when it hits the encoder.

Neither TMPGenc nor any other encoder assumes your luminence levels, though I guess you could look at it that way. It simply gives you the option of adjusting the output. It requires YOU to know the nature of your source and determine whether you want to compress it or leave it as is. I already explained why TMPGenc encodes to 16-235 by default in my eariler post. To overcompress your luma is bad, to undercompress them is REALLY bad because those levels get completely hard clipped at playback. As with many other default settings in TMPGenc, it plays it safe.

when re-encoding my captured ATI MPEG files (which I am pretty sure are disc-ready with all the proper modes such as 16-235)

Before you question other's credibility, please make a point to verify your tests rather than assume. I have run histograms on both my pre-encoded source and my post encoded output to determine exactly what happened to the luminence levels. Unless you have done the same, you need to consider the fact that YOUR source may not be in the same range as you think it is when it actually hits the encoder, and thus any results you derive from your tests may be meaningless. As a matter of fact, it is well known that ATI's YUY codec does not do the conversion to RGB correctly. http://www.avisynth.org/index.php?page=Convert
This could very well be the reason your results are differing from ours.

I think we all agree on most of these issues. A properly encoded mpg for NTSC tv playback should be in the 16-235 range, and anything we take off the tv or off a format which is tv ready should presumably already be in this range. All we want to do is preserve it. So the only real questions of contention are, "does enabling this setting stretch it out or leave it as is?" and "does unchecking it compress it or leave it as is?"

There is no document or authority I can post to prove this one way or the other. You can only do the simple test yourself if you want to be convinced. Do not trust your codec, do not trust your eyes. Run a series of histogram tests to postively determine what your outer most range is on your source. Encode with each option checked and then test it again.

I have done this. I have convinced myself. If anyone chooses not to believe what I have to say, that is perfectly fine because all I have ever done is provided the technical reasoning behind this setting, and suggested that everyone test it out for themselves.

[lordsmurf]

Don't be pissed. You seem mad. Many of us are trying to understand this topic. Plus you have to admit, it's not smart to rely solely on the tests and opinions of one person. That why we see several specialists before an operation and the reason 3 estimates are needed after a car wreck.

I get realtime encoding in TMPGEnc, and not at the expense of quality. So while CCE is faster, I'm clueless where huge speed and quality difference ideas come from, having seen results from both encoders. But that's neither here nor there. Not at this time.

I don't use that ATI codec.

My eyes are my most imporant test. If it looks good on tv, its a go. Nothing else matters.

Also, where can I run a histrogram? Send me on, and I shall test.

[DJRumpy]

This statements leads me to believe that regardless of the checking or unchecking of this option, when using 16-235 source, it won't make any difference. If it adds just black and white to the unfilled ends of the luma range, then nothing is changed. This would make it a cut/add option and not a squeezing effect.

I would hope that is the only cut/add. The preferred method of converting 0-255 would be to compress the luma into the 16-235 values. Not chop off 0-15 and 236-255.

It only adds black/white to the unfilled ends when your output is set to 0-255 (i.e when moving from 16-235 to the larger 0-255 luminance scale - leaving it unchecked). Moving in the other direction (compressing), with a source that is already using a 16-235 luminance scale, and telling TMPGenc to convert that scale again to 16-235 would only compress it more (undesirable). If your source is 0-255 though, this would seem to be the proper course of action for a video destined for NTSC tv

Are we absolutely positive? Because that would seem to go against the pop-up info when you hover your mouse over the TMPGEnc option.

Unfortunately no. The authors english is known to be somewhat flakey ( do not frame rate conversion anyone? ), so who knows? In the end, if you don't like the look a particular setting gives you, you can always turn it off.

[adam]

I use the histogram function in Adobe After Effects. You can also do one in avisynth. Check avisynth.org for the syntax.

I agree one person's tests should not be considered dispositive. That is why I have always suggested people use my ideas to conduct their own tests. Like I said, the luminence levels can be changed at any stage in the process, without you even knowing it. The ONLY way for someone to know whether to check this stupid option or not is to test their own particular source, because an avi/mpg captured on your computer and fed to TMPGenc will not necessarily have the same luminence levels as a captured avi/mpg on my system.

My eyes are my most imporant test. If it looks good on tv, its a go. Nothing else matters.

Yes but you don't know what the luminance level of your source is. Its ok for you if your output is correct, even though you don't know how you got there. But that doesn't help anyone else. To use this setting correctly you can either use trial and error or you can understand what it does and use it accordingly.

If your source is 16-235 you should check this option.
If your source is 0-255 you should uncheck this option.

If you are getting better results with this option unchecked, then your source is probably in the 0-255 range. This is not something that can be judged by your eyes or something which can be presumed, you have to test it yourself.

[nimco]

Thanks for clearing things up.