Vapoursynth

[l33tmeatwad]

Question, does Kubuntu use /usr/lib64? That could be the root of a lot of this confusion.

[BabaG]

there is a /usr/lib64 directory. nothing much in it. two shared libraries that don't seem vapoursynth related.
file:///usr/lib64/ld-linux-x86-64.so.2
file:///usr/lib64/libDaVinciPanelAPI.so


thanks,
babag

[l33tmeatwad]

You really need to just start troubleshooting things like trying to manually load plugins and such. VapourSynth either isn't looking in the /usr/local/lib/vapoursynth directory or ffms2 for some reason can't find it's dependencies.

[Mystery Keeper]

For all the people concerned with antivirus alerts.
Just upload the binaries here:
https://www.virustotal.com
Take Kaspersky as the most reliable.
Don't trust Avast or Norton. They're notorious for false positives.

[ChaosKing]

Norton just bought Avast for 8 billion!

[lansing]

I want to invoke a few filters in order programmatically, I want to reuse the VSMap that was returned from the invoke and the VSNodeRef.


VSMap * pResultMap = nullptr;

pResultMap = m_cpVSAPI->invoke(firstPlugin, filterName, pArgumentMap);
m_cpVSAPI->freeNode(pProcessingNode);
m_cpVSAPI->clearMap(pArgumentMap);

pProcessingNode = m_cpVSAPI->propGetNode(pResultMap, "clip", 0, nullptr);
m_cpVSAPI->freeMap(pResultMap);
pResultMap = nullptr;

// second filter
VSPlugin * secondPlugin = m_cpVSAPI->getPluginById(
"com.vapoursynth.std", m_pCore);
m_cpVSAPI->propSetNode(pArgumentMap, "clip", pProcessingNode, paReplace);


Will the `freeMap(pResultMap)` also killed my `pProcessingNode` so it won't get passed to the second filter?

[Myrsloik]

I want to invoke a few filters in order programmatically, I want to reuse the VSMap that was returned from the invoke and the VSNodeRef.


VSMap * pResultMap = nullptr;

pResultMap = m_cpVSAPI->invoke(firstPlugin, filterName, pArgumentMap);
m_cpVSAPI->freeNode(pProcessingNode);
m_cpVSAPI->clearMap(pArgumentMap);

pProcessingNode = m_cpVSAPI->propGetNode(pResultMap, "clip", 0, nullptr);
m_cpVSAPI->freeMap(pResultMap);
pResultMap = nullptr;

// second filter
VSPlugin * secondPlugin = m_cpVSAPI->getPluginById(
"com.vapoursynth.std", m_pCore);
m_cpVSAPI->propSetNode(pArgumentMap, "clip", pProcessingNode, paReplace);


Will the `freeMap(pResultMap)` also killed my `pProcessingNode` so it won't get passed to the second filter?

No, propGetNode() increases the reference count.

[lansing]

No, propGetNode() increases the reference count.

Thanks. Also do I even need the `pResultMap = nullptr;` after freeing it?

[Myrsloik]

Thanks. Also do I even need the `pResultMap = nullptr;` after freeing it?

No. That's obviously pointless.

[Selur]

Does anyone have a working RemoveDirtMC script for Vapoursynth ?
The one from https://forum.doom9.org/showpost.php?p=1711199&postcount=2 is using a variable called 'quad' which isn't defined anywhere.

Cu Selur

[kedautinh12]

Here new RemoveDirtMC_SE.avsi
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/RemoveDirtMC_SE.avsi

[Selur]

@kedautinh12: Thanks, but you probably missed the 'for Vapoursynth' part,...

[kedautinh12]

@kedautinh12: Thanks, but you probably missed the 'for Vapoursynth' part,...

I think you need port to Vapoursynth and i give you new ver for port

[poisondeathray]

Does anyone have a working RemoveDirtMC script for Vapoursynth ?
The one from https://forum.doom9.org/showpost.php?p=1711199&postcount=2 is using a variable called 'quad' which isn't defined anywhere.

Cu Selur


Just replace "qpel" for "quad" . That version uses mv.compensate

There a couple other vapoursynth versions in this thread
https://forum.doom9.org/showthread.php?t=169771

[Selur]

@poisondeathray: thanks :)

[feisty2]

does the same frame/node/func always have the same VSFrameRef/VSNodeRef/VSFuncRef pointer?

[lansing]

I'm a little confuse with the color matrix conversion

I want to convert from rec601 to rec709, if I specified both the input and output matrix, the clip info and frame info will give me matrix of rec709.

clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P8, matrix_in_s="470bg", matrix_s="709")

clip = core.text.ClipInfo(clip, alignment=7)
clip = core.text.FrameProps(clip, alignment=9)


But if I only specified the input matrix, both info will give me a matrix of Rec601?

clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P8, matrix_in_s="470bg")

[Myrsloik]

does the same frame/node/func always have the same VSFrameRef/VSNodeRef/VSFuncRef pointer?

No, assume different pointers can point to the same thing.

[Myrsloik]

I'm a little confuse with the color matrix conversion

I want to convert from rec601 to rec709, if I specified both the input and output matrix, the clip info and frame info will give me matrix of rec709.

clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P8, matrix_in_s="470bg", matrix_s="709")

clip = core.text.ClipInfo(clip, alignment=7)
clip = core.text.FrameProps(clip, alignment=9)


But if I only specified the input matrix, both info will give me a matrix of Rec601?

clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P8, matrix_in_s="470bg")


If no output matrix is specified it's assumed to be the same as the input. And as you probably know 470bg and 601 is the same thing.

[Selur]

Okay, I got RemoveGrainMC running and thought it would be nice wo have a version which can use SVP instead of MVTools. :)
Problem is I have no idea what I'm doing.
So here is my go at it:
import vapoursynth as vs
# dependencies:
# RemoveGrain (http://www.vapoursynth.com/doc/plugins/rgvs.html)
# MVTools (https://github.com/dubhater/vapoursynth-mvtools) or SVP libraries when gpu=True is used
# RemoveDirt (https://github.com/pinterf/removedirtvs)
# ChangeFPS (https://github.com/Selur/VapoursynthScriptsInHybrid/blob/master/ChangeFPS.py)


def RemoveDirt(input, repmode=16, remgrainmode=17, _grey=False, limit=10):
core = vs.get_core()
cleansed = core.rgvs.Clense(input)
sbegin = core.rgvs.ForwardClense(input)
send = core.rgvs.BackwardClense(input)
scenechange = core.rdvs.SCSelect(input, sbegin, send, cleansed)
alt = core.rgvs.Repair(scenechange, input, mode=[repmode,repmode,1])
restore = core.rgvs.Repair(cleansed, input, mode=[repmode,repmode,1])
corrected = core.rdvs.RestoreMotionBlocks(cleansed, restore, neighbour=input, alternative=alt, gmthreshold=70, dist=1, dmode=2, noise=limit, noisy=12, grey=_grey)
return core.rgvs.RemoveGrain(corrected, mode=[remgrainmode,remgrainmode,1])

def RemoveDirtMC(input, limit=6, _grey = False, block_size=8, block_over = 4, gpu=False):
core = vs.get_core()
quad = core.rgvs.RemoveGrain(input, mode=[12,0,1]) # blur the luma for searching motion vectors orig avs: mode=12, modeU=-1
if gpu:
# no clue what to do with _grey here, I assume it can be ignored
block_over = 0 if block_over == 0 else 1 if block_over == 2 else 2 if block_over == 4 else 3
Super = core.svp1.Super(quad, "{gpu:1,pel:2}")
bvec = core.svp1.Analyse(Super['clip'], Super['data'], input, "{ gpu:1, block:{w:"+str(block_size)+", h:"+str(block_size)+",overlap:"+str(block_over)+"} }")
fvec = core.svp1.Analyse(Super['clip'], Super['data'], input, "{ gpu:1, block:{w:"+str(block_size)+", h:"+str(block_size)+",overlap:"+str(block_over)+",special:{delta: 1}} }")
backw = core.svp2.SmoothFps(quad,Super['clip'], Super['data'],bvec['clip'],bvec['data'],"{}") # here the frame rate&count is doubled
forw = core.svp2.SmoothFps(quad,Super['clip'], Super['data'],fvec['clip'],fvec['data'],"{}") # here the frame rate&count is doubled
# since backw and forw now have twice the frame count I drop half the frames
backw = ChangeFPS.ChangeFPS(backw,input.fps_num,input.fps_den)
forw = ChangeFPS.ChangeFPS(forw,input.fps_num,input.fps_den)
else:
#block size of MAnalyze, blksize 8 is much better for 720x576 noisy source than blksize=16
#block overlapping of MAnalyze 0! 2 or 4 is not good for my noisy b&w 8mm film source
i = core.mv.Super(quad, pel=2)
bvec = core.mv.Analyse(super=i,isb=True, blksize=block_size,overlap=block_over, delta=1, truemotion=True, chroma= not _grey)
fvec = core.mv.Analyse(super=i,isb=False, blksize=block_size,overlap=block_over, delta=1, truemotion=True, chroma= not _grey)
backw = core.mv.Flow(clip=quad,super=i,vectors=[bvec])
forw = core.mv.Flow(clip=quad,super=i,vectors=[fvec])

clp = core.std.Interleave([backw,quad,forw])
clp = RemoveDirt(clp, remgrainmode=2, limit=limit,_grey=_grey)
clp = core.std.SelectEvery(clp,3,1)
return clp
A few things that seem kind of 'ugly' and are probably wrond:
a. I'm not using the _grey-parameter in the gpu case.
b. block_over in SVP only allows 0 - none, 1 - 1/8 of block size in each direction, 2 - 1/4 of block size, 3 - 1/2 of block size and I have no clue how I should handle this properly
b. when calculating backw and forw I end up with clips that have twice the number of frames which causes problems in the 'clp = core.std.Interleave([backw,quad,forw])', so I simply drop frames
-> would be nice if someone who actually understands what the cpu part of the script does could help 'fixing' this. :)


Cu Selur

[Myrsloik]

Okay, I got RemoveGrainMC running and thought it would be nice wo have a version which can use SVP instead of MVTools. :)
Problem is I have no idea what I'm doing.
So here is my go at it:
...
A few things that seem kind of 'ugly' and are probably wrond:
a. I'm not using the _grey-parameter in the gpu case.
b. block_over in SVP only allows 0 - none, 1 - 1/8 of block size in each direction, 2 - 1/4 of block size, 3 - 1/2 of block size and I have no clue how I should handle this properly
b. when calculating backw and forw I end up with clips that have twice the number of frames which causes problems in the 'clp = core.std.Interleave([backw,quad,forw])', so I simply drop frames
-> would be nice if someone who actually understands what the cpu part of the script does could help 'fixing' this. :)


Cu Selur

I think the grey argument is a leftover from the time when Avisynth didn't support greyscale clips and you passed YV12 instead. The correct solution is probably to remove it since if a user only want to process the Y plane only the Y plane will be passed to the function.

Also:
vs.get_core() => vs.core or just put vs.core everywhere instead of storing it in a variable.

And is this really correctly transcribed? I have no idea what it is in the original script but processing only Y and U plane looks iffy.
mode=[repmode,repmode,1]

[TheSpectre]

Hello. I'm having issues installing vapoursynth in Debian 11. It worked fine in Debian 10, but the update to Python 3.9 from 3.7 has caused me nothing but trouble. No matter where I install Vapoursynth to and what I set PYTHONPATH to, it always produces the following error: Failed to initialize VapourSynth environmentI've even followed l33tmeatwad's installation guide to a tee to no avail. Any ideas?

[qyot27]

Hello. I'm having issues installing vapoursynth in Debian 11. It worked fine in Debian 10, but the update to Python 3.9 from 3.7 has caused me nothing but trouble. No matter where I install Vapoursynth to and what I set PYTHONPATH to, it always produces the following error: I've even followed l33tmeatwad's installation guide to a tee to no avail. Any ideas?
VapourSynth:
sudo apt-get install checkinstall && \

git clone git://github.com/vapoursynth/vapoursynth.git && \
cd vapoursynth && \
autoreconf -fiv && \
CPPFLAGS="-march=native" LDFLAGS="-Wl,-Bsymbolic" ./configure --with-pic && \
make -j$(nproc) && \

sudo checkinstall --pkgname=vapoursynth --pkgversion="$(grep Version pc/vapoursynth.pc | \
sed 's/ /"/g' | cut -f2 -d "\"")"R-r"$(git rev-list --count HEAD)-g"$(git rev-parse --short HEAD)"" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes \
--addso=yes --fstrans=no --default && \

sudo checkinstall --pkgname=vapoursynth-cython --pkgversion="$(grep Version pc/vapoursynth.pc | \
sed 's/ /"/g' | cut -f2 -d "\"")"R-r"$(git rev-list --count HEAD)-g"$(git rev-parse --short HEAD)"" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes \
--addso=yes --fstrans=no --default --requires=vapoursynth python3 ./setup.py install

[TheSpectre]

VapourSynth:
sudo apt-get install checkinstall && \

git clone git://github.com/vapoursynth/vapoursynth.git && \
cd vapoursynth && \
autoreconf -fiv && \
CPPFLAGS="-march=native" LDFLAGS="-Wl,-Bsymbolic" ./configure --with-pic && \
make -j$(nproc) && \

sudo checkinstall --pkgname=vapoursynth --pkgversion="$(grep Version pc/vapoursynth.pc | \
sed 's/ /"/g' | cut -f2 -d "\"")"R-r"$(git rev-list --count HEAD)-g"$(git rev-parse --short HEAD)"" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes \
--addso=yes --fstrans=no --default && \

sudo checkinstall --pkgname=vapoursynth-cython --pkgversion="$(grep Version pc/vapoursynth.pc | \
sed 's/ /"/g' | cut -f2 -d "\"")"R-r"$(git rev-list --count HEAD)-g"$(git rev-parse --short HEAD)"" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes \
--addso=yes --fstrans=no --default --requires=vapoursynth python3 ./setup.py install

Same issue :(

[TheSpectre]

I've purged all installation remnants of Vapoursynth and I'll try the script again

[TheSpectre]

Manually importing Vapoursynth in a Python instance and checking the version works, but VSPipe doesn't. What the heck?

[TheSpectre]

I ran vspipe in a verbose Valgrind check and noticed these entries in particular right before Vapoursynth fails to initlise through vspipe. The full output can be found here https://controlc.com/8a255b52
--2369746-- Reading syms from /usr/local/lib/python3.9/dist-packages/VapourSynth-55-py3.9-linux-x86_64.egg/vapoursynth.cpython-39-x86_64-linux-gnu.so
--2369746-- object doesn't have a symbol table
--2369746-- Reading syms from /usr/local/lib/libvapoursynth.so
--2369746-- object doesn't have a symbol table
--2369746-- Reading syms from /usr/lib/x86_64-linux-gnu/libzimg.so.2.0.0
--2369746-- object doesn't have a symbol table
--2369746-- REDIR: 0x49380a0 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4838d80 (operator new(unsigned long))
--2369746-- Reading syms from /usr/lib/python3.9/lib-dynload/_ctypes.cpython-39-x86_64-linux-gnu.so
--2369746-- object doesn't have a symbol table
--2369746-- Reading syms from /usr/local/lib/libffi.so.7
--2369746-- object doesn't have a symbol table
Failed to initialize VapourSynth environment

[qyot27]

Did something happen to /etc/ld.so.conf that removed /usr/local/lib? As either running sudo ldconfig after installing or checkinstall as illustrated above (the addso=yes parameter specifically) should have made sure that step was completed.

You could also try and force it (assuming that libvapoursynth[-script].so is in /usr/local/lib):
LD_LIBRARY_PATH=/usr/local/lib vspipe --version

The thing that jumps out from the log though is this:
by 0x4E5586F: _PyEval_EvalFrameDefault (in /usr/local/lib/libpython3.9.so.1.0)
==2369746== by 0x4E09612: _PyFunction_Vectorcall (in /usr/local/lib/libpython3.9.so.1.0)
Why is it trying to look for libpython in /usr/local? The libpython3.9-dev package should have installed that stuff in /usr/lib/x86_64-linux-gnu (https://packages.debian.org/bullseye/amd64/libpython3.9-dev/filelist).

[l33tmeatwad]

Manually importing Vapoursynth in a Python instance and checking the version works, but VSPipe doesn't. What the heck?
Just tried it out on a fresh Debian 11 install and it worked fine, your install is an upgrade correct? It's possible that /usr/local/lib/python3.7 is still there, and if you copy/pasted the instructions with the * in it, it may have taken you there and you may not have setup site-packages to forward to dist-packages in the python3.9 folder.

[TheSpectre]

Just tried it out on a fresh Debian 11 install and it worked fine, your install is an upgrade correct? It's possible that /usr/local/lib/python3.7 is still there, and if you copy/pasted the instructions with the * in it, it may have taken you there and you may not have setup site-packages to forward to dist-packages in the python3.9 folder.

This is an upgraded installation, but I have purged all versions of Python other than 3.9

[TheSpectre]

The thing that jumps out from the log though is this:
by 0x4E5586F: _PyEval_EvalFrameDefault (in /usr/local/lib/libpython3.9.so.1.0)
==2369746== by 0x4E09612: _PyFunction_Vectorcall (in /usr/local/lib/libpython3.9.so.1.0)
Why is it trying to look for libpython in /usr/local? The libpython3.9-dev package should have installed that stuff in /usr/lib/x86_64-linux-gnu (https://packages.debian.org/bullseye/amd64/libpython3.9-dev/filelist).

It might have something to do with this https://wiki.debian.org/UsrMerge
Edit: Nevermind. This isn't related.

[l33tmeatwad]

I don't recall VapourSynth needing an egg, in fact I think I had a plugin once setup a vs egg and it conflicted with the main install. Try removing (or temporally relocating) /usr/local/lib/python3.9/dist-packages/VapourSynth-55-py3.9-linux-x86_64.egg, then if it's still failing remove and reinstall, but try R54 just for good measure.

[TheSpectre]

I don't recall VapourSynth needing an egg, in fact I think I had a plugin once setup a vs egg and it conflicted with the main install. Try removing (or temporally relocating) /usr/local/lib/python3.9/dist-packages/VapourSynth-55-py3.9-linux-x86_64.egg, then if it's still failing remove and reinstall, but try R54 just for good measure.

No luck. I've completely purged R55 and reinstalled R54 using qyot27's instructions, but still get the same bloody error :mad:

[TheSpectre]

At this rate, it may be better to either completely reinstall or do my encodes in a debootstrap chroot environment.

[l33tmeatwad]

Just to clarify, you did remove the VapourSynth egg and tried reinstalling again?

[TheSpectre]

Just to clarify, you did remove the VapourSynth egg and tried reinstalling again?

Correct :(

[l33tmeatwad]

Don't forget to sudo ldconfig after the install each time, Debian is funny like that. I would say do a complete purge of VapourSynth and make sure the egg is gone, then do a regular stock compile, no special extras, and then after the install do the ldconfig and try vspipe again. If that doesn't work a fresh install or alternative may be best *shrugs*

[TheSpectre]

Don't forget to sudo ldconfig after the install each time, Debian is funny like that. I would say do a complete purge of VapourSynth and make sure the egg is gone, then do a regular stock compile, no special extras, and then after the install do the ldconfig and try vspipe again. If that doesn't work a fresh install or alternative may be best *shrugs*

No luck. debootstrap it is :(
Thanks for trying to help me through Python Hell :thanks:

[Selur]

And is this really correctly transcribed? I have no idea what it is in the original script but processing only Y and U plane looks iffy.
mode=[repmode,repmode,1]
got it from https://forum.doom9.org/showthread.php?t=169771

Any opinion about the 'ChangeFPS' it's the main thing bothering me in the gpu part of the script where I'm totally unsure whether it makes sense. :)

Cu Selur

Ps.: uploaded the current RemoveDirt and a new SpotLess version to my Vapoursynth script collection (https://github.com/Selur/VapoursynthScriptsInHybrid/).

[Quadratic]

Since day one of using Vapoursynth, I have found the type hints included in the documentation to be rather confusing. Has there ever been any discussion on improving upon them?

Take Std.DeleteFrames() for instance https://vapoursynth.com/doc/functions/deleteframes.html
This is of very poor conveyance std.DeleteFrames(clip clip, int[] frames)
The hints from my environment are infinitely more useful: DeleteFrames: (clip: VideoNode, frames: int | Sequence[int]) -> VideoNode

Why is clip mentioned twice for all standard functions? Why are there commas after some square brackets? None if this is immediately clear and in my opinion only serves to confuse beginners. std.Crop(clip clip[,

[Boulder]

Since day one of using Vapoursynth, I have found the type hints included in the documentation to be rather confusing. Has there ever been any discussion on improving upon them?

Take Std.DeleteFrames() for instance https://vapoursynth.com/doc/functions/deleteframes.html
This is of very poor conveyance
The hints from my environment are infinitely more useful:

Why is clip mentioned twice for all standard functions? Why are there commas after some square brackets? None if this is immediately clear and in my opinion only serves to confuse beginners.

The format makes it easier for Avisynth users to adopt VapourSynth. I personally would not have understood the latter one, but the first one immediately tells me that the first argument is a clip to process and the next one needs some frame numbers.

[ChaosKing]

Why are there commas after some square brackets? None if this is immediately clear and in my opinion only serves to confuse beginners.

Looks like optional parameters to me.
The "simple" version is easier to read, especially when you have many parameters.

[_Al_]

Since day one of using Vapoursynth ...
The nature of python syntax, chaining attributes, functions where arguments could be optional or mandatory asks for an example to show nature of programing language - python. That web page should have examples with working script above it, including getting core and using correct syntax. Some functions have it (difficult ones). This would bring at least 50% more vapoursyth users. That was going thru my head , how many folks drop vapoursynth not succeding to make it work after one hour, or struggling with fcs syntax (like me)
import vapoursynth as vs
from vapoursynth import core
red = core.std.BlankClip(format=vs.RGB24, color=(255,0,0), length=1)
green = core.std.BlankClip(format=vs.RGB24, color=(0,255,0), length=1)
blue= core.std.BlankClip(format=vs.RGB24, color=(0,0,255), length=1)
clip = red + green + blue #clip with 3 frames, red,green and blue
no_green_frame = core.std.DeleteFrames(clip, 1)
no_green_frame.set_output(0)
just_green_frame = core.std.DeleteFrames(clip, [0,2])
just_green_frame.set_output(1)
Question is, who is going to do it, for example that web page, documentations. Myrsloik cannot be asked to do it. Or developers, same thing. It is up to some user that used to struggle with syntax to actually help and make it more clear for beginner to make a working script right away.

[Myrsloik]

The nature of python syntax, chaining attributes, functions where arguments could be optional or mandatory asks for an example to show nature of programing language - python. That web page should have examples with working script above it, including getting core and using correct syntax. Some functions have it (difficult ones). This would bring at least 50% more vapoursyth users. That was going thru my head , how many folks drop vapoursynth not succeding to make it work after one hour, or struggling with fcs syntax (like me)
import vapoursynth as vs
from vapoursynth import core
red = core.std.BlankClip(format=vs.RGB24, color=(255,0,0), length=1)
green = core.std.BlankClip(format=vs.RGB24, color=(0,255,0), length=1)
blue= core.std.BlankClip(format=vs.RGB24, color=(0,0,255), length=1)
clip = red + green + blue #clip with 3 frames, red,green and blue
no_green_frame = core.std.DeleteFrames(clip, 1)
no_green_frame.set_output(0)
just_green_frame = core.std.DeleteFrames(clip, [0,2])
just_green_frame.set_output(1)
Question is, who is going to do it, for example that web page, documentations. Myrsloik cannot be asked to do it. Or developers, same thing. It is up to some user that used to struggle with syntax to actually help and make it more clear for beginner to make a working script right away.

A bunch of getting started scripts as examples could be useful. Or general examples of how to use some of the most popular filters.

Speaking of documentation I'm kinda hoping for some nice person passing by to help with updating it for API4.

[Myrsloik]

You should all go test the API4/audio builds now. Get it here: R55-API4-RC (https://github.com/vapoursynth/vapoursynth/releases)

Supports Python 3.8/win7 as well so no excuses.

It also performs better on most scripts and computers for those of you who don't care about audio. You'll most likely need to update some of your scripts to the latest version if you encounter errors.

A thread with more specific information is here (https://forum.doom9.org/showthread.php?t=183070). Some of it already outdated so start from the back.

This will probably be the main release branch in a week or two unless major problems appear.

[Selur]

Do old plugins still work with the new version or do we need to have adjusted and recompiled plugins?

[Myrsloik]

Do old plugins still work with the new version or do we need to have adjusted and recompiled plugins?

Should work properly with all old plugins.

[Yomiko]

Do you have a recommended size limit for frame property values?

[Myrsloik]

Do you have a recommended size limit for frame property values?

Not really. As long as you have the ram for it.

[Yomiko]

Nice. Would you like to attach ICC profiles of images as frame properties via imwri? Like here (https://github.com/YomikoR/VapourSynth-ICCConvert/blob/882e460b6896c4f3658ad6c7c4d17ee271aaf3fb/src/magick/magick.cc#L11-L15). The ->datum is unsigned char * so nothing will be fancy. Typically ICC profiles are from 1KB to 1MB. For preparation, it suffices to build ImageMagick with Little CMS (will add <500KB to the imwri dll) with MAGICKCORE_LCMS_DELEGATE macro checked when building imwri.