Here's a sequence of steps to reproduce an unwanted "feature"...
- take a fragment from the upper right-hand corner of a tiff image
that is greater than 200x200, like so...
convert -depth 8 -gravity NorthEast -crop 100x100+0+0 x1.tif y1.tif
- now try to take a 50x50 fragment frpm that...
convert -depth 8 -gravity NorthEast -crop 100x100+0+0 y1.tif z1.tif
Here's what happens on my machine...
[m3000][waltdnes][~] convert -depth 8 -gravity NorthEast -crop 100x100+0+0
x1.tif y1.tif
[m3000][waltdnes][~] convert -depth 8 -gravity NorthEast -crop 50x50+0+0 y1.tif
z1.tif
convert: geometry does not contain image `y1.tif'.
convert: "XPosition": Information lost writing value (-1) as (unsigned)
RATIONAL. `z1.tif'.
convert: "YPosition": Information lost writing value (-1) as (unsigned)
RATIONAL. `z1.tif'.
After much pounding of head against brick wall, I think I have a clue
about what's happening. If I view y1.tif with mc (Midnight Commander)
it shows the following...
y1.tif TIFF 100x100 100x100+600+0 DirectClass 30kb
So the offset of the fragment in the original file is written into the
metadata. Probably useful if you want to cut up a file, process
different pieces with diffent filters, and then stich it all back
together again. I think what's happening to me is that convert assumes
that the fragment is still part of the original file. So it tries to go
to offset 600,0... in a 100x100 file... oops.
--
Walter Dnes <[EMAIL PROTECTED]> In linux /sbin/init is Job #1
My musings on technology and security at http://tech_sec.blog.ca
_______________________________________________
Magick-users mailing list
[email protected]
http://studio.imagemagick.org/mailman/listinfo/magick-users
