ImageMagick writer/reader

[kolak]

It does support sequences also, just use ffmpeg naming convention for image sequences.

[Myrsloik]

Nothing, tried using vspipe and changing file, but nothing, still the same error

Confirmed. Apparently it still looks for the already installed imagemagick binaries for some reason.

[Myrsloik]

After an evening of debugging I can proudly report that ImageMagick has some of the worst code I've looked at in a while. Including my own ancient YATTA code.

It automatically initializes itself when its dlls are loaded and it misuses its own api to set the path to use so it can never work. I suggest you send hate letters to the ImageMagick developers so they stop writing code. The world will be better off that way.

[Reel.Deel]

That's a pity to hear that. If I'm understanding correctly this is the end of imwri? Are there better alternatives? Could ffmpeg be used to write images (similar to ffms2 but for exporting)?

[Myrsloik]

That's a pity to hear that. If I'm understanding correctly this is the end of imwri? Are there better alternatives? Could ffmpeg be used to write images (similar to ffms2 but for exporting)?

It's only a maybe end. If they apply the changes in my bug report it can still be made to work. Have to wait and see. I could also compile my own fixed binaries but that's extremely annoying and the build system on windows is a joke.

[Myrsloik]

A small update. My fix has been accepted and the next ImageMagick release will have it. Expect a new and finally properly self contained release when version 6.9.0-4 is out.

[MonoS]

The impossible is happened
Thank you

[Myrsloik]

HAHAHA! YOU THOUGHT THE STORY WOULD END HERE? FOOLS!

The ImageMagick developers decided to simply release the broken 6.9.0-3 binaries as 6.9.0-4. Because why not? They've now wasted yet another evening for me. Maybe one day they'll get around to release updated binaries...

[MonoS]

WTF, wonderful!

I saw some 7.0 binaries in some repo, maybe they are preparing your commit for the next release??

[Myrsloik]

Here's test6 (https://www.dropbox.com/s/no628ujeuhd1gfo/imwri_test6.7z?dl=1). Tell me if it works. Only briefly tested.

Had to compile my own imagemagick binaries because that's how shit the official ones are. At least it appears to work.

[MonoS]

I'm trying it right now with the exr from BBB.
It seems to work really well, if i have some spare cpu in the next years maybe there will be a 16bit h265 lossless version of BBB thanks to vapoursynth :D

[Myrsloik]

If this version is confirmed to mostly work I'll probably go on and add float output support as well since it's a very small modification to do.

...some day.

[MonoS]

Maybe something don't work quite well, but i don't know.

Importing the exr from BBB [16bit float] the format is specified as RGB48 and not RGBS.
Is this expected??

[Myrsloik]

Maybe something don't work quite well, but i don't know.

Importing the exr from BBB [16bit float] the format is specified as RGB48 and not RGBS.
Is this expected??

Yes. Imagemagick is retarded so at compile time you have to specify the image format. For all images opened... Ever. This is why I may add float support later.

[MonoS]

I bet they won the Ig Nobel for programing at some point :D

[Kupildivan]

I've done this script:

import vapoursynth as vs
core = vs.get_core()
v = core.ffms2.Source ('HOB2.mkv')
v = core.std.Trim (v, 1600, 1701)
v = core.fmtc.matrix (v, mat="709", col_fam=vs.RGB, bits=16)
v = core.imwri.Write (v, 'PNG48', 'IMG\%05d.png')
v.set_output()

and the .bat file for it:

"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" VS.vpy -

that writes on disk only 7 first images and cmd hangs.

How to write all of these 101 images proprerly?

[Myrsloik]

I've done this script:

import vapoursynth as vs
core = vs.get_core()
v = core.ffms2.Source ('HOB2.mkv')
v = core.std.Trim (v, 1600, 1701)
v = core.fmtc.matrix (v, mat="709", col_fam=vs.RGB, bits=16)
v = core.imwri.Write (v, 'PNG48', 'IMG\%05d.png')
v.set_output()

and the .bat file for it:

"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" VS.vpy -

that writes on disk only 7 first images and cmd hangs.

How to write all of these 101 images proprerly?

I'll have to test it myself and see. I mostly tested reading images acutally...

[sneaker_ger]

Try piping to NUL:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" VS.vpy NUL

[Kupildivan]

Try piping to NUL:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" VS.vpy NUL

It's worked for me - "Output 102 frames in 217.67 seconds (0.47 fps)".

As for real writing I forgot to mention when I click on that .bat file cmd window begins to draw very long sequence of symbols for a while and then it hangs without suggesting to close it until I click on it.
I suppose I have done a mistake somewhere in the script or bat.

[jackoneill]

It's worked for me - "Output 102 frames in 217.67 seconds (0.47 fps)".

As for real writing I forgot to mention when I click on that .bat file cmd window begins to draw very long sequence of symbols for a while and then it hangs without suggesting to close it until I click on it.
I suppose I have done a mistake somewhere in the script or bat.

Yes. The hyphen (which you replaced with "NUL") tells vspipe to write the output to stdout, i.e. dump it all in the cmd window.

[Kupildivan]

I knew it. Anyway it doesn't matter, for I found another way to convert 10-bit mkv to png in the neighbour thread:
%ffmpeg% -i "Хоббит. Битва пяти воинств - Трейлер №2 в 3D [DCPrip 2K Hi444PP Hi10P OU].mkv" IMG\%%04d.png
Even without forcing 16-bits to output it creates correct sequence of PNG48 by default for such video.

[sneaker_ger]

Can someone with a clean R27 Windows install check whether or not he has the ImageMagick plugin? I thought it's supposed to come with the VapourSynth package nowadays but it seems to be missing here. Or at least it does not load here (Win 7 x64, no AVX CPU)

ret = core.imwri.Read('graded_edit_%05d.tiff')
"Python exception: No attribute with the name imwri exists"

[Myrsloik]

It's not included and never will be due to its insane size.

[sneaker_ger]

It's listed as included in the docs:
http://www.vapoursynth.com/doc/includedplugins.html

[Myrsloik]

That should be read as "included in the source tree"

[dipje]

I'm able to write EXR images no problem, but they get saved as (if I see it correctly) full 32-bit floating-point uncompressed files. Or at least 16-bit FP uncompressed.. ie huge :).
The ImageMagick build seems to have support for other compression types (For example 'piz') since it's listed in the output that convert.exe and mogrify.exe give.

So is it possible to add a parameter to specify compression type (also handy for things like TIFF and such), or at least change the default for EXR somehow?

I'm also willing to mock around and try to change + compile it for my own, but you said you used a custom-built ImageMagick for all this. Is that located somewhere so it's easier for me to recompile imwri.dll against your ImageMagick build?

[Myrsloik]

I'm able to write EXR images no problem, but they get saved as (if I see it correctly) full 32-bit floating-point uncompressed files. Or at least 16-bit FP uncompressed.. ie huge :).
The ImageMagick build seems to have support for other compression types (For example 'piz') since it's listed in the output that convert.exe and mogrify.exe give.

So is it possible to add a parameter to specify compression type (also handy for things like TIFF and such), or at least change the default for EXR somehow?

I'm also willing to mock around and try to change + compile it for my own, but you said you used a custom-built ImageMagick for all this. Is that located somewhere so it's easier for me to recompile imwri.dll against your ImageMagick build?

You can use the official sdk stuff I think. Just grab the actual dlls from my version. I think that should work.

I'll add an argument for compression type and that stuff some day. Actually I completely forgot about it since I mostly tested with png.

[dipje]

Had a bit of a fight to understand how the ImageMagick build-thingy works. Actually reading the manual helped :S, so I got _something_ build for MSVC 2010 with a slightly more recent ImageMagick built than what you used.
Then, as you said, used it just to compile my imwri.dll and just replaced that in my Vapoursynth folder, so using your DLLs. Stuff works.

Had to fight a bit to get imwri.cpp compiling under MSVC 2010, since you seem to be using some c++11 stuff. After it compiled and worked, added a simple 'compresstype' optional string parameter, then used an ugly 'if else if else'-block to match the strings to image.compressType() calls, and tadaaah. Seems to be working. Full-hd EXR files go from 16mb to +/- 6mb with Piz compression enabled while still being lossless and some sort of deep color. Finally a nice way to go in-and-out of After Effects / Vapoursynth :).

[kaefert]

how can the imwri plugin be compiled on linux? I've followed the guide here: http://www.vapoursynth.com/doc/installation.html#linux-and-os-x-installation-instructions but this did not compile the imwri plugin, only a few others.
@dipje what manual do you mean? is there some manual for compiling imwri somewhere?

UPDATE: Okey. So far thats what I managed to do:
cd ~/src/vapoursynth/src/filters/imwri
g++ -std=c++0x -I/usr/include/ImageMagick/ -I/home/kaefert/src/vapoursynth/include/ imwri.cpp

which still gives quite a few errors:
imwri.cpp: In function ‘const VSFrameRef* writeGetFrame(int, int, void**, void**, VSFrameContext*, VSCore*, const VSAPI*)’:
imwri.cpp:169:19: error: ‘class Magick::Image’ has no member named ‘quantizeDitherMethod’
image.quantizeDitherMethod(Magick::FloydSteinbergDitherMethod);
^
imwri.cpp:169:40: error: ‘FloydSteinbergDitherMethod’ is not a member of ‘Magick’
image.quantizeDitherMethod(Magick::FloydSteinbergDitherMethod);
^
imwri.cpp:169:40: note: suggested alternative:
In file included from /usr/include/ImageMagick/magick/deprecate.h:34:0,
from /usr/include/ImageMagick/magick/MagickCore.h:85,
from /usr/include/ImageMagick/Magick++/Include.h:43,
from /usr/include/ImageMagick/Magick++.h:9,
from imwri.cpp:27:
/usr/include/ImageMagick/magick/quantize.h:32:3: note: ‘FloydSteinbergDitherMethod’
FloydSteinbergDitherMethod
^
imwri.cpp:173:23: error: ‘class Magick::Image’ has no member named ‘alphaChannel’
image.alphaChannel(Magick::ActivateAlphaChannel);
^
imwri.cpp:173:36: error: ‘ActivateAlphaChannel’ is not a member of ‘Magick’
image.alphaChannel(Magick::ActivateAlphaChannel);
^
imwri.cpp:173:36: note: suggested alternative:
In file included from /usr/include/ImageMagick/magick/draw.h:26:0,
from /usr/include/ImageMagick/magick/annotate.h:25,
from /usr/include/ImageMagick/magick/MagickCore.h:66,
from /usr/include/ImageMagick/Magick++/Include.h:43,
from /usr/include/ImageMagick/Magick++.h:9,
from imwri.cpp:27:
/usr/include/ImageMagick/magick/image.h:33:3: note: ‘ActivateAlphaChannel’
ActivateAlphaChannel,
^
imwri.cpp: In function ‘void readCreate(const VSMap*, VSMap*, void*, VSCore*, const VSAPI*)’:
imwri.cpp:572:58: warning: narrowing conversion of ‘d.std::unique_ptr<_Tp, _Dp>::operator-><ReadData, std::default_delete<ReadData> >()->ReadData::filenames.std::vector<_Tp, _Alloc>::size<std::basic_string<char>, std::allocator<std::basic_string<char> > >()’ from ‘std::vector<std::basic_string<char> >::size_type {aka long unsigned int}’ to ‘int’ inside { } [-Wnarrowing]
d->vi[0] = { nullptr, 30, 1, 0, 0, d->filenames.size(), 0 };

update2: okey, so I guess maybe the imagemagick version included in my distribution is too old (8:6.7.7.10-6ubuntu3 --> 6.7.7.10)
I'm gonna try and update

[jackoneill]

how can the imwri plugin be compiled on linux? I've followed the guide here: http://www.vapoursynth.com/doc/installation.html#linux-and-os-x-installation-instructions but this did not compile the imwri plugin, only a few others.

You need to pass '--enable-imwri' to configure. It's right there in the output of 'configure --help'.

[kaefert]

thanks jackoneill! That worked!
now I only need to find out how to overlay my clip loaded with the imwri filter from png files over another clip.
http://www.vapoursynth.com/doc/avisynthcomp.html says I need to use std.Lut2 or std.Expr.
From reading http://www.vapoursynth.com/doc/plugins/imwri.html I guess I need to get the alpha channel as a seperate clip and somehow use this to tell std.Lut2 or std.Expr which parts of the png are transparent

UPDATE: okey, so I've found that I can get the images + their alpha channel in 2 seperate clips like this:
[bb,ba] = core.imwri.Read(filename="LOG00103.01/LOG00103.01.%06d.png", firstnum=0, alpha=True)
now all I need is some way to overlay every frame from bb according to the alpha info from the according frame in ba over the frames of some 3rd clip which contains my video

[dipje]

@kaefert I was talking about the ImageMagick manual, had nothing to do (yet) with imwri

[kaefert]

@kaefert I was talking about the ImageMagick manual, had nothing to do (yet) with imwri

okey, no problem. jackoneill told me the solution, so that problem is solved. Now I only need to learn how to use std.Expr and or std.Lut2 to overlay a transparent png clip over a video. I've done something similar before - dissolving two clips - if I can't find out how to do it with Expr or Lut2, maybe I'll try to adapt that code to my current needs:

def dissolve(clip1, clip2):
fade_frames = [clip1[0:clip1.num_frames-dissolveCount]]
for i in range(dissolveCount):
frame1 = clip1[clip1.num_frames - dissolveCount + i]
frame2 = clip2[i]
fade_frames.append(core.std.Merge(clipa=frame1, clipb=frame2, weight=i/(dissolveCount-1)))

fade_frames.append(clip2[dissolveCount:clip2.num_frames])
return core.std.Splice(clips=fade_frames)

[splinter98]

now all I need is some way to overlay every frame from bb according to the alpha info from the according frame in ba over the frames of some 3rd clip which contains my video

You need to addborders to your alpha clip so it matches the resolution of the clip you're overlaying onto, then use MaskedMerge to overlay them.

I have the following function which I use:


def Overlay(clipa, clipb, x=0,y=0, alpha=None):
core = vs.get_core()
if alpha is None:
#Create Blank Alpha Mask
alpha = core.std.BlankClip(clipb, color=[0xFF,0xFF,0xFF])
if clipb.format.id != clipa.format.id:
#Change clip b to same image type as clip a
clipb = core.resize.Bicubic(clipb, format=clipa.format.id)
if alpha.format.id != clipa.format.id:
#Change alpha to clip a format
alpha = core.resize.Bicubic(alpha, format=clipa.format.id)
#Calculate padding sizes
l, r = x, (clipa.width - clipb.width - x)
t, b = y, (clipa.height - clipb.height - y)
#Add padding
mask = core.std.AddBorders(alpha,l,r,t,b)
layer = core.std.AddBorders(clipb,l,r,t,b)
#return padded clips
return core.std.MaskedMerge(clipa, layer, mask, first_plane=True)

clip = overlay(clip, bb, x=20, y 30, ba)

[kaefert]

wow! thanks splinter98! however, in the return statement of your function you use a variable called "output" that is not defined anywhere
UPDATE: okey, found quite quickly that "output" was supposed to be "clipa"

update2: this question is not really to much related to this thread, but here it is anyway:
Is there a way to get seekable output from vapoursynth?
I currently preview my output using
vspipe playground.vpy --y4m - | mpv -
but mpv will tell me "Can't seek in this file." (of course, since its playing std input)

I found here:
https://wiki.archlinux.org/index.php/Mpv#Vapoursynth
that mpv can be compiled with VapourSynth support using the --enable-vapoursynth flag

I've installed the mpv release from this repository:
https://launchpad.net/~djcj/+archive/ubuntu/vapoursynth
So my mpv should have this flag set. Can this be used to simply play a vpy script instead of using one as a filter (as described on the archlinux wiki)?
mpv playground.vpy gives me Failed to recognize file format.

using
mpv --vf=vapoursynth=playground.vpy someunusedfile.avi
I can also get a preview of my script's output, but mpv will crash when I try to seek the output

UPDATE3: I've found vsedit - it can preview and select specific frames, but it lacks the feature to simply play the script, you can only go one from back or forward using arrows, or 10 frames back or forward using pageup & pagedown - or select a frame on the timeline or enter its number in a box. but not playing and if you "fake-play" by holding down an arrow key but that will continue playing for me after releasing the arrow key because it stacks "give me the next frame" messages instead of listening to keydown and keyup or something like that.

[splinter98]

wow! thanks splinter98! however, in the return statement of your function you use a variable called "output" that is not defined anywhere
UPDATE: okey, found quite quickly that "output" was supposed to be "clipa"


Ah yes you're correct, I simplified my code as I have it broken up into three separate functions (which allows me to prepare a whole set clips to overlay and then to the final merge with a single function call), so output is just a rename fail. I will update the code for anyone else who uses the code.

[splinter98]

I assume we should use mask instead of alpha here.

Yes! I really should test my code before publishing.

[kaefert]

hey there! I've added some functionality to splinter98's function (allow x & y values that move part of the overlay out of the base clip) and thought I'd share it, maybe its useful for other people too:
def Overlay(clipa, clipb, x=0,y=0, alpha=None):
if alpha is None:
#Create Blank Alpha Mask
alpha = core.std.BlankClip(clipb, color=[0xFF,0xFF,0xFF])
if clipb.format.id != clipa.format.id:
#Change clip b to same image type as clip a
clipb = core.resize.Bicubic(clipb, format=clipa.format.id)
if alpha.format.id != clipa.format.id:
#Change alpha to clip a format
alpha = core.resize.Bicubic(alpha, format=clipa.format.id)
#Calculate padding sizes
l, r = x, (clipa.width - clipb.width - x)
t, b = y, (clipa.height - clipb.height - y)
#split into crop and padding values
cl, pl = min(l,0)*-1, max(l,0)
cr, pr = min(r,0)*-1, max(r,0)
ct, pt = min(t,0)*-1, max(t,0)
cb, pb = min(b,0)*-1, max(b,0)
#crop and padding
alpha = core.std.CropRel(alpha,cl,cr,ct,cb)
clipb = core.std.CropRel(clipb,cl,cr,ct,cb)
mask = core.std.AddBorders(alpha,pl,pr,pt,pb)
layer = core.std.AddBorders(clipb,pl,pr,pt,pb)
#return padded clips
#print(clipa, layer, mask)
return core.std.MaskedMerge(clipa, layer, mask, first_plane=True)

[Myrsloik]

Test7 released. All output will be float. I think.

jackoneill did the compiling so now it's a much smaller set of files. Report your findings.

[dipje]

So, imwri can now be compiled against a Q32 or a Q16 ImageMagick, and it becomes 'imwrif' or 'imwri' namespace depending on which library it is compiled again?

Or it supports both Q16 and Q32 at the same time and you need to use the appropriate namespace?

If the first case is true, what version is included in test7? The files are way different than previous ImageMagick builds. Is that a new 'condensed all in one' ImageMagick compile in the archive? Is it standard or something cooked up specially for imwri? Is it Q32 or Q16? Reading your 'output is now float, I think' I think it's Q32, but want to be sure :).

If the build is Q32 / float / HDRI, what does that mean for 16 bit tiff output or DPX files and such. Impossible now?

[Myrsloik]

So, imwri can now be compiled against a Q32 or a Q16 ImageMagick, and it becomes 'imwrif' or 'imwri' namespace depending on which library it is compiled again?

Or it supports both Q16 and Q32 at the same time and you need to use the appropriate namespace?

If the first case is true, what version is included in test7? The files are way different than previous ImageMagick builds. Is that a new 'condensed all in one' ImageMagick compile in the archive? Is it standard or something cooked up specially for imwri? Is it Q32 or Q16? Reading your 'output is now float, I think' I think it's Q32, but want to be sure :).

If the build is Q32 / float / HDRI, what does that mean for 16 bit tiff output or DPX files and such. Impossible now?

QXX is different. The imwrif depends on HDRI (aka make everything floating point in imagemagick). Test7 is Q16 WITH HDRI so float stuff will work too. It makes no sense but that's the way it is. But the namespace is imwri because it was compiled before I changed my mind.

The QXX won't change anything apart from possible max output integer bitdepth. But in practice I'd say only Q16 and Q16 HDRI are worth to bother with.

Don't expect amalgamations because ImageMagick is shit. And a mess.

And to answer your question: HDRI=>always float output

[dipje]

So it is still a Q16 build like it was before, and I can still output 16 bit DPX or TIFF files like before... but the internal precision in the ImageMagick build is float so that it can do HDRI stuff on HDRI supported formats. For the other formats no change?

(Well I guess there is some sort of internal float -> 16bit integer conversion / dithering going on but that's OK).

[Myrsloik]

So it is still a Q16 build like it was before, and I can still output 16 bit DPX or TIFF files like before... but the internal precision in the ImageMagick build is float so that it can do HDRI stuff on HDRI supported formats. For the other formats no change?

(Well I guess there is some sort of internal float -> 16bit integer conversion / dithering going on but that's OK).

Probably no change. I guess. I'm not an ImageMagick expert.

[shader]

First of all: Thanks Myrsloik and all others for that great software. I like frame processing and Python. Great!

But I have a problem...

When I use Test7, unfortunatelly I can't load a sequence of files anymore.

Test6:
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path='C:/Program Files (x86)/VapourSynth/plugins32/imwri6/imwri.dll')
v = core.imwri.Read( filename=r"d:/test/%d.png", firstnum=1001)
v.set_output()
==> ok

Test7 with wildcard:
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path='C:/Program Files (x86)/VapourSynth/plugins32/imwri7/libimwri.dll')
v = core.imwri.Read( filename=r"d:/test/%d.png", firstnum=1001)
v.set_output()
==> not ok :(, "Read: No files matching the given pattern exist"

but Test7 without wildcard:
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path='C:/Program Files (x86)/VapourSynth/plugins32/imwri7/libimwri.dll')
v = core.imwri.Read( filename=r"d:/test/1001.png")
v.set_output()
==> ok

Does anybody see this problem? Or are wildcards working for anybody else?

Thanks!!!

[Myrsloik]

This will be investigated. Definitely should work. As a workaround you can create a list of all individual files using python and pass that. I think.

[shader]

Thanks and good luck!

[mawen1250]

files = ['{:0>3}.bmp'.format(i) for i in range(91)]
clip = core.imwri.Read(files, mismatch=True)
I tried using imwri test7 to read a list of RGB24 bmp files and found that the output format is not RGBS but RGB96 (32-bit integer).
As far as I know, none of the VapourSynth plugins supports 32-bit integer, including zimg and fmtconv, so I can do nothing with the output clip...

EDIT: tried reading a single file and the output is RGBS.

[sneaker_ger]

vspipe crashes when trying to open an exr file.
import vapoursynth as vs
core = vs.get_core()

ret = core.imwri.Read("0001.exr")
ret.set_output()
http://distribution.bbb3d.renderfarming.net/video/exr/1114/0001.exr
imwri "test7" build
VS R32 64 bit on Windows 7

[jackoneill]

vspipe crashes when trying to open an exr file.
import vapoursynth as vs
core = vs.get_core()

ret = core.imwri.Read("0001.exr")
ret.set_output()
http://distribution.bbb3d.renderfarming.net/video/exr/1114/0001.exr
imwri "test7" build
VS R32 64 bit on Windows 7

http://ulozto.net/x7jRBqpB/imwri-r31-win64-7z

Does it still crash with this one? The namespace will be "imwrif".

[sneaker_ger]

Behaves exactly the same. Even "imwrif" does not exist, only "imwri".