Legacy ImageMagick Discussions Archive

magick wrote: The patch is in ImageMagick 6.3.2-1 Beta to support backwards compatibility. If you get the time, test it and let us know.

I grabbed it and it seems to work fine the old way. Many thanks.

Rick

magick wrote: The patch is in ImageMagick 6.3.2-1 Beta to support backwards compatibility. If you get the time, test it and let us know.

I'll do that. And also, I like the newer version better, since it gives a meaningful argc.

Rick

Now to do something simular for perspective transforms. Though the question is should IM be given the 16 box arguments, or the 8 perspective matrix arguments. It would be cool if there were a few ways to give the args. Another nice thing would be to be able to feed it the coordinates of four points...

I just downloaded 6.3.1-7 and built it with no errors with VC++7, but doing likewise with 6.3.2-0 gave me linker errors for all the UTIL's. UTIL_convert error LNK2019: unresolved external symbol __imp__ConvertImageCommand referenced in function _main UTIL_convert fatal error LNK1120: 1 unresolved ex...

Did you try convert inface1.jpg -process "myproc -opt1 arg1 -opt2 arg2" outface.jpg Let us know if that works. Hi, thanks for the quick reply (as always). I see. Even though that didn't work at first (I used 6.3.1), a minor tweak of the code did get it to work. Prior, I was checking to se...

My custom modules work no more. Not so long ago I could execute something like convert inface1.jpg -process myproc="-opt1 arg1 -opt2 arg2" outface.jpg and my module (myproc.dll) got the call at the follow line. ModuleExport MagickBooleanType myprocImage(Image **images,const int argc, char ...

Note that -border 4 is that same as -border 4x but different to -border 4x0 Yup. But in my needling opinion, -border 4 should be the same as -border 4x4 , while -border 4x should be the same as -border 4x0 . Either of these is logical: 1) 4x = x4 = 4 = 4x4 2) 4x = 4x0, x4 = 0x4, 4 = 4x4 though I pr...

Try convert rose: -extent 80x56 -roll +10+10 rose.miff to add space to the left and top of the image. Ah, yes, that's better than what I was doing. It still seems a shame that it cannot be done in one shot. These methods move things twice rather than just once, do they not? In other words, it's a s...

A simple thing... I can use -extent to add pixels to the right and bottom of an image, but what if I prefer the left and top? convert rose: -extent 80x56 ... This adds 10 pixels on the right and bottom. I can get what I want with convert rose: -rotate 180 -extent 80x56 -rotate 180 ... but this seems...

This is a first step toward a smooth and proper installation of PerlMagick on Windows. In PerlMagick/Makefile.nt there is the line, 'LIBS' => ['-L..\VisualMagick\lib -L..\VisualMagick\bin -lCORE_RL_magick_.lib'], which seems not nice to those of us who build the (default) Debug version, assuming as ...

If your image is RGB it does not copy the matte channel when updating pixels. That accounts for the different behavior for Append(). But this seems the opposite -- the entire RGB image is "promoted" to RGBA with a completely transparent matte, evidently obtained from the border or backgro...

Your problem has to do with default values. Try $image1->Border(width=>4, height=>0, color=>'blue'); and you get the expected results. Yes, I noted that above (the red borders). PerlMagick defaults the width and height to the image columns and rows. "Defaults" in that the geometry field i...

Why should the following not work? convert -size 200x200 gradient:red-blue gradient.png This gives me a major crash in 6.3.1-4,5. Likewise for the PerlMagick version. The following never lives long enough to die. #!/usr/bin/perl -- use Image::Magick; $image = new Image::Magick; $image->Set(size=>'20...

As of 6.3.1-4, there is some funny bidness along the Border. Start with our sweet 'rose:' ... #!/usr/bin/perl -- use Image::Magick; $image = new Image::Magick; $image->Read("rose:"); ... add a border of width 4. $image1 = $image->Clone(); $image1->Border(width=>4, color=>'blue'); $image1->...

I don't know if this is a bug, an undesirable effect or an expected result. But I was surprised to find that under some conditions (which I have not pinned down), stacked (appended) images behave differently depending on the order of the images, even when of the same size, perhaps with some dependen...