How to Segement a Large Image into a 2x2 array of images ?

[Bonzo]

Crop an image into 200 x 200 pieces - you do get a remainder if the original
does not divide exactly.

convert original_image.jpg -crop 200x200 image-%d.jpg

The images will be in the format: image-0.jpg, image-1.jpg etc.

No overlap - to do that you would probably need to do multiple crops instead.

[fmw42]

For no overlap and image width and height each divisible by 2, see http://www.fmwconcepts.com/imagemagick/ ... .php#crop2

To get overlap, you need to do each crop separately, but here is the easy way to take a 256x256 image an crop into 4 corners of size 150x150 each (thus overlap) by using -gravity

mandril3.jpg



convert mandril3.jpg -gravity northwest -crop 150x150+0+0 +repage mandril3_nw150.jpg
convert mandril3.jpg -gravity northeast -crop 150x150+0+0 +repage mandril3_ne150.jpg
convert mandril3.jpg -gravity southeast -crop 150x150+0+0 +repage mandril3_se150.jpg
convert mandril3.jpg -gravity southwest -crop 150x150+0+0 +repage mandril3_sw150.jpg

[anthony]

Crop an image into 200 x 200 pieces - you do get a remainder if the original
does not divide exactly.

I would like to see a special 'dividing into NxM tiles' type operator that lets you specify the number of tiles. Of course some tiles may be one pixel larger or smaller than other tiles (evenly distributed).

For example divide a 10 pixel image into 3 should produce tile images of
3 pixels at offset 0
4 pixels at offset 3
3 pixels at offset 7


A dedicated tile generating operator like that can posibly include 'overlap' amounts (probably as a '+X+Y' argument addition

So the question becomes how should you divide a 10 pixel image into 3 with a 3 pixel overlap
between tiles? What maths should be followed to generate 3 tiles of about the same size
but with 3 pixel overlaps?

Experimentally that should result in a image
5 pixels at offset 0
6 pixels at offset 3
5 pixels at offset 5

But how would you calculate those image sizes an offsets to have a 3 pixel overlap?

If we can figure out that, then we have a chance of working out a method of tile cropping to produce NxM tiles with a +X+Y overlap.

Note that like a tile -crop the resulting tiles should still remember the offset' they were extracted from so that after processing they can be restored appropriately.

PS see old notes on this in Equalized Sub-division

[fmw42]

Why not start simple with something say called tiled-crop, that just crops the same size and with a given offset. The last column and row might not be the same size as all the rest.

convert image.png -tiled-crop 100x100+50+50 croppedimage_%d.png

This would simply make 100x100 pixel images with 50 pixel overlap in each direction from the input.


Another idea is an array crop of 1, 2 or 3 images per dimension. That can be reasonably scripted using the method I suggested above using -gravity, since -gravity allows up to 9 orientations. This way one gets an array from 1, 2, 6 or 9 potentially overlapping subsections oriented relative to the corners, mid-sides and/or center.

convert image.png -array-crop 100x100+2+3 overlappedimage_%d.png

This would produce 100x100 sized images in a 2x3 array, overlapping if the image is not divisible by 2 and 3 respectively if the image is smaller than 200x300 or non-overlapping images if the image is larger than 200x300.

[anthony]

Why not start simple with something say called tiled-crop, that just crops the same size and with a given offset. The last column and row might not be the same size as all the rest.

convert image.png -tiled-crop 100x100+50+50 croppedimage_%d.png

This would simply make 100x100 pixel images with 50 pixel overlap in each direction from the input

the point was not to specify the final size of the image but the number of tiles wanted, and let IM try its best to equally divide the image into that many rows and columns. The tiles will not be perfectlky equal in size but should be no more than one pixel difference between the largest and smallest tile.

The overlap part is an extra. In any case I figured it out. Just do all calculationf of tile bounds in floating point then only at the last step round it up or down to nearest integer. See the link I gave above (bugs future) for my write up (on my test site now).

Seems to work. It just needs to be encoded, (if I can get the time, which I never seem to have).

[fmw42]

I understand, but just suggested something simple, easy to use in a limited way. Specifying size and offset is one simple method rather than trying to optimize the sizes. All these methods could be useful.