AviSynth+ thread Vol.2

[wonkey_monkey]

Has something changed with animate? I just dug out an old script which used animate without specifying a clip (i.e. using implicit last) but that no longer seems to work. Now I have to specify "last" or tack it directly on the end:

# this works:

colorbars.animate(0,100,"blur",0.1,1.5)

# this works:

colorbars
animate(last, 0,100,"blur",0.1,1.5)

# this DOESN'T work:

colorbars
animate(0,100,"blur",0.1,1.5)

Edit: seems to be a problem with implicit last as in the post below.

[ajp_anton]

colorbars.converttoyv12

trim(0,0)

writefileif(last, "test.txt", "ydifferencefromprevious==0", "current_frame")

"Invalid arguments to function 'writeif'."

Comment out the trim, and it works. Also works with "trim(last,0,0)", but "last.trim(0,0)" fails.

[Dogway]

Originally Posted by Boulder

Despot v3.6.3.0 (x64) causes an access violation error with 3.6.2-test1. I didn't test any previous releases.

It's been reported here as well at the expect Groucho2004 replies back.

[Groucho2004]

Originally Posted by Dogway

It's been reported here as well at the expect Groucho2004 replies back.

I've been doing some debugging but to no avail. Also, very little time ATM.

[Groucho2004]

Originally Posted by Dogway

It's been reported here as well at the expect Groucho2004 replies back.

I have uploaded a new version (3.6.3.1), shouldn't crash any more.

[hello_hello]

Avisynth+ 3.5 on XP.

The following results in an access violation error message.

ConvertToRGB64().ConvertBits(8, dither=1)

As does this.

ConvertToRGB48().ConvertBits(8, dither=1)

Without dithering, or with dither=0, they're fine.

While I'm here, is there any dithering applied for this sort of down-conversion?

ConvertToRGB64().ConvertToRGB32()

Thanks.

[poisondeathray]

Originally Posted by hello_hello

Avisynth+ 3.5 on XP.

The following results in an access violation error message.

ConvertToRGB64().ConvertBits(8, dither=1)

As does this.

ConvertToRGB48().ConvertBits(8, dither=1)

Without dithering, or with dither=0, they're fine.

You should use planar RGB for any processing
ConvertToPlanarRGB()

But maybe a better error message could be added

While I'm here, is there any dithering applied for this sort of down-conversion?

ConvertToRGB64().ConvertToRGB32()

No

[hello_hello]

Originally Posted by poisondeathray

You should use planar RGB for any processing
ConvertToPlanarRGB()

I only put ConvertToRGB64() before ConvertBits() to imply the source was already RGB64 and I'm converting to RGB32 with
ConvertBits(8, dither=1)
I should have made the clear.

If a source is interlaced RGB, the script I'm working on converts the colorimatry with HDRTools the following way. It's probably not something there'd be a need for often, but the option is included.

ConvertToRGB64().ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

This way for planer:
ConvertBits(32).ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

It makes it a little easier to convert back to the original bitdepth afterwards, but do you know if there's an advantage to always using a planar input? It needs to be RGB32, RGB64 or 32 bit planer, but RGB32 causes color banding.

Originally Posted by poisondeathray

But maybe a better error message could be added

But why can I down-convert with dither=0 or dither=-1?
Is there a reason dither=1 can't be used when down converting RGB64 or RGB48?

Originally Posted by poisondeathray

No

Does that mean for converting an RGB64 source to RGB32, there's no difference between these two methods?

ConvertBits(8, dither=-1)
ConvertToRGB32()

I assumed it'd be better to dither when down-converting. Is that correct?

Thanks.

[poisondeathray]

Originally Posted by hello_hello

I only put ConvertToRGB64() before ConvertBits() to imply the source was already RGB64 and I'm converting to RGB32 with
ConvertBits(8, dither=1)
I should have made the clear.

If a source is interlaced RGB, the script I'm working on converts the colorimatry with HDRTools the following way. It's probably not something there'd be a need for often, but the option is included.

ConvertToRGB64().ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

This way for planer:
ConvertBits(32).ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

It makes it a little easier to convert back to the original bitdepth afterwards, but do you know if there's an advantage to always using a planar input? It needs to be RGB32, RGB64 or 32 bit planer, but RGB32 causes color banding.



But why can I down-convert with dither=0 or dither=-1?
Is there a reason dither=1 can't be used when down converting RGB64 or RGB48?

That was referring planar vs. packed (interleaved) RGB , not "bits"

It's analogous to YV16 vs. YUY2 . Planar vs. Packed

eg. "RGB64" would be "RGBAP16" . Both are 16bit per channel RGB with alpha

http://avisynth.nl/index.php/Avisynthplus_color_formats

Planar processing is faster; most modern filters work with planar. Packed support is only for legacy purposes

When something doesn't work in avisynth for RGB processing , chances are you need planar RGB. That's where some better error message could be helpful

Does that mean for converting an RGB64 source to RGB32, there's no difference between these two methods?

ConvertBits(8, dither=-1)
ConvertToRGB32()

I assumed it'd be better to dither when down-converting. Is that correct?

There should be no difference. You can check with subtract or psnr or simlar methods

"Better or not" depends on the situation

[hello_hello]

Thanks for the info. I'll do the color conversion in 32 bit planer and convert back to RGB64 or RGB32 etc later.

[pinterf]

Originally Posted by wonkey_monkey

Has something changed with animate? I just dug out an old script which used animate without specifying a clip (i.e. using implicit last) but that no longer seems to work. Now I have to specify "last" or tack it directly on the end:

# this works:

colorbars.animate(0,100,"blur",0.1,1.5)

# this works:

colorbars
animate(last, 0,100,"blur",0.1,1.5)

# this DOESN'T work:

colorbars
animate(0,100,"blur",0.1,1.5)

Edit: seems to be a problem with implicit last as in the post below.

Fixed on git.

# this DOESN'T work:
colorbars
Animate(0,100,"blur",0.1,1.5)

Animate is special in the way that it has two function signatures: "iis." and "ciis."
Passing the parameters with the syntax above will find the "clipless" version. Animate is created O.K.
When its internal expression parameter "blur" is evaluated later, it turnes out that it requires a clip. But it's too late, function with the matching (clipless) function signature was already chosen and Invoking "Animate" as a whole will fail and giving a function arguments error.

When such function parameter error exception is thrown, Avisynth will try to give a second changce and find the appropriate function with a forced clip ("last") variable.

[pinterf]

Originally Posted by hello_hello

Avisynth+ 3.5 on XP.

The following results in an access violation error message.

ConvertToRGB64().ConvertBits(8, dither=1)

As does this.

ConvertToRGB48().ConvertBits(8, dither=1)

Without dithering, or with dither=0, they're fine.

While I'm here, is there any dithering applied for this sort of down-conversion?

ConvertToRGB64().ConvertToRGB32()

Thanks.

From RGB64 and RGB48 ConvertBits failed to get its floyd converter function internally, so it crashed.

Fixed on git, result should be the same as with planar RGB formats. Indeed, in this case 16 bit packed formats are treated internally (losslessly converted to and from) as planar RGB.

[pinterf]

Originally Posted by ajp_anton

colorbars.converttoyv12

trim(0,0)

writefileif(last, "test.txt", "ydifferencefromprevious==0", "current_frame")

"Invalid arguments to function 'writeif'."

Comment out the trim, and it works. Also works with "trim(last,0,0)", but "last.trim(0,0)" fails.

Could not reproduce.

[pinterf]

Originally Posted by Boulder

I have a video clip, which has a green bar at the right side of the frame if I convert bitdepth to 16 bits and use Blur.
[...]

FFVideoSource("snip.avi")
convertbits(16)
Blur(0.65)

fixed on git
AVX2 issue which occurs with non mod32 width.

[real.finder]

Function SCDetect(clip c, string "scFile", int "thSCD1", int "thSCD2", float "mDiff", int "pel", int "search", int "searchparam", bool "preblur", bool "info"){

  scFile  = Default(scFile, "scFile.log")
  thSCD1  = Default(thSCD1,          360)
  thSCD2  = Default(thSCD2,          120)
  mDiff   = Default(mDiff,           2.5)
  pel     = Default(pel,               1)
  search  = Default(search,            4)
  searchparam = Default(searchparam,   2)
  preblur = Default(preblur,        true)
  info    = Default(info,          false)

  last    = preblur ? c.RemoveGrain(20, 0) : c

  Assert( IsYV12 , "SCDetect needs YV12 input!" )

  super   = MSuper(pel=pel, chroma=false)
  vector  = super.MAnalyse(pelsearch=pel, search=search, searchparam=searchparam, chroma=false)
  global scMask = MSCDetection(vector, thSCD1=thSCD1, thSCD2=thSCD2).Crop(0,0,16,16)

  global SC_mD  = mDiff
  global mean   = Histogram(mode="Color").Crop(width+64, 64, 128, 128)

  SCTrue  = c.Subtitle("Scene change: true" )
  SCFalse = c.Subtitle("Scene change: false")

  info ? ConditionalFilter( last, SCTrue, SCFalse, "boolSC", "==", "true" )
  \    : nop
  FrameEvaluate( """global boolSC =
  \           (
  \             ( scMask.YPlaneMax == 255 ) &&
  \             (
  \               (mean.YDifferenceFromPrevious > SC_mD*3) ||
  \               (
  \                 (mean.YDifferenceFromPrevious > SC_mD) &&
  \                 (mean.YDifferenceFromPrevious > (mean.YDifferenceToNext+mean.loop(0, 0, -1).YDifferenceToNext+mean.loop(0, 0, 1).YDifferenceToNext)/1.2)
  \               )
  \             )  
  \           )""" )

  ( scFile != "nul" ) ? WriteFileStart( scFile, """ "# Scene change frame list" """ ).WriteFileIf( scFile, "boolSC==true", "current_frame" ) : nop

  return last
}
ColorBars
Converttoyv12
SCDetect

still not work with build 0bf7242 I made, but Animate now work

[real.finder]

Originally Posted by ajp_anton

colorbars.converttoyv12

trim(0,0)

writefileif(last, "test.txt", "ydifferencefromprevious==0", "current_frame")

"Invalid arguments to function 'writeif'."

Comment out the trim, and it works. Also works with "trim(last,0,0)", but "last.trim(0,0)" fails.

Originally Posted by pinterf

Could not reproduce.

I can, but you need to have grunt, without grunt not reproduce

[StainlessS]

Suspect BUG.
Prefetch(), seem to interfere with scriptclip evaluated runtime functions, optional named args, following an array of data args.

Here, and the following post:- https://forum.doom9.org/showthread.p...11#post1922711

[real.finder]

Originally Posted by StainlessS

Suspect BUG.
Prefetch(), seem to interfere with scriptclip evaluated runtime functions, optional named args, following an array of data args.

Here, and the following post:- https://forum.doom9.org/showthread.p...11#post1922711

did you tried with test 2 ? https://drive.google.com/file/d/1h-C...rp8eovr9w/view

[StainlessS]

Thanks RF, no I did not yet, I always have problems downloadng Pinterf google drive stuff, I'll boot to linux and re-try download.

EDIT:
Got it under linux.
It actually downloads under Windows 7 with Opera (I forgot this time about Opera, but downloads usually only after some wait),
I have big-ish hosts file on windows blocking all kinds of ads/telemetry and stuff, Also Adblock origin, flash block and other stuff under both linux and
windows versions of firefox, so its probably my system hosts and firefox addons that cause me problems.

[StainlessS]

Yep, 3.6.2 test 2, removes the problem OK, thanks RF, sorry for the bother P & Q.

EDIT: I dont usually download files only test version of Avs+, until/unless there is an XP version included.