Avisynth+

[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]

Originally Posted by 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.

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]

Originally Posted by pinterf

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]

Originally Posted by pinterf

- 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]

Originally Posted by StainlessS

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]

Originally Posted by 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.

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, 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]

Originally Posted by blaze077

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]

Originally Posted by raffriff42

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]

Originally Posted by real.finder

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.