Avisynth+

[pinterf]

Using "averageluma", 128 is converted to 0.501961 (128/255).
Using "yplanemax"/"-min", 128 is converted to 32896 (is this a bug? should be a float number, not a 16bit int)
.
Yes, it was fixed recently, perhaps after v2397. MinMax-like conditional functions (Min, Max, MinMaxDifference and Median) were done at the very beginning and could not decide that the return value should be the old integer or can be float (always the compatibility in mind). Then recently it was changed to float.

Conditional runtime functions have 10-16 bit/float support for YUV, PlanarRGB and 16 bit packed RGB formats.

Since RGB is also available as a planar colorspace, the plane statistics functions logically were expanded.

New functions
• AverageR, AverageG AverageB like AverageLuma
• RDifference, GDifference, BDifference like LumaDifference(clip1, clip2)
• RDifferenceFromPrevious, GDifferenceFromPrevious, BDifferenceFromPrevious
• RDifferenceToNext, GDifferenceToNext, BDifferenceToNext
• RPlaneMin, GPlaneMin BPlaneMin like YPlaneMin(clip [, float threshold = 0, int offset = 0])
• RPlaneMax, GPlaneMax BPlaneMax like YPlaneMax(clip [, float threshold = 0, int offset = 0])
• RPlaneMinMaxDifference, GPlaneMinMaxDifference BPlaneMinMaxDifference like YPlaneMinMaxDifference(clip [, float threshold = 0, int offset = 0])
• RPlaneMedian, GPlaneMedian, BPlaneMedian like YPlaneMedian(clip [, int offset = 0])

For float colorspaces the Min, Max, MinMaxDifference and Median functions populate pixel counts for the internal statistics at a 16 bit resolution internally.

[Khanattila]

Packed RGB
8 bits: RGB24, RGB32 (BGR and BGRA internally)
16 bits: RGB48, RGB64

Check: IsRGB ; note: IsRGB now true for planar RGB(A) color spaces.
Check2: IsRGB24, IsRGB32, IsRGB48, IsRGB64


I'm working on adding new formats to my program and I need a clarification.
Packed RGB64 is BGRA internally?

[pinterf]

Packed RGB
8 bits: RGB24, RGB32 (BGR and BGRA internally)
16 bits: RGB48, RGB64

Check: IsRGB ; note: IsRGB now true for planar RGB(A) color spaces.
Check2: IsRGB24, IsRGB32, IsRGB48, IsRGB64


I'm working on adding new formats to my program and I need a clarification.
Packed RGB64 is BGRA internally?
Yes, same as RGB32 and the same upside down order.

[Khanattila]

Yes, same as RGB32 and the same upside down order.

Perfect, I will not have problems.

[poodle]

The original blending formula is something like that, where an ideal mask is 0..1.0:
new_value = orig*(1-mask) + overlay*mask

This is equivalent to (only one multiplication, faster):
new_value = orig+(overlay-orig)*mask

As mask is coming from a clip, its value is 0..255

The approximation in overlay core:
new_value = ((orig * 256 + 128)+(overlay-orig)*mask) / 256

When orig=255, overlay=0, mask=255 (overlay is fully visible), we would expect 0 (=overlay)

Unfortunately the approximation above results in:

new_value = ((orig * 256 + 128)+(overlay-orig)*mask) / 256:
(255*256+128) + (0-255)*255) / 256 = 383/256 =
(65408 - 65025) / 256 =
383/256 = 1
which is obviously incorrect

For orig=0, overlay=255, mask=255 the result is 254 instead of 255.

Hi.
I encountered similar problem.
Chroma is offset signed value, then these asymmetric conversion brings to color shift.

In order to cope with this problem, I wrote the following codes.

u = _mm_sub_epi16(u, offsetUV);
sign = _mm_cmpgt_epi16(zero, u);
u = _mm_sub_epi16(_mm_xor_si128(u, sign), sign); // abs(u)

process U

u = _mm_sub_epi16(_mm_xor_si128(u, sign), sign); // if (sign) neg(u)
u = _mm_add_epi16(u, offsetUV);

It is complex than madd. :)

[pinterf]

I decided to make a release, I hope this version is much better than the previous one, it is quite a few months since v2294 was released. Sure, it has a wider feature set than the ROM routines of a ZX81, which I started programming on.

Avisynth Plus v2420 (https://github.com/pinterf/AviSynthPlus/releases/)

Report bugs, regressions, wish-list as always.

!!! There is a long readme.txt in the packet which contains detailed informations on the new and changed functions, fixes and hints. Formatting is not that nice, but at least there is some doc (sort of).

Changelog since last dev release (v2397):

- CombinePlanes:
When there is only one input clip, zero-cost BitBlt-less subframes are used, which is much faster.

e.g.: casting YUV to RGB, shuffle RGBA to ABGR, U to Y, etc..
Target planes that are not specified, preserve their content.

Examples:
CombinePlanes(clipRGBP, planes="RGB",source_planes="BGR") # swap R and B
CombinePlanes(clipYUV, planes="GBRA",source_planes="YUVA",pixel_type="RGBAP8") # cast YUVA to planar RGBA
CombinePlanes(clipYUV, planes="Y",source_planes="U",pixel_type="Y8") # extract U

- fix: SubframePlanarA (available in IScriptEnvironment2)
- faster: Difference-type conditional functions: Simd for 10-16 bits
- Fix: MinMax-type conditional functions (min, max, median): return float value for float clips
- ConvertToPlanarRGB(A):
PlanarRGB <-> PlanarRGBA is now allowed
- ConvertToPlanarRGB(A):
YUY2 source is now allowed (through automatic ConvertToRGB proxy)
- faster: RemoveAlphaPlane (subframe instead of BitBlt copy)
- Overlay: "Blend" native greyscale mode: process y plane only w/o conversion
- Overlay: automatic use444=false for "blend"/"luma"/"chroma"
for inputs: 420/422/444 and any RGB, lossless Planar RGB intermediate for PackedRGB
Overlay/mask auto-follows input clip format.
For compatibility: when greymask=true (default) and mask is RGB then mask source is the B channel
- faster: RGB48->RGB64 SSSE3 (1,6x), RGB64->RGB48 SSSE3 (1.5x speed)
- faster: RGB24,RGB48->PlanarRGB: uses RGB32/64 intermediate clip
- Histogram "levels": allow RGB24/32/48/64 input.
Display R, G and B channels instead of Y, U and V
Reminder 1: "levels" for Planar RGB was working already
Reminder 2: Histogram "levels" and "Classic" allows bits=xx parameter, xx=8..12
If "bits" is specified then Histogram is drawn with 9..12 bits precision. Get a wide monitor though :)

[ajp_anton]

Small feature request: In histogram, add some parameter to show the histogram itself in a higher bitdepth. Even a histogram of an 8-bit video can benefit from being able to display the data more accurately. Probably has to convert the whole clip into a higher bitdepth in the process, unless you add another bool parameter (default false) to only return the histogram part and make it faster. Only returning the histogram would also help with those ultra-wide histograms that you can crop and stretch more easily, without having to crop away the video part first.

[real.finder]

Native 16-bit will provide great performance improvement over LSB, especially for a heavy script like SMDegrain. However, it's kind of pointless until enough plugins support 16-bit to actually use it.

How about producing a list of filters supporting LSB that don't support the new native formats? Since they already work with high-bit-depth, I'm supposing it wouldn't be too hard to update those.

lsb in SMDegrain is not full 16 bit, it's done in MDegrain and some prefilters only, even MDegrain is not full cuz there are no lsb_in in MDegrain, dogway use some dither tools functions to do the lsb_in support in crooked ways

but anyway, since pinterf promise to work on masktools2 you can try port Dfttest, it's work in float internally too so I think it's not hard to you

[mp3dom]

Regarding histogram levels, I don't know if there are already plugins that do that, but it could be helpful to have the min and max value of each channel written down. Sometimes there are videos with some levels off that needs to be "shifted" (especially the old ones) and having the min/max value can be useful to shift with more precision.

[LigH]

One may use WriteFile (http://avisynth.nl/index.php/WriteFile) to log a CSV with strings concatenated from Color plane median, min, max, range (http://avisynth.nl/index.php/Internal_functions#Color_plane_median.2C_min.2C_max.2C_range) function results.

[mp3dom]

Nice, thanks!

[dandyclubs]

http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

#rgtools
SetFilterMTMode ( "RemoveGrain", MT_NICE_FILTER)
SetFilterMTMode ( «réparation», MT_N ICE_FILTER)
SetFilterMTMode ( «verticalcleaner», MT_NICE_FILTER)
SetFilterMTMode ( "clense", MT_NICE_FILTER)
#medianblur
SetFilterMTMode ( «medianblur», MT_MULTI_INSTANCE)
SetFilterMTMode ( «medianblurtemporal», MT_MULTI_INSTANCE)
#masktools
SetFilterMTMode ( «mt_invert», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_binarize», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_inflate», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_deflate», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_inpand», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_expand», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lut», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutxy», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutxyz», MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_luts", MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutf», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutsx», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutspa», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_merge», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_logic», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_convolution», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_mappedblur», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_makediff», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_average», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_adddiff», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_clamp», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_motion», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_edge», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_hysteresis», MT_MULTI_INSTANCE)
SetFilterMTMode ( "sangnom2", MT_SERIALIZED) #can exécuté avec 2 mais vous devez spécifier threads = 1 alors, sinon trop de threads se crée sans aucun bénéfice
SetFilterMTMode ( «moyenne», MT_NICE_FILTER)
SetFilterMTMode ( «TMaskCleaner», MT_MULTI_INSTANCE)
SetFilterMTMode ( "mater", MT_NICE_FILTER)
SetFilterMTMode ( "Deblock", MT_NICE_FILTER)
SetFilterMTMode ( «msharpen», MT_MULTI_INSTANCE)
SetFilterMTMode ( «TColorMask», MT_NICE_FILTER)
SetFilterMTMode ( «Vinverse», MT_MULTI_INSTANCE)
SetFilterMTMode ( «Vinverse2», MT_MULTI_INSTANCE)



wrong..

replace

#rgtools
SetFilterMTMode ( "RemoveGrain", MT_NICE_FILTER)
SetFilterMTMode ( "repair", MT_NICE_FILTER)
SetFilterMTMode ( "verticalcleaner", MT_NICE_FILTER)
SetFilterMTMode ( "clense", MT_NICE_FILTER)
#medianblur
SetFilterMTMode ( "medianblur", MT_MULTI_INSTANCE)
SetFilterMTMode ( "medianblurtemporal", MT_MULTI_INSTANCE)
#masktools
SetFilterMTMode ( "mt_invert", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_binarize", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_inflate", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_deflate", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_inpand", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_expand", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lut", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutxy", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutxyz", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_luts", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutf", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutsx", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutspa", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_merge", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_logic", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_convolution", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_mappedblur", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_makediff", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_average", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_adddiff", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_clamp", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_motion", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_edge", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_hysteresis", MT_MULTI_INSTANCE)
SetFilterMTMode ( "sangnom2", MT_SERIALIZED) #can exécuté avec 2 mais vous devez spécifier threads = 1 alors, sinon trop de threads se crée sans aucun bénéfice
SetFilterMTMode ( "moyenne", MT_NICE_FILTER)
SetFilterMTMode ( "TMaskCleaner", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mater", MT_NICE_FILTER)
SetFilterMTMode ( "Deblock", MT_NICE_FILTER)
SetFilterMTMode ( "msharpen", MT_MULTI_INSTANCE)
SetFilterMTMode ( "TColorMask", MT_NICE_FILTER)
SetFilterMTMode ( "Vinverse", MT_MULTI_INSTANCE)
SetFilterMTMode ( "Vinverse2", MT_MULTI_INSTANCE)


Listes #Another

La mise à jour de # tp7: sangnom2 enlevés et des lignes vinverse car ils ne peuvent pas fonctionner avec le mode 1 correctement (versions mises à jour peuvent mais ceux qui vont se faire enregistrer de toute façon), a également retiré les filtres de base

replace

#Listes #Another

#La mise à jour de # tp7: sangnom2 enlevés et des lignes vinverse car ils ne peuvent pas fonctionner avec le mode 1 correctement (versions mises à jour peuvent mais ceux qui vont se faire enregistrer de toute façon), a également retiré les filtres de base

[Groucho2004]

Some fucking moron messing around in that list with google translate again?

[LigH]

I don't believe angular quotes (&laquo; / &raquo;) are supported as string delimiters; better disable typographic autotext features or just never edit such documents with external advanced word processors.

Oh, does Google Translate also translate quote styles?

[Groucho2004]

Oh, does Google Translate also translate quote styles?https://s6.postimg.org/gxfxb98jl/Image1.png

This happened before, Tp7 (when he was still active with Avisynth+) got very upset at the time and used very colourful language to discourage the idiot(s) from using google translate on that page.

[real.finder]

this link ok http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/rev.495

Public Pad Version 496 Saved Jan 28, 2017 is full with shit and French words

[Groucho2004]

Public Pad Version 496 Saved Jan 28, 2017 is full with shit and French words
Apparently these (purple) changes were done by someone with the moniker "A.SONY".

[LigH]

So let's hope that it is easy to revoke a change.

[real.finder]

Apparently these (purple) changes were done by someone with the moniker "A.SONY".

I am A.SONY :D

I don't even know something in French, my edit is http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/rev.495 and did it in 2016

[Groucho2004]

I am A.SONY :D

I don't even know something in French, my edit is http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/rev.495 and did it in 2016
Ok. Go to rev 496 and you can see that the stupid changes have a slightly different shade of purple than the ones made by you. Sorry, my mistake, I just saw "purple". :D

[real.finder]

Ok. Go to rev 496 and you can see that the stupid changes have a slightly different shade of purple than the ones made by you. Sorry, my mistake, I just saw "purple". :D

even me, I start think there someone used my name or I have Alzheimer's :p until I see my laptop monitor from another angle

[Reel.Deel]

Reverted the changes :)

[MysteryX]

I was using Dither_resize16nr to convert from YV12 to YV24 with either Spline36 or Bicubic.

ConvertToYUV444 and ConvertToYUV420, however, don't allow specifying the algorithm for upscaling or downscaling the chroma. Please consider adding this in the future :)

As for the 'no ringing' variant, it can be nice, but perhaps it won't change much at all in the case of chroma resampling.

[Reel.Deel]

I was using Dither_resize16nr to convert from YV12 to YV24 with either Spline36 or Bicubic.

ConvertToYUV444 and ConvertToYUV420, however, don't allow specifying the algorithm for upscaling or downscaling the chroma. Please consider adding this in the future :)

As for the 'no ringing' variant, it can be nice, but perhaps it won't change much at all in the case of chroma resampling.

Umm, both functions have the chromaresample parameter: https://github.com/pinterf/AviSynthPlus/blob/5e45d740b8d78f2c19d220c0247238bba26c1499/avs_core/convert/convert.cpp#L73

[MysteryX]

oh, sorry.

Question. What happens with ConvertToDoubleWidth on 32-bit clips?

[DJATOM]

Question. What happens with ConvertToDoubleWidth on 32-bit clips?

ConvertBits(32)
ConvertToDoubleWidth()
This will complain about "clip must be 16 bit" or something.

ConvertBits(32)
ConvertBits(16,false)
ConvertToDoubleWidth()
This will expose 32-bit clip as 8.

[pinterf]

ConvertBits(32)
ConvertToDoubleWidth()
This will complain about "clip must be 16 bit" or something.

ConvertBits(32)
ConvertBits(16,false)
ConvertToDoubleWidth()
This will expose 32-bit clip as 8.
That false is not necessary, it has meaning only when converting 10-16 bit video to 10-16 bit video, and we want to change only the video bitdepth (clip property) but not the data itself.
To tell the truth, a well behaving avisynth+ would warn you that that parameter is irrelevant :)

[pinterf]

Hi.
I encountered similar problem.
Chroma is offset signed value, then these asymmetric conversion brings to color shift.

Thanks, poodle, finally I did not want to touch that part, if it was good for a decade, it will stay as-is for another couple of weeks or months.

[DJATOM]

That false is not necessary, it has meaning only when converting 10-16 bit video to 10-16 bit video, and we want to change only the video bitdepth (clip property) but not the data itself.
To tell the truth, a well behaving avisynth+ would warn you that that parameter is irrelevant :)

So... ok. It seems I've got the wrong idea about this parameter. I thought if it's set to true, clip will be actually converted or just changed bit depth information (but not the actual data) if false.

[MysteryX]

oh... but on 32-bit, I could call ConvertToDoubleWidth twice; if it would convert 32-bit to 16-bit. Is there a simple script that would achieve that?


ConvertBits(32)
ConvertBits(16)
ConvertToDoubleWidth()

This would first discard 16-bit of the 32-bit, which is not what I'm looking for.

[DJATOM]

oh... but on 32-bit, I could call ConvertToDoubleWidth twice; if it would convert 32-bit to 16-bit. Is there a simple script that would achieve that?


ConvertBits(32)
ConvertBits(16)
ConvertToDoubleWidth()

This would first discard 16-bit of the 32-bit, which is not what I'm looking for.
Lol, I just realized that I misread what pinterf said, so I was right about truerange. Set it 'false' and ConvertToDoubleWidth will work for 32 bit input.

[pinterf]

32 bit is float. 16 bit is integer. ConvertToDoublewidth is a hack to fake both the format and frame dimension.

[MysteryX]

How about integrating these conversion functions into the core DLL? In that way, plugin developers could write 16-bit code using the native format, and still support Stack16 by calling these standard conversion functions. Otherwise, I might as well copy and integrate that code into my DLL to avoid dependencies.

Basically, I keep the standard v2.6 conversion code, and on Avisynth+, I'm branching into another code that does it using the new functions -- and supports extra formats. The Stack16 conversion functions would be useful for any developer doing that. I also want to keep using DoubleWidth to preserve compatibility with v2.6

[DJATOM]

32 bit is float. 16 bit is integer. ConvertToDoublewidth is a hack to fake both the format and frame dimension.

Indeed. But if we need to process our clip with filter which can process exposed 32-bit data, but does not support avs+ colorspaces, that will help.

[MysteryX]

I would need a "ConvertToQuadripleWidth" if I want to allow someone to use AviSynthShader while allowing overflow values; as all other formats are INT. Again, I keep the double-width hack to maintain compatibility with AVS 2.6, and since I'm doing a data transfer to the GPU, it doesn't matter how the metadata is set.

[real.finder]

How about integrating these conversion functions into the core DLL? In that way, plugin developers could write 16-bit code using the native format, and still support Stack16 by calling these standard conversion functions. Otherwise, I might as well copy and integrate that code into my DLL to avoid dependencies.

Basically, I keep the standard v2.6 conversion code, and on Avisynth+, I'm branching into another code that does it using the new functions -- and supports extra formats. The Stack16 conversion functions would be useful for any developer doing that. I also want to keep using DoubleWidth to preserve compatibility with v2.6

no more hack please, and you can keep the lsb (Stack16) supports just like what pinterf did in mvtools

[real.finder]

Reverted the changes :)

:thanks:


#rgtools # starting from v0.94, the plugin self registers the MT mode
SetFilterMTMode("removegrain", MT_NICE_FILTER)
SetFilterMTMode("repair", MT_NICE_FILTER)
SetFilterMTMode("verticalcleaner", MT_NICE_FILTER)
SetFilterMTMode("clense", MT_NICE_FILTER)


should


#rgtools # starting from v0.94, the plugin self registers the MT mode
SetFilterMTMode("removegrain", MT_NICE_FILTER)
SetFilterMTMode("repair", MT_NICE_FILTER)
SetFilterMTMode("verticalcleaner", MT_NICE_FILTER)
#SetFilterMTMode("clense", MT_NICE_FILTER)


it's better, cuz when reduceflicker is true, MULTI_INSTANCE MT mode is reported in RGtools

[MysteryX]

Is there a way to pass a format as a string and get the properties of that format? For example, a parameter "FormatOut" might be set to "YUVAP16", and in my code, I want to know a few things. Does that format have an alpha plane? What is BitsPerComponent?

Of course I can get it done with a bunch of IF, but the code then gets very clumsy especially with all the new formats.

[pinterf]

Is there a way to pass a format as a string and get the properties of that format? For example, a parameter "FormatOut" might be set to "YUVAP16", and in my code, I want to know a few things. Does that format have an alpha plane? What is BitsPerComponent?

Of course I can get it done with a bunch of IF, but the code then gets very clumsy especially with all the new formats.
Declare a temporary VideoInfo variable, fill its pixel_type, now you can request all its properties.

[edcrfv94]

I update r2420 from r1858, have a problem with MP_Pipeline.
Very high CPU usage and very slow.

r2420 1.6 fps 40-50% CPU usage
r1858 26 fps 16-20% CPU usage

MP_Pipeline("""

SetMemoryMax(500)

input = "K:\test.m2ts"
LWLibavVideoSource(input, threads=1)

src = last

### export clip:src
### prefetch: 92,88
### ###

SetMemoryMax(2000)

src
kf_awarpFCB_test(depth=8, thresh=96, blur=3, lsb_in=true, lsb_out=true, YV12_out=false, cplace="MPEG2")
dither_out()

function kf_awarpFCB_test(clip src, int "depth", int "thresh", int "blur", bool "lsb_in", bool "lsb_out", bool "isYV24", bool "YV12_out", string "cplace")
{

depth = Default(depth, 6)
thresh = Default(thresh, 96)
blur = Default(blur, 3)

lsb_in = Default(lsb_in, false)
lsb_out = Default(lsb_out, true)
isYV24 = Default(isYV24, false)
YV12_out = Default(YV12_out, false)

w = width(src)
h = (lsb_in == false) ? height(src) : height(src)/2

src16 = (lsb_in == false) ? src.Dither_convert_8_to_16() : src

Y416 = src16.Dither_resize16(w, h, csp="YV24", kernel="bicubic", a1=0.6, a2=0.4, cplace=cplace)
YV24 = (isYV24 == false) ? Y416.DitherPost(mode=7) : (lsb_in == false) ? src : src.DitherPost(mode=7)
emask = YV24.ConvertToY8().aSobel(thresh, 1).aBlur(blur, 1, 1)
uv_fcb = YToUV(YV24.UToY8().awarp(emask, depth, 1), YV24.VToY8().awarp(emask, depth, 1), YV24)
Dither_limit_dif16(Y416, uv_fcb.Dither_convert_8_to_16(), thr=1.0, elast=2, y=2, u=3, v=3)

YV12_out ? last.Dither_resize16(w, h, csp="YV12", kernel="bicubic", a1=0, a2=0.5) : last

lsb_out ? last : last.DitherPost(mode=7)

return last
}

""")

[pinterf]

I update r2420 from r1858, have a problem with MP_Pipeline.
Very high CPU usage and very slow.

r2420 1.6 fps 40-50% CPU usage
r1858 26 fps 16-20% CPU usage
I think I found the reason. r2043 is ok, r2068 is slow.

Beginning from r2068 Eval-like and runtime functions are detected internally in order to apply an appropriate cache and MT behaviour for them.

But MP_Pipeline is an external Eval-like filter and the core is not able to detect it. In my test, when I have set a hardcoded line to apply this rule on MP_Pipeline, the speed returned to the original. I don't know yet how to detect such external filters automatically, from the core point of view it is a filter that takes a string parameter and returns a clip. Like a source filter.
Perhaps we have to introduce a registration command for this case, e.g. RegisterScriptFunction(string filter_name) (?)

[real.finder]

since there are no more than 8 bit in 411, then should convertbits show error Message, but it's not

if I use convertbits(16) in yv411 source it will work but with unsupported colour format

[pinterf]

since there are no more than 8 bit in 411, then should convertbits show error Message, but it's not

if I use convertbits(16) in yv411 source it will work but with unsupported colour format
True. I expect to have increasing number of reports for 10+ bit stuff after reaching a critical mass in the number of non-8bit users and supporting scripts.

Currently under progress:
Integrate GScriptClip and co.
Better handling MP_Pipeline-like filters (speedwise)
Playing with masktools.

[tormento]

True. I expect to have increasing number of reports for 10+ bit stuff after reaching a critical mass in the number of non-8bit users and supporting scripts.
When every plugin we need will be 16 bit and we will work internally at 16 bit to output in 8 bit, I think you will be flooded :D

[MysteryX]

Pinterf, you're already flooded porting every plugin to 16-bit :) Now get to work

[Reel.Deel]

Pinterf, you're already flooded porting every plugin to 16-bit :) Now get to work

Since you're a programmer also, help him out :)

[MysteryX]

Since you're a programmer also, help him out :)
I got a lot of priorities to focus on already (but I guess that also applies to most of us). For now I must get 16-bit to work with AviSynthShader (somehow I'm having a hard time to get that simple task done), and release the next version of Natural Grounding Player as the YouTube downloader doesn't work anymore with the currently released version. And even more importantly... working on my business instead of putting too much time on Open Source projects, and publishing some more books.

There's the Floyd-Steinberg Dithering I could work on, but then, it would only be a CPU version. Someone else would have to write it in assembly. I can write a C# 432hz Music Player and playlist manager in a few hours, but C++ is much harder for me.

So yeah... first must empty the pipeline of work to do.

[MysteryX]

Declare a temporary VideoInfo variable, fill its pixel_type, now you can request all its properties.
Except that pixel_type is an int, not a string. In C# I could easily convert a string to its enumeration value but that won't work in C++. It seems the only way is to create a map with all the possible values and get the int matching the string from the map. A standard function to accomplish that would be nice. Is it possible to include such a function in the header file so that it also works with older versions of Avisynth? Actually I'll need to call such a function from the script so I'll need to create a custom filter for it anyway, unless I'm missing something.

So there are 2 tasks:
1. Get current format as a string so the script can use it.
2. Get VideoInfo from string to know the properties of specified format.

Formats were quite easy to handle in Avisynth 2.6 because there were only a few pixel formats. With the new version, however, the amount of formats increased exponentially.

The best might be to create a map and use it for both tasks.

[MysteryX]

I believe code like this should do the job to convert back and forth between INT and STRING format types. It might be useful to have something similar in the header.


#pragma once
#include <map>
#include <string>
#include "avisynth.h"

class PixelFormatParser {
typedef std::map<std::string, int> my_map;
my_map enumMap;
public:
PixelFormatParser();

int GetPixelFormatAsInt(std::string format) {
my_map::const_iterator iValue = enumMap.find(format);
if (iValue == enumMap.end())
return 0;
return iValue->second;
}

std::string GetPixelFormatAsString(int pixel_type) {
int key = 0;
std::string Result = std::string("");
for (auto &i : enumMap) {
if (i.second == pixel_type) {
Result = i.first;
// If format ends with P8, continue searching to return the other name variant.
if (i.first.length() < 3 || i.first.substr(i.first.length() - 2, 2) != std::string("P8"))
break;
}
}
return Result;
}

VideoInfo GetVideoInfo(int pixel_type) {
VideoInfo Result;
Result.pixel_type = pixel_type;
return Result;
}

VideoInfo GetVideoInfo(std::string format) {
VideoInfo Result;
Result.pixel_type = GetPixelFormatAsInt(format);
return Result;
}
};

PixelFormatParser::PixelFormatParser() {
enumMap["RGB24"] = VideoInfo::CS_BGR24;
enumMap["RGB32"] = VideoInfo::CS_BGR32;
enumMap["YUY2"] = VideoInfo::CS_YUY2;
enumMap["RAW32"] = VideoInfo::CS_RAW32;
enumMap["YV24"] = VideoInfo::CS_YV24;
enumMap["YV16"] = VideoInfo::CS_YV16;
enumMap["YV12"] = VideoInfo::CS_YV12;
enumMap["I420"] = VideoInfo::CS_I420;
enumMap["IYUV"] = VideoInfo::CS_IYUV;
enumMap["YUV9"] = VideoInfo::CS_YUV9;
enumMap["YV411"] = VideoInfo::CS_YV411;
enumMap["Y8"] = VideoInfo::CS_Y8;
enumMap["YUV444P8"] = VideoInfo::CS_YV24;
enumMap["YUV422P8"] = VideoInfo::CS_YV16;
enumMap["YUV420P8"] = VideoInfo::CS_YV12;
enumMap["YUV444P10"] = VideoInfo::CS_YUV444P10;
enumMap["YUV422P10"] = VideoInfo::CS_YUV422P10;
enumMap["YUV420P10"] = VideoInfo::CS_YUV420P10;
enumMap["Y10"] = VideoInfo::CS_Y10;
enumMap["YUV444P12"] = VideoInfo::CS_YUV444P12;
enumMap["YUV422P12"] = VideoInfo::CS_YUV422P12;
enumMap["YUV420P12"] = VideoInfo::CS_YUV420P12;
enumMap["Y12"] = VideoInfo::CS_Y12;
enumMap["YUV444P14"] = VideoInfo::CS_YUV444P14;
enumMap["YUV422P14"] = VideoInfo::CS_YUV422P14;
enumMap["YUV420P14"] = VideoInfo::CS_YUV420P14;
enumMap["Y14"] = VideoInfo::CS_Y14;
enumMap["YUV444P16"] = VideoInfo::CS_YUV444P16;
enumMap["YUV422P16"] = VideoInfo::CS_YUV422P16;
enumMap["YUV420P16"] = VideoInfo::CS_YUV420P16;
enumMap["Y16"] = VideoInfo::CS_Y16;
enumMap["YUV444PS"] = VideoInfo::CS_YUV444PS;
enumMap["YUV422PS"] = VideoInfo::CS_YUV422PS;
enumMap["YUV420PS"] = VideoInfo::CS_YUV420PS;
enumMap["Y32"] = VideoInfo::CS_Y32;
enumMap["RGB48"] = VideoInfo::CS_BGR48;
enumMap["RGB64"] = VideoInfo::CS_BGR64;
enumMap["RGBP"] = VideoInfo::CS_RGBP;
enumMap["RGBP8"] = VideoInfo::CS_RGBP;
enumMap["RGBP10"] = VideoInfo::CS_RGBP10;
enumMap["RGBP12"] = VideoInfo::CS_RGBP12;
enumMap["RGBP14"] = VideoInfo::CS_RGBP14;
enumMap["RGBP16"] = VideoInfo::CS_RGBP16;
enumMap["RGBPS"] = VideoInfo::CS_RGBPS;
enumMap["RGBAP"] = VideoInfo::CS_RGBAP;
enumMap["RGBAP8"] = VideoInfo::CS_RGBAP;
enumMap["RGBAP10"] = VideoInfo::CS_RGBAP10;
enumMap["RGBAP12"] = VideoInfo::CS_RGBAP12;
enumMap["RGBAP14"] = VideoInfo::CS_RGBAP14;
enumMap["RGBAP16"] = VideoInfo::CS_RGBAP16;
enumMap["RGBAPS"] = VideoInfo::CS_RGBAPS;
enumMap["YUVA444"] = VideoInfo::CS_YUVA444;
enumMap["YUVA422"] = VideoInfo::CS_YUVA422;
enumMap["YUVA420"] = VideoInfo::CS_YUVA420;
enumMap["YUVA444P8"] = VideoInfo::CS_YUVA444;
enumMap["YUVA422P8"] = VideoInfo::CS_YUVA422;
enumMap["YUVA420P8"] = VideoInfo::CS_YUVA420;
enumMap["YUVA444P10"] = VideoInfo::CS_YUVA444P10;
enumMap["YUVA422P10"] = VideoInfo::CS_YUVA422P10;
enumMap["YUVA420P10"] = VideoInfo::CS_YUVA420P10;
enumMap["YUVA444P12"] = VideoInfo::CS_YUVA444P12;
enumMap["YUVA422P12"] = VideoInfo::CS_YUVA422P12;
enumMap["YUVA420P12"] = VideoInfo::CS_YUVA420P12;
enumMap["YUVA444P14"] = VideoInfo::CS_YUVA444P14;
enumMap["YUVA422P14"] = VideoInfo::CS_YUVA422P14;
enumMap["YUVA420P14"] = VideoInfo::CS_YUVA420P14;
enumMap["YUVA444P16"] = VideoInfo::CS_YUVA444P16;
enumMap["YUVA422P16"] = VideoInfo::CS_YUVA422P16;
enumMap["YUVA420P16"] = VideoInfo::CS_YUVA420P16;
enumMap["YUVA444PS"] = VideoInfo::CS_YUVA444PS;
enumMap["YUVA422PS"] = VideoInfo::CS_YUVA422PS;
enumMap["YUVA420PS"] = VideoInfo::CS_YUVA420PS;
}


Then I could write a GetFormat function like this.


AVSValue __cdecl Create_GetFormat(AVSValue args, void* user_data, IScriptEnvironment* env) {
VideoInfo vi = args[0].AsClip()->GetVideoInfo();
static PixelFormatParser pfp;
std::string Result = pfp.GetPixelFormatAsString(vi.pixel_type);
return AVSValue(env->SaveString(Result.c_str(), Result.length() + 1));
}

[JoeyMonco]

Why do you need a whole class simply to write a utility function? Just write a simple function that just uses a switch statement to return the value based on the integer.