Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th March 2021, 20:39   #861  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
Either I doing something wrong or some degradation happens:

Code:
BlankClip(1000,100,100,"RGB24",25,color=$00101010)

BilinearResize(target_width=width, target_height=height, src_left=0.5, src_top=0.3, src_width=width, src_height=height)
Looks like all built-in resizers start to fail with target_width and target_height params directly typed. Resizers from jpsdr pack works OK.
Documentation still lists these params - http://avisynth.nl/index.php/Resize and supplied with 3.7.0 release too.

Error message: Script error: Invalid arguments to function 'BilinearResize'. If delete 'target_width' and 'target_height' params names it works.

This:
Code:
BilinearResize(width, height, src_left=0.5, src_top=0.3, src_width=width, src_height=height)
works.

Tested with latest 3.7.0 release and also on some previous like 3.6.2.

Last edited by DTL; 6th March 2021 at 20:43.
DTL is offline   Reply With Quote
Old 6th March 2021, 21:01   #862  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
They are non-optional, unnamed parameters. They have names in the description just to have a clue what they really are for.
pinterf is offline   Reply With Quote
Old 6th March 2021, 21:29   #863  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
May be change error message to describe to user what to do to got resizer to work finally ? Or accept these params with names as we have in jpsdr's versions of resizers ?

Current error message is completely mysterious about what going wrong.

Last edited by DTL; 6th March 2021 at 21:36.
DTL is offline   Reply With Quote
Old 6th March 2021, 22:23   #864  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,146
Quote:
Originally Posted by DTL View Post
May be change error message to describe to user what to do to got resizer to work finally ? Or accept these params with names as we have in jpsdr's versions of resizers ?

Current error message is completely mysterious about what going wrong.
You're pretty much asking for NEARLY EVERY existing builtin filter to be updated [and if extended to non builtins, then an awful lot more].
Also ALL docs would likely need update, or at least compulsory arg names checked against implemented compulsory arg names. [for eg error messages]

Perhaps it aint gonna happen any time soon.

Quote:
Originally Posted by pinterf View Post
They are non-optional, unnamed parameters. They have names in the description just to have a clue what they really are for.
And also gives hint about which arguments you are describing in any documentaion.
[easier than "un-named arg 1, un-named arg 2" etc]

Also, If giving compulsory args optional names, then each filter would need additional code to detect where compulsory args were omitted,
and throw error - for each and every compulsory arg. As it is, Avisynth itself throws an error if compulsory arguments are not supplied, with the
"Script error: Invalid arguments to function ..." thing.

Where "Invalid arguments to function " error is given, it aint that much bother to check your supplied arguments against
a function prototype, whether it be style
Code:
BilinearResize(clip clip, int target_width, int target_height [,float src_left, float src_top, float src_width, float src_height ] )
or
Code:
BilinearResize(clip clip, int target_width, int target_height ,float "src_left", float "src_top", float "src_width", float "src_height" )
Where RED are compulsory and BLUE are optional, and in above clip args are compulsory but can use Special Last clip.
[ (Compulsory or Special Last) clip has no defined way of specifying it as such in function/filter prototype].

EDIT: I guess could use something like [where clip in "clip=Last" is not in double quotes and so not optional, but default to Last if not supplied]
Code:
BilinearResize(clip clip=Last, int target_width, int target_height ,float "src_left" = 0.0,  ... )
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 7th March 2021 at 04:26.
StainlessS is offline   Reply With Quote
Old 7th March 2021, 00:43   #865  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 115
" Avisynth itself throws an error if compulsory arguments are not supplied, with the
"Script error: Invalid arguments to function ..." thing."

In the syntax BilinearResize(target_width=width, target_height=height) compulsory arguments do supplied. But this syntax looks like not compatible with built-in Avisynth+ filters. But works for external filters. May be external jpsdr's plugin was designed much time after the beginning of Avisynth, so it uses newer API (or extended) that allow to have names for compulsory arguments too ? Or it is just 'special processing' of arguments list in jpsdr's plugins so it works ? I think plugin uses common API for function calls so it may work equally - either both works or both not works.

I stil not read all documentation on Avisynth+ but may be in some page about function calling and parameters naming there is a restriction to use names for compulsory arguments ?

The provided with current install engine for version 3.7.0 documentation at docs\English\avisynthdoc\syntax\syntax_ref.html only says:
"AviSynth functions can take named arguments. The named arguments can be specified in any order, and the filter will choose default values for any that you leave off."

So it is still undocumented feature that only optional function arguments for built-in functions can be provided in 'named' form ? Or it will raise error about Invalid arguments. And for other (external) functions it depends on exact arguments processing code in the plugin.

Also typically if function actually do not have named argument (or user make error in argument name) it is usually throwed error: Script error: <function name> does not have named argument "__"

So if BilinearResize actually do not have named argument 'targed_width' it is expected to have more pointed to error source message like: Script error: BilinearResize does not have named argument "target_width"

Last edited by DTL; 7th March 2021 at 01:09.
DTL is offline   Reply With Quote
Old 7th March 2021, 01:04   #866  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,146
jpsdr's plugin must use this stuff

Quote:
Also, If giving compulsory args optional names, then each filter would need additional code to detect where compulsory args were omitted,
and throw error, for each and every compulsory arg. As it is, Avisynth itself throws an error if compulsory arguments are not supplied, with the
"Script error: Invalid arguments to function ..." thing.
So, external to the plugin (ie as far as Avisynth is concerned) they are optional, but internal to the plugin, they are detected if missing
and then throws error, and as the plugin knows [well the author knows] the now optional names, so can throw error using those optional names
(although and because, they are actually compulsory).

You can do that for a one-off plugin, so long as author knows he is fully responsible for all errror processing, and avisynth
argument error checking will do pretty much nothing [although it will still check syntax].

I doubt if any special case will be given to any resizers just because jpsdr's did it with a few of his.
EDIT: Additionally, if in future any app [eg AvsPMod] was wanting to scan function prototype
exported/extracted from CPP/C plugin, then jpsdr's plugs compulsory args would be wrongly ascribed as being optional
and perhaps displayed to user as if so.

EDIT:
Code:
BlankClip
#Return test(2,3)             # 6, OK
#Return test(arg2=2,arg3=3)   # 6, OK
#Return test(arg2=2)          # 6, OK, arg3 defaults
#Return test(2)               # 6, OK, arg3 defaults
#Return test(3)               # 9, arg2=3, arg3 = defaults 3, if given arg was intended to be for arg3, then result is wrong.
Return test(arg3=3)           # ERR, arg2 not specified, & no default (ie internal compulsory)
                              #   Error either:-
                              #     "Evaluate: operands of '*' must be numeric"
                              #   or
                              #     "Test: arg2 Undefined", if the Assert() is uncommented.
return last

Function Test(clip c, int "arg2", int "arg3") { # Externally, both arg2 and arg3 are specified optional (surrounded by double quotes).
# arg2 is compulsory although externally specified as optional. So looking at prototype, you have NO IDEA AT ALL that arg2 is actually compulsory.
# Bucket loads of new and exciting bugs to experience and fix.
    arg3 = default(arg3 , 3)                     # arg3 is optional both internal (has default) and external.

#   Function author must detect missing arg2, Otherwise ::: "Evaluate: operands of '*' must be numeric"
#   Assert(arg2.defined,"Test: arg2 Undefined")  # Is internal compulsory. ::: UnComment to fix where gives error if missing.

    x = arg2 * arg3                              # arg2 no default value, is undefined if not supplied.
    return c.Subtitle(String(x),size=48)
}
EDIT:
Quote:
Originally Posted by DTL View Post
So if BilinearResize actually do not have named argument 'targed_width' it is expected to have more pointed to error source message like: Script error: BilinearResize does not have named argument "target_width"
OK, I accept that as a good observation, and could be (dare I say "easily") implemented within avisyhth
main code for both internal and external plugs

Quote:
I stil not read all documentation on Avisynth+ but may be in some page about function calling and parameters naming there is a restriction to use names for compulsory arguments ?
So far as I know (maybe it changed recently), compulsory args never have a name in CPP/C spec [just a type]
eg "ci" for clip, int, both un-named.
Optional as in "ci[boolarg]b[floatarg]f", where Function (clip, int, bool "boolarg", float "floatarg") sort of in script speak.
Un-named optional arg as in ""ci[]b" where bool arg is un-named optional.
As far as new arrays and such are concerned, I got no idea at all how that works.

From an old RT_stats script that extracts function prototypes from C style specifiers.
The script will only extract a single specifier string where there are multiple alternate specifiers strings, multiples are not exposed for extraction.
There should be 2 versions of Abs() below, ie Abs "f" and Abs "i". The script actually extracts 2 identical copies of Avs "f", I removed one by hand.
Code:
        AviSynth+_3.5.2_(r3218,_neo,_i386)_ORDERED_Function_List

There follows a list of all function names together with CPP style argument specifiers that inform
Avisynth the argument types and optional names. Optional arguments have square brackets surrounding
their name as in [name] and are followed by a type specifier character that gives the type.
Unnamed arguments are not optional. eg "cc[arg1]b[arg2]i" would be two compulsory unnamed clip args,
followed by optional 'arg1' of type bool and optional 'arg2' of type int.

# Argument type specifier strings.
 c - Video Clip
 i - Integer number
 f - Float number
 s - String
 b - boolean
 . - Any type (dot)
# Array Specifiers
 i* - Integer Array, zero or more
 i+ - Integer Array, one or more
 .* - Any type Array, zero or more
 .+ - Any type Array, one or more
#    Etc


abs                       "f"
acos                      "f"
AddAlphaPlane             "c[mask]."
AddAutoloadDir            "s[toFront]b"
AddBorders                "ciiii[color]i[color_yuv]i"
AlignedSplice             "cci"
Amplify                   "cf+"
AmplifydB                 "cf+"
Animate                   "ciis.*"
Apply                     "s.*"
ApplyRange                "ciis.*"
Array                     ".*"
ArrayGet                  "a.+"
ArraySize                 "a"
asin                      "f"
Assert                    "s"
AssumeBFF                 "c"
AssumeFieldBased          "c"
AssumeFPS                 "cc[sync_audio]b"
AssumeFrameBased          "c"
AssumeSampleRate          "ci"
AssumeScaledFPS           "c[multiplier]i[divisor]i[sync_audio]b"
AssumeTFF                 "c"
atan                      "f"
atan2                     "ff"
audiobits                 "c"
audiochannels             "c"
AudioDub                  "cc"
AudioDubEx                "cc"
audioduration             "c"
audiolengthf              "c"
audiolengthhi             "c[]i"
audiolengthlo             "c[]i"
audiolengths              "c"
audiorate                 "c"
AudioTrim                 "cf[end]f"
AutoloadPlugins           ""
AverageB                  "c[offset]i"
AverageChromaU            "c[offset]i"
AverageChromaV            "c[offset]i"
AverageG                  "c[offset]i"
AverageLuma               "c[offset]i"
AverageR                  "c[offset]i"
AVIFileSource             "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i[utf8]b"
AVISource                 "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i[utf8]b"
BDifference               "cc"
BDifferenceFromPrevious   "c"
BDifferenceToNext         "c[offset]i"
BicubicResize             "cii[b]f[c]f[src_left]f[src_top]f[src_width]f[src_height]f"
BilinearResize            "cii[src_left]f[src_top]f[src_width]f[src_height]f"

# ...
EDIT: In above extraction, ArrayGet "a.+", the 'a' is new array specifier.
Looks something like, an array of any type of 1 or more elements, or maybe its an array of arrays or something,
as ".+" = any type Array, one or more.
EDIT: "a.+" Probably an array of arrays where each of the 2nd dim arrays has one or more elements of any type,
no idea what to call it, dont think "sparse array".
I still got no real idea, but wondering if "a.+" should be "a.*" where 2nd dim arrays could be 0 or more elements,
v3.7.0 (r3382) still uses ArrayGet "a.+".
EDIT: Or maybe I got it back-to-front and ".+" specifies 1st dimension of 1 or more. [no spec minimum els for 2nd dim].

EDIT: Nah, musta been half asleep, "a" is maybe single variable holding array, and ".+" one of more variables of any type", maybe.


EDIT: Also note un-named optional, audiolengthhi "c[]i"
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 8th March 2021 at 16:27.
StainlessS is offline   Reply With Quote
Old 10th March 2021, 23:43   #867  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,147
AVSValue's AsFloat(...) returns a double, but if you try and pass a double as the default value the compiler warns that there'll be a conversion to float. If it returns a double, shouldn't it accept a double as a default value?
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 11th March 2021, 07:40   #868  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
Quote:
Originally Posted by wonkey_monkey View Post
AVSValue's AsFloat(...) returns a double, but if you try and pass a double as the default value the compiler warns that there'll be a conversion to float. If it returns a double, shouldn't it accept a double as a default value?
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.

Last edited by pinterf; 11th March 2021 at 07:47.
pinterf is offline   Reply With Quote
Old 11th March 2021, 08:14   #869  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
Quote:
Originally Posted by StainlessS View Post
EDIT: In above extraction, ArrayGet "a.+", the 'a' is new array specifier.
Looks something like, an array of any type of 1 or more elements, or maybe its an array of arrays or something,
as ".+" = any type Array, one or more.
EDIT: "a.+" Probably an array of arrays where each of the 2nd dim arrays has one or more elements of any type,
no idea what to call it, dont think "sparse array".
I still got no real idea, but wondering if "a.+" should be "a.*" where 2nd dim arrays could be 0 or more elements,
v3.7.0 (r3382) still uses ArrayGet "a.+".
EDIT: Or maybe I got it back-to-front and ".+" specifies 1st dimension of 1 or more. [no spec minimum els for 2nd dim].

EDIT: Nah, musta been half asleep, "a" is maybe single variable holding array, and ".+" one of more variables of any type", maybe.


EDIT: Also note un-named optional, audiolengthhi "c[]i"
The new array specifier "a" expects a real array at its parameter position. Such arrays can be more-than 1D, and their elements are not restricted to have the same type.

In classic Avisynth arrays were always used behind the scenes (.+ one or more anything, .* zero or more anything). Script parser logic was grouping the comma delimited parameters into the given array variable. Only 1D arrays were supported, and array elements must have of the same type.
This kind of array element collection logic thus needs to know where the array elements are ended. This is easy for array of specific types. Comma separated list has an end where the value type gets changed. E.g. Avisynth parser can easily read and populate a string list into array when it has a specific end.
For this function signature:
Code:
[paramname_s]s*[anotherparam]i
the script parameters given
Code:
"Item1", "Item2", "Item3", 123
Parser will stop collecting string array when it encounters a non-string type.
paramname_s: array[3] : ("Item1", "Item2", "Item3")
anotherparam: integer : 123

What about the ".*" type? These mean array of zero-or-more any-type.
Avisynth can only detect the end of such arrays in a comma delimited list when a named parameter is explicitely given (thanks for StainlessS for the explanation).
Unnamed parameters cannot follow a ".*" array.

Edit: with Stain"EagleEye"LessS' corrections

Last edited by pinterf; 11th March 2021 at 14:38. Reason: corrections by StainlessS
pinterf is offline   Reply With Quote
Old 11th March 2021, 12:41   #870  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 9,146
Thanks P, it all seems very complicookered

EDIT: Removed some stuff.
I'll leave below in-situ as it maybe helps show practical usage example of
Explicitly given named param to terminate data list ('.*' or '.+' , zero/one or more, of any type).

Some of my plugs use eg "Append=True/False" following a pseudo array of zero/one or more items of any type,
user must explicitly use optional name to terminate pseudo data array early eg

".*", Any type, zero or more, if wanting to supply Append=true, then must explicitly use "Append=true" after final data arg, even if zero data args.
Code:
env->AddFunction("RT_WriteFile",  "ss.*[Append]b",RT_WriteFile, 0);
Script doc style prototype (and doc), compulsory arg names FileName and format are only for docs, they cannot have names supplied.
Unnamed dat1 to datn, also cannot have names supplied, are only for docs.
Code:
RT_WriteFile(String FileName, string format, dat1, ... , datn, bool "Append"=False)

 Writes  a formatted string to FileName file. The unnamed 'format' string and optional unnamed 'dat' args are used to construct the
 text string that is written, uses C/CPP printf() style formatting.
 Format: compulsory string controlling format and describing the datn type args that are expected.
 datn: Variable number of data args of any type (excluding clip).
 Append, Default False, optional and MUST be supplied with name (eg Append=True) as we do not know where optional data args end,
 Appends to file if already exists, else opens new FileName.
NOTE, Above, dat1 ... datn, are described as optional because of the zero or more spec [although they have no optional names].

Example script usage
Code:
RT_WriteFile(".\Fred.log", "%d] %s", current_frame, "Hello Sexy", Append=True)  # Two Data Args are required as specified in format string(Int, String)
RT_WriteFile(".\Fred.log", "Some Text", Append=True)    # Zero Data args in Pseudo Array (Format string has no '%' data insertion markers)
NOTE, above format string %d and %s describes only the C printf() style expected data args and is only to do with file output formatting,
it is not part of or related to the ".*" spec, we used only because its the easiest and only example that we thought of.

Dont think above has ever been documented anywhere, is result of testing to see what happens, ie 'suck-it-and-see' tactics.

EDIT: https://dictionary.cambridge.org/dic...uck-it-and-see
Quote:
suck it and see
UK informal

to try something to find out if it will be successful:
I'm not sure whether this paint is the right colour for the bedroom - we'll just have to suck it and see.
If you've got a bag of identical looking (but multiple flavour) chocolates, you may implement a Suck It And See policy.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 12th March 2021 at 04:41.
StainlessS is offline   Reply With Quote
Old 11th March 2021, 14:41   #871  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
Thank you SssS. You know the language so much better than me. Fixed the lines but I'm sure I put other stupid declarations there.
pinterf is offline   Reply With Quote
Old 13th March 2021, 14:58   #872  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,165
Quote:
Originally Posted by real.finder View Post
is https://publishwith.me/ep/pad/view/r...cdWn4k9/latest locked?
edit: I think I know why, I note there were some CCP writing spam text
I was trying to add
SetFilterMTMode("IT", MT_SERIALIZED)

anyway, here my MtModes.avsi https://pastebin.com/tmw7J2mj
uptodate one here https://github.com/realfinder/Univer...B/MtModes.avsi
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 15th March 2021, 00:22   #873  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 1,088
I have a question about ImageSource from AVS+.
Is it supposed to support 16bpc image input natively? Because I have a 16bpc PNG images sequence that by default is opened as RGB32 (with or without Devil library). If I force the pixel_type to RGB48 I get 16bpc but the difference (with subtract command) from this image and the same decoded as 8bit is zero. On the other side, if I open the image with LWLibavVideoSource, and doing the same subtraction, the results is a visible difference.
Maybe I'm doing something wrong somewhere?

Last edited by mp3dom; 15th March 2021 at 00:37.
mp3dom is offline   Reply With Quote
Old 15th March 2021, 01:57   #874  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,629
Quote:
Originally Posted by mp3dom View Post
I have a question about ImageSource from AVS+.
Is it supposed to support 16bpc image input natively? Because I have a 16bpc PNG images sequence that by default is opened as RGB32 (with or without Devil library). If I force the pixel_type to RGB48 I get 16bpc but the difference (with subtract command) from this image and the same decoded as 8bit is zero. On the other side, if I open the image with LWLibavVideoSource, and doing the same subtraction, the results is a visible difference.
Maybe I'm doing something wrong somewhere?


Works ok for me (difference detected with subtract)

Are you converting 8bit up to 16bit, or 16bit down to 8bit to compare?

There is a difference for me when I convert 8bit to 16bit to compare vs. original 16bit; or 16 down to 8 to compare with imagesource default 8bit

(But if you downconvert 16 to 8, then the dithering algo choice can also make other difference)


a=imagesource("16bitpng.png")
b=imagesource("16bitpng.png", pixel_type="RGB48")

subtract(a.convertbits(16), b) => difference
#subtract(a, b.convertbits(8, dither=-1)) => difference


Another way to confirm this is write out the imagesource pixel_type="RGB48" png (e.g. pipe to ffmpeg) , then check in vapoursynth. Since vsedit can display >8bit values with the color picker (x=, y=, and R,G,B values) , you can check if it works. eg. You can use a known 16bit RGB test ramp such as x=0, RGB4096, to x=1919, RGB6015. And yes, imagesource pixel_type="RGB48" works correctly.
poisondeathray is offline   Reply With Quote
Old 15th March 2021, 02:24   #875  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 1,088
I tried both ways (16 to 8 and 8 to 16). There were slighty differences, while with LWLibav the differences were higher.
Anyway thanks for the check, I'll investigate further on my side.
mp3dom is offline   Reply With Quote
Old 15th March 2021, 02:27   #876  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,629
Quote:
Originally Posted by mp3dom View Post
I tried both ways (16 to 8 and 8 to 16). There were slighty differences, while with LWLibav the differences were higher.
Anyway thanks for the check, I'll investigate further on my side.
No difference for me between ImageSource pixel_type="RGB48" and LSmash

b=ImageSource("16bit.png", pixel_type="RGB48")
l=LWLibavVideoSource("16bit.png")

subtract(b,l)

avs 3.7 x64 r3382
Maybe something peculiar about your png ?
poisondeathray is offline   Reply With Quote
Old 15th March 2021, 08:42   #877  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,399
Maybe one of the methods respects the Gamma flag in the PNG?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 15th March 2021, 18:06   #878  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,629
Quote:
Originally Posted by LigH View Post
Maybe one of the methods respects the Gamma flag in the PNG?
Yes, this can explain a difference in handling of PNG's in avisynth

ImageSource will adjust the image according to the cHRM and gAMA tags. LSmash will ignore.

You can examine png's with tweakpng
poisondeathray is offline   Reply With Quote
Old 19th March 2021, 23:14   #879  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,147
http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API

On this page it states:

Quote:
MakeWritable only copies the active part of the frame to a completely new frame with a default pitch. You need this to recieve a valid write pointer to an existing frame.
a) What is meant by "active part"?
b) Does MakeWriteable make a new copy even if the frame is already writeable? (IsWritable() == true)

PS The section on IsWriteable() has a typo:

Quote:
if (src->IsWritetable()) {...}
__________________
My AviSynth filters / I'm the Doctor

Last edited by wonkey_monkey; 19th March 2021 at 23:25.
wonkey_monkey is offline   Reply With Quote
Old 20th March 2021, 11:26   #880  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,853
Quote:
Originally Posted by wonkey_monkey View Post
MakeWritable makes a NewVideoFrame (NewVideoFrameP for avs+) and BitBlt for all planes.

Active part means that when a frame was created by the quick SubFrame method (e.g. ExtractY, Crop) if won't copy the whole memory content of the original framebuffer, only those which are really take part of the specific colorspace and frame.

Quote:
Originally Posted by wonkey_monkey View Post
b) Does MakeWriteable make a new copy even if the frame is already writeable? (IsWritable() == true)
No. It then copies nothing, returns immediately and leaves PVideoFrame pointer in its original state.
pinterf is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 02:23.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.