Quote:
Originally Posted by real.finder
if only tv_range=false solve it then yes the old bug is back, try with many avs+ versions until you get the one that work
|
The old bug is back, but now it's dither_lut16 is the culprit.
It seems that under Win10 (?) configuration it understands only the decimal separator of the current input local.
Just replace the decimal point to commas in yexpr parameter and it will work fine. (the used ReplaceStr is built-in in AVS+)
Code:
function Dither_Luma_Rebuild (clip src, float "s0", float "c",int "uv", bool "lsb", bool "lsb_in", bool "lsb_out", int "mode", float "ampn", bool "slice"){
[...]
src
lsb ? (lsb_in ? Dither_lut16 (yexpr=ReplaceStr(e,".",","),expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv) : \
Dither_lut8 (yexpr=ReplaceStr(e,".",","),expr="x 128 - 32768 * 112 / 32768 +" ,y=3, u=uv, v=uv)) : \
avs26 ? mt_lut(yexpr=e,expr="x range_half - range_half * 112 scaleb / range_half +",y=3, u=uv, v=uv) : \
mt_lut(yexpr=e,expr="x 128 - 128 * 112 / 128 +" ,y=3, u=uv, v=uv)
[...]
}
And one more remark. When you want to scale the YUV TV range limits 16-235, 16-240, or their difference (like 112 = (240-16)/2), use scaleb instead of scalef. scaleb correctly converts "official" bit-shifted limits (e.g. 16*4, 235*4: 64-940 for 10 bits), while scalef (Scale _F_ull range) is for stretching a range of 0-255,1023,4095,16383,65535 to another bit-depth's full range of 0..255,1023,4095,16383,65535. So 235 in a 8bit world would become 235*1023/255 = 942 in 10 bits, which is not correct.