Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
i've been looking around for ages to find a tool which allows me to cut an image in tiles. thanks a lot for graphicsmagick! currently i am using this commandline:
gm convert -crop 128x128 Huge_Image.jpg "tiles-%d.jpg"
this creates images: tiles-1.jpg to tiles-444.jpg
is there an option to put the tile coordinates in the name? (to get tile-0-0.jpg, tile-0-1.jpg to tile-443-443.jpg)? something like "tiles-%x-%y.jpg" for the output filename (hope the explanation is somehow clear)
or does this need to be done manually (there seems to be only the %d available) after the crop?
thanks for any suggestions!
While I can see that this filename substitution would be useful for you, it turns out that the simple %d substitution has already caused us plenty of trouble (security/robustness issues). People who chose to include %d in the real filenames are out of luck. In order to be reliable, secure, and flexible, a special mode would be needed in order to apply many possible substitutions to file names.
As a work-around, I suggest writing a Perl script using PerlMagick (or a Ruby script using RMagick, or a Tcl script using TclMagick) since this will allow you to do whatever you want and can be more efficient. As the parts are cropped out, they can be named as you like, and immediately saved/deallocated in order to save memory.
thanks for the reply! (very quick indeed)
after some sleep i can see the trouble behind it. i can also imagine quite some different numbering (not starting (0,0) top left for ex). so i even couldn't define requirements.
yet i wonder why scripting is more efficient than using the command line? iterating over an image is done in both cases? or does -crop reopen the image everytime?
i had a look at the script adapters. JMagick won the competition :)
thanks a lot!
Scripting can be more efficient since then you can control when memory is deallocated. With the -crop approach, all of the output images are created in one big list, and then they are finally saved to the output file, doubling memory consumption. With the script approach, you can save the output files as they are cropped so there is no need to keep more than one crop image in memory at a time. Memory consumption is really only an issue if you don't have very much memory or the input image is very large.
As far as I am aware, JMagick is not currently ported to work properly with GraphicsMagick. The script interfaces which do currently work are PerlMagick (Perl), TclMagick (Tcl), and RMagick (Ruby). We should probably remove mention of other interfaces from the GraphicsMagick web pages.
I don't think that porting JMagick to work with GraphicsMagick is very difficult and I may end up doing this myself someday and including it with GraphicsMagick.