Avisynth+

[videoh]

I have Avisynth+ 1576 in my SysWOW64 directory. I open a script with just Version() in it in VirtualDub. It opens fine. I replace Avisynth.dll with the x86 DLL from Avisnth+ 2455. Now VirtualDub says import error. What stupid mistake am I making?

Win10 64

Thank you.

[Reel.Deel]

I have Avisynth+ 1576 in my SysWOW64 directory. I open a script with just Version() in it in VirtualDub. It opens fine. I replace Avisynth.dll with the x86 DLL from Avisnth+ 2455. Now VirtualDub says import error. What stupid mistake am I making?

Win10 64

Thank you.

Did you update the plugins with the new ones from the latest release?

[videoh]

I just did now and it still fails.

Do you know how to do a clean install of 2455, i.e., what installer version should I use before copying over all the files.

[videoh]

I cleaned everything out and installed Groucho's last installer for 2294, checking both x32 and x64. Loading version.avs in VirtualDub 64 works, loading it in VirtualDub 32 fails. Then, just replacing the x32 avisynth.dll with the r1576 makes x32 work again. Any ideas?

[yup]

videoh!
Try
https://forum.doom9.org/showthread.php?p=1585008#post1585008
and post log.
yup.

[videoh]

yup, you're my hero, thank you so much!

I didn't have the 32-bit runtime installed, only the x64 one.

EDIT: AOK now.

[yup]

videoh!
Installing avisynth tricky process :D.
yup.

[StainlessS]

@videoh, you might want to thank Groucho2004 too, is theguy that provided the app that sorted you, and same guy that you not so long ago barred from your forum for no concrete reason.

Mobile.

[yup]

I try load 16 bit image (grey scale) to Avisynth+.
1. I prepare stacked version of image:
"C:\Program Files\ImageMagick-7.0.5-Q16\magick" "film7 1.tif" -depth 16 ( +clone -evaluate and 255 -evaluate multiply 256 ) -append stacked001.png
2. try load to Avisynth:
ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24")
ConvertToYV24()
ConvertFromStacked()
And do not see my image, if remove ConvertFromStacked I see stacked image.
yup.

[LigH]

Converting each significant bit part in RGB representation to YUV does not result in each significant bits for the YUV representation. This is caused by the specific PC-affine color representation in different YUV color space matrices (8 bit integer per component, instead of floating point values).

Trivial case: You create an RGB image in 8 bit depth for the more significant half, and the less significant half is kept at $000000 (black in RGB). Converting this to YCbCr (Rec.601, TV scale) will return (16, 128, 128) as "TV black". Combining LSB and MSB to a 16-bit value now will result in garbage colors.

To do the conversion correctly, I believe you would first need to ConvertFromStacked(), and then ConvertToYUV... with 16 bit depth. But I am not sure if that is supported, and which functions are available if.

[yup]

Converting each significant bit part in RGB representation to YUV does not result in each significant bits for the YUV representation. This is caused by the specific PC-affine color representation in different YUV color space matrices (8 bit integer per component, instead of floating point values).

Trivial case: You create an RGB image in 8 bit depth for the more significant half, and the less significant half is kept at $000000 (black in RGB). Converting this to YCbCr (Rec.601, TV scale) will return (16, 128, 128) as "TV black". Combining LSB and MSB to a 16-bit value now will result in garbage colors.

To do the conversion correctly, I believe you would first need to ConvertFromStacked(), and then ConvertToYUV... with 16 bit depth. But I am not sure if that is supported, and which functions are available if.
Easy way do not exist?
Right?
New Devil.dll, ImageSeq.dll in last avs+ builds do not support 16 bit?
yup.

[pinterf]

I try load 16 bit image (grey scale) to Avisynth+.
1. I prepare stacked version of image:
"C:\Program Files\ImageMagick-7.0.5-Q16\magick" "film7 1.tif" -depth 16 ( +clone -evaluate and 255 -evaluate multiply 256 ) -append stacked001.png
2. try load to Avisynth:
ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24")
ConvertToYV24()
ConvertFromStacked()
And do not see my image, if remove ConvertFromStacked I see stacked image.
yup.

ConvertFromStacked cannot have RGB input, we have to play with lossless format conversions (data is unchanged, planes are copied as-is). Once we have YUV, we can use ConvertFromStacked, than go back to planar RGB.
At this stage we have the original 16 bit RGB, in planar RGB format (RGBP16).

You can convert it further if you wish.

This works for me
stacked_rgb24 = ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24")
stacked_fakeyuv = CombinePlanes(stacked_rgb24,"YUV","RGB","YV24")
fakeyuv16 = ConvertFromStacked(stacked_fakeyuv)
rgbp_16=CombinePlanes(fakeyuv16,"RGB","YUV","RGBP16")
#here we have 16 bit planar RGB
rgbp_16.ConvertToYUV444() # convert to YUV444P16
# or rgbp_16.ConvertToRGB64() # convert to packed RGB64

[real.finder]

FFImageSource should load HBD without hack

[Reel.Deel]

FFImageSource should load HBD without hack

Not necessarily, FFMS2 v2.23.1 used SWScale and could not load HBD images. This issue affected both AVS+ and VS. I told Myrloik about it some time ago: https://github.com/FFMS/ffms2/issues/277

I have not tried it yet but the latest test version of FFMS2000 might support it since it has FFmpeg compiled with zlib (http://forum.doom9.org/showpost.php?p=1802287&postcount=19).


@pinterf

Any plans to add HDB support to ImageReader/Writer? If I understand correctly Wilbert said he had already written the code for that: http://forum.doom9.org/showthread.php?p=1773088#post1773088

[pinterf]

@pinterf

Any plans to add HDB support to ImageReader/Writer? If I understand correctly Wilbert said he had already written the code for that: http://forum.doom9.org/showthread.php?p=1773088#post1773088
It was forgotten, that was at the very beginning.

Wilbert's link needs authentication, anyway I have tried something quickly and this works fine for my 48 bit tiff sample.
ImageSource("img010.tif", start=1, end=1, use_DevIL=true, pixel_type ="RGB64") # or RGB48

A bit nicer that my previous stacked workaround.

[yup]

pinterf!
I try Your first script:
stacked_rgb24 = ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24")
stacked_fakeyuv = CombinePlanes(stacked_rgb24,"YUV","RGB","YV24")
fakeyuv16 = ConvertFromStacked(stacked_fakeyuv)
rgbp_16=CombinePlanes(fakeyuv16,"RGB","YUV","RGBP16")
#here we have 16 bit planar RGB
rgbp_16.ConvertToYUV444() # convert to YUV444P16
# or rgbp_16.ConvertToRGB64() # convert to packed RGB64
Without success using shekh VirtualDub. Exist restriction for image size? My image (stacked) 6639x8062 pixels.
Second also not work, error about not support RGB48.
yup.

[pinterf]

pinterf!
I try Your first script:
[...]
Without success using shekh VirtualDub. Exist restriction for image size? My image (stacked) 6639x8062 pixels.
yup.
As a stress test, I set the a final size (not stacked) to 6640x8062. (my stacked size is 2320x6670)

One final frame (as RGB64) needs almost 500 MBytes.

I had to raise the default memory for 32 bit Avisynth+ (because Avisynth+ complained for low memory, default is 1GBytes), and when I have set it to 3000, then 32 bit Virtualdub was showing memory error (could not allocate x bytes)

In 64 bit virtualdub (and thus 64 bit Avisynth+), I was able to open and view the script (see below) producing rgb64 image.

SetMemoryMax(3000)
stacked_rgb24 = ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24").Loop(100)
stacked_fakeyuv = CombinePlanes(stacked_rgb24,"YUV","RGB","YV24")
fakeyuv16 = ConvertFromStacked(stacked_fakeyuv)
rgbp_16=CombinePlanes(fakeyuv16,"RGB","YUV","RGBP16")#.Histogram("levels",bits=11)
#here we have 16 bit planar RGB
rgbp_16.ConvertToRGB64()
#just to have a big input for virtualdub
Spline64Resize(6640,8062)

[yup]

pinterf! :thanks:
Work under avs+ 64 bit.
Problem loading 16 bit image solved.
How now organize conversion for KNLMeans plugin? ConvertToStacked?
yup.

[pinterf]

pinterf! :thanks:
Work under avs+ 64 bit.
Problem loading 16 bit image solved.
How now organize conversion for KNLMeans plugin? ConvertToStacked?
yup.
Probably yes, but you have to consider which format you are using.

Once you have the 16 bit/channel RGB clip, you can convert it to YUV444P16 with ConvertToYUV444(), then use ConvertToStacked, and you can feed it into KNLMeansCL (in YUV mode only Y channel is denoised by default).

Or you can leave the RGB clip in a fake_yuv format, convert to stacked, and request processing all Y, U and V planes. Then back to non-stacked, and back to RGB with CombinePlanes.

Remember that when using CombinePlanes we avoid the real RGB->YUV->RGB conversions (only format is changed), still we can feed the clip to the filter.

(I don't know if there is any difference in processing, depending on plane origin (Y or U or G, anything))

[yup]

Hi pinterf!

I am add code
ConvertToYUV444()
ConvertToStacked()
KNLMeansCL(device_type="GPU",h=6, lsb_inout=true)
ConvertFromStacked()
ConvertToRGB64()
to Your first script and now all work.
:thanks:
yup.

[pinterf]

dev news: ImageReader and ImageWriter got RGB48, RGB64 and Y16 support through devIL.
Strange, saving greyscale (8 or 16 bit) TIFF is corrupted, while PNG is O.K.

[Reel.Deel]

dev news: ImageReader and ImageWriter got RGB48, RGB64 and Y16 support through devIL.
Strange, saving greyscale (8 or 16 bit) TIFF is corrupted, while PNG is O.K.

Awesome.

Don't know if you have any interest in fixing this but a while back I reported an issue with ImageWriter and Y8 colorspace: https://github.com/AviSynth/AviSynthPlus/issues/58

Feature request:
Is it possible to add a parameter to ImageWriter to be able to specify DPI? And also add the ability to save B/W 1-bit images?

I don't know the ins and outs of DevIL so if it's something complicated, please ignore me. :)

[pinterf]

I recognized the vertical flipping at greyscale, and corrected it already, I flip always. Or is raw format an exception?

[Reel.Deel]

I recognized the vertical flipping at greyscale, and corrected it already, I flip always. Or is raw format an exception?l

IIRC, raw format did not need flipping. I'll test again when you release the update.

[yup]

Hi all!
Thanks for support!
I am trying filtering grey scale image 6639x4032 using
KNLMeansCL(device_type="GPU",h=2, lsb_inout=true,a=32,s=4)
and image was ready after 30 seconds with my GTX 960, using Ximagic filter, CPU based with (a=16,s=2) need 20-30 minutes.
yup.

[pinterf]

More dev news:
- avs scripts with unicode filenames can be opened though the VfW interface (VirtualDub, MPC-HC)
- SubTitle: new parameter bool "utf8" to allow rendering an UTF8 encoded text. Something like this:
Title="Cherry blossom "+CHR($E6)+CHR($A1)+CHR($9C)+CHR($E3)+CHR($81)+CHR($AE)+CHR($E8)+CHR($8A)+CHR($B1)
SubTitle(Title,utf8=true)
I don't know whether this was a huge demand or not, but someone probably can use it.

[StainlessS]

- avs scripts with unicode filenames can be opened though the VfW interface (VirtualDub, MPC-HC)


In Docs, maybe should point out failure caveat of ScriptName(), ScriptFile() and ScriptDir() if UniCode used in script names in such cases.
(Also other functions using filenames, builtin or plugin [EDIT: where filenames generated from eg ScripName()]).

[pinterf]

In Docs, maybe should point out failure caveat of ScriptName(), ScriptFile() and ScriptDir() if UniCode used in script names in such cases.
(Also other functions using filenames, builtin or plugin [EDIT: where filenames generated from eg ScripName()]).
Yes, this fix only helps opening such scripts.
The plugin directories, reading them from registry, adding them through LoadPlugin and SCRIPTxxx macro expansion is not effected yet.
Now there are ScriptNameUtf8(), ScriptFileUtf8() and ScriptDirUtf8() functions.
All functions working with file names and path would be nice to have an utf8 version, maybe we'll need functions converting to and from utf8 as well. ImageSource, etc. have to be extended too. Nice plans anyway, but sticking with the idea of "keep it compatible with everything existed so far" makes it harder.

[jmac698]

Thanks for adding support to read 16bit images. I use this also for processing of raw stills in avisynth, for filtering and to make time lapse.

filed under: finally in 2017

[blaze077]

I have a few questions regarding Stacked16, its interleaved counterpart and "Native" bit depth.
First off, how is a Stacked format converted to and from "native" bit depth and likewise for interleaved formats? I also do not understand what native bitdepth. Is it when both the MSB and the LSb are at the same place in memory?
Secondly, let's say you have a piece of code like this:
ConvertToStacked()
StackVertical(dither_get_msb().mt_lut("x 20 +"), dither_get_lsb().mt_lut("x 0.8 ^")).ConvertFromStacked()
Is there a way to perform this in "native" bit depth rather than utilizing the Stack16 format?
Sorry if I don't make much sense.

Thank you.

[real.finder]

I have a few questions regarding Stacked16, its interleaved counterpart and "Native" bit depth.
First off, how is a Stacked format converted to and from "native" bit depth and likewise for interleaved formats? I also do not understand what native bitdepth. Is it when both the MSB and the LSb are at the same place in memory?
Secondly, let's say you have a piece of code like this:
ConvertToStacked()
StackVertical(dither_get_msb().mt_lut("x 20 +"), dither_get_lsb().mt_lut("x 0.8 ^")).ConvertFromStacked()
Is there a way to perform this in "native" bit depth rather than utilizing the Stack16 format?
Sorry if I don't make much sense.

Thank you.

Stacked16 hack and interleaved16 hack both 8bit (will be yv12 or yv24 or y8 or so) but some plugins can read them with some Parameters (like lsb), Stacked16 is slow and interleaved is fast like native one

native in memory will be like interleaved, but it's not use any hack, so no extra parameters will needed to tell the filter what is the bitdepth

[raffriff42]

With pinterf's masktools v2.2.x (http://avisynth.nl/index.php/MaskTools2), stacking is not needed. The following statements are equivalent (or very close):## 8-bit gamma 0.8, TV range:
mt_lut("x 16 - 219 / 1 0.8 / ^ 219 * 16 +")
## 16-bit gamma 0.8, TV range:
ConvertBits(16) ## (if needed)
mt_lut(x 16 @B - 219 @B / 1 0.8 / ^ 219 @B * 16 @B +")
ConvertBits(8) ## (if needed)

You might have other reasons for using stack16, but masktools ain't one of them.

[blaze077]

I am aware of what you both said but I guess I'm looking for a description of the method to convert from stack16 to native 16 bits and vice versa and the same thing for stack16 and interleaved. As in when converting from stack16 to native 16 bits, is it the average of the MSB and LSB then bitshifted [((MSB+LSB)/2) >> 8]. It's probably not that easy so I would just like to know. Again, sorry if I do not make much sense.

Thank you.

[raffriff42]

when converting from stack16 to native 16 bits, is it the average of the MSB and LSB then bitshifted [((MSB+LSB)/2) >> 8]. They are added together, like this: [MSB<<8 + LSB]

[blaze077]

They are added together, like this: [MSB<<8 + LSB]
That's what I was looking for. Thank you.

[real.finder]

so this will do same thing

mt_lut("x 256 / Floor 20 + 0 255 clip 8 << x 256 % 0.8 ^ +")

it only work on 16 bit native

and this

mt_lut("i16 clamp_f_i16 x 256 scalef / Floor 20 + 0 255 clip 256 scalef * x 256 scalef % 0.8 ^ +")

will work on all

[blaze077]

mt_lut("i16 clamp_f_i16 x 256 scalef / Floor 20 + 0 255 clip 256 scalef * x 256 scalef % 0.8 ^ +")
Thanks, this is quite useful too. Now I understand the usage of the scaling operators better.

[vcmohan]

i am on r2420_MT 64 bit version. I have problem if I convertto YUY2()
my script is

imagesource(....)
#converttoYV24()
#converttoYUY2()
a = stackhorizontal(last, last)
b = stackhorizontal(last, last)
stackvertical(a,b)
# reduceby2 does take back last to image with YUY2
reduceby2()
return(last)

It appears reduceby2() call is the problem. If I convertto YV24 it works OK. If I remove reduceby2 it works ok for YUY2 also

[LigH]

The planar equivalent of YUY2 is YV16. How does it look if you try this (and in addition, convert to YUY2 as last step before the return)?

[pinterf]

What's the problem exactly? YUY2 looks identical to the other formats for me.

[LigH]

Might be related to the image he loaded?

[pinterf]

Wow, thanks for quick reply. Looking fwd to fix. Unfortch I've just discovered that TDecimate does not work with MT enabled, whether using tritical's original TIVTC.dll or groucho2004's build. Works fine in r1858_pfmod, quits with "internal error during prebuffering!" in r2085, r2161, r2172.
and
I get error like this https://forum.doom9.org/showpost.php?p=1779374&postcount=2372

with TDecimate and MT, is this bug didn't fixed yet?
There are two different things.

The right-side error window in the first quote (from August, 2016) is showing very big numbers. That problem was fixed, it had the same reason as the garbage text error messages.

The second problem comes from TIVTC, now with proper numbers:
TDecimate: internal error during pre-buffering (n1=19,n2=20,pos=0)
This error occurs in MT, when the two filters (TFM and TDecimate) are set to MT_MULTI and MT_SERIALIZED, respectively. I have copied these lines from the file containing MT modes for popular filters.
FFMS2("sample.m2v")
SetFilterMTMode("TFM", MT_MULTI_INSTANCE) #2 is faster. 1 crashes randomly.
SetFilterMTMode("TDecimate", MT_SERIALIZED) #1 gave error, 2 was slower than 3

TFM()
TDecimate()
Prefetch(8)
The internal error came in seconds. (I was using Prefetch(8))

When I have set the filter TDecimate to MT_MULTI_INSTANCE, the script has run without error.
SetFilterMTMode("TFM", MT_MULTI_INSTANCE)
SetFilterMTMode("TDecimate", MT_MULTI_INSTANCE)
I think this must be an internal bug of TIVTC, it is receiving the frames in some special order, that is not handled or checked properly and is different than other versions of Avisynth.

Anyway, in the last couple of weeks I was working on TIVTC x64 port (just because x64-less basic filters are annoying me). Hey, it's crazy, quite a lot of work. Hundreds of lines of magically optimized inline asm (really, really professional), but sometimes without any C equivalent. I am moving all asm stuff to simd intrinsics, write functions in SSE2 where only MMX or ISSE is implemented, replace non-vectorized inline asm with C code.
TFM and TDecimate is working already in YV12. There are still two longer asm-only sections in YUY2 that have to be reverse engineered and moved to C.

And found a bug (buffer overwrite) that occured with AVS+, since the code allocated a buffer assuming 16 byte alignment (Avs+ alignes frames and rows to 32 bytes)

[vcmohan]

What's the problem exactly? YUY2 looks identical to the other formats for me.
I get proper stacked images with YUY2 also if I comment out reduceby2() call. With reduceby2() call it looks all the stackhorizontal and stackvertical calls are bypassed and only converttoYUY2() result is output without even reducing image.. With YV24 it works OK.

[Myrsloik]

Find a slightly older tivtc version if tou want c code for everything. That's what I did. Obviously the c code doesn't match the asm because real men don't test things.

[Reel.Deel]

Find a slightly older tivtc version if tou want c code for everything. That's what I did. Obviously the c code doesn't match the asm because real men don't test things.

You mentioned this a long time ago and IIRC that version is no longer publicly available. At least not from here: https://web.archive.org/web/20081017060943/http://bengal.missouri.edu/~kes25c/old_stuff/

Maybe this?
https://www.dropbox.com/s/35pzwufzw7w8d0g/tivtcv09110.zip?dl=1

[Myrsloik]

Why is isyuv() true for y16? Why? Whyyyyyyyyyyyyyy? Makes no sneeze!

[pinterf]

Haha. Y8 heritage. Compatibility :)

[StainlessS]

Makes no sneeze!

Perchance typo, "Makes no senze!" (or sense).

[LigH]

Surely on purpose; or blame the autocorrection. Bless you!

Looks like "IsYUV" mainly means "is not RGB".

[Myrsloik]

Can we have "isreallyyuv"?