Legacy ImageMagick Discussions Archive

OK.. I'll give -crop a try and report back. Although I omitted it in my post, I did have a +repage in my "convert -extract" syntax so would have expected it to work.

version 6.7.5-7 on Linux Mint 10 My program extracts a portion of an image using "convert -extract wxh+x+y input.tif interim.tif" syntax, and that gives me the results I am looking for. However, when I subsequently want to extract a portion of interim.tif using the same syntax "convert -extract wxh ...

Well, that was easy . Working like a charm now. The script is churning through the images as I type. Thanks for your help.

Thanks for doing the analysis and the confirmation of the issue. Much appreciated. Are there any other steps necessary to register this as a bug, or is it simply enough to leave in this forum "as is"?

In the meantime, I'll need to try to figure out a "workaround".

I have tried putting in echos and the resulting values all seem to make sense. This seems to be supported by the fact that on every loop a valid interim.tif is being produced (same dimensions), each containing the full sprocket.tif sub-image (i.e. I can see it, and it isn't 'cutoff' or anything). I ...

thanks for the fast reply... 1. yes... interim.tif (first) is always larger than sprocket.tif (second), and visual comparison of the interim.tif's produced always contain the sprocket.tif subimage. 2. I have tried adding the extension (such as results.tif) and no difference First time round the loop ...

version 6.7.5-7 on Linux Mint 10 I am trying to extract a series of similar (but not 100% similar) subimages from an image. I know the approximate position of each of these sub-images (they are pretty regularly spaced within the image), so I've written a bash script with a "for" loop which in turn ...