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

[ProGamer]

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.

Can various ImageMagick commands/parameters be used to compensate for the oddities of using negative montage overlap?






Using

Code: Select all

montage -tile 3x3 *.png -geometry -68.8151+0 test_1.png

Only the the right and left side of the output image are cropped/trimmed:

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


When trying the opposite of the above command:

Code: Select all

montage -tile 3x3 *.png -geometry +0-68.8151 test_2.png

Only the top and bottom of the output image are cropped/trimmed.

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


When both -geometry values are 0, then the resulting output has no cropping/trimming on any of the sides:

Code: Select all

montage -tile 3x3 *.png -geometry +0+0 test_3.png

https://i.imgur.com/62Qdnp9.jpg

Which means the geometry command's negative values are responsible for the cropping/trimming.

[fmw42]

Can various ImageMagick commands/parameters be used to compensate for the oddities of using negative montage overlap

Not that I know, since negative offsets were never designed for montage.

[fmw42]

Your best approach is to continue to use -smush.

[ProGamer]

Your best approach is to continue to use -smush.

Using -smush with the convert command? Or how would I use -smush to achieve the behavior I am looking for?

[fmw42]

Use -+smush as you did before with convert. But do not include -+append. Smush each row of images with +smush. Then smush all the resulting rows with -smush. Before processing your resized image, just take a smaller test image and crop it as before, then try to put it back together with the smush commands.

[ProGamer]

Use -+smush as you did before with convert. But do not include -+append. Smush each row of images with +smush. The smush all the resulting rows with -smush. Before processing your resized image, just take a smaller test image and crop it as before, then try to put it back together with the smush commands.

It appears this method works!

Code: Select all

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

And the resulting output image:

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

I don't think I set the smush values exactly right in the above image, but it's proof that what I am trying to do is more than possible!

[ProGamer]

Any suggestions on how to calculate the -smush value if I know the -geometry value?

[fmw42]

If the geometry is in pixels, then it should be the same as the smush value. If the geometry is in %, then you may have to convert % for your original image for both width and height and use pixels for smush. Smush does accept %, but it may not be the same since the tiles are now smaller. Thus I think you need to convert to pixels.

[ProGamer]

For the old final output, I layered a feathered Image on top of a non-feathered image, and it produced a result where the "fading into white" effect caused by the feathering, disappears. This step resulted in the original final output: https://i.imgur.com/8ENBJsw.jpg

When using the new -smush method for combining the tiles, the "fading into white" effect caused the feathering only disappears on the vertical side of the inside portion of image composed of the modified tiles. The "fading into white" effect on the horizon sides, and the entire border of the newly created output image, remains even with the layering process. The current final output can be seen below:

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

The code that does this, remained the same for both the old and the new final outputs:

Code: Select all

# 9. Combine feathered and un-feathered output images to disguise feathering.

	composite $output/$clean_name.large_feathered.png $output/$clean_name.large.png $output/$clean_name.large_final.png

I assume that this new issue is caused by a lack of saving the transparency while the modified feathered tiles are being combined into the final feathered output.

This is the code that creates the feathered output:

Code: Select all

# 7. Smush the feathered tiles together
	convert \( $feathered_dir/$clean_name'_0.png' $feathered_dir/$clean_name'_1.png' $feathered_dir/$clean_name'_2.png' +smush -$smush_value_w \) \
	\( $feathered_dir/$clean_name'_3.png' $feathered_dir/$clean_name'_4.png' $feathered_dir/$clean_name'_5.png' +smush -$smush_value_w \) \
	\( $feathered_dir/$clean_name'_6.png' $feathered_dir/$clean_name'_7.png' $feathered_dir/$clean_name'_8.png' +smush -$smush_value_w \) \
	-background none -smush -$smush_value_h  $output/$clean_name.large_feathered.png

The code that "feathers" the tiles, is:

Code: Select all

	# 6. Feather the tiles
	feathered_dir=$out_dir/feathered
	mkdir -p $feathered_dir
	for tile in `ls $tiles_dir | grep $clean_name"_"[0-9]".png"`
	do
		tile_name="${tile%.*}"
		convert $tiles_dir/$tile -alpha set -virtual-pixel transparent -channel A -morphology Distance Euclidean:1,50\! +channel "$feathered_dir/$tile_name.png"
	done

What am I missing here?

[ProGamer]

Using the following code:

Code: Select all

convert \( IMG_3926_0.png IMG_3926_1.png IMG_3926_2.png +smush -137.6302 -alpha set -virtual-pixel transparent -background transparent \) \
\( IMG_3926_3.png IMG_3926_4.png IMG_3926_5.png +smush -137.6302 -alpha set -virtual-pixel transparent -background transparent \) \
\( IMG_3926_6.png IMG_3926_7.png IMG_3926_8.png +smush -137.6302 -alpha set -virtual-pixel transparent -background transparent \) \
-smush -137.6302 -alpha set -virtual-pixel transparent -background transparent  convert_append_tiles_f.png

Creates this output: https://i.imgur.com/qHJmEWs.jpg

And then layering it over top of the non-feathered output results in this: https://i.imgur.com/UzN40Rm.jpg

But I cannot figure out why the top 3 tiles have a white background instead of the intended transparency. Any ideas as to what is causing the top 3 to loose their transparency?

[ProGamer]

I figured out the issue.

After removing "-background transparent" from the top 3 0,1,2 tiles, the second row lost it's transparency: https://i.imgur.com/zWBwVT3.jpg

Code: Select all

convert -background transparent \( IMG_3926_0.png IMG_3926_1.png IMG_3926_2.png +smush -137.6302 -alpha set -virtual-pixel transparent -background transparent \) \
\( IMG_3926_3.png IMG_3926_4.png IMG_3926_5.png +smush -137.6302 -alpha set -virtual-pixel transparent -background transparent \) \
\( IMG_3926_6.png IMG_3926_7.png IMG_3926_8.png +smush -137.6302 -alpha set -virtual-pixel transparent -background transparent \) \
-smush -137.6302 -alpha set -virtual-pixel transparent -background transparent  convert_append_tiles_f.png

Adding the "-background transparent" command to before the first 3 tiles of the first row, made them transparent: https://i.imgur.com/IP3HEBV.jpg

[fmw42]

Put -background transparent before -smush. I am not sure you even need worry about the virtual-pixel. Remove -alpha set also

try

Code: Select all

convert \
\( IMG_3926_0.png IMG_3926_1.png IMG_3926_2.png -background transparent +smush -137.6302 \) \
\( IMG_3926_3.png IMG_3926_4.png IMG_3926_5.png -background transparent +smush -137.6302 \) \
\( IMG_3926_6.png IMG_3926_7.png IMG_3926_8.png -background transparent +smush -137.6302 \) \
-background transparent -smush -137.6302 convert_append_tiles_f.png

[ProGamer]

So I take the overlap (crop) value that I used, and try to calculate the new overlap value for use by -smush. But for whatever reason, my code only gets me close the real -smush value, and not the exact -smush value. Any ideas as to why?

I can figure out where I am screwing up the math for the -smush value.

I get the height and width of the tiles I cropped out of my starting image:

Code: Select all

original_tile_w=`convert $out_dir/$clean_name'_0.png' -format "%w" info:`
original_tile_h=`convert $out_dir/$clean_name'_0.png' -format "%h" info:`

All the original tiles are resized so that they are equal in size:

Code: Select all

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

I get the height and width of the processed tiles (which should be larger than the original tiles):

Code: Select all

upres_tile_w=`convert $tiles_dir/$clean_name'_0.png' -format "%w" info:`
upres_tile_h=`convert $tiles_dir/$clean_name'_0.png' -format "%h" info:`

I specify the "overlap" value (The value I used to crop the image into tiles) future code to use:

Code: Select all

overlap_w=50
overlap_h=50

I calculate the difference between the original tiles, and the new tiles for both the height and width:

Code: Select all

tile_diff_w=`echo $upres_tile_w $original_tile_w | awk '{print $1/$2}'`
tile_diff_h=`echo $upres_tile_h $original_tile_h | awk '{print $1/$2}'`

I then calculate how much the overlap should have increased on the processed tiles for both the height and width:

Code: Select all

overlap_diff_w=`echo $overlap_w $tile_diff_w | awk '{print $1*$2}'`
overlap_diff_h=`echo $overlap_h $tile_diff_h | awk '{print $1*$2}'`

Then finally to calculate the -smush value, I add the overlap change to the original overlap value:

Code: Select all

smush_value_w=`echo $overlap_w $overlap_diff_w | awk '{print $1+$2}'`
smush_value_h=`echo $overlap_h $overlap_diff_h | awk '{print $1+$2}'`

But this code does not put the image back together correctly. It looks like it's close-ish to putting the image back together, but I can't figure out my mathematical error.

All the -smush values for when I put the image back together, are made negative like this:

Code: Select all

-smush -$smush_value_w 
-smush -$smush_value_h

[ProGamer]

I was able to simplify the code and make it work correctly with the code below:

Code: Select all

#Perform the required mathematical operations:	

	upres_tile_w=`convert $tiles_dir/$clean_name'_0.png' -format "%w" info:`
	upres_tile_h=`convert $tiles_dir/$clean_name'_0.png' -format "%h" info:`

	overlap_w=50
	overlap_h=50
	
	tile_diff_w=`echo $upres_tile_w $original_tile_w | awk '{print $1/$2}'`
	tile_diff_h=`echo $upres_tile_h $original_tile_h | awk '{print $1/$2}'`

	smush_value_w=`echo $overlap_w $tile_diff_w | awk '{print $1*$2}'`
	smush_value_h=`echo $overlap_h $tile_diff_h | awk '{print $1*$2}'`

So now the project works exactly how I wanted/intended it to work! https://github.com/ProGamerGov/Neural-Tile

Thank you so much for the help fmw42!

[fmw42]

You can save a little time by adding -ping right after convert in your extraction of w and h. In fact you can get both from the same read of the input image by using

Code: Select all

wxh=`convert -ping $tiles_dir/$clean_name'_0.png' -format "%wx%h" info:`
w=`echo "$wxh" | cut -dx -f1`
h=`echo "$wxh" | cut -dx -f2`