probablycorey/mini_magick — comment on commit 63d701e6501e1861b54a7f9e546d7032bf5b7dce
File:  line 0
By mikehoward:

OK - I've looked at this in some detail now.

1. Yes, the example does not work.

2. There is a minor bug in the way image operators are handled, but there is **almost** a work-around. Create an instance of a MiniMagick::CommandBuilder.new(command) - where 'command' defaults to 'morgify', but can be any of the ImageMagick commands. To create an image out of nothing, you should use 'convert' (strange as it seems) [ImageMagick isn't designed to create images so much as to transform them, so your mileage may vary]

You can then 'push' your commands, in order, onto the command builder stack. These commands can be any string you want.

You then need to create a MiniMagick::Image object without an input file - which is where the rubber meets the road. That doesn't seem possible without adding a new method or modifying MiniMagick::Image#initialize

3. But the real issue for most people is ImageMagick.

MiniMagick is a very thin layer on top of ImageMagick shell commands. This is good because it keeps memory bloat down *and* allows you to test your MiniMagick commands on the command line. ImageMagick is really picky about order of operations, spelling, etc etc - so if it won't work on the command line, it's not MiniMagick's fault

Please make sure your issues are not with constructing the correct command rather than with the MiniMagick implementation.

The patch as stands is pretty much OK, unless you use some of the operators without arguments.