Page 1 of 1

TransformImage alternative

Posted: 2008-02-01T01:46:47-07:00
by nicolas1
Hello,
I see "TransformImage" makes 2 operations: crop and resize. So, one temporary object is created... It is possible to make these 2 operations in single operation?

Re: TransformImage alternative

Posted: 2008-02-01T06:23:29-07:00
by Bonzo
Have you tried:

Code: Select all

convert image.jpg -resize 200x200 -crop 100x100+10+10 output.jpg

Re: TransformImage alternative

Posted: 2008-02-03T17:36:12-07:00
by anthony
You can also either resize, or crop during the read process.

And JPG library takes the -size hint to do rough (not exact) resizing of JPEG images as they are read from disk to speedup the decode, and memory usage.

NOTE: techniqually as Resize generates a new image from the old image, (twice over) it should be techniqually posible for it to do a crop at the same time it is doing the resize.

The -distort operator can do this too using its output 'viewport' expert control, though its resize is basied on the use of a more free form cylindrical resize filter and not a two pass orthogonal filter, making it a lot slower than resize.

WARNING: Distort filter handling is currently primitive and is defaulting to a blurry 'gaussian' type of resize filter due to the current standard implementation method it uses for 'area resampling'. My next IM library core programming will involve the improvement of distorts use of resize filters (now that resize filters have been overhauled), as well as improvements in its use of interpolation functions (which badly needs an overhaul), and its handling on 'near horizon' problems (using a simplified pyramid image structure). This is a work in progress.

Re: TransformImage alternative

Posted: 2008-02-05T19:27:53-07:00
by nicolas1
This means that there are no such routines in IM now?

Re: TransformImage alternative

Posted: 2008-02-05T20:24:33-07:00
by anthony
It means the development has yet to add the next set of routines.

Re: TransformImage alternative

Posted: 2008-02-06T07:55:43-07:00
by el_supremo
The MagickCore function TransformImage does a crop and then a resize on an image.
What do you mean by "one temporary object is created" ?

Pete

Re: TransformImage alternative

Posted: 2008-02-06T17:18:52-07:00
by anthony
He means that most imagemagick library routines do not modify an exsiting image, but creates a clone (for the images meta-data information), and transfers the changes needed to the new image.

As such internally doing two operations, has the first operation creating a temporary image object which is then used to feed the next operation. The API surrounding those operations typically then deletes the old, no longer needed images.

Re: TransformImage alternative

Posted: 2008-04-15T05:07:49-07:00
by nicolas1
Hello,
Are there any news about is crop+resize in single operation?
What is the fastest resize operation in IM with ability to set NN filter, linear and cubic filters?
regards

Re: TransformImage alternative

Posted: 2008-05-07T00:16:10-07:00
by anthony
The fastest resize is the -sample resize filter which is its own seperate function to do single point lookups from the source image. Outpus is as expected horrible.

The normal resize on the other hand should be variable depending on the 'neighborhood' or 'support' the specific filter requires. A complex filter with a enlarged expert setting support size (for sinc function windowing) will of course take longer.

At this time the only resize+crop type of resize, in a single operation will be as a side effect of the -disort option using a 'viewport' expert setting to limit the output to a specific area of the distorted output space. Of course that is a bit slower than resize as it would use a 2 dimensional cylindrical filter rather than a 2 pass one dimensional rectangular filter that -resize uses (due to different requirements).

Note however that the actual filters in -distort are not yet fully enabled, as it was awaiting my return from China, to fix its support handling. Currently the filters are being clipped at a rough 2*scale pixel radius, rather that suppor*scale pixel radius. This is my next major task, after I get a lot of current minor ones (non-IM) out of the way.