ConvertBits and frame properties

[hello_hello]

Its been my understanding that 32 bit YUV is, or should be, full range, so I'm wondering about ConvertBits and the color range in frame properties.

BlankClip().ConvertToYV12(matrix="rec709").ConvertBits(32)
ConvertToYV12 writes limited range to frame properties and ConvertBits doesn't change it. The result stays limited range.

BlankClip().ConvertToYV12(matrix="pc.709").ConvertBits(32)
ConvertToYV12 writes full range to frame properties and ConvertBits doesn't change it.

BlankClip().ConvertToYV12().propClearAll().ConvertBits(32)
ConvertBits writes limited range to frame properties.

I thought for the third example at least, ConvertBits would set full range in frame properties, or nothing at all, as the wiki states in the description of "fulls":
Conversion from and to float is always full-scale.
http://avisynth.nl/index.php/ConvertBits
Should that be interpreted to mean it doesn't clip to limited range though?

ConvertBits(32, fulld=true) results in limited range being expanded to full range as well as writing full range to frame properties.

If there's no color range in frame properties should YUV float be assumed to be full range and if so, why does ConvertBits(32) write limited range when there's no color range in frame properties? Thinking about it, the same question would apply to integer YUV formats if ConvertBits doesn't know whether they're full or limited range.

Cheers.

[StvG]

I think this (https://github.com/AviSynth/AviSynthPlus/issues/189) should answer your question.

[hello_hello]

Thanks. It kinda does.... although I'm still not sure why, when converting the bitdepth, ConvertBits writes a default color range to frame properties.

Does it make a difference if you convert the bitdepth of full range YUV, for example, without a color range in frame properties for ConvertBits to know it's full range? In that sort of situation it'd write limited range to frame properties which would be incorrect. I guess I don't quite understand the difference between a conversion using scaling and a conversion using bit shifting, at least in respect to full vs limited range.

Cheers.

[StvG]

Thanks. It kinda does.... although I'm still not sure why, when converting the bitdepth, ConvertBits writes a default color range to frame properties.

ConvertBits writes _ColorRange frame property based on fulld argument. If fulld=false - _ColorRange 1 (limited), if fulld=true - _ColorRange 0 (full). And default fulld is fulld=fulls.

Does it make a difference if you convert the bitdepth of full range YUV, for example, without a color range in frame properties for ConvertBits to know it's full range?

If you want to convert full range YUV without frame properties you should use ConvertBits(fulls=true).

If you want to convert 8-16-bit limited range YUV to 32-bit YUV (full range assumed) you should do ConvertBits(32, fulls=false, fulld=true).

If you want to to convert 32-bit YUV (full range assumed) to 8-16-bit limited range YUV you should do ConvertBits(x, fulls=true, fulld=false).

[rgr]

Its been my understanding that 32 bit YUV is, or should be, full range, so I'm wondering about ConvertBits and the color range in frame properties.

Why do you suspect that?
(In Vegas project I can set 32-bit video levels or full range.)

However, I think that Converters without arguments should not touch the color range flag.

[hello_hello]

Why do you suspect that?
(In Vegas project I can set 32-bit video levels or full range.)

Is it 32 bit float in Vegas or 32 bit integer?

I'm sure I'd read here that float should be full range, so I searched a bit and found something to indicate it was supposed to be full range until it didn't need to be any more. Obviously I didn't get the memo. :)

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist34pre.html
Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits E.g. after a 8->32 bit fulls=false fulld=true: Y: 16..235 -> 0..1 U/V: 16..240 -> -0.5..+0.5 Note: now ConvertBits does not assume full range for YUV 32 bit float. Default values of fulls and fulld are now true only for RGB colorspaces.

[rgr]

Is it 32 bit float in Vegas or 32 bit integer?

Internet says float.

[Argaricolm]

You can check range using ShowChannels plugin.
If Y channel has many values of 0-15 than it is most likely full range.

[Corn Xin]

Its been my understanding that 32 bit YUV is, or should be, full range, so I'm wondering about ConvertBits and the color range in frame properties.

BlankClip().ConvertToYV12(matrix="rec709").ConvertBits(32)
ConvertToYV12 writes limited range to frame properties and ConvertBits doesn't change it. The result stays limited range.

BlankClip().ConvertToYV12(matrix="pc.709").ConvertBits(32)
ConvertToYV12 writes full range to frame properties and ConvertBits doesn't change it.

BlankClip().ConvertToYV12().propClearAll().ConvertBits(32)
ConvertBits writes limited range to frame properties.

I thought for the third example at least, ConvertBits would set full range in frame properties, or nothing at all, as the wiki states in the description of "fulls":
Conversion from and to float is always full-scale.
http://avisynth.nl/index.php/ConvertBits
Should that be interpreted to mean it doesn't clip to limited range though?

ConvertBits(32, fulld=true) results in limited range being expanded to full range as well as writing full range to frame properties.

If there's no color range in frame properties should YUV float be assumed to be full range and if so, why does ConvertBits(32) write limited range when there's no color range in frame properties? Thinking about it, the same question would apply to integer YUV formats if ConvertBits doesn't know whether they're full or limited range.

Cheers.

You're right, 32-bit YUV should be full range. Here's the deal:

ConvertToYV12 sets color range based on the matrix.
ConvertBits doesn't change color range, even if you change bit depth.
If no color range is set, it's assumed limited range.
Use ConvertBits(32, fulld=true) to ensure full range.
That's it!