Legacy ImageMagick Discussions Archive

I have to join 15 images (png with transparency) into a single one (tiled in 5 columns 3 rows, without any space or border). All the images have the same size (256x256).
After reading at http://www.imagemagick.org/Usage/montage/ and searching the net I tried in several ways, the results were:

> montage *.png -tile 5x -background none fileout.png
keeps transparency but the images are resized, output dimensions are less than the sum of the input ones. I expected 1280x768 but I got 640x378.

> montage *.png -tile 5x -geometry +0+0 -background none fileout.png
Adding '-geometry +0+0' gives the correct output size, but adds a black background, even with -background none.

> montage *.png -mode Concatenate -tile 5x fileout.png
Gives white background.

> montage *.png -mode Concatenate -tile 5x -background none fileout.png
Gives black background.

> montage *.png -mode Concatenate -tile 5x -background BLUE fileout.png
> montage *.png -mode Concatenate -tile 5x -background RED fileout.png
Correctly give blue and red background. So seems that '-background' option works, except with 'none' and 'transparent'.

I also tried with convert and various options, but can't get it.
Is there a way to join .png images without resizing them, without adding borders and keeping their original transparency?
I'm using command-line version 'ImageMagick 6.6.5-9 2010-11-15 Q16' on WinXP SP2.
Thanks.

I am having a similar problem with IM 6.6.5-10 Q16 (hdri) MacOSX Tiger

montage logo2t.png logo2t.png logo2t.png logo2t.png -background none -tile 2x -geometry +0+0 logo2t_tmp.png

I think you should report this as a bug.

I don't know if this is related at all to viewtopic.php?f=3&t=16240

ImageMagick seems to be a very good instrument, I'd rather think i'm not able to get it work yet.
If it really is a bug, someone more skilled will tell us.
I read the post you linked. As Anthony said "-compose copy means copy the transparent pixels too" I also tried adding it, but still can't get transparency.
Hi.
-Marco-

DO not use -geometry +0+0 it has special meaning to Montage (concatenation mode)

see Montage, Zero Geometry, caution required
http://www.imagemagick.org/Usage/montage/#zero_geometry

Start with at least -geometry +1+1 if you really don't want gaps between images then use the non-zero geometry -geometry '1x1+0+0<'. This means only resize images smaller than 1x1 which is plainly impossible so no resize is performed, and you get zero spacing gaps.

Eventually I hope to be able to use the equivalent montage style arrays of images (and many other styles) using some form of "convert" image processing option, (see Future proposals, Image layout methods).

Anthony,

In my case the -geometry was not the issue (ie spacing), it was total loss of transparency. The input image (used 4 times) was created by

convert logo: -resize 50% -transparent white logo2t.png

but after the montage, all I got was a black background. All the transparency had turned black. The positioning of the images seemed fine.


Fred

Then it is probably the current problem with PNG images. Did you have a look using show: or pipe a miff: image into display? That is see if the image actually had transparency. As the background was black then that is probably what is going on.

anthony wrote:Then it is probably the current problem with PNG images. Did you have a look using show: or pipe a miff: image into display? That is see if the image actually had transparency. As the background was black then that is probably what is going on.

You are right. This works fine and keeps the transparency.

montage logo2t.png logo2t.png logo2t.png logo2t.png -background none -tile 2x -geometry +0+0 miff:- | convert - show:

whereas for this the transparency turns black.

montage logo2t.png logo2t.png logo2t.png logo2t.png -background none -tile 2x -geometry +0+0 logo2t_tmp.png

but this also works I now see:

montage logo2t.png logo2t.png logo2t.png logo2t.png -background none -tile 2x -geometry +0+0 PNG32:logo2t_tmp.png

Yes the problem appears to be with the newly implements internal automatic conversion to a smaller 'palette' PNG when number of colors are small. However it is not clear if the special semi-transparency addition was added to the PNG palette form in the coder.

Of course if anyone can add it, Glen would be the one to do it.

I can confirm that this is working fine for joining png with transparency:
montage *.png -background none -tile 4x -geometry +0+0 PNG32:OUT.png
Thanks a lot guys, for finding the solution.

I've tried starting from the simpliest command without options, trying to understand how montage works:

montage *.png OUT.png
white background, images spaced and resized, automatically tiled depending on the number of the images

montage *.png -tile 4x OUT.png
white background, images spaced and resized, tiled as desired (4x)
I really can't understand why joining 4x3 images of 256x256 gives an output image of 512x378 instead of 1024x768 (tiling 4x4 gives 512x504 instead of 1024x1024). Is there any default resizing option?
Seems to apply an automatic resizing factor of 0.5 in the X direction and of 0.4921875 in the Y direction.
I think in this case the user expects the images to be tiled side by side without resizing, especially when all of them are simply squares of 256x256.

montage *.png -tile 4x -background none OUT.png
transparent background, images spaced and resized

montage *.png -tile 4x -background none -geometry +0+0 OUT.png
black background, images NOT spaced and NOT resized

montage *.png -tile 4x -background none -geometry +0+0 PNG32:OUT.png
transparent background, images NOT spaced and NOT resized. That's it!

So seems that the -geometry +0+0 option also changes the output image type to one which doesn't support transparency, in fact adding PNG32: the output file size grows from 165Kb up to 255Kb.

So seems that the -geometry +0+0 option also changes the output image type to one which doesn't support transparency, in fact adding PNG32: the output file size grows from 165Kb up to 255Kb.

PNG32 forces a 32-bit truecolor representation rather than an 8-bit pseudocolor 8-bit alpha (binary alpha should work), so the file size will be much larger. Seems like IM cannot produce the latter. see http://www.imagemagick.org/Usage/formats/#png_formats

You could report as a bug on the Bugs forum and see what Glennrp says about where he is in fixing that.

ImageMagick-6.6.6.1 seems to be behaving reasonably:
resulting in

• -rw-r--r-- 1 glennrp glennrp 158635 2010-11-29 13:58 p23q16png32.png
  -rw-r--r-- 1 glennrp glennrp 282149 2010-11-29 13:58 p23q16png.png
  -rw-r--r-- 1 glennrp glennrp 158635 2010-11-29 13:58 p23q8png32.png
  -rw-r--r-- 1 glennrp glennrp 158635 2010-11-29 13:58 p23q8png.png
  lrwxrwxrwx 1 glennrp glennrp 10 2010-11-29 13:58 logo2t00.png -> logo2t.png
  lrwxrwxrwx 1 glennrp glennrp 10 2010-11-29 13:58 logo2t01.png -> logo2t.png
  etc.

The one is larger because it contains 16-bit samples. The rest contain 8-bit samples.
All of them look OK wth regard to transparency.

Glenn,

This is working correctly, now, (IM 6.6.6.1 Q16 HDR Mac OSX Tiger) to keep transparency in a palette PNG with binary transparency; whereas before it turned transparency black

montage logo2t.png logo2t.png logo2t.png logo2t.png -background none -tile 2x -geometry +0+0 logo2t_tmp.png

Thanks for fixing it.

Fred

@Fred, you're welcome. Also, Cristy has fixed a typo in my bugfix
code that was causing the one file to be too large. Should be OK in 6.6.6-3.