#1 - I did not say it is not an option. Tmpgenc and CCE let you the choice but the default is to encode in TV scale.
#2 - even if this was not an option, using limiter in a clip is still a nonsense, moreover if you want to encode for PC monitor.

For sure not !
Since when having numbers in entry that are 16-235 gives you number in output that are 16-235 also ???
If you do not tell to the encoder to round (or clip, or scale - it depends on the tool) its internal maths to 16-235 then whatever you give to it, it generates numbers between 0-255 !

Not if you're encoding for a "Streaming" target over the net, where the destination is a PC monitor

-kwag

At least that's what the manual says so I would expect it to be that way. The range is used for converting from RGB to YUY2 in which the encoder works internally.

The luma range would be padded in its super values. But the movie treatment informations would be within 16-235.
What you see is what you get and thats why my re-encodings (especially captures .. but the logic is the same) where never clipped, too dark, too bright or even in their details cropped.
Basic YCbCr komponent output regulary means "do encode what you get and dont touch it" thats th logic, but some people say so or so according to TmpgEncs internal routines and that has to be proofed.
IF the non-CCIR setting in tmoegenc results in a blowed up luma range from whatever to 0-255 RGB than this also could happen via the decoder of the system as tmpgenc requests rgb24 thats why I said, to convert in the script to the native colorspace of the encoder.
also its a thing of the mpeg stream provided coefficents of color luma as "it could be" that a real 16-235 luma ONLY data would be encoded, means less luma/chroma data, means smaller encoding sizes?

We should do a real test, means a clear table where all steps are mentioned and the final image output compared to the orig or even optimal state.



http://www.digvid.info/tmpgenc/settings_quantize.php
To me that means not "forcing a convers. of the ACTIVE Luma to a 0-255 range" but taking whats happning within the whole 0-255, means to me "untouched".

But anyhow, if you go out in the script using perfect 16-235 CCIR Video Data, then no matter if let YCrCb raw untouched or CCIR "cropped"!, the result would be a full ACTIVE detail range of 16-235 within CCIR(16-235) or raw YCrCb(0-255).

Also IF you do correct the luma range its better to use Levels() in avisynth instead of a simple Coloryuv() incl. pc-tv scale as it gots an internal FIXED math for scaling!
A simple Levels(x,x,x,x,x) usage DOES crop the luma input first to CCIR 16-235 specs so watch out, thats why I ALWAYS use the parameter "coring=false" in levels, which uses the FULL luma input for correction via its values in the commandline, otherwise luma first will be cropped and then be corrected.

The only pro argument for just cropping the luma is that the luma histogram itself between 16 and 235 wont be affected at all, but what happens if already the source is NOT CCIR conform encoded? I got many DVDs which are in such a state. In case of a high contrast capable Beamer output its nice and supports the beamers Contrast Specs. but for TV it would be a mess or the luma could be cropped before by the SAP like my cyberhome does thats why some SAPs cant really support the THX optimizer in its Brightness/contrast Patterns in a correct way.

I have been reading a lot of posts and a special one which deals with exactly that problem of Cspace conversions and especially Tmpgenc/CCE.

The resumeé is:

Conversions between all YUV format like YV12 and YUY2 wont touch the luma range. BUT if a conversion is done between YUV and RGB in avsiynth the luma will be "stretched" to 0-255 or othewiese "cutted" to 16-235. Thats the case IF NO additional coefficient parameters are set in the ConverttoXXX() command! http://www.avisynth.org/Convert

The first risk is WHAT vfw codec is used when loading a video source into avisynth via Avisource(). Here already some codecs do stretch or expand or cut, so every codec model gots his own way of handling.

mpeg2dec3 by MarcFD doesnt touch the luma range, so a perfect 16-235 DVD in avisynth is kept by the mpeg2source command. Also a 0-255 DVD is kept at 0-255.

Lets see what happens:

A simple d2v file in a 16-235 Luma rangeout of a DVD will be imported into avisynth, no conversion etc., so YV12 is still the result out of the script:

mpeg2source("16-235.d2v")

Result:
TmpgEnc with CCIR option enabled = Cant be specified as all lays on the decoder in the system which handles the YV12 to RGB24 conversion, means mega Tricky as its individual codec specific if the luma range is kept or scaled!
TmpgEnc NO CCIR option enabled = Same as above!


mpeg2source("16-235.d2v")
ConverttoRGB24()

This causes a 16-235 to 0-255 expanding due a default YUVtoRGB Cspace conversion in avisynth when using NO coefficient parameters in the converttoXXX() command.

Result:
TmpgEnc with CCIR option enabled = Correct output! as the luma range of 0-255 will be "copressed"!! (not cropped!) to 16-235.
TmpgEnc No CCIR option enabled = 0-255 input is kept as NO luma modification is done! Whaterver comes in, it will be encoded untouched, means 16-235 stays 16-235, 0-255 stays 0-255!

Conclusion on TmpgEnc:
If you use Converttorgb24() and the CCIR option in TmpgEnc the luma will be expanded and compressed within the whole video-job. To me thats not they 100% way, better staying totally at 16-235 by converting to RGB24 using the convertto parameter to KEEP the luma 16-235! Afterwards NO CCIR option checked and you get a NON Luma touched encoding of your source.

But what happens if going with a YV12 (16-235) Cspace into TmpgEnc?? As said thats tricky AS if the decoder (YV12 to RGB24) used by the system KEEPS the 16-235 range when decoding TO rgb24 you will get a too bright encoding IF then CCIR is checked as CCIR option in TmpgEnc DOES compress the luma no matter which luma range comes in.

Now, CCE:
Very easy ALL YUV inputs will be untouched! No matter if "16-235" option in CCE settings is set or not, as that option ONLY affects RGB feeded to the CCE.

SO imho limiter() at the end makes no sense as anyway we use converttorgb24() which stretches the luma back to 0-255. Also in case if NO converttorgb24() is included as by that 2 possibilities are given:
1. The system decoder keeps the 16-255 (out of limiter()) and a CCIR based encoding in TmpgEnc will brighten too much the encoding.
2. The system decoder expands the 16-255 (out of limiter()) to 0-255 and a CCIR based encoding in TmpgEnc will result correctly.

But now there will be the question "Hmmmm If my original already IS 0-255 the converttorgb24() by this will expand my already 0-255 OUT of the range?? As the command just uses an internal FIX math??? So luma cropping via limiter() BEFORE converting to rgb for me is a MUST!"
Logically seen thats like a luma cropping where afterwards in TmpgEnc the "scaling" to CCIR also here will result like if it would have been cropped to 16-235 So that would be THE SAME result as if you would use limiter() ... means also here in the script no limiter is needed.

Hmmmmm .... I did new tests, maybe TmpgEnc has changed his internal luma handling in rgb 0-255 AND rgb 16-235 input when checking/unchecking CCIR or Avisynth has changed hmmmm......

Status now .... No CCIR checked to me now seems a forced stretching to 0-255 and CCIR seems ALSO to force a stretch to 16-235 (this stretch factor is also given IF an rgb already gots correct 16-235 as input = fatal!)

Scaling isn't the option to use every time. I just did a small test on my latest capture file which reportedly has values over 235.





The scaled image looks washed out when compared to the original and the limiter one. You might not notice it on this page, but save the three images and view them sequentially.

Boulder thats exactly the point: Means a not clear 0-255 or 16-235 Range ... a washed out picture results out of a "simple fixed" math of ColorYUV incl. PCtoTV params.

First you should check what range is provided by your PVR's driver, it should be 16-235 YUV (YV12), but your statement "above 235" already is serious to me.

ALSO I did find out today that the used Coefficients in YUV-RGB-YUV Conversions are a very importand thing, thats why Colormatrix does exist. Also in The ConverttoXXX() Commands you can set 601 and 709 Coefficients.

"Washed out Colours" ... does it mean to you less contrast on the whole Picture? As the TV compensates that to a TV-full-Contrast range.
On your last Picture I can clearly see more Luma Details on the Mans right Arm. Look at the reflexion of the Mirror on the Doorwindow! And even that will be more dark (in relation) on TV as 16 is Black and 235 is white.
Please do keep in mind that Im talking about TV purposed Encodings

ALL captures should be set to keep the clear 16-235 Range, my 7134Cards Driver Settings got Sliders to affect the outgoing of Contrast and Brightness, on my 1734 for example if Contrast and Brightness are set to default the range is Shitty as its between 0-255 and 16-255, means no conversion afterwards would result ok if you want to keep all luma details.

So I wouldnt use ColorYUV incl. PCtoTV params., better is this:

mpeg2source(....)
Levels(0,1.0,255,0,255, false)
Histogram("Levels")

Now scroll through your capture and watch the histogram right above. Im shure you will have to tune a bit the range so it fits the correct 16-235.

So use the levels options to match the range (dont forget to set ",false" as a coring would "crop" all below 16 and above 235 before acting, ... like Limiter().

As said above limiter() isnt needed as a converttorgb24() will make all values below 16 and above 235 exceeding the rgb range, means cropped where in TmpgEncs CCIR option 16-235 again will be the encoded result.

What I mean by washed out is that the scaled image looks like there's a slight grey haze over the whole image.

I do a ColorYUV(off_y=5,gain_y=-16) on my captures, the values were determined like in the Doom9 capture guide. Basically that scales stuff to 16-235 but that doesn't turn the image into washed out look.

I just checked and the PVR outputs 0-255 values, at least according to ColorYUV(analyze=true).

Do a ......

Mpeg2source("pvrCapture.d2v")
Histogramm("Levels")

comparison with ....

Mpeg2source("pvrCapture.d2v")
ColorYUV(analyze=true)
Histogramm("Levels")

... and I saw that already Coloryuv in a simple analyze mode (not modifying mode) already does affect the source Range.

Hmm, IMHO the difference comes from the fact that ColorYUV outputs the text over the existing video which then alters the histogram.

In some cases of mine there was a significant affection of the superblack level, means a spike at 0 or between 0 and 5. Without Coloryuv in analyze mode there isnt such a spike.