Legacy ImageMagick Discussions Archive

How does one use the "extract" option in PerlMagick?

The docs indicate that the extract geometry is an attribute. Okay, so,

$image->Set(extract=>"24x48+0+0");

should set it. But then what? Using WriteImage subsequently gives the original image, not an extracted one.

But why would such a thing be an attribute, rather than an image method? I would have expected something more like this:

$newImage = $image->ExtractImage("24x48+0+0");

Rick

Set the extract attribute before you read an image. It useful for extracting a region from an image at read time. The best example would be if you want to extract, for example, a 1024x1024 section from a massive raw RGB image.

There is no need for an ExtractImage() since CropImage() already does that.

magick wrote:Set the extract attribute before you read an image. It useful for extracting a region from an image at read time. The best example would be if you want to extract, for example, a 1024x1024 section from a massive raw RGB image.

I see, thanks. Here's my situation: I have a giant image in memory and want to extract many small chunks of it. Reading a big image (and re- and re-re-reading) isn't good in that case. What's the best way to grab small subimages from an existing image, one after another?

There is no need for an ExtractImage() since CropImage() already does that.

But (correct me if I am wrong) CropImage modifies the big image and produces a small one from it. So if you need a bunch of small chunks, as I do, that doesn't work either.

I need something like this:

$image1 = $bigImage->GrabImageChunk("40x50+2500+1800);
$image2 = $bigImage->GrabImageChunk("30x90+1500+1980);
etc.

Thanks for the reply,

Rick

Use Extent() to do what you want. First clone the big image with Clone(). If you recall, clone uses a pixel cache reference so it should be light-weight.

magick wrote:Use Extent() to do what you want. First clone the big image with Clone(). If you recall, clone uses a pixel cache reference so it should be light-weight.

Thanks --- I avoided Clone() because I did NOT recall that, but thanks for your generous assumption! It works in a small test, so I'll give it a whirl in the big setting and report back.

Meanwhile, I see (note to self and others) that in PerlMagick, I cannot use

geometry => "40x15+2000+1800"

and must instead use

geometry => "40x15", x=>2000, y=>1800

or

width=>40, height=>15, x=>2000, y=>1800

Rick

We cannot reproduce the problem. Whatever offset we use in a string geometry is used in the results (we added a print statement to PerlMagick to confirm). We're using ImageMagick 6.4.6-5.

magick wrote:We cannot reproduce the problem.

I'm having that trouble myself! Perhaps I confounded myself keeping track of all the experiments.

Now I get sort of the opposite. After reading an image,

$image = new Image::Magick;
$image->ReadImage('logo:');

I tried

$ok = $extImage->Extent(geometry => "55x", x=>0, y=>0);

versus

$ok = $extImage->Extent(geometry => "55x+0+0");

The first fails, saying,

Exception 445: no pixels defined in cache `LOGO'

This is XP (6.4.5) but it is the same for Linux (6.4.4).

This is bizarre: The first two calls to Extent (below) fail, the rest succeed, even the fifth (which has no width given, to emulate the first two versions):

$image = new Image::Magick;
$image->ReadImage('logo:');
$extImage = $image->CloneImage();

# $ok = $extImage->Extent(geometry => "x55", x=>0, y=>0); #fails
# $ok = $extImage->Extent(geometry => "x55+0+0"); #fails
# $ok = $extImage->Extent(geometry => "640x55", x=>0, y=>0);
# $ok = $extImage->Extent(geometry => "640x55+0+0");
$ok = $extImage->Extent(height => 55, x=>0, y=>0);


Clearly, I'm having issues contrary to what others report, so I'll try not to pester on this any further, as I am able to work around it. Sorry for the noise.

Well, one more bit --- the command-line options doc has the following:

-extent width
-extent widthxheight

set the image size and offset. If the image is enlarged, unfilled areas are set to the background color.

But the first two lines do not give an indication of an offset being allowed. Change the doc?
I'm not even going to try the first one!

Rick

We can reproduce the problem you posted and have a patch in the Subversion trunk available sometime tomorrow. Thanks.