$ convert +append WorldMap-A_non-Frame.png WorldMap-A_non-Frame.png WorldMap-A_non-Frame.png /tmp/threeworlds.png $ convert -crop 7980x3980+7956+0 /tmp/threeworlds.png world-tiled.png
The first command is to replicate the map so that the larger crop window can grab the 8 columns of pixels of the East and paste them west of the West, and the same for the opposite edge of the image.
Now I thought it would be simple to view a window of this map, scaled down by some integer factor. A degenerate case is to view the whole map, at a 1:1 scaling:
$ convert -crop 7980x3980+0+0 -scale 399x199 world-tiled.png /tmp/wf.png $ file /tmp/wf.jpeg /tmp/wf.jpeg: JPEG image data, JFIF standard 1.01, resolution (DPCM), density 28x28, segment length 16, baseline, precision 8, 1x199, frames 3
I'm tearing my hair out trying to figure out why world-tiled.png crops this way, but WorldMap-A_non-Frame.png crops exactly as expected when I notice one Internet search result using the
convert(1). Combined with some warnings I saw while flailing about with random geometry specifications:
$ convert world-tiled.png -crop 7900x3900+0+0 /tmp/wf.jpeg convert: geometry does not contain image `world-tiled.png' @ warning/transform.c/CropImage/674.
I start to wonder if there's some metadata in PNG files that
file(1)doesn't report, that characterizes the coordinate system reference frame for the pixel data. Indeed, when I load world-tiled.png in GIMP, it prompts me whether I want to keep the image offset or ditch it.
I ditch the offset of course, let GIMP overwrite the image, and since then my image crops as expected. Side benefit: GIMP seems to compress the image harder, although that may just be a difference in defaults.