Any harm in using ConvertToRGB24() by default?

[DRP]

I'm looking to consolidate my AviSynth scripts a bit to reduce the amount of customising I have to do for every encoding job and I was wondering if there's any harm in always having ConvertToRGB24() as a default script line before all crop & resize lines?

I need ConvertToRGB24() for many jobs because otherwise I can't crop or resize to the values I want and that's fine. I was just wondering if it would actually do something nasty or reduce the final quality in the case that it was applied to a source that was already RGB.

Any thoughts?

[FulciLives]

Most video is not RGB so conversion to RGB should be avoided if at all possible unless you really really really need to do it.

Cropping and cropping alone is not a reason to use it.

- John "FulciLives" Coleman

[jagabo]

You lose precision going from YUV to RGB and likely back again to YUV when you encode. And the default is to contrast stretch the luma so you lose details below luma 16 and above 235. And it's a waste of time if you don't need it.

[DRP]

Well, I'm using TMPGEnc 2.5 Plus for encoding and I'm happy with it. I understand that TMPGEnc only outputs in RGB anyway regardless of input, so there's no getting away from it and therefore I may as well do the conversion at the AviSynth stage because it's gonna be converted anyway.

I can add that I have no issues with the quality of my conversions and neither does anyone else who views them, so this is not really a problem. IMHO the difference between NTSC & PAL is far more obvious and marked than any differences between colour space. I can for instance easily identify an NTSC video from a PAL one just by watching it. I cannot say the same for videos encoded in different colour spaces. And for me, that makes it insignificant.

So given that I'm perfectly happy converting to RGB, is there any harm in applying that script to a video that may already be RGB?

[manono]

If you are going to use TMPGEnc, then it's OK to put it at the very end of the script. Do all the filtering in the original colorspace. And if getting MPEG-2 video out the other end, it gets converted back to YV12. It doesn't output RGB.

[FulciLives]

HCenc is a great quality freeware encoder that does YV12 or you have CCE Basic which is fairly cheap and does YUY2

As for your attitude (yes I am talking to you DRP) ... it sucks. Don't ask us our opinion and then shit on it. You are wrong plain and simple no way around it.

- John "FulciLives" Coleman

[DRP]

As for your attitude (yes I am talking to you DRP) ... it sucks. Don't ask us our opinion and then shit on it. You are wrong plain and simple no way around it.

Lets see about that shall we? I asked a simple question. I did NOT ask for any input or opinions on whether or not I should be converting to RGB or not. You are the one who answered a question that wasn't asked. Furthermore, in your initial response, you didn't even attempt to answer the actual question I did ask. If you had, then I might have felt more inclined to listen to your opinion on a subject that wasn't asked about.

I think it is you who needs to consider more carefully the topic of threads before replying in the way you do, not me. If you have nothing to say on the subject matter of the thread, then don't reply at all. It's as simple as that. Taking a thread OT with the very first reply is not helpful to anyone.

[Midzuki]

As manono has impatiently taught me ,
you can Crop() and Resize() without any colorspace conversion
if you have already learned to use AddBorders()

[FulciLives]

@DRP

How can saying "do not convert to RGB unless absolutely necessary" be off-topic in a thread asking about the merit of ALWAYS converting to RGB ... especially when you clearly do not know what you are talking about as cropping alone does not necessitate conversion to RGB.

You make no sense

- John "FulciLives" Coleman

[SCDVD]

Video -----> Convert -----> Lose quality -----> Don't do unless need to.

[jagabo]

So given that I'm perfectly happy converting to RGB, is there any harm in applying that script to a video that may already be RGB?

No common video format is RGB except uncompressed RGB.

Using ConvertToRGB() on a source that is already RGB will not harm your source but it won't do anything useful either.

If you are using an encoder (TEMPGEnc) that converts all inputs to RGB (and then converts back to YUV for MPEG compression -- because MPEG is always YUV internally) then it doesn't hurt to convert to RGB just before the end of your script.

Converting to RGB before performing any operations that involve adjusting the luma or chroma will cause you to lose precision and the ability to recover blacker-than-black (IRE below 0) or brighter-than-bright (IRE over 100) details.

It's possible to convert to RGB without losing black and bright details by using the PC.601 or PC.709 (whichever is appropriate for your source) matrices in AviSynth. When this is fed to TMPGEnc as RGB you must enable the "output YUV data as basic YCbCr not CCIR601" option.

Performing color, contrast, brightness, or gamma adjustments in RGB gives different results than performing them in YUV.

The only time cropping requires converting to RGB is when you want to crop an odd number of pixels because AviSynth has no 4:4:4 YUV mode.

[DRP]

The only time cropping requires converting to RGB is when you want to crop an odd number of pixels because AviSynth has no 4:4:4 YUV mode.

That's exactly what I'm wanting to do. I find the restrictions about cropping in even numbers or multiples of 4 or 16 or whatever extremely annoying and I want a way around that. Converting to RGB solves the issue nicely.

[mpack]

I find the restrictions about cropping in even numbers or multiples of 4 or 16 or whatever extremely annoying and I want a way around that. Converting to RGB solves the issue nicely.

You said you were converting to MPEG later? In which case, having dimensions a multiple of 8 or 16 (depending on color sampling) is an MPEG requirement. TMPGEnc can't encode the video unless it forces it to meet this requirement somehow - most likely by cropping again or padding.

[mpack]

If you are using an encoder (TMPGEnc) that converts all inputs to RGB ...

I realize that you were just taking DRP's word for it in order to address his question, but are you aware of any evidence that TMPGEnc does work that way? I regularly supply TMPGEnc Plus 2.5 with YUY2 (Huffyuv) AVIs, and I would find it odd if it internally converted the frames to RGB only to later convert them back to YUV again for MPEG encoding.

[jagabo]

If you are using an encoder (TMPGEnc) that converts all inputs to RGB ...

I realize that you were just taking DRP's word for it in order to address his question, but are you aware of any evidence that TMPGEnc does work that way?

It's been a long time since I tested it but I'm pretty sure it does convert incoming YV12 or YUY2 to RGB then back to YV12, even if you're not doing any filtering. Although, now that I think about it, I don't remember how I determined that. Maybe it just clamped luma to 16-235 -- so I assumed it had done the conversions.

[manono]

There's quite a lot of evidence out there that says it first converts everything to RGB24 if it isn't already RGB24:

Using TMPGEnc you have to add the line ConvertToRGB24 to your script, and for CCE SP you need to add the line ConvertToYUY2 to your script...

http://mediacoder.sourceforge.net/wiki/index.php/YV12_FAQ

In particular, if I feed TMPGEnc an Avisynth script as a source
file (producing the video data in "YV12" format in the script),
does TMPGEnc still internally convert it to the R'G'B' colorspace
and back to Y'CbCr again? And if it does, is there any way to
prevent this needless conversion from taking place?
.
.
.
It always converts it to RGB24 (by some external codec when
necessary).

http://www.tomshardware.com/forum/142470-33-feeding-cbcr-yv12-data-tmpgenc

MPEG-2 encoders such as CCE, Procoder and TMPGEnc can't handle YV12 input directly. CCE and Procoder needs YUY2, and TMPGEnc RGB24. This only means that the last line of AviSynth must be a ConvertToYUY2 (for CCE/Procoder, or ConvertToRGB24 for TMPGEnc) call

http://avisynth.org/mediawiki/FAQ_YV12

[mpack]

Could it just be that TMPGEnc doesn't recognize the YV12 fourcc - but does recognize YUY2?

Like I (sort of) said before, YUY2 is my standard working format, and TMPGEnc is my standard encoder, so I think I would have noticed if the two didn't work well together.

I can't think of an easy way to prove it though: all I know for sure is that TMPGEnc Plus 2.5 does accept OpenDML_AVI+Huffyuv+YUY2 because that's what I feed it most of the time. I've never used YV12.

[manono]

I don't think anyone's saying it won't accept video in other color spaces. It's not going to crash or anything like that if you feed it something in YV12. It's just going to first convert it to RGB24 itself. Many of us believe a better job can be done using AviSynth for the conversion.

I've never used YV12.

So you've never reencoded a DVD or an XviD/DivX AVI?

[jagabo]

Yes, TMPGEnc Plus accepts both YV12 and YUY2 as inputs.

[mpack]

I've never used YV12.

So you've never reencoded a DVD or an XviD/DivX AVI?

My projects are mostly YUY2-AVI --> DVD, so no, I have never encoded to or from Xvid/DivX. Yes I have re-encoded a DVD, but YV12 was not necessary for any stage of that.

I'm still curious as to how anyone knows that TMPGEnc converts YUY2 to RGB internally. I just did a little experiment getting TMPGEnc to encode a Huffyuv+YUY2 video, but this time making sure that Huffyuv's "Always suggest RGB for output" cfg option was turned off. TMPGEnc did not complain. It may still be converting to RGB internally (though that makes no sense to me), but how would I, you, or anyone else know that?

[jagabo]

I'm still curious as to how anyone knows that TMPGEnc converts YUY2 to RGB internally.

It loses luma below 16 and above 235. The implication is that it is converting to RGB using a rec601 matrix.

[mpack]

It loses luma below 16 and above 235. The implication is that it is converting to RGB using a rec601 matrix.

Well again, how was that determined? The only way I can think of is take the MPEG produced by the encoder and run it through an MPEG decoder to recover the decompressed frames - then look at the Y values. This of course adds the effect of the MPEG decoder to the mix.

I may be wrong, but AFAIK the luma range of 16..235 is standard for YUV, and MPEG uses YUV, hence all sources should have their luma gamuts clipped to the 16..235 range.

One thing I don't know is if YUY2 is supposed to be standard YUV, ie. with the same 16..235 gamut - so should an MPEG encoder accept the Y component as is (still clipping of course), or squeeze it?

[DRP]

Thanks all. Question has been answered. I'm convinced that TMPGEnc does do all internal source encoding management in RGB colour space and then outputs in standard MPEG format. That is what I had read from ages ago and it makes sense to me. There are afterall no restrictions in how much or how little you can crop/resize etc. in TMPGEnc's own filters and this can only be achieved if the program is doing it in RGB colour space.

That being the case, there is no disadvantage to me doing what I'm doing with my AviSynth scripts, which is what I wanted to hear.

I understand that I could maybe improve things by changing to a different encoder which doesn't have the colour space handling limitations of TMPGEnc, but I'm afraid that isn't a change I'm willing to make. I am devoted to and very happy with the old TMPGEnc and it would take a mammoth & obvious improvement in picture quality to convince me to ditch it. To be honest, I can't see that ever happening. The discs I make using TMPGEnc are virtually indistinguishable from retail DVDs on my television viewed through my eyes, so improvement of that scale is simply not going to be possible.

[jagabo]

It loses luma below 16 and above 235. The implication is that it is converting to RGB using a rec601 matrix.

Well again, how was that determined? The only way I can think of is take the MPEG produced by the encoder and run it through an MPEG decoder to recover the decompressed frames - then look at the Y values. This of course adds the effect of the MPEG decoder to the mix.

Do you know any other way to examine the contents of an MPG file? I have enough confidence in the tools I use (AviSynth, DgIndex, DgDecode, VideoScope, etc.), and my knowledge of how they work, to believe my observations accurately reflect the contents of the video.

I worked out a way to show that TMPGEnc loses precision when fed YV12. I created an MPEG file with blocks of luma from 0 to 255, all 256 values. If fed to TMPGEnc as RGB (via AviSynth's ConvertToRGB(matrix="PC.601") to preserve the luma range), and encoded with TMPGEnc "Output YUV data as basic YCbCr not CCIR601" setting, the output shows all 256 values with no errors:



When fed to TMPGEnc as YV12 and using the same "basic YCbCr" settings TMPGEnc does not preserve all 256 luma values:



It has clamped values below 16, above 235, and lost precision in the rest of the range. For example, you can see that the block that should have had a value of 61 has a value of 60, and much of the higher values have shifted down by 1. It does the same with YUY2 input. In a separate similar test CCE retained the full range and lost no precision.

This isn't definitive proof that TMPGEnc converts incoming video to RGB. But given that we know it performs all its filtering in RGB, and that incoming YV12 results in exactly the kind of precision errors that converting YUV to RGB and back to YUV generates, I am satisfied that the program converts YUV sources to to RGB.

[DRP]

That's interesting. So then does this mean that I should be using the AviSynth ConvertToRGB(matrix="PC.601") script and encoding with TMPGEnc "Output YUV data as basic YCbCr not CCIR601" selected instead of what I have been doing? Will this yield a better quality MPEG-2 without restricting my ability to crop/resize in all sorts of funky odd-numbered values?

Edit: Why does the preview image in TMPGEnc window suddenly get markedly duller as soon as I test this new ConvertToRGB(matrix="PC.601") line and load it?

[jagabo]

That's interesting. So then does this mean that I should be using the AviSynth ConvertToRGB(matrix="PC.601") script and encoding with TMPGEnc "Output YUV data as basic YCbCr not CCIR601" selected instead of what I have been doing?

Yes.

Will this yield a better quality MPEG-2 without restricting my ability to crop/resize in all sorts of funky odd-numbered values?

Yes, a more accurate result.

Edit: Why does the preview image in TMPGEnc window suddenly get markedly duller as soon as I test this new ConvertToRGB(matrix="PC.601") line and load it?

When TMPGEnc converts to RGB it performs the usual rec601 contrast expansion. Then when not using the "basic YCbCr" option it performs the usual rec601 contrast reduction when it converts back to YV12 for MPEG compression. So you see the intermediate higher contrast RGB picture in TEMPGEnc's display, you lose luma below 16 and above 235, and you lose accuracy over the rest of the picture.

When you use ConvertToRGB(matrix="PC.601") in AviSynth the contrast expansion is not performed. Then enabling the "basic YCbCr" option in TMPGENc avoids contrast reduction on conversion back to YV12. You see the intermeidate RGB image with less contrast in TMPGEnc's display but there is no loss of luma below 16 and over 235, and no loss of accuracy.

[DRP]

Okay. I think I get that. I think. Anyway, 90% of the time my source is XviD and I've just read in the AviSynth documentation that for XviD type source I should be using plain old ConvertToRGB(matrix="Rec601").

Also, I wish to make MPEGs that are watchable on both CRT and LCD TVs. In the 10% of the times case where I do convert a DVD, is there a negative result on maintaining the colour space to PC scale when watching it on a CRT TV (which I presume is not capable of reproducing the extreme upper and lower levels of colour accurately)?

[jagabo]

Okay. I think I get that. I think. Anyway, 90% of the time my source is XviD and I've just read in the AviSynth documentation that for XviD type source I should be using plain old ConvertToRGB(matrix="Rec601").

No, not if you are going to use the "basic YCbCr" option in TMGPEnc. (rec601 is the default matrix for ConvertToRGB() and TMPGEnc).

Also, I wish to make MPEGs that are watchable on both CRT and LCD TVs. In the 10% of the times case where I do convert a DVD, is there a negative result on maintaining the colour space to PC scale when watching it on a CRT TV (which I presume is not capable of reproducing the extreme upper and lower levels of colour accurately)?

You don't seem to understand. TMPGEnc expands the contrast (rec601) when it converts to RGB then reduces the contrast (rec601) when converting back to YUV. In the process it loses dark and light areas and loses accuracy in what's left. Using AviSynth with the PC.601 matrix along with TMPGEnc's "basic YCbCr" (PC.601) option avoids the contrast expansion and reduction. So there is no loss of dark and light areas and no loss of accuracy. Between luma 16 and 235 the two will look very similar with just minor inaccuracies in the former. Below 16 and above 235 there will be no detail in the former. The latter will still have some detail. Whether you can see it or not depends on how your TV is adjusted.

In general, the black level of your TV should be set to luma 16. You shouldn't see any blacker detail. At the other end, above luma 235, most TVs will still show some detail, that is 255 will be visibly brighter than 235. If there is something you want to see below luma 16 you can bump up the brightness control on your TV to see it. Unless you used the rec601 matrices, in which case all those blacker-than-black details are gone.

Here's the basis for all of this:

The darkest darks in digital video should be at luma=16. The brightest whites should be at luma=235. But on computers the blackest blacks are at RGB=0 and brightest whites at RGB=255. So normally, for viewing YUV video on a computer you expand the contrast so that luma 16 and everything below it become RGB=0, luma 235 and everything above it go to RGB=255. The 220 values between 16 and 235 are spread out between 0 and 255.

Conversely when taking RGB images and converting to YUV video you want to compress the RGB range so that the 256 different RGB levels fall between luma 16 and 235.

Both of those conversions can lose accuracy.

But you are recompressing one YUV format to another YUV format. You're just using RGB as an intermediate state, it doesn't matter how the RGB looks on the monitor during the recompression. So you can avoid the contrast expansion/reduction cycle to retain more information and avoid losing accuracy.

[DRP]

Okay, it's time for a test encode. The preview screen in TMPGEnc does look 'worse' when loaded with the ConvertToRGB(matrix="PC.601") script plus 'basic YCbCr' option checked than it does with just the default ConvertToRGB() script, but I'm going to assume the preview screen is taken from TMPGEnc's internal handling rather than the actual output, so maybe the only real test is to do a encode and check it playing on the TV.

[mpack]

This isn't definitive proof that TMPGEnc converts incoming video to RGB.

Seems convincing enough to me! Thanks for going to all that effort.