How can I stop the “montage -tile 3x3” command from cropping the output?

[ProGamer]

I take an image and chop it into 9 equally sized tiles. Each tile is run through a process that increases it's resolution (For example 289x289 to 768x768). All 9 tiles slightly overlap each other based on a specific hard-coded value.

The issue however is that when the modified tiles are put back together into the original image. ImageMagick seems to crop the new output made of the modified tiles. All the tiles appear to be perfectly positioned, and thus I can't figure out why ImageMagick crops the final output, let alone how I can stop it.

This is the original image before it's chopped into 3x3 overlapping tiles:

https://i.imgur.com/TPWygd0.jpg

This is the final output composed of the modified tiles:

https://i.imgur.com/8ENBJsw.jpg

How can I prevent ImageMagick from cropping this output? Is it possible to disable cropping?


The code used to put the modified tiles back together, is shown below:

Code: Select all

# 6. merge feathered tiles
    montage $feathered_dir/$clean_name'_0.png' $feathered_dir/$clean_name'_1.png' \
                    $feathered_dir/$clean_name'_2.png' $feathered_dir/$clean_name'_3.png' \
                    $feathered_dir/$clean_name'_4.png' $feathered_dir/$clean_name'_5.png' \
                    $feathered_dir/$clean_name'_6.png' $feathered_dir/$clean_name'_7.png' \
                    $feathered_dir/$clean_name'_8.png'  -tile 3x3 -geometry -$border_w-$border_h $output/$clean_name.large_feathered.png


    # 7. merge un-feathered tiles
    montage $tiles_dir/$clean_name'_0.png' $tiles_dir/$clean_name'_1.png' \
                    $tiles_dir/$clean_name'_2.png' $tiles_dir/$clean_name'_3.png' \
                    $tiles_dir/$clean_name'_4.png' $tiles_dir/$clean_name'_5.png' \
                    $tiles_dir/$clean_name'_6.png' $tiles_dir/$clean_name'_7.png' \
                    $tiles_dir/$clean_name'_8.png'  -tile 3x3 -geometry -$border_w-$border_h $output/$clean_name.large.png

The specific script can be found here: https://github.com/ProGamerGov/Neural-T ... s_tiled.sh

This command reproduces the same issue:

Code: Select all

montage IMG_3926_0.png IMG_3926_1.png IMG_3926_2.png IMG_3926_3.png IMG_3926_4.png IMG_3926_5.png IMG_3926_6.png IMG_3926_7.png IMG_3926_8.png -tile 3x3 -geometry -68.8151-68.8151 out_correct_geometry.png

Stackoverflow post: https://stackoverflow.com/questions/416 ... ropping-th

[fmw42]

Just a guess, but your tile cropping has an overlay 3x3+50+50@, which might(?) be removing some of the data from the tiles around the edges. Have you looked at each of the (border) tiles that are cropped to see if they contain all the data?


What is your IM version and platform? If old, perhaps you need to upgrade.

[ProGamer]

Just a guess, but your tile cropping has an overlay 3x3+50+50@, which might(?) be removing some of the data from the tiles around the edges. Have you looked at each of the (border) tiles that are cropped to see if they contain all the data?

Yes, I have visually verified that the modified tiles aren't missing parts. You can see an example with this modified tile here: https://i.imgur.com/MVnrlbw.png. I drew an arrow in MS Paint that points towards a recognizable part of the image that gets cropped out by montage. All of the modified tiles can be found here: https://imgur.com/a/dX6o2



This issue seems to occur on every final output composed of the modified tiles. And thus far I haven't had success in preventing/avoiding/fixing the issue.

[ProGamer]

I also added "-debug All" to the problematic command in my script, and recorded the output here: https://gist.github.com/ProGamerGov/c99 ... 32c6809a21

And I am using ImageMagick version 6.8.9-9, according to the debug output. The OS is a 64bit Ubuntu AWS AMI. Ubuntu version 16.04. Another user of the script reported the same cropping issue while running OSX/Mac OS X (Or whatever Apple computers use for their OS).





I have seen your overlapping crop script here: http://www.fmwconcepts.com/imagemagick/ ... /index.php, but I was unable to tell if your "montage" feature had the same issue/flaw?

[fmw42]

Does it happen if you do not do overlapping and just crop, resize and montage?

Were you able to look at each cropped tile of one image after your cropping command and see if all the data was there. If it is hard to see whether all the data is there, then tile crop a gradient image and check the graylevels of the border tiles.

[fmw42]

P.S. The use of negative values in -geometry in montage was not designed. I found that it worked to make an overlap. But I never checked to see if due to the negative value, it would trim part of the montaged result. So it is conceivable the there is an issue. It may be there, but is not a bug in the sense of it was designed to handle negative values. So I cannot say if it can be fixed or not. That would be up to a developer.

But first, you need to figure out if it is due to the cropping or to the montage.

[fmw42]

I am not sure -crop was intended to use both % and @ at the same time. I seem to get inconsistent results, which are not all equal size. When I crop a 512x512 image with -crop 2x2+50+50%@, I get 121 tiles of unequal size for the side tiles. When I crop the rose: image with the same, I get only one image resulting. So perhaps you are not getting the odd sized border tiles when you tell montage which images to combine.

How many tiles are you really getting from your crop? Is it only an array of 3x3, which is what you are putting into montage -tile 3x3? Perhaps you have more tiles from your crop and you are not using those, since you expect only 3x3 set of tiles.

[ProGamer]

P.S. The use of negative values in -geometry in montage was not designed. I found that it worked to make an overlap. But I never checked to see if due to the negative value, it would trim part of the montaged result. So it is conceivable the there is an issue. It may be there, but is not a bug in the sense of it was designed to handle negative values. So I cannot say if it can be fixed or not. That would be up to a developer.

But first, you need to figure out if it is due to the cropping or to the montage.

With the following command:

Code: Select all

montage IMG_3926_0.png IMG_3926_1.png IMG_3926_2.png IMG_3926_3.png IMG_3926_4.png IMG_3926_5.png IMG_3926_6.png IMG_3926_7.png IMG_3926_8.png -tile 3x3 -geometry 699.1849x699.1849 test_4.png

The resulting image has the tiles not overlapping correctly, but there is no cropping of the output composed of the modified tiles:

https://i.imgur.com/fo9TDfN.jpg

Using the -border command with the montage command, the output composed off the modified tiles is still cropped, but it's not cropped as much as the final output from the unmodified script:

https://i.imgur.com/T5eiI5i.jpg



Using the following convert command:

Code: Select all

convert \( IMG_3926_0.png IMG_3926_1.png IMG_3926_2.png +append +smush -68.8151 \) \
\( IMG_3926_3.png IMG_3926_4.png IMG_3926_5.png +append +smush -68.8151 \) \
\( IMG_3926_6.png IMG_3926_7.png IMG_3926_8.png +append +smush -68.8151 \) \
-background none -append +smush -68.8151  convert_append_tiles.png

This is the result: https://i.imgur.com/1orBtjq.jpg, and it seems that there is no cropping of the output composed of the modified tiles.

[fmw42]

-geometry 699.1849x699.1849

Resizing with -geometry in montage is not a good idea. I do not think it works properly and Anthony has suggested not to do it in his notes. If you need to resize, then do it first and save or resize using convert and pipe the results to montage.

Yes, -smush is an option, but I think the downside is that you have to do each row separately and then -smush on the rows to make the whole image.

Don't use +-append and +-smush at the same time? Perhaps I misunderstand. append is the same as -mush except it won't overlap as -smush will. You just need +-smush. I could be wrong, but I do not think you will get fractional pixel offsets. The will probably be rounded or truncated to integers.

[ProGamer]

I am not sure -crop was intended to use both % and @ at the same time. I seem to get inconsistent results, which are not all equal size. When I crop a 512x512 image with -crop 2x2+50+50%@, I get 121 tiles of unequal size for the side tiles. When I crop the rose: image with the same, I get only one image resulting. So perhaps you are not getting the odd sized border tiles when you tell montage which images to combine.

How many tiles are you really getting from your crop? Is it only an array of 3x3, which is what you are putting into montage -tile 3x3? Perhaps you have more tiles from your crop and you are not using those, since you expect only 3x3 set of tiles.

There are exactly 9 tiles created by the crop. Though there was the slight issue that the unmodified tiles were ever so slightly different sized.

For example, the tiles arranged in the intended 3x3 pattern, had this pattern for their resolution (I specified an image size of 1000 for this test):

Code: Select all

677x1000 680x1000 677x1000
679x1000 682x1000 679x1000
677x1000 680x1000 677x1000

The corresponding time number, and it's resolution:

Code: Select all

0: 677x1000 
1: 680x1000 
2: 677x1000
3: 679x1000 
4: 682x1000 
5: 679x1000
6: 677x1000 
7: 680x1000 
8: 677x1000

I solved the issue by using the following code in the script:

Code: Select all

#Resize all tiles to avoid ImageMagick weirdness
	 convert $out_dir/$clean_name'_0.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_0.png'
	 convert $out_dir/$clean_name'_1.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_1.png'
	 convert $out_dir/$clean_name'_2.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_2.png'
	 convert $out_dir/$clean_name'_3.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_3.png'
	 convert $out_dir/$clean_name'_4.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_4.png'
	 convert $out_dir/$clean_name'_5.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_5.png'
	 convert $out_dir/$clean_name'_6.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_6.png'
	 convert $out_dir/$clean_name'_7.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_7.png'
	 convert $out_dir/$clean_name'_8.png' -resize "$w2"x"$h2"\! $out_dir/$clean_name'_8.png'	 					
					#WxH

The fix was basically resizing each of the 9 images so that the height and width were that of the first tile. I came up with this fix after testing many different sized input images, and I assumed it was bug in ImageMagick's code as the pattern was easily reproducible.

The issue if it's not caused by my ImageMagick crop output size fix, is related to trying to put the tiles back together, and not the tiles themselves.

[ProGamer]

-geometry 699.1849x699.1849

Resizing with -geometry in montage is not a good idea. I do not think it works properly and Anthony has suggested not to do it in his notes. If you need to resize, then do it first and save or resize using convert and pipe the results to montage.

Yes, -smush is an option, but I think the downside is that you have to do each row separately and then -smush on the rows to make the whole image.

Don't use +-append and +-smush at the same time? Perhaps I misunderstand. append is the same as -mush except it won't overlap as -smush will. You just need +-smush. I could be wrong, but I do not think you will get fractional pixel offsets. The will probably be rounded or truncated to integers.

The same command without using "smush", resulted in the exact same output image as the command with "smush":

Code: Select all

convert \( IMG_3926_0.png IMG_3926_1.png IMG_3926_2.png +append  \) \
\( IMG_3926_3.png IMG_3926_4.png IMG_3926_5.png +append  \) \
\( IMG_3926_6.png IMG_3926_7.png IMG_3926_8.png +append  \) \
-background none -append  convert_append_tiles.png

I was basically just trying everything in the hopes that I could gain more insight into what was causing the issue. This is also why I tried to exploit -geometry's size feature that the guide said not to use. The issue has existed for so long, and many people have tried and failed to solve it, so I was really just hoping I would get lucky.

[ProGamer]

The person who initially confirmed the issue on their OSX/Mac OS X, believes that creating a border around the outer sides of the 8 outside images, could help prevent the cropping from occurring, but I have no idea if such a solution would work, or even how to test this solution.

[fmw42]

My guess is that montage does trim the tiles on the right and bottom due to the negative offset. If you think about how it works, you take the first tile and trim the offset from the right of it. Then you add the next tile to its right so that it merges properly. This continues to the last tile on the right. But montage was not expecting negative offsets, so it treats the last tile just like the others and trim its right side as if another tile would be added. That is it is not taking into account that it is the last tile on the right and doing something special to avoid the trim on its right side so as to keep its full tile size.

[fmw42]

Actually, the negative offset is not working the way I envisioned. You can see that from:

Code: Select all

montage rose: rose: -tile 2x1 -geometry -20+0 rose2.png

vs.

Code: Select all

montage rose: rose: -tile 2x1 -geometry +20+0 rose1.png

I think the negative offset is being doubled.

If I do

Code: Select all

montage rose: rose: -tile 2x1 -geometry -10-0 rose3.png

You can see that the overlap is too far to the left and that the right side of the second tile is cropped on its right side.

So it does seem that montage with negative offsets does overlap, but since it was not designed to do so, it works in an odd manner.

[fmw42]

My overlapcrop script, keeps track of the tile offsets in the virtual canvas. And since I did not scale the tiles, they should fit perfectly back together using convert (not montage) without any trimming. I do not know if IM will modify the virtual canvas values if the tiles are resized.