Squaring images.

[anthony]

I'm not sure this is what you're after but....

Code: Select all

convert INPUT.JPG  -write mpr:0 /
  -gamma -1 /
  ( mpr:0 -gamma 0 ( +clone -gamma -1 -rotate 90 ) -compose Over -composite -bordercolor BLACK -border 1 -trim +repage      mpr:0 -compose Src -gravity East -composite ) /
  -compose Copy -gravity Center -composite /
OUTPUT.JPG

Select the section of your image with the -gravity setting after Src.
Reposition your image on the background canvas with the -gravity setting after Copy.

Messy code!
s.

Looks like it uses the image itself to set up a 'internal squaring' however it relies on trim to do the task.

• save original image.
• make white version (for later)
• make black version.
• make rotated white version.
• Overlay that on black (composite trims)
• then use trim to remove any black still remaining to get 'internal square'
• overlay (with Src compose) the original (composite trims) using gravity to select what part of image,
• overlay on white

That last operation is an error, you should swap (or create a new white image at that point), and underlay the background. Otherwise you will again loose the 'square cropped' size you so carfully worked to create.

Still it is a novel use of composite and trim to create an internal square crop, and uses pure white and black images for this process to avoid any dependancy on colors within the input image. Though it also requires a lot of processing steps to achive the goal.

What is amazing is that this would work with extrememly old versions of IMv6, long before the 'distort' operator was added.

[stupid]

The whole point of the code was to retain the original canvas size for padding - white, in my example. The interesting part of a non-square image can be cut out, and the position of that image on the canvas can be varied independently. He also wanted to run the routine on a fairly large number of images. Generally, mechanical methods work slightly faster than mathematical methods. (-distort is very slow on my machine; and with big images... zzz.) Also, of course, some users only have access to earlier versions of IM.


s.

[fmw42]

After reading the further discussion, I stand corrected in user stupid's approach being valid.

However, you can speed up -distort SRT 0 by adding -filter point before -distort (as mentioned by Anthony), especially for this problem using my method above with the viewport. It should be faster than all the other processing steps that were proprosed.

[anthony]

The whole point of the code was to retain the original canvas size for padding

yes we went a little beyond what you were wanting.

The distort solution shoud however be able to either internal (cropping) or external (padding) to square an image. It is just a matter of using either w>h or w<h in the %[fx:...] expressions. Though the offset expressions will also need the w and h swapped (for a change of sign).

It should be posible to generate a non-distort solution as well. Hmmm... yes using -mosaic with rotated images to create the padding canvas.

Code: Select all

convert  rose: \
   \( +clone -rotate 90 +clone -mosaic +level-colors white \) \
   +swap -gravity center -composite    square_padded.png

This and a cleaned up version of 'previous code' will appear in IM Examples in a hour or so
http://www.imagemagick.org/Usage/thumbnails/#square

[RQuadling]

OK. A LOT of what's being talked about has gone over my head.

To explain my requirement.

We are processing images from multiple third parties.

I am attempting to speed this process up and have done a LOT of work on this.

My goal, for this question, was how to I take an original image and from it create a new image where the new image has the same x and y pixel count, and the image is suitably padded on either the x or y, depending upon the original image.

The visible part of the image is not resized/rescaled, etc.

So, if an image is 100x150, I want a 150x150 where the left 25 and the right 25 are just white space.

I'm using (based upon answers received here) ...

Code: Select all

execImageMagick("convert '{$s_TrimJPG}' -bordercolor white -border 1 -gravity center -filter point -set option:distort:viewport \"%[fx:max(w,h)]x%[fx:max(w,h)]-%[fx:max((h-w)/2,0)]-%[fx:max((w-h)/2,0)]\" -virtual-pixel edge -distort SRT 0 '{$s_OriginalJPG}'");

Is the order of the -filter point and -virtual-pixel edge make any difference?

[anthony]

Is the order of the -filter point and -virtual-pixel edge make any difference?

No, as long as it is before the -distort which is the operation that uses it.

But check out the cleaned up alternatives in the link I gave in my last post.

[fmw42]

I have posted my versions of padding or cropping to square dimensions on my IM tidbits site at http://www.fmwconcepts.com/imagemagick/ ... rop_square

The method has nice symmetry --- use max() for pad, min() for crop

[anthony]

I have posted my versions of padding or cropping to square dimensions on my IM tidbits site at http://www.fmwconcepts.com/imagemagick/ ... rop_square

The method has nice symmetry --- use max() for pad, min() for crop

Very nice, but you can set the -virtual-pixel setting instead of needing the extra border/shave wrapping operations.

I have added it to IM Examples Thumbnails, Squaring Images (appear in an hour or so).
http://www.imagemagick.org/Usage/thumbnails/#square

Note that your 'square crop' is not centered. For that you also need a offset sign change! and +repage
The +repage is not needed for padding as GIF can't save negative offsets, so are automatically set to zero.
PNG however would save a negative offset!

[fmw42]

Anthony,

Good point about using -virtual-pixel white for padding, but it would be more versatile for other colors to use -virtual-pixel background -background white.

You are right about the crop , I did not think the logic through carefully. I though -max((w-h)/2,0) would be the same +min((h-w)/2,0) that is a change of sign and a min vs max and a change of w-h to h-w would have been the same. But that is not true. So the correct solution is not as symmetric.

With regard to the +repage, yes, I should add that for versatility. I did not add it because my example was output to jpg.

I have corrected my tidbits page.

Thanks.

Fred

[anthony]

It can me made a little better when I get geometry fixed to allow +-X+-Y to be equivelent to a negative offsets, as you previously suggested.

Now that I have finished IMv7 syntax check for operators I'll be getting on with a few things like this.
Similarly more percent escapes that can be used with geometry strings, perhaps even backporting to IMv6

[RQuadling]

Thank you to you all. Is there a way to determine which route is faster/less memory etc.? I don't know a lot of the terminology you mention and I'm pretty much just using your suggestions. Not a perfect solution I know - understanding them would be great.

I'd like to have the fastest option if that is easily identifiable.

But, as it stands, I have a working setup now. Thank you very much.

[fmw42]

If you are on linux/mac, you can just add "time" to the beginning of your command line and it will report how much time it takes to process. Do that several times for each method to get an average. Sometimes the first run takes longer.

time convert ....

If using PHP, then you will have to extract the time results from the exec command. Better if you can run your commands from the command line in a terminal directly.

[anthony]

As for memory use the distort method is probably least (2X image data) The other need at least 3 or 4 times the input image data due to the extra working images it needs.

Time wise the distort is also probably faster, as long as you use -filter point, though testing (and reporting your results) is still a good idea.