Legacy ImageMagick Discussions Archive

Is Clone & Crop the only way to get a rectangular region from an image (leaving the original intact)??

(something like
$original=Image::Magick->[whichever way];
$rectangle=$original->Clone();
$rectangle->Crop(geometry=>'80x80+25+50'); )

Is there a way to get/select a rectangular region without having to clone the whole thing first? Or perhaps the overhead is not as scary as I imagine it might be?

I mean, if you're dealing with 100MB (uncompressed) images, and you want to process 1000 rectangular regions... seems like a waste of CPU

It also seems like, with ImageMagick being so versatile and powerful, it would have a more runtime-efficient alternative.

I haven't thoroughly explored the differences yet, but, on cursory research, GTK2 might do this, with its pixel buffers

ImageMagick supports efficient cropping for raw images and MPC images. Assume a rectangular array of RGB pixels:

• convert -size 100000x100000 -depth 8 'rgb:myimage.dat[1000x1000+100+100]' crop.png

Or MPC:

• convert image.mpc -crop 1000x1000+100+100 crop.jpg

For all other formats, the image must first be read entirely before its cropped. For an explanation, see http://www.imagemagick.org/script/archi ... p#overview.

magick wrote:ImageMagick supports efficient cropping for raw images and MPC images. Assume a rectangular array of RGB pixels:

• convert -size 100000x100000 -depth 8 'rgb:myimage.dat[1000x1000+100+100]' crop.png

Or MPC:

• convert image.mpc -crop 1000x1000+100+100 crop.jpg

For all other formats, the image must first be read entirely before its cropped. For an explanation, see http://www.imagemagick.org/script/archi ... p#overview.

Not sure I understand: your solution suggests stepping outside of PerlMagick, doing some type of command-line processing (directly, with "convert", at the shell) and then pulling the results into PerlMagick?

If I sound like a clueless newbie here -- that's because I am. Apologies in advance

Does reading from raw RGB images meet your requirements? If so, verify it works from the command line and then we can post a code snippet how to accomplish the same task from PerlMagick/

note that cloning an image is not scary, memory wise.

Cloning does make a copy of image meta-data, but the actual image data is not copied until it is changed.

Crop only reads the existing data, and creates a new image of the area being cropped.

As such a clone-crop only costs the original image, + a copy of its meta data (not much) + the croped image.

It is very efficient and not scary!

anthony wrote:note that cloning an image is not scary, memory wise.

Cloning does make a copy of image meta-data, but the actual image data is not copied until it is changed.

Crop only reads the existing data, and creates a new image of the area being cropped.

As such a clone-crop only costs the original image, + a copy of its meta data (not much) + the croped image.

It is very efficient and not scary!

Just to disambiguate: until WHAT is changed? You mean cloning doesn't pull in all the image data until THE ORIGINAL is changed? Or until THE CLONE is changed? (or either?)

thanks!

An image clone copies the image meta data but shares the pixel data cache with the source image. Its only when you try to update the clone pixel data that the pixel cache is cloned.

magick wrote:An image clone copies the image meta data but shares the pixel data cache with the source image. Its only when you try to update the clone pixel data that the pixel cache is cloned.

OK. I guess I got my answer. Just for academic purposes, though:

The replies seem to suggest the following:

Given a $clone that is an unmodified clone of $original, if $original gets modified, $clone is automatically and implicitly modified along with it (without $clone itself being explicitly modified) ?

So, $clone would by like, dynamically linked to $original, almost like a pointer to it... until user modifies $clone, whereupon the two will finally become COMPLETELY distinct.

a little strange, but I can work with that (or with the alternative, either way)...

but if the implicit modification of the clone, it's a heads-up, for future reference.

Image clones are based on a well known concept called reference counting. See http://en.wikipedia.org/wiki/Reference_counting for details.

Basically by using "reference counts" a record is kept of how may images are pointing to the data. If one (any one) of those images wanted to change that data it is then and only then given its own separate copy (with appropriate reference count chnages) so it can change the data without effecting the other images also referencing the data.

In terms of the original question. Making a clone of an image then croping it will not need to modify the original data at all. Crop only reads the data of the image given, so as to create the new smaller image. Afterward this new smaller image will replace the image given, which was why you wanted to give it a clone in the first place.

In other words clone-crop is VERY memory efficent and does not cause you to 'double' memory usage for the original image data.

Note the clone is actually only needed for the Command Line Interface. In most other API's (such a MagickWand for PHP or C), 'crop' just generates a new (smaller) image from the given image, just as procided by the internal Core library function. I do not know why PerlMagick did not allow this, but it was proably due to the style of the API the developer was trying to achieve. The CLI interface also needs 'cloning' ro preserve the original when using 'crop' as it only has one active 'Image List', thus it needs to juggle images using it 'image list stack' style of handling.