Avisynth+

[bxyhxyh]

can you confirm with version() ?
https://i.imgur.com/E8M6DXP.png

I can reproduce it. Adding a simple "ConvertToYV12()" (or YV16/YV24) after the source filter (I used "ImageSource()") fixes it.

Same for me too.
But I need to convert it to YV24/YV12 after the resizing, so it's really problematic for me.

Well, I can live with converting the source to the YV24 for now I guess.
BTW I'm on Windows 8.1

[poisondeathray]

I'm on Win8.1 too . Haswell (only AVX2) ; maybe some instruction issue ? what CPU ?

What about ConvertTo16Bit only ? or ConvertTo16Bit and the resize only (RGB48) ?

[poisondeathray]

Or use avsresize (zimg/z.lib) as a workaround

But I'm curious why I can't reproduce bug


ConvertToPlanarRGB()
z_ConvertFormat(512,384,resample_filter="spline16",pixel_type="RGBP16")

[bxyhxyh]

I'm on Win8.1 too . Haswell (only AVX2) ; maybe some instruction issue ? what CPU ?

What about ConvertTo16Bit only ? or ConvertTo16Bit and the resize only (RGB48) ?

ConvertTo16Bit and the resize only. Even if I insert some filters before resize, it still is the same.
CPU is Ivy Bridge

[pinterf]

I'll check it soon

EDIT: cannot reproduce. Tested with AVX2, AVX-only, SSE4.1 only builds. (Win10)

Function Diff(clip src1, clip src2)
{
return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}
source=ImageSource("test.png").Info().trim(0, 100) # 256x224 RGB24
c8=source.Spline16Resize(512,384)
c16=source.ConvertTo16Bit().Spline16Resize(512,384).ConvertTo8Bit()
StackVertical(c8,c16,Diff(c8,c16))

[Groucho2004]

But that's a problem...

I used ImageSource() too , and it returns RGB24 on the source PNG (as expected)

And I can't reproduce it in RGB24, or YV12, or YV16, or YV24
I tested again with this script:
imagesource("3ZWGafM.png", pixel_type = "RGBXX") #XX to be substituted with 24/32/48/64
ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()

The resulting image is corrupted for RGB32 and RGB64 but looks fine for RGB24 and RGB48, tested with r2664 and pinterf's test build r2671 on XP32 (no AVX optimization).

[tormento]

pinterf's test build r2671
Can we play with it too? :cool:

[Groucho2004]

Can we play with it too? :cool:I suppose pinterf won't object:
http://www.mediafire.com/file/kmq3po2cw2b3inw/AvisynthPlus_r2671tst.7z

[pinterf]

I tested again with this script:
imagesource("3ZWGafM.png", pixel_type = "RGBXX") #XX to be substituted with 24/32/48/64
ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()

The resulting image is corrupted for RGB32 and RGB64 but looks fine for RGB24 and RGB48, tested with r2664 and pinterf's test build r2671 on XP32 (no AVX optimization).
Ahh, RGB32. Reproduced.
EDIT: RGB64 Turnleft / Turnright issue (which is used in RGB64 resize)
EDIT2: Bug found and fixed. I'll prepare a release in the near future.

[pinterf]

x86 test (mediafire link) (not a release)
(see also readme_history.txt for other interesting changes)
http://www.mediafire.com/file/een9bfx66sigzlr/AvisynthPlus_r2671_test2.7z

[Groucho2004]

x86 test (mediafire link) (not a release)
(see also readme_history.txt for other interesting changes)
http://www.mediafire.com/file/een9bfx66sigzlr/AvisynthPlus_r2671_test2.7zWorks now for me with all RGB colour spaces. :)

[pinterf]

Thanks for testing. This rgb64 bug must have been there since the beginnings.

[bxyhxyh]

I tested again with this script:
imagesource("3ZWGafM.png", pixel_type = "RGBXX") #XX to be substituted with 24/32/48/64
ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()

The resulting image is corrupted for RGB32 and RGB64 but looks fine for RGB24 and RGB48, tested with r2664 and pinterf's test build r2671 on XP32 (no AVX optimization).
Double checked this. Result is same.
Test build 2 fixes it.

Sorry guys, I should have provided a sample so problem would be found faster.

[tormento]

I suppose pinterf won't object:
http://www.mediafire.com/file/kmq3po2cw2b3inw/AvisynthPlus_r2671tst.7z
Need x64 :p

[Stereodude]

Can I put in a feature request for Avisynth+ to add ConditionalReader capability to the internal RGBAdjust filter (like ColorYUV has)?

[pinterf]

Need x64 :p
I am planning to put together a proper release in the near future (but probably "near" <> 1-2 days)

[pinterf]

Unofficial test build (x86/x64 installer w/o VC2017 redistributables)
https://drive.google.com/open?id=1sjNKaukrz51RiCtHd88nwIRavOU0PqmF

I hope some of you will find some new exiting features in this build. (And report bugs if they are found)


- AviSource to support more formats with 10+ bit depth.
http://avisynth.nl/index.php/AviSource

When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

Full support list (* = already supported):
'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery
YV24 YV24 *YV24
YV16 YV16 *YV16
YV12 YV12 *YV12
YV411 YV411 *Y41B
YUY2 YUY2 *YUY2
RGBP10 RGBP10 G3[0][10] r210 R10k
r210 RGBP10 r210
R10k RGBP10 R10k
RGBP RGBP10 G3[0][10] r210 R10k
RGBP12 G3[0][12]
RGBP14 G3[0][14]
RGBP16 G3[0][16]
RGBAP10 G4[0][10]
RGBAP12 G4[0][12]
RGBAP14 G4[0][14]
RGBAP16 G4[0][16]
RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32
RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24
RGB48 RGB48 BGR[48] b48r
RGB64 RGB64 *BRA[64] b64a
Y8 Y8 Y800 Y8[32][32] GREY
YUV422P10 YUV422P10 v210 P210
v210 YUV422P10 v210
P210 YUV422P10 P210
YUV422P16 YUV422P16 P216
P216 YUV422P16 P216
YUV420P10 YUV420P10 P010
P010 YUV422P10 P010
YUV420P16 YUV420P16 P016
P016 YUV422P16 P016
YUV444P10 YUV444P10 v410
v410 YUV444P10 v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
- VirtualDub2 support with extended colorspaces
Allow RGB24, RGB48, RGB64 besides RGB32
AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
- Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
- Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
- Supports when filter changes frame count of the output clip
- Extra filter parameter added at the end of filter's (unnamed) parameter list
Imported Virtualdub filters are getting and extra named parameter to the end:
String [rangehint]
This parameter can tell the filter about a YUV-type clip colorspace info
Allowed values:
"rec601": limited range + 601
"rec709": limited range + 709
"PC.601": full range + 601
"PC.709": full range + 709
"" : not defined (same as not given)
Parameter will be ignored when clip is non-YUV
How it works: the hint will _not_ change the internal VirtualDub colorspace
constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
Filter can either use this information or not, depending on supported API version and its implementation.
E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a
template clip, from which the undefined format elements are inherited.
"[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

string family: YUV, YUVA, RGB, RGBA, Y
int bits: 8, 10, 12, 14, 16, 32
string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

Example#1: define YUV 444 P 10

family = "YUV"
bits = 10
chroma = 444
compat = false
oldformat = false
s = BuildPixelType(family, bits, chroma, compat, oldformat)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

Example#2: Change only the bit depth of the format to 16

newbits = 16
c = last
s = BuildPixelType(bits=newbits, sample_clip=c)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.

[MysteryX]

What is the format code for 32-bit YUV420?

Also, is VapourSynth 32-bit based around .5 or around 0?

[shekh]

- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)


Amazing.

[MysteryX]

- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
Next step will be porting this updated VirtualDub interface to VapourSynth, which should be easy -- EXCEPT that VapourSynth doesn't have any stacked format...

[MysteryX]

Would it be a good idea to add an option for VirtualDubFilter to pass YUV data in RGB format without converting it? This would be useful for filters that support only RGB format but if YUV was sent in that format it would work as well.

[jpsdr]

Nice !!!

[poisondeathray]

What is the format code for 32-bit YUV420?


YUV420PS

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

[MysteryX]

YUV420PS

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

It's not in the list above

[poisondeathray]

It's not in the list above

It's in the list under pixel type. Or were you asking for something else like fourcc code ? It doesn't have a fourcc

Or did you mean the *new* list posted by pinterf above ?


YUV420 YUV420PS 32


Maybe it was dropped ? Vapoursynth doesn't have support for this either, the 32bit YUV float formats are not subsampled

[lansing]

Good and long-waited fix for the virtualdub filter, now I can call multiple instances of the same vd filter without the program crashing.

[pinterf]

Would it be a good idea to add an option for VirtualDubFilter to pass YUV data in RGB format without converting it? This would be useful for filters that support only RGB format but if YUV was sent in that format it would work as well.
See CombinePlanes example and adapt to RGBA
http://avisynth.nl/index.php/CombinePlanes

[StainlessS]

I'm trying to access Pinterf upload,
Getting blocked by SonicWall, for reason 'radicalism and extremism', (something you aint tellin' us Pinterf)

Second time this has happened, currently on Cloud network wifi in pub, last time got an apology, but still now reblocked.

EDIT: Problem seems to be with MediaFire, rather than Pinterf upload.

[pinterf]

I'll try to arrange something instead of mediafire.
EDIT: Done. Link in original post edited.

[StainlessS]

Thanx P, but you should be more careful about the types of terrorist you associate yourself with. :)

[MysteryX]

For 32-bit, VapourSynth, UV is in the -.5 to .5 range. Everything else is 0 to 1.

Is it now the same with Avisynth?

[pinterf]

Yes.

I also had to update some external filters, most of their sub-filters are o.k., will work as-is, but some filters need to be updated for the new 32bit float UV ranges.
For example:
masktools2: mt_diff, predefined constants in lut expressions (finished, not released yet)
fft3dfilter: chroma center

[pinterf]

New test build
Avisynth+ r2696
https://drive.google.com/open?id=1yUiuTTTY3yGGf-7iNkbDpSdEbR6yugUm

Compared to last test build (r2693):
- ConvertBits from/to 32 bits assume full source/destination range only for RGB. Additional fix was in limited range conversion when source is 32 bits
- Avisource: Greyscale 10, 12, 14, 16 bits for Y1[0][10] .. Y1[0][16] (not tested)

Full list since last official release (r2664)
- AviSource to support more formats with 10+ bit depth.
http://avisynth.nl/index.php/AviSource

When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

Full support list (* = already supported):
'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery
YV24 YV24 *YV24
YV16 YV16 *YV16
YV12 YV12 *YV12
YV411 YV411 *Y41B
YUY2 YUY2 *YUY2
RGBP10 RGBP10 G3[0][10] r210 R10k
r210 RGBP10 r210
R10k RGBP10 R10k
RGBP RGBP10 G3[0][10] r210 R10k
RGBP12 G3[0][12]
RGBP14 G3[0][14]
RGBP16 G3[0][16]
RGBAP10 G4[0][10]
RGBAP12 G4[0][12]
RGBAP14 G4[0][14]
RGBAP16 G4[0][16]
RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32
RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24
RGB48 RGB48 BGR[48] b48r
RGB64 RGB64 *BRA[64] b64a
Y8 Y8 Y800 Y8[32][32] GREY
Y Y8 Y800 Y8[32][32] GREY
Y10 Y1[0][10]
Y12 Y1[0][12]
Y14 Y1[0][14]
Y16 Y1[0][16]
YUV422P10 YUV422P10 v210 P210
v210 YUV422P10 v210
P210 YUV422P10 P210
YUV422P16 YUV422P16 P216
P216 YUV422P16 P216
YUV420P10 YUV420P10 P010
P010 YUV422P10 P010
YUV420P16 YUV420P16 P016
P016 YUV422P16 P016
YUV444P10 YUV444P10 v410
v410 YUV444P10 v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5
Note: now ConvertBits does not assume full range for YUV 32 bit float.
Default values of fulls and fulld are now true only for RGB colorspaces.
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
- VirtualDub2 support with extended colorspaces
Allow RGB24, RGB48, RGB64 besides RGB32
AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
- Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
- Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
- Supports when filter changes frame count of the output clip
- Extra filter parameter added at the end of filter's (unnamed) parameter list
Imported Virtualdub filters are getting and extra named parameter to the end:
String [rangehint]
This parameter can tell the filter about a YUV-type clip colorspace info
Allowed values:
"rec601": limited range + 601
"rec709": limited range + 709
"PC.601": full range + 601
"PC.709": full range + 709
"" : not defined (same as not given)
Parameter will be ignored when clip is non-YUV
How it works: the hint will _not_ change the internal VirtualDub colorspace
constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
Filter can either use this information or not, depending on supported API version and its implementation.
E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a
template clip, from which the undefined format elements are inherited.
"[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

string family: YUV, YUVA, RGB, RGBA, Y
int bits: 8, 10, 12, 14, 16, 32
string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

Example#1: define YUV 444 P 10

family = "YUV"
bits = 10
chroma = 444
compat = false
oldformat = false
s = BuildPixelType(family, bits, chroma, compat, oldformat)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

Example#2: Change only the bit depth of the format to 16

newbits = 16
c = last
s = BuildPixelType(bits=newbits, sample_clip=c)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.
- Planned: include current header files and def/exp file in installer

[pinterf]

Another test build, r2700, installer w/o Visual C++ Redistributables
https://drive.google.com/open?id=1LPlP8My94_aRNQHmyqNo3Bi6--2NtdzF

Change since r2696: RGBAdjust fix and enhancements

Full change since last official release (r2664):

- Fix: RGBAdjust memory leak when used in ScriptClip
- Enhanced: RGBAdjust new parameter: conditional (like in ColorYUV)
The global variables "rgbadjust_xxx" with xxx = r, g, b, a, rb, gb, bb, ab, rg, gg, bg, ag are read each frame, and applied.
It is possible to modify these variables using FrameEvaluate or ConditionalReader.
- Enhanced: RGBAdjust: support 32 bit float ('analyze' not supported, 'dither' silently ignored)
- Enhanced: AviSource to support more formats with 10+ bit depth.
http://avisynth.nl/index.php/AviSource

When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

Full support list (* = already supported):
'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery
YV24 YV24 *YV24
YV16 YV16 *YV16
YV12 YV12 *YV12
YV411 YV411 *Y41B
YUY2 YUY2 *YUY2
RGBP10 RGBP10 G3[0][10] r210 R10k
r210 RGBP10 r210
R10k RGBP10 R10k
RGBP RGBP10 G3[0][10] r210 R10k
RGBP12 G3[0][12]
RGBP14 G3[0][14]
RGBP16 G3[0][16]
RGBAP10 G4[0][10]
RGBAP12 G4[0][12]
RGBAP14 G4[0][14]
RGBAP16 G4[0][16]
RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32
RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24
RGB48 RGB48 BGR[48] b48r
RGB64 RGB64 *BRA[64] b64a
Y8 Y8 Y800 Y8[32][32] GREY
Y Y8 Y800 Y8[32][32] GREY
Y10 Y1[0][10]
Y12 Y1[0][12]
Y14 Y1[0][14]
Y16 Y1[0][16]
YUV422P10 YUV422P10 v210 P210
v210 YUV422P10 v210
P210 YUV422P10 P210
YUV422P16 YUV422P16 P216
P216 YUV422P16 P216
YUV420P10 YUV420P10 P010
P010 YUV422P10 P010
YUV420P16 YUV420P16 P016
P016 YUV422P16 P016
YUV444P10 YUV444P10 v410
v410 YUV444P10 v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5
Note: now ConvertBits does not assume full range for YUV 32 bit float.
Default values of fulls and fulld are now true only for RGB colorspaces.
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
- VirtualDub2 support with extended colorspaces
Allow RGB24, RGB48, RGB64 besides RGB32
AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
- Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
- Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
- Supports when filter changes frame count of the output clip
- Extra filter parameter added at the end of filter's (unnamed) parameter list
Imported Virtualdub filters are getting and extra named parameter to the end:
String [rangehint]
This parameter can tell the filter about a YUV-type clip colorspace info
Allowed values:
"rec601": limited range + 601
"rec709": limited range + 709
"PC.601": full range + 601
"PC.709": full range + 709
"" : not defined (same as not given)
Parameter will be ignored when clip is non-YUV
How it works: the hint will _not_ change the internal VirtualDub colorspace
constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
Filter can either use this information or not, depending on supported API version and its implementation.
E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a
template clip, from which the undefined format elements are inherited.
"[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

string family: YUV, YUVA, RGB, RGBA, Y
int bits: 8, 10, 12, 14, 16, 32
string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

Example#1: define YUV 444 P 10

family = "YUV"
bits = 10
chroma = 444
compat = false
oldformat = false
s = BuildPixelType(family, bits, chroma, compat, oldformat)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

Example#2: Change only the bit depth of the format to 16

newbits = 16
c = last
s = BuildPixelType(bits=newbits, sample_clip=c)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.
- Planned: include current header files and def/exp file in installer

[`Orum]

As I understand it, when using GetFrame(), pitch can vary on a per-frame basis for all planes. Is it possible to get the maximum possible pitch for each plane?

The reason I ask is I'd like to avoid painful reallocations, so if I can simply allocate the maximum pitch * vi.height (right shifted by GetPlaneHeightSubsampling()) for each plane, then I don't have to worry about it exceeding my initial allocation later on.

[StainlessS]

As I understand it, when using GetFrame(), pitch can vary on a per-frame basis for all planes. Is it possible to get the maximum possible pitch for each plane?


I would say NO, unless you can find the maximum possible size of a frame.
Pitch can change because of interleaving of cropped clips, I forget what the new rules are on avs+ concerning crop and Align arg, but on v2.6 standard, Align is False by default, and so is much more likely to do a Soft Crop, ie Subframe() and SubframePlanar(), so pitch could be pretty much any size.
(I take it that you would like it to work on avs standard too).
Output frame pitch is guaranteed identical. [EDIT: When calling NewVideoFrame, ie not simply passing though a frame like in ClipClop or ReplaceFramesSimple.]

IanB Torture Test

....
A=SelectEvery(3, 0).AddBorders(0,0, 16,0).Crop(0,0, -16,0)
B=SelectEvery(3, 1).AddBorders(0,0, 32,0).Crop(0,0, -32,0)
C=SelectEvery(3, 2).AddBorders(0,0, 64,0).Crop(0,0, -64,0)
Interleave(A, B, C)
....


https://forum.doom9.org/showthread.php?p=1613005&highlight=torture#post1613005
https://forum.doom9.org/showthread.php?p=1603626&highlight=torture#post1603626
https://forum.doom9.org/showthread.php?p=1628159&highlight=torture#post1628159

[pinterf]

Alignment:
Plane pointers and pitches are 64 bytes aligned in recent Avisynth+ versions (but it was 32 bytes before - avx and avx2-safe), this is the minimum.
It can be larger, when NewVideoFrame is called with a larger align value, e.g. 128
But there is no guarantee that a pitch is simply an up-aligned value of the plane width, framebuffers are mostly re-used internally to avoid reallocation.
Plus, as StainlessS mentioned, a Crop (in avs+ always producing an aligned output, the alignment rule can never be broken), or SeparateRows can simply change the pitch value internally w/o making a frame copy.

[StainlessS]

Made edit in my previous post, I should have caught that.

Presumably, MakeWritable can change Pitch from original input too.
EDIT: On frame like this for instance:
SeparateRows can simply change the pitch value internally w/o making a frame copy.

[`Orum]

Okay, so I'm guessing the best bet here is to get the per plane pitches for the first frame, and for every later frame check if they're increased. If so, recreate my buffer with a larger size. Unless there is some better option I'm not thinking of...

[shekh]

I guess you don't have to repeat any pitch for your own buffer, just allocate whatever is sufficient?

[`Orum]

I guess you don't have to repeat any pitch for your own buffer, just allocate whatever is sufficient?
You bring up a good point. As I'm using OpenCL, that probably makes sense in some circumstances; namely, when copying a frame to a discrete GPU for processing. The trick is probably going to be figuring out the best way to perform the copy efficiently, as you either have to map the buffer and memcpy() row-by-row into the mapped buffer and then unmap, or queue each row via separate calls to clEnqueueWriteBuffer(). Neither is pretty, but may still be faster than what I'm doing now (which is copying the memory including the pitch bytes), and would at the very least avoid any reallocation.

However, if processing is done on a CPU or integrated GPU (or really anything with unified memory between host and device), this incurs an additional copy operation, which I'd like to avoid. Fortunately, this can be avoided in these circumstances (and already is in my current code), as when you create a buffer with CL_MEM_USE_HOST_PTR no copying is done anyway—or so I assume. It certainly is faster than an explicit copying of the buffer.

[`Orum]

On another note, I've noticed what I think is some color shift toward Cb-/Cr- with the ColorYUV(levels="TV->PC") / ColorYUV(levels="PC->TV"). The results look different from what I see with the conversion filters within MPC-HC, and while that means that problem could be in either MPC-HC or AviSynth+, I suspect it's in AviSynth+. Why? Consider the following script:
function s(clip c) {
return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV")
}

ColorBars(pixel_type="YV12")
Interleave(last.s(), last.s().s().s().s().s().s().s().s().s().s().s().s().s().s().s().s()) # Initial clip calls s() once because ColorBars() has some strange levels
ColorYUV(analyze=true)
Yes, it's an extreme example, and while this only proves that the functions are not reciprocal, it shows a clear trend toward green. If someone knows of another way to perform the conversion (I know "levels" is not accurate for chroma planes) to compare it against instead, let me know.

Edit: Animated for those too lazy or unable to run the script on their devices
https://my.mixtape.moe/gnfyur.png

[StainlessS]

Is it (in the main) perhaps down to a part of the 'pluge' (think thats what its called) being @ luma value 7 [EDIT: and 242] (ie non TV range).


A=ColorBars(pixel_type="YV12").BicubicResize(480,360)
B=A.ColorYUV(levels="TV->PC")
C=B.ColorYUV(levels="PC->TV")
A=A.ColorYUV(analyze=true)
B=B.ColorYUV(analyze=true)
C=C.ColorYUV(analyze=true)
StackVertical(A,B,C)


First image minimum luma is 7.
https://s20.postimg.cc/rt0cxbbx9/cyuv.jpg (https://postimg.cc/image/uzuwgxwd5/)



EDIT: Did not notice this line,
because ColorBars() has some strange levels
that would be the pluge 7 [EDIT: and 242] thing I think.
But even with pluge fixed with eg limiter, does exhibit strange behaviour as pin pointed by Orum.

ie like this

function s(clip c) {
return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV")
}

# Initial clip calls s() once because ColorBars() has some strange levels

ColorBars(pixel_type="YV12").Limiter
Interleave(last, last.s().s().s().s().s().s().s().s().s().s().s().s().s().s().s().s())
ColorYUV(analyze=true)

Still flickers a helluva lot.

EDIT:
Limiter dont work as required, mod to Levels [EDIT: This is rubbish, dont know why I thought Limiter did not work, it does]

function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") }

ColorBars(pixel_type="YV12").Bicubicresize(480,360)
Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels
A=Last
B=last.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s
StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true))

https://s20.postimg.cc/qs0480uvx/cyuv.jpg (https://postimages.org/)



EDIT: Only 1 iteration

function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") }

ColorBars(pixel_type="YV12").Bicubicresize(480,360)
Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels
A=Last
B=last.s #.s.s.s.s.s.s.s.s.s.s.s.s.s.s
StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true))

https://s20.postimg.cc/5wdtwp6dp/cyuv.jpg (https://postimages.org/)

[Motenai Yoda]

maybe it's caused by coloryuv levels work as levels(16,1,235,0,255)~levels(0,1,255,16,235)
without maintain chroma planes centered on 128, like a
mergechorma(levels(16,1,235,0,255),levels(16,1,240,0,255)) will do

[Stereodude]

What if you run the test script in 16-bits dithering back to 8-bits at the end instead of running it multiple times in 8-bits? That should point to either rounding errors or perhaps a rounding bias vs. an error in the calculations.

[poisondeathray]

Alternatively, you can use smoothlevels and set the chroma processing to zero

By default, lato set it at 100 (from 0-200) or intermediate

e.g using stainlesss's (enough sssss's :D ? )test


ColorBars(pixel_type="YV12").Bicubicresize(480,360)
Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels
A=Last
B=last.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s
StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true))

#function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") }

function s(clip c) { return c.smoothlevels(preset="tv2pc", chroma=0).smoothlevels(preset="pc2tv",chroma=0) }


https://s33.postimg.cc/9bb07h99r/smoothlevels.png (https://postimages.org/)

[`Orum]

What if you run the test script in 16-bits dithering back to 8-bits at the end instead of running it multiple times in 8-bits? That should point to either rounding errors or perhaps a rounding bias vs. an error in the calculations.
The crux of the issue is I think it happens on a single instance of ColorYUV(levels="TV->PC"), at 8-bit and possibly other depths. I originally noticed it when comparing it to MPC-HC's conversion which I think is accurate.

When you add dithering, I think if anything that would only muddy the waters (as then you wouldn't be sure if the source of any shift was ColorYUV() or ConvertBits()). It would be interesting to know if it affects HBD clips, though I suspect if it does it may take more instances of conversion to get the same amount of error (in terms of relative distance).

Alternatively, you can use smoothlevels and set the chroma processing to zero
Sure you can do that, but aren't chroma planes supposed to be changed when doing TV->PC level conversion? If not one could simply do a MergeChroma() as well...

[StainlessS]

but aren't chroma planes supposed to be ...
Yes, avoid color shift.

[poisondeathray]

Sure you can do that, but aren't chroma planes supposed to be changed when doing TV->PC level conversion? If not one could simply do a MergeChroma() as well...

Maybe. I think that was the reason he chose intermediate as the default setting (chroma is processed intermediate strength). You can leave it default 100, or increase it to 200 , or 0 for YLevels like behaviour. Eitherway, you don't get contamination of greyscale patches with smoothlevels (you can disable dithering too as well) . ie. U=V . So it is a problem with coloryuv

[poisondeathray]

I took RGB test pattern (0-255), greyscale, R,G,B . ConvertToYV24(matrix="pc.709") , then PC->TV, PC->TV eight times , then back to TV. Dithering is disabled for all . The RGB screenshot used "PC" levels for the original, "REC" for the others (because they were scaled to TV)

"TV" levels means U,V should be limited 16-240, so chroma=100 looks correct at least for the max U,V value


Not only is there a green shift for coloryuv, there are more weird patterns

https://s33.postimg.cc/3ku0l75qj/smoothlevels_vs_coloryuv.png (https://postimg.cc/image/3ku0l75qj/)