Legacy ImageMagick Discussions Archive

magick wrote:We'll have a patch in ImageMagick 6.9.0-10 Beta by sometime tomorrow to address your suggestion.

Thanks, it's working now

Download / install ImageMagick 6.9.0-8 Beta tomorrow. It has a patch to improve the results of the jpeg:extent define. I now had the opportunity to test the new windows binary " ImageMagick 6.9.0-9 Q16 x64 2015-02-28", and unfortunately it doesn't work as intended. For example with two test files ...

I recently downloaded an IM update from http://www.imagemagick.org/download/binaries/ with date "28-Feb-2015" and the filename... ImageMagick-6.9.0-9-Q8-x64-dll.exe ... but the actual version number from "convert -version" is ... Version: ImageMagick 6.9.0-8 Q8 x64 2015-02-21 It took me some time to ...

When updating an IM release with the windows installer binaries, it complains about "this file already exists". If these files are supposed to be user-changeable and the warning is meant for protection, they would be better placed in %appdata%. If they are stock files that are static, then this is a ...

Download / install ImageMagick 6.9.0-8 Beta tomorrow. It has a patch to improve the results of the jpeg:extent define. That's great news, IM gets my award for the most responsive oss team :-) I'll have to wait until there are windows binaries to test the change, I'm done trying to compile IM myself ...

I don't know if you feel this is over the top, but for what it's worth I'd like to do IM internally what I'm currently doing scripted with multiple runs: When defining "-define jpeg:extent" imho what is of interest very often is not to go higher than a certain *maximal* size, not to have a *fixed ...

The 6.9.0-2 release is available now. Thanks for fixing this, after trying to debug my scripts to no avail, this is a good incentive to visit the IM forum :-) ... I couldn't imagine for this basic fault, actually IM itself is to blame. Probably some regression testing suite to avoid something like ...

This request certainly doesn't come as a surprise, and I image you have though about it and decided against it, at least for the time being? Anyway, since I didn't find such a request in the forum yet, here's my case: 1. The imaging world is moving to xmp, so sticking with the iptc tag subset seems ...

For the record: As a simple user, I would find it great if this would be incorporated into IM. Sure most of the time you can run a second command line with pngquant after IM, but getting it "all in one" would be preferable because the file size reduction is unheard of with plain IM png8 output.

By the way, I do not see any font specified in your command. Damn, you're correct - I didn't see the wood because of the trees as my im command line has grown to nearly unmanageable size by now: I've really forgotten the font statement in when probing for the pointsize, that's why it worked with ...

I'm experiencing a weird issue I think could be a bug or bad behavior on im's side with the free font "Stark". I'm trying to find the best pointsize to fit a caption into a pre-determined width with "label"... convert -quiet -ping ( -size 1000x -background black -fill white label:"%string ...

Ok, I've got the solution and post it here for reference. As already assumed, gcc-ld defaults to shared libs if they exist no matter what you tell it, LDFLAGS='-static' or not. The "proper" though intricate solution seems to be to explicitly link all required libs with LDFLAGS='-static -static ...

Try 'configure --enable-static --disable-shared'. Now build. Does that work for you? Nope, already did that, sorry for not mentioning it :-o My current research indicates that "problem" is that the dependencies like libtiff are already there by the cygwin package manager system in static and shared ...

The download page http://www.imagemagick.org/script/binary-releases.php#windows offers an all-static version of IM with all dependencies packed into one exe. Problem: I'm failing to reproduce this compilation, with LDFLAGS=-static just the IM dependencies are included but the exes are still looking ...

Conclusion: bigger Q takes longer, but not by much. HDRI has hardly any effect. Great you're doing a systematic test, thanks! Do you have any means of measuring the memory footprint when for example doing polaroid thumbnails of say 4x4 medium-sized 2048x1536 source images? The q difference seems to ...