Legacy ImageMagick Discussions Archive

I've developed a thumbnail editor for my application, which allows the user to "move" his large avatar within a set dimensions and thus save a thumbnail that looks better than the auto-generated one. I do this by using the old method of "-resize Y -resize Xx< -resize 50% -gravity center -crop XxY+offsetX+offsetY +repage" (which is described here: http://www.imagemagick.org/Usage/resize/#space_fill). This works beautifully.

I then tried to change the command to use the new "^" feature (which is described here: http://www.imagemagick.org/Usage/thumbnails/#cut), like this:

-define jpeg:size=X*2xY*2 source.jpg -auto-orient -thumbnail XxY^+offsetX+offsetY -gravity center -unsharp 0x.5 jpeg:output.jpg

Unfortunately, the +offsetX and +offsetY parameters for the -thumbnail geometry are ignored.

for example (should show a thumbnail that has been pushed downwards by 50px, but its not):

*bump*

nobody?

try

-thumbnail XxY+offsetX+offsetY^

or


-thumbnail XxY+offsetX+offsetY\^

unfortunately, that didn't work.

does it work for others? maybe my version (6.5.8-10) is a bit too old?

I tried version 6.7.0, then I tried 6.7.4... I tried to move the ^ character and made sure it is properly escaped.... no go, they all have the same problem.

Probably a bug that has been around for a long time but nobody noticed because it is not so frequent to displace/offset a thumbnail.

Here is a test case:

convert im logo to a 100x100 thumbnail without any offset: do the same with +50px vertical offset: Based on the documentation, the "^" character is part of the "size" part of the geometry and not part of the offset, so in theory it should stay as: dX x dY ^ +|- oX +|0 oY

Can someone please test the above commands? If they produce the same result then there is definitely a bug in im, unless -thumbnail is on purpose made to ignore offsets for some reason?

If the "-thumbnail" option runs StripImage(image) (as if the "-strip" option had been supplied) then the offset information gets stripped by the PNG encoder.

There's probably a workaround via the "-define png:include-chunks=vpag,offs" but I'm not sure. I'll test and report back when I get a few minutes.

[edit] That's not the problem. Apparently it's more like an automatic "+repage" has happened, so there is nothing for the PNG encoder to ignore.
If you add "-page +0+50" after the -thumbnail option you get the offset included in an oFFs chunk in the PNG file.

Does it work with -resize? If so then add -strip after the -resize and see if that will produce what you want.

I'm sorry to report but none of the suggestions worked. I had to resort to the "long" way of doing this:

-resize xY -resize Xx< -resize 50% -crop XxY+OffsetX+OffsetY

not very elegant, and the "^" character was supposed to be a shortcut but since ^ doesn't work with offsets... I have to go the long way

I can say definitive that -thumbnail does NOT take a offset!

In the cut to fit thumbnailing technique (using '^' resize flag) the option that does take -gravity and -geometry offset info is -extent.

http://www.imagemagick.org/Usage/thumbnails/#cut
http://www.imagemagick.org/Usage/crop/#extent

The alternative is to do a crop with the righ aspect ratio BEFORE the resize.