View Full Version : AviSynth+ thread Vol.2
cretindesalpes
7th August 2021, 17:52
real.finder:
Ah, great, thank you for the clarification. So if I understand correctly, 0–1 and -0.5–+0.5 is the target standard. Float was added earlier to the various Avs+ filters without a well-defined spec so their behaviours may vary and they would require a conforming update.
DTL:
Working with about -0.1..1.x range may cause more precision lost because of walking around zero (very small values of positive and negative floats): There is a warning about using close to denornals in float32
This is the other way round: with f.p., working close to 0 helps with the precision. The exponent part takes care of the range reduction. This is important when working with linear light, because of the (approximate) power curve of the eye sensitivity. So the numerical noise is related to the magnitude of the value. When representing a pixel value b + x (where b is a non-null constant assigned to nominal black), the precision is limited by the mantissa and very small values of x cannot be represented. It becomes more or less the equivalent of a 24-bit fixed-point coding. Anyway even in this case, the mantissa precision is more than enough for usual video processing.
Denomal numbers are not an issue here (funnily I wrote one of the articles referenced by the Wikipedia page you linked), the involved magnitudes are way too small for optical signals. Usually they caused problems because they were handled very slowly (esp. on Intel hw) by special micro-code in the FPU and could possibly trigger an exception. But the goal of the denormals was to increase the dynamic range of the f.p. numbers, so from a numeric point of view they are a good thing. Nowadays FPU is replaced by vector engines like SSE, AVX or NEON and denormals are ignored or muted by default with the appropriate flags (DAZ/FTZ).
Normal video camera for moving pictures must feed RGB in limited range also. See for example HDTV https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf
Video camera (consumer grade, I don’t know for high-end professional cams) outputs are generally files containing AVC or HEVC streams in Y’Cb’Cr’ colorspace, so full range is perfectly legal.
DTL
7th August 2021, 20:39
Video camera (consumer grade, I don’t know for high-end professional cams) outputs are generally files containing AVC or HEVC streams in Y’Cb’Cr’ colorspace, so full range is perfectly legal.
Good consumer video camera also writes YUV 4:2:0 in 'limited' range. The only example of RGB-full may be some USB-connected web-cams with RGB24 'full' range output mode.
LigH
7th August 2021, 23:07
SONY camcorders may use "x.v.Colour", AVCHD with full range YUV.
FranceBB
8th August 2021, 00:51
real.finder:
Video camera (consumer grade, I don’t know for high-end professional cams)
SDI Stream in Limited TV Range with some possible overshoots in the luma if there are bright objects, like for instance if the cameraman is recording a person sitting on a chair and there's a bright lamp behind.
But yeah, it's always limited TV Range, unless you're recording in a logarithmic curve to go to HDR as in that case it's full range, however even if the flag in the file would be "full range", due to the nature of the log the waveform would appear as if it was "compressed" in the middle of a waveform monitor, so it shouldn't peak at the extreme boundaries of the full range values.
Anyway, we're getting out of track, you already have the answer with the values you're looking for, so good for it, mine was just to satisfy your curiosity. ;)
kedautinh12
8th August 2021, 07:00
SDI Stream in Limited TV Range with some possible overshoots in the luma if there are bright objects, like for instance if the cameraman is recording a person sitting on a chair and there's a bright lamp behind.
But yeah, it's always limited TV Range, unless you're recording in a logarithmic curve to go to HDR as in that case it's full range, however even if the flag in the file would be "full range", due to the nature of the log the waveform would appear as if it was "compressed" in the middle of a waveform monitor, so it shouldn't peak at the extreme boundaries of the full range values.
Anyway, we're getting out of track, you already have the answer with the values you're looking for, so good for it, mine was just to satisfy your curiosity. ;)
Sr for don't relate comment, are you test last build of L-SMASH Works
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/e5bb1ecb71f0edb5b7632b1013faaed77277e2b4#r54560114
guest
9th August 2021, 10:13
This may not be the right place to ask this....I have been searching for info on MDegrain scripts, that I know used to be available, now I can't find diddly squat !
Has SMDegrain (NotSMDegrain) completely replaced it, and wiped it of the face of the earth ??
I have some scripts that were kinda optimised for HD content, as I find just "straight" SMDegrain is VERY slow with 4K filtering / encoding.
Any info would be welcome.
FranceBB
9th August 2021, 13:07
Sr for don't relate comment, are you test last build of L-SMASH Works
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/e5bb1ecb71f0edb5b7632b1013faaed77277e2b4#r54560114
Ah, crap, I saw the notification the other day, but I was at the park (https://photos.app.goo.gl/Z9ZR8EvZ2Cs3wMM3A) with my phone; not exactly the best place to test it ehehehehehe
I'm now in front of my laptop with an RDP session to the server at work, so I can totally test it. I'll let you know on GitHub and thanks for reminding me.
real.finder
13th August 2021, 15:41
in this (https://github.com/AviSynth/AviSynthPlus/tree/master/distrib/Readme) read me there are
"array" or "val_array": array of any type.
When unnamed, then this kind of parameter must be the very last one.
Unnamed free-typed parametes cannot be followed by any other parameter.
Translates to ".*" in a plugin parameter definition rule.
if I save this as Average.avsi
Function Average(array a)
{
LoadPlugin("C:\path\Average.dll")
Average(a)
}
then load it like this
ClearAutoloadDirs()
ColorBars(width=640, height=480, pixel_type="yv12")
import("Average.avsi")
Average(Blur(1),0.5,last,0.5)
it should work but I get
https://i.postimg.cc/4ddwGBQK/Untitled.png (https://postimages.org/)
seems I missed something or something is already missing in avs side (way to convert array to arguments maybe?)
wonkey_monkey
13th August 2021, 17:56
It's probably picking up the implict last as the first argument. Try
Blur(1).Average(0.5,last,0.5)
or
ClearAutoloadDirs()
a = ColorBars(width=640, height=480, pixel_type="yv12")
import("Average.avsi")
Average(a.Blur(1),0.5,a,0.5)
real.finder
13th August 2021, 21:30
It's probably picking up the implict last as the first argument. Try
Blur(1).Average(0.5,last,0.5)
or
ClearAutoloadDirs()
a = ColorBars(width=640, height=480, pixel_type="yv12")
import("Average.avsi")
Average(a.Blur(1),0.5,a,0.5)
both not work
wonkey_monkey
14th August 2021, 00:58
Ah, then probably Average just doesn't handle arrays as input. It's getting only one parameter, the array, which is not the right number as far as it is concerned. You need to separate out the elements and send them as individual parameters (if you can do such a thing).
real.finder
14th August 2021, 01:04
yes, that why I said "way to convert array to arguments"
cretindesalpes
14th August 2021, 10:11
Another thing: is the Avisynth+ ABI still restricted to MSVC? Or could Clang/MSYS2 or GCC compile plug-ins now?
FranceBB
14th August 2021, 12:38
Another thing: is the Avisynth+ ABI still restricted to MSVC? Or could Clang/MSYS2 or GCC compile plug-ins now?
If I remember correctly MSVC yes, Clang yes, GCC no, in the sense that if you compile a plugin with GCC, then you need an Avisynth build compiled with GCC as well, otherwise you're not gonna be able to run such plugin, so you can't mix GCC builds of plugins with MSVC builds of Avisynth and since almost every build of everything is done with MSVC, then no one compiles with GCC.
Stephen (also called "qyot" for the Doom9 friends) did some successful experiments a while ago in which he compiled Avisynth with GCC and tried to use GCC Compiled plugins with it and it worked, however no one uses it for obvious reasons...
At least this is true on Windows, but it's different for Linux and Mac OSX (yep, as hard to believe as it is, Avisynth is cross platform now eheheheh)
qyot27
14th August 2021, 12:54
Another thing: is the Avisynth+ ABI still restricted to MSVC? Or could Clang/MSYS2 or GCC compile plug-ins now?
Clang is probably okay if you're using clang-cl. Other than that, there be dragons. The only way that's guaranteed would be as a C plugin (in which case the GCC-centric symbol logic is the assumed default), not a C++ plugin.
And currently something has broken the ability for FFmpeg to use GCC builds, although the GCC builds actually compile. It definitely is something on our side, since archived builds (r2831, from 2019) work with the same newer (May 2021) FFmpeg binary.
Myrsloik
14th August 2021, 14:49
Another thing: is the Avisynth+ ABI still restricted to MSVC? Or could Clang/MSYS2 or GCC compile plug-ins now?
It's still the MS C++ ABI only. The only two compilers that support it are MSVC and clang-cl (not other variants of clang, they use the GCC ABI). It's trivial to try out clang-cl, simply select clang in the visual studio installer and then you can choose it as the platform toolset. Binaries are usually noticeable faster.
Do however note that clang-cl doesn't understand the instruction set selection (as done through property pages) very well which can cause problems with intrinsics being rejected.
cretindesalpes
14th August 2021, 19:39
I see. So I’ll stick with MSVC for the Avisynth+ version of fmtconv for the moment.
real.finder
14th August 2021, 19:45
I see. So I’ll stick with MSVC for the Avisynth+ version of fmtconv for the moment.
if MSVC is not good for you, you can always use C API of avs/avs+ https://github.com/Asd-g/AviSynth-VMAF/commit/5c1a5e08fc6c8979dd3fec2a87c9cac81f082269
AviSynth+ can even autoload C plugins unlike the old AviSynth, also you don't need to use loadCplugin in avs+, loadplugin work with it too
vcmohan
22nd August 2021, 13:24
Sorry for asking a simple question. How does one read a double value for an input parameter by the plugin? args[n].AsFloat() I vaguely remembered actually outputs a double but when I tried args[n].AsFloat(0.001) I got a warning of truncating double to float. The input string has f for the value.
cretindesalpes
22nd August 2021, 13:35
You can use AsDblDef(), but anyway the stored type within the AVSValue is always a float.
StainlessS
22nd August 2021, 14:48
You can append default value with trailing 'f', args[n].AsFloat(0.001f)
[not sure if Avs+/visual studio, gives warning now for default value as double without trailing f]
EDIT: AsDblDef() probably better way, never used it.
With VS2008 and earlier, I sometimes had to use something like eg
d = (double)args[n].AsFloat(0.001f)
f = (float)args[n].AsFloat(0.001f)
StvG
22nd August 2021, 15:32
Sorry for asking a simple question. How does one read a double value for an input parameter by the plugin? args[n].AsFloat() I vaguely remembered actually outputs a double but when I tried args[n].AsFloat(0.001) I got a warning of truncating double to float. The input string has f for the value.
The original post. (https://forum.doom9.org/showthread.php?p=1937801&highlight=double#post1937801)
There is an AsFloatf version of AsFloat that should be used to avoid warnings. This function exists for this very reason.
EDIT: maybe I explained the opposite: to avoid return value warning. You can use AsDblDef, but since there is no double in AVSValue there is no point of doing that.
Side note: internally there is no double type in Avisynth. Double and 64 bit integer types are impossible to implement. Reason: AVSValue defined in avisynth.h has its maximum value size dependent of the size of pointer - pointer type is 4 bytes on a 32 bit system - so only a 32 bit float can be held there, no 64 bit double. 64 bit systems would easily support them - of course this needs an interface update - I had plans for that but there are always more important stuffs in the development queue. With the extinction of 32 bit Avisynth versions nobody will care if interface would change.
DTL
23rd August 2021, 11:03
Some idea to Avisynth core clip properties:
Add property to indicate full-band color 4:4:4 clip and half-color band (half vertical, half-horizontal or half-both, may be bitmask ?).
For example fresh non-distorted in spectrum 4:4:4 clip upconverted from 4:2:0 source is half-banded in color in both vertical and horizontal directions. But the next in chain filters can not get this information currently. Also this property need to be user-controllable so if user damage half-banding it may set property to full-band.
It may be useful hint for processing like color subsampling processing and other.
Also use it automatically in Convert4:4:4To4:2:0 and from 4:4:4To4:2:2 operations with defaulting chromaresample to sinc for half-band marked clips and may be current default bicubic (gauss prefferable with fixed p-param adjusted after tuning) for full-band marked 4:4:4 sources.
Also it is very great to add to Contert() the abiliti to pass kernel chromaresampler params (for example p for gauss) because currently used defaults (?) may be far from good for chromaresample.
FranceBB
23rd August 2021, 12:14
Also it is very great to add to Contert() the ability to pass kernel chromaresampler params (for example p for gauss) because currently used defaults (?) may be far from good for chromaresample.
^This^
As result of this discussion: Link (https://forum.doom9.org/showthread.php?t=160038&page=13)
In Converttoyv12, YUY2, yv16, yv24, YUV420, YUV422, YUV444 etc only the built in resizing kernels are supported and with no additional parameters, so that is actually limiting.
I know that just only around 5% of the Doom9 population is actually even bothering to specify the resizing kernel when changing chroma, but anyway I'm in favor of a full args support in the default built-in conversion, to be fair.
vcmohan
26th August 2021, 08:26
You can append default value with trailing 'f', args[n].AsFloat(0.001f)
[not sure if Avs+/visual studio, gives warning now for default value as double without trailing f]
On MS VC 2019 community version tried:-
float d = args[].AsFloat(0.5f)
warning conversion double to float
float d = args[].AsFloat(0.5)
argument truncation from double to float
initializing from double to float.
So it always expects a trailing f in default value, but outputs a double. A bit confusing and is not right.
double d = args[].AsDblDef(0.5) works ok
cretindesalpes
26th August 2021, 08:38
You also can use AsFloatf() which takes a float and returns a float.
StainlessS
26th August 2021, 16:23
Dont think AsDblDef() or AsFloatf() work in avs 2.58, so I dont use either.
DTL
27th August 2021, 10:12
An idea - it looks avisynth support dropping out only error messages. But it may be good for hinting and warning of user to have some method to output warning messages too. In complex processing it may be method to put info about not very best current processing path or where developer not sure and/or ask to pay special attention (where quality may be degraded or where parameter in most cases need adjustment etc).
Dogway
27th August 2021, 10:25
Is there a way to know how string floats get converted to single floats in Expr? I was reading IEEE 754 but nothing on it hinted the following findings:
Merge(a,b,0.25)
equals
Expr(a,b,"x 0.749999 * y 0.249999 * + ")
or
Merge(a,b,0.5)
equals
Expr(a,b,"x y + 0.500001 * ")
For example I tested in this (https://www.h-schmidt.net/FloatConverter/IEEE754.html)online converter, and 0.25 turns out as 0.25 and 0.5 as 0.5.
cretindesalpes
27th August 2021, 11:40
Expr only works with float (no double). Integer multiples of powers of 2 can be represented exactly (like 0.75 = 3 * 2^-2). Other values are rounded, and the exact rounding process depends on the implementation of the standard library used to compile the program. Generally you can expect about 6 digits of precision.
Dogway
27th August 2021, 12:18
Yes I know, but as I was suggested (https://forum.doom9.org/showthread.php?p=1946601#post1946601) you can help the rounding by declaring more float values or like in the example I posted adding or substracting epsilon
I would like to know where I can read more about this, precisely related to the Expr rounding method, and if this also affects summation and not only multiplications.
RRD
29th August 2021, 19:41
On https://avs-plus.net/, at the bottom of the page, "You can find us on our Doom9 thread (http://forum.doom9.org/showthread.php?t=168856)" links to the old thread (http://forum.doom9.org/showthread.php?t=168856) instead of the new one (http://forum.doom9.org/showthread.php?t=181351).
Dogway
7th September 2021, 20:12
Since mid-grey in YUV (128) is not centered within the range (16-235), is it ok that range conversions don't keep mid-grey? Converting from TV range 128 to PC range leads to 130, and the opposite to 126. Shouldn't we compensate for that?
wonkey_monkey
7th September 2021, 20:52
"Mid-grey" is different in TV range than in PC range, just as black and white are. No need for compensation, I think.
Also bearing gamma in mind it's not even really "mid".
Dogway
7th September 2021, 21:58
I thought mid-grey for PC levels was also 128, at least for sRGB. I wasn't talking about scene referred middle grey.
Here's a little experiment, ColorYUV "correctly" converts mid grey to PC range 130, but then when converting that to RGB it keeps 130 when RGB mid-grey is known (https://en.wikipedia.org/wiki/Middle_gray#Table_of_middle_grays)to be 128 for sRGB.
BlankClip(width=256,height=256,color=$828282,pixel_type="YV12")
ColorYUV(levels="TV->PC",matrix="Rec709")
ConvertToPlanarRGB(matrix="PC.709")
DTL
7th September 2021, 22:39
Can Avisynth+ support sequential function calling in scripting with freeing memory after each return ? I trying to make full-frame 1080p (and need 2160p) rasterizer of text for shifting with Animate(). Text is rendered with Subtitle and 100x SSAA with small blocks, but number of blocks is about 12 and system died with swapping at 4 GB memory PC. I think it is because all calls to function with Subtitle() and Overlay() are performed in parallel for each frame ? May exist solution for serializing ?
I can not even fill 1080p frame with text - I trying to render blocks of 132 lines into raw files for later stacking.
Current script:
LoadPlugin("plugins_JPSDR.dll")
function Ast1(clip c, int iFontSize, string strText, string strFont, float fHPos, int iVPos)
{
iHSubPos=fHPos*10 - (10*Int(fHPos))
temp=BlankClip(c, width=8000, height=(iFontSize*15)+40, color=$101010)
temp=Subtitle(temp, strText, x=iHSubPos, font=strFont, size=iFontSize*10, align=4, halo_color=$FF000000, text_color=$00e0e0e0)
temp=UserDefined2ResizeMT(temp, temp.width/10, temp.height/10, b=130,c=23)
return Overlay(c, temp, Int(fHPos), iVPos)
}
function Ast2(clip c, int iFontSize, string strText, string strFont, float fHPos, int iVPos)
{
iHSubPos=fHPos*10 - (10*Int(fHPos))
temp=BlankClip(c, width=8000, height=(iFontSize*15)+60, color=$101010)
temp=Subtitle(temp, strText, x=iHSubPos, font=strFont, size=iFontSize*10, align=4, halo_color=$FF000000, text_color=$00e0e0e0)
temp=UserDefined2ResizeMT(temp, temp.width/10, temp.height/10, b=95,c=-10)
return Overlay(c, temp, Int(fHPos), iVPos)
}
function MyFullFrameTextH(clip c, string strText, float fHPos, int iVShift)
{
c=Ast1(c, 10, strText, "Arial", fHPos + 10, iVShift + 20)
c=Ast1(c, 10, strText, "Times New Roman", fHPos + 70, iVShift + 20)
c=Ast1(c, 10, strText, "Wolfgang Amadeus Mozart", fHPos + 130, iVShift + 20)
c=Ast1(c, 20, strText, "Arial", fHPos + 180, iVShift + 20)
c=Ast1(c, 20, strText, "Times New Roman", fHPos + 300, iVShift + 20)
c=Ast1(c, 20, strText, "Wolfgang Amadeus Mozart", fHPos + 410, iVShift + 20)
c=Ast1(c, 35, strText, "Arial", fHPos + 490, iVShift + 20)
c=Ast1(c, 35, strText, "Times New Roman", fHPos + 690, iVShift + 20)
c=Ast1(c, 35, strText, "Wolfgang Amadeus Mozart", fHPos + 880, iVShift + 20)
c=Ast1(c, 50, strText, "Arial", fHPos + 1000, iVShift + 20)
c=Ast1(c, 50, strText, "Times New Roman", fHPos + 1280, iVShift + 20)
c=Ast1(c, 50, strText, "Wolfgang Amadeus Mozart", fHPos + 1550, iVShift + 20)
c=Ast2(c, 10, strText, "Arial", fHPos + 10, iVShift + 80)
c=Ast2(c, 10, strText, "Times New Roman", fHPos + 70, iVShift + 80)
c=Ast2(c, 10, strText, "Wolfgang Amadeus Mozart", fHPos + 130, iVShift + 80)
c=Ast2(c, 20, strText, "Arial", fHPos + 180, iVShift + 80)
c=Ast2(c, 20, strText, "Times New Roman", fHPos + 300, iVShift + 80)
c=Ast2(c, 20, strText, "Wolfgang Amadeus Mozart", fHPos + 410, iVShift + 80)
c=Ast2(c, 35, strText, "Arial", fHPos + 490, iVShift + 80)
c=Ast2(c, 35, strText, "Times New Roman", fHPos + 690, iVShift + 80)
c=Ast2(c, 35, strText, "Wolfgang Amadeus Mozart", fHPos + 880, iVShift + 80)
c=Ast2(c, 50, strText, "Arial", fHPos + 1000, iVShift + 80)
c=Ast2(c, 50, strText, "Times New Roman", fHPos + 1280, iVShift + 80)
c=Ast2(c, 50, strText, "Wolfgang Amadeus Mozart", fHPos + 1550, iVShift + 80)
return c
}
function MyFullFrameTextH_upper(clip c, string strText, float fHPos, int iVShift)
{
c=Ast1(c, 10, strText, "Arial", fHPos + 10, iVShift + 20)
c=Ast1(c, 10, strText, "Times New Roman", fHPos + 70, iVShift + 20)
c=Ast1(c, 10, strText, "Wolfgang Amadeus Mozart", fHPos + 130, iVShift + 20)
c=Ast1(c, 20, strText, "Arial", fHPos + 180, iVShift + 20)
c=Ast1(c, 20, strText, "Times New Roman", fHPos + 300, iVShift + 20)
c=Ast1(c, 20, strText, "Wolfgang Amadeus Mozart", fHPos + 410, iVShift + 20)
c=Ast1(c, 35, strText, "Arial", fHPos + 490, iVShift + 20)
c=Ast1(c, 35, strText, "Times New Roman", fHPos + 690, iVShift + 20)
c=Ast1(c, 35, strText, "Wolfgang Amadeus Mozart", fHPos + 880, iVShift + 20)
c=Ast1(c, 50, strText, "Arial", fHPos + 1000, iVShift + 20)
c=Ast1(c, 50, strText, "Times New Roman", fHPos + 1280, iVShift + 20)
c=Ast1(c, 50, strText, "Wolfgang Amadeus Mozart", fHPos + 1550, iVShift + 20)
return c
}
function MyFullFrameTextH_lower(clip c, string strText, float fHPos, int iVShift)
{
c=Ast2(c, 10, strText, "Arial", fHPos + 10, iVShift + 80)
c=Ast2(c, 10, strText, "Times New Roman", fHPos + 70, iVShift + 80)
c=Ast2(c, 10, strText, "Wolfgang Amadeus Mozart", fHPos + 130, iVShift + 80)
c=Ast2(c, 20, strText, "Arial", fHPos + 180, iVShift + 80)
c=Ast2(c, 20, strText, "Times New Roman", fHPos + 300, iVShift + 80)
c=Ast2(c, 20, strText, "Wolfgang Amadeus Mozart", fHPos + 410, iVShift + 80)
c=Ast2(c, 35, strText, "Arial", fHPos + 490, iVShift + 80)
c=Ast2(c, 35, strText, "Times New Roman", fHPos + 690, iVShift + 80)
c=Ast2(c, 35, strText, "Wolfgang Amadeus Mozart", fHPos + 880, iVShift + 80)
c=Ast2(c, 50, strText, "Arial", fHPos + 1000, iVShift + 80)
c=Ast2(c, 50, strText, "Times New Roman", fHPos + 1280, iVShift + 80)
c=Ast2(c, 50, strText, "Wolfgang Amadeus Mozart", fHPos + 1550, iVShift + 80)
return c
}
function MyAnimFF(clip c, float fHPos, int VPos)
{
temp=MyFullFrameTextH_upper(c, " TXT Sample ", fHPos, VPos)
return MyFullFrameTextH_lower(temp, " TXT Sample ", fHPos, VPos)
# MyFullFrameTextH(c, " TXT Sample ", fHPos, VPos)
}
full=BlankClip(501,1920,135,"Y16",fps=25, color=$101010)
Animate(full, 1,500, "MyAnimFF", 50, 0, 1, 0)
ConvertToRGB24()
Attempt to make cut function MyFullFrameTextH(clip c, string strText, float fHPos, int iVShift) into 2 pieces did not helps any - the amount of used memory is the same. The size of intermediate frames for AA operation is max about 8000x810 and it is about 12 MByte in size in Y16 format.
poisondeathray
8th September 2021, 01:08
I thought mid-grey for PC levels was also 128, at least for sRGB. I wasn't talking about scene referred middle grey.
Here's a little experiment, ColorYUV "correctly" converts mid grey to PC range 130, but then when converting that to RGB it keeps 130 when RGB mid-grey is known (https://en.wikipedia.org/wiki/Middle_gray#Table_of_middle_grays)to be 128 for sRGB.
BlankClip(width=256,height=256,color=$828282,pixel_type="YV12")
ColorYUV(levels="TV->PC",matrix="Rec709")
ConvertToPlanarRGB(matrix="PC.709")
But if you use that assumption , and defining "middle grey" in sRGB as 128,128,128, shouldn't you should start with sRGB ?
RGB 128,128,128 => Y 126 in limited range, Y 128 in full range
So how are you defining "middle grey" in Y ?
BlankClip(width=256,height=256, color=$808080, pixel_type="RGB24")
ConvertToYV12(matrix="Rec709")
ColorYUV(levels="TV->PC",matrix="Rec709")
ConvertToPlanarRGB(matrix="PC.709")
RGB 128,128,128
Dogway
8th September 2021, 02:46
Well, YUV can also be sRGB (aka PC.709), so it wasn't a fault on my part, but reading on YCbCr (https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.601_conversion)I concluded that Y middle grey is actually 125.5.
Coming from analog (full range) RGB where 0.5 is asummed to be middle grey and converting to YUV by 0.5*(235-16)+16 = 125.5
This actually correctly transforms to 127.5 in PC range.
Dogway
10th September 2021, 22:16
Can this be fixed? Expr() gets the variables mixed in the first example.
Expr("x[0,0] M^ x[1,0] N^ x[2,0] O^
M N + WA@ O + WB@ N - WB WA + + 4 /","")
Expr("x[0,0] M^ x[1,0] N^ x[2,0] O^
M N + W@ O + X@ N - X W + + 4 /","")
pinterf
11th September 2021, 05:56
Can this be fixed? Expr() gets the variables mixed in the first example.
Expr("x[0,0] M^ x[1,0] N^ x[2,0] O^
M N + WA@ O + WB@ N - WB WA + + 4 /","")
Expr("x[0,0] M^ x[1,0] N^ x[2,0] O^
M N + W@ O + X@ N - X W + + 4 /","")
Sure. WA and WB? Anyway that must be an obvious bug, thanks for the report
EDIT: there was a bug with handling multi-letter parameter names ended with @. Fix is coming soon
pinterf
11th September 2021, 07:48
Fixed in
Avisynth+ 3.7.1 test build 11 (20210911) (https://drive.google.com/uc?export=download&id=1L0P-QNyWNiylKd6KTE9kB52S5eS-fRER)
Reel.Deel
11th September 2021, 08:51
Pinterf,
I found a bug in Overlay when the bitdepth is 16 and opacity is less than 1. Happens in RGB and YUV but the problem goes away at any other lower bitdepths.
base = Blankclip(width=270, height=69, color=$FFFFFF, pixel_type="YUV444P16")
over = Blankclip(width=270, height=19, color=$FF0000, pixel_type="YUV444P16")
mask = ExtractY(over).mt_lutspa(mode="relative", expr="x range_max *")
Overlay(base, over, mask=mask, x=0, y=3, mode="blend", opacity=.75)
pinterf
11th September 2021, 09:41
Pinterf,
I found a bug in Overlay when the bitdepth is 16 and opacity is less than 1. Happens in RGB and YUV but the problem goes away at any other lower bitdepths.
What processor type do you have?
edit: issue emerges from SSE4.1 and up
Reel.Deel
11th September 2021, 09:52
What processor type do you have?
Intel i7 4930k. Let me update to the latest test version avs+. I have 3.7 installed right now.
Edit:
https://i.ibb.co/nMrSpRX/cpu.png (https://imgbb.com/)
Edit 2:
Still the same behavior with latest test version and setting SetMaxCPU("sse3") or less fixes the problem.
pinterf
11th September 2021, 12:38
Fixed.
Avisynth+ 3.7.1 test build 12 (20210911) (https://drive.google.com/uc?export=download&id=1tZKYyQEaru1K_QyD_Q4CFiW8arze6aWl)
FranceBB
11th September 2021, 13:46
Wow, so many builds, so little time to upgrade ehehehehe
Thanks for the new version, Ferenc, testing now. :)
Dogway
11th September 2021, 19:11
Sure. WA and WB? Anyway that must be an obvious bug, thanks for the report
EDIT: there was a bug with handling multi-letter parameter names ended with @. Fix is coming soon
Thank you! It was hard to work around it, I will test new version and if it works it allows for great optimizations in Expr()
Reel.Deel
11th September 2021, 20:23
Fixed.
Avisynth+ 3.7.1 test build 12 (20210911) (https://drive.google.com/uc?export=download&id=1tZKYyQEaru1K_QyD_Q4CFiW8arze6aWl)
Just tested the new build and the shift is still there. It is not as drastic as before but with opacity < 1 it shifts the overlay image by 6 pixels to the left. Now the shift is consistent, before it would change depending on the opacity value.
pinterf
12th September 2021, 06:46
Just tested the new build and the shift is still there. It is not as drastic as before but with opacity < 1 it shifts the overlay image by 6 pixels to the left. Now the shift is consistent, before it would change depending on the opacity value.
Thanks. I'm curious. Since I accidentally switched off my remote developer PC instead of the actual :) one over TeamViewer we'll have to wait until Monday.
Reel.Deel
12th September 2021, 20:16
Thanks. I'm curious. Since I accidentally switched off my remote developer PC instead of the actual :) one over TeamViewer we'll have to wait until Monday.
Excellent way to get off of working on a Sunday :D
----
I think I found another discrepancy. Using the color presets from here (http://avisynth.nl/index.php/Color_presets) I cannot get the same results in Blankclip; it returns a different color.
Blankclip(width=132, height=152, color=$9400D3, pixel_type="rgb24") # color_darkviolet
I know it worked in the past but have not needed a colored blankclip in a while.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.