Avisynth+

[jpsdr]

I've made some tests, and i'm screwed, as i was afraid. As i suspected, the fact that Prefetch must be at the end of the script made me unable to get the value using GetProperty(AEP_FILTERCHAIN_THREADS) inside AvisynthPluginInit3, or, in worst case, inside Create_xxxx. I'll probably get the information only within GetFrame, but it's too late.
Using the value of the size of the internal threadpool is not interesting because it may lead to create too much threads, so, for now, i'll use the workaround to add a prefetch parameter to my plugins (the purpose is to try to speed-up things with script using prefecth).

[qyot27]

Originally Posted by fAy01

Why do I have to convert my encode from 10bit to 8bit? It worked fine before. Please help

You mean it worked fine before high bit depth support was added to FFMS2's AviSynth interface and it downscaled everything to 8bit on its own?

Report the issue in the avspmod or YATTA threads. That's where the problems are, not here.

[real.finder]

if I have 2 mvtools2.dll one that work with 2.5 in non plus folder and one that work with 2.6 in plugins+ I note that the one in the non plus folder is used in encode! is this normal?

[Groucho2004]

Originally Posted by real.finder

if I have 2 mvtools2.dll one that work with 2.5 in non plus folder and one that work with 2.6 in plugins+ I note that the one in the non plus folder is used in encode! is this normal?

It should load from the "+" directory first. Run "AVSMeter -avsinfo -log" and post the created log file.

[real.finder]

Originally Posted by Groucho2004

It should load from the "+" directory first.

Isn't better to have it opposite? first non plus then plus

in AVSMeter -avsinfo show the non plus first then plus one!

whether in avsdeps.log or in avsinfo.log

[jpsdr]

Originally Posted by real.finder

Isn't better to have it opposite? first non plus then plus

I think it's the way avs+ is designed.
The plugins+ directory is "only" for the avs+ system plugins, the plugins directory is for the user plugins. "Theoricaly", you shouldn't put plugins in the plugins+ directory. As it's where are supposed to be the system plugins, it's (from my point of view) normal to have this directory read first.

[Groucho2004]

Originally Posted by jpsdr

I think it's the way avs+ is designed.
The plugins+ directory is "only" for the avs+ system plugins, the plugins directory is for the user plugins. "Theoricaly", you shouldn't put plugins in the plugins+ directory. As it's where are supposed to be the system plugins, it's (from my point of view) normal to have this directory read first.

Here's how the whole thing works in AVS+. In addition to the plugins that ship with AVS+ you're supposed to put the ones that won't work with classic Avisynth for some reason into the "+" directories.

[tormento]

I usually put 2.6 plugins in + dir and 2.5 in normal.

[real.finder]

Originally Posted by Groucho2004

Here's how the whole thing works in AVS+. In addition to the plugins that ship with AVS+ you're supposed to put the ones that won't work with classic Avisynth for some reason into the "+" directories.

I think this will be better

PluginDir2_5 in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir2_5 in Software/Avisynth in HKEY_CURRENT_USER
PluginDir+ in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir+ in Software/Avisynth in HKEY_CURRENT_USER

[jpsdr]

Question about the float format. Is there some kind of "rule/limitation", or are value totaly free, and it's normal to have a pixel with value for exemple of 10e-8 or +1e10 or -5000000 ?

[Groucho2004]

Originally Posted by jpsdr

Question about the float format. Is there some kind of "rule/limitation", or are value totaly free, and it's normal to have a pixel with value for exemple of 10e-8 or +1e10 or -5000000 ?

Do you mean the limits of the float data type? They are defined in "float.h":

#define FLT_DIG         6                       /* # of decimal digits of precision */
#define FLT_EPSILON     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */
#define FLT_GUARD       0
#define FLT_MANT_DIG    24                      /* # of bits in mantissa */
#define FLT_MAX         3.402823466e+38F        /* max value */
#define FLT_MAX_10_EXP  38                      /* max decimal exponent */
#define FLT_MAX_EXP     128                     /* max binary exponent */
#define FLT_MIN         1.175494351e-38F        /* min positive value */
#define FLT_MIN_10_EXP  (-37)                   /* min decimal exponent */
#define FLT_MIN_EXP     (-125)                  /* min binary exponent */
#define FLT_NORMALIZE   0
#define FLT_RADIX       2                       /* exponent radix */
#define FLT_ROUNDS      1                       /* addition rounding: near */

[jpsdr]

No, i mean the limit of the value a pixel can have in a float format.
I should take a look at the avisynth code which convert float to 8bits (if i found it), i think i'll have the answer i'm looking for.

[pinterf]

Float is 0.0 to 1.0 for all planes. Usually not clamped. But the range may change if it is against silent standards, e.g. -0.5 to 0.5 for U and V planes. Now there is no danger of change unless zillions of plugins appear supporting it

[feisty2]

Originally Posted by jpsdr

No, i mean the limit of the value a pixel can have in a float format.
I should take a look at the avisynth code which convert float to 8bits (if i found it), i think i'll have the answer i'm looking for.

there SHOULD be no clamping for floating point samples, to make sure that all intermediate data are mathematically correct..
the only exception would be a floating point mask clip, which should be clamped to 0.0 - 1.0

[Myrsloik]

Originally Posted by pinterf

Float is 0.0 to 1.0 for all planes. Usually not clamped. But the range may change if it is against silent standards, e.g. -0.5 to 0.5 for U and V planes. Now there is no danger of change unless zillions of plugins appear supporting it

Why u use offset float 4 uv? Whyyyyyy?

[LigH]

Because U (Cb) and V (Cr) are defined as "difference away from neutral gray" towards blue/yellow or red/green. So it's quite intuitive. A default chrominance in short integer is unfortunately not 0 (between -128 and 127, as signed short int) but 128; it's unsigned short int (Pascal type: Byte).

[feisty2]

Originally Posted by LigH

Because U (Cb) and V (Cr) are defined as "difference away from neutral gray" towards blue/yellow or red/green. So it's quite intuitive. A default chrominance in short integer is unfortunately not 0 (between -128 and 127, as signed short int) but 128; it's unsigned short int (Pascal type: Byte).

unsigned short int = uint16_t
unsigned char = uint8_t

[LigH]

Oops ... still have Pascal in my mind.

[jpsdr]

Originally Posted by pinterf

Float is 0.0 to 1.0 for all planes.

Ok, i'll work with that. I'm trying to see if i can change nnedi3 to support extended format. So far, results are not good, i have to continue to work/test, but i'm affraid that neural network is trained for range value of 0-255. Every input out of this range will produce improper result. For now, my next step will be to put all values in the 0-255 range, but in float format. So if input is float, multiply by 255, if input is integer more than 8 bits, convert to float by 255*(value/valuemax) (all in float of course).
This will be my next thing to try.

[feisty2]

Originally Posted by jpsdr

Ok, i'll work with that. I'm trying to see if i can change nnedi3 to support extended format. So far, results are not good, i have to continue to work/test, but i'm affraid that neural network is trained for range value of 0-255. Every input out of this range will produce improper result. For now, my next step will be to put all values in the 0-255 range, but in float format. So if input is float, multiply by 255, if input is integer more than 8 bits, convert to float by 255*(value/valuemax) (all in float of course).
This will be my next thing to try.

floating point support has been added to vaporsynth nnedi3 since, forever. (I'm actually the one who did it, and the original vaporsynth nnedi3 author then merged my floating point patches)

just do some copy-paste work from vaporsynth nnedi3 and ur good to go