[real.finder]

Originally Posted by pinterf

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+)

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.

yes that right, will did next time when do update, in fact I stopped updating scripts waiting for the new changes of bit convert, even if SMDegrain don't need those changes, I will do adding some parameters that come with the next update of masktools to make sure that no one will run it with older masktools and get some wrong outputs like https://forum.doom9.org/showthread.p...70#post1813270