lut HBD scale and frame properties

[realfinder]

I was think about FrameProperties-aware additions

"intp" "floatp" "allp"

to scale_inputs, they will use _ColorRange if available, else they will act as "int", "float" and "all" for YUV

also for scale operators, scalep that can act like scalef or scaleb dependence on _ColorRange if available, if not available then it will be scaleb for YUV and scalef for RGB

same thing for avs+ expr

[pinterf]

First Avisynth core itself must read and write proper frame properties. I won't do it until this task is done. And only then I consider it, though you know my opinion about putting another special hacks into the expr "language", ehhh. Ugly.

[realfinder]

I know but I don't see them as hack rather than features, anyway it's kinda update to existing "hacks" :) also I think many plugins can do proper frame properties these days especially if there are not much internal filters used

btw https://github.com/AkarinVS/vapoursynth-plugin can read frame properties in expr, is it considered as hack too?

[pinterf]

Not a hack. I know it and considered implementing it. But frame properties - as the name says - are per frame data. Expr is precompiled on clip level, once. Scaleb or scalef? They and the others are already known at compile time, percalculated and optimized away when they are after constants, it all happens before frame processing. So all frameprop related data or decision must be dynamic and evaluated frame by frame at runtime. Conceptional difference. More on that later

[realfinder]

Expr is precompiled on clip level, once. Scaleb or scalef? They and the others are already known at compile time, percalculated and optimized away when they are after constants, it all happens before frame processing. So all frameprop related data or decision must be dynamic and evaluated frame by frame at runtime. Conceptional difference. More on that later

yes, I was think about that, I think the lut need to be doubled in case of scalep, one for "tv range" and another for "pc range", but for avs+ expr things different I think

btw, a bit off topic but if we have not-float YUV or RGB clip that have one Expression and all 3 planes need to be processed (all them use one Expression), it will have 1 lut (optimized) or 3 luts (not optimized)?

[pinterf]

One lut is calculated when no new expression is given. Historically this was the case for xy and xyz and with the latest release for 1d lut as well.

[pinterf]

Pls check a new Avisynth build (see doom9) with experimental frameprop reader syntax. Thx for the motivation

[realfinder]

thanks! it seems work fine

d2vSource("001_Video01.d2v")
propShow
expr("x._QuantsAverage 5 > 128 x ?","","")

this can used for adaptive deblocking or another things

[pinterf]

Your welcome. I have to cleanup the source and make proper commits but I think only next week. Until then comments are welcome.

[realfinder]

but

Nonexistent or non-number frame properties return with 0.0 value

isn't better to make it -1 or -2 (for more safety, or better -1 for non-number and -2 for Nonexistent) to distinguish between zero property (most of http://avisynth.nl/index.php/Internal_functions#Functions_for_frame_properties have it) and Nonexistent/non-number one?

btw, I think frameprop reader in mt_lut* is impossible (unless with realtime=true), right? so this discussion is off topic maybe

[pinterf]

I'm trying not to differ too much from VS version. Choosing any number is not a good choice either. Maybe a "defined" or "default" option would help while keep things still generic. Nor did I implement array-type frame property access yet which should be done as well for the sake of completeness.

[pinterf]

mt_lut w/ frameprops. Yes, only realtime. But it is then not a lut any more.