Page 1 of 1
crop bug
Posted: 2011-06-25T03:39:32-07:00
by mjn
If I do as described below, I end up with an image of size 1572x1560 instead of the requested 1607x2100. Any idea why?
Regards, Marcel
input file:
http://dl.dropbox.com/u/219844/desktop.png
script:
convert desktop.png -crop 1607x898+35+108 part.png
convert part.png part.png part.png part.png part.png -append in.png
convert in.png -crop 1607x2100+0+0 out.png
identify out.png
output:
out.png PNG 1572x1560 1920x6000+35+540 8-bit DirectClass 2.115MB 0.000u 0:00.000
Re: crop bug
Posted: 2011-06-25T08:57:38-07:00
by mjn
After looking into this some more, I see weird things going on:
$ identify part.png
part.png PNG 1607x898 1920x1200+35+108 8-bit DirectClass 1.237MB 0.000u 0:00.000
$ identify in.png
in.png PNG 1607x4490 1920x6000+35+540 8-bit DirectClass 6.175MB 0.000u 0:00.000
The offsets in part.png (+35+108) are taken from my original crop. This becomes +35+540 in in.png. By the way, those are just the number of pixels that I am missing in out.png (35 horizontally and 540 vertically).
If I open all 3 created files in Acorn, and save them again, I get:
$ identify part.png
part.png PNG 1607x898 1607x898+0+0 8-bit DirectClass 1.596MB 0.000u 0:00.000
$ identify in.png
in.png PNG 1607x4490 1607x4490+0+0 8-bit DirectClass 7.968MB 0.000u 0:00.000
$ identify out.png
out.png PNG 1572x1560 1572x1560+0+0 8-bit DirectClass 2.727MB 0.000u 0:00.000
which looks a lot better. (And how the script works, with part.png as input)
What are crop and append doing to to the second dimension field??
Re: crop bug
Posted: 2011-06-25T10:11:36-07:00
by fmw42
PNG saves the virtual canvas offsets when you crop. If you do not want the offsets afterwards add +repage after the crop. See
http://www.imagemagick.org/Usage/crop/#crop_repage
Re: crop bug
Posted: 2011-06-25T10:21:26-07:00
by mjn
Thanks Fred, I should have read the documentation better.
I'm still puzzled though why append would add the offsets. How can that be useful? The sum of the offsets don't seem to refer to any real units.
Re: crop bug
Posted: 2011-06-25T10:31:16-07:00
by fmw42
I was talking about -crop. I am not sure how -append deals with the virtual canvas offsets as I don't usually keep them.
A quick test does indeed show that IM is adding the virtual offsets from appending two images.
Re: crop bug
Posted: 2011-06-25T21:52:30-07:00
by anthony
I do not believe append was looked at with regards to virtual offsets. My understanding was it does not use them.
I have no idea why it adds them together, though I can understand it adding virtual canvas sizes together. That may be part of it.
In any case how it deals with layer information is NOT defined in the Core library function (which is VERY simplistic!)
Code: Select all
% AppendImages() takes all images from the current image pointer to the end
% of the image list and appends them to each other top-to-bottom if the
% stack parameter is true, otherwise left-to-right.
%
% The current gravity setting now effects how the image is justified in the
% final image.
%
% The format of the AppendImages method is:
%
% Image *AppendImages(const Image *images,const MagickBooleanType stack,
% ExceptionInfo *exception)
%
% A description of each parameter follows:
%
% o images: the image sequence.
%
% o stack: A value other than 0 stacks the images top-to-bottom.
%
% o exception: return any errors or warnings in this structure.
%
I would actually like to see append replaced with a more versatile 'layout' type operator, (see this proposal...)
http://www.imagemagick.org/Usage/ugs/future/#layout
I would hope such a future operator would also understand virtual offsets. But before that we should get 'justification' (as separate to gravity placement) working properly.
This would be something for IMv7 beta work.
