Unwanted gaps between combined PNG images

[fmw42]

What is your version of libpng?

Code: Select all

convert -list format

should tell you that for the line starting with PNG. Look at the end of the line. For me, I have

PNG* PNG rw- Portable Network Graphics (libpng 1.6.35)

If you do not have a current version of libpng, then upgrade.

IM 6.9.0.0 is a bit old, too. Currently it is at 6.9.10.12. So you might want to upgrade Imagemagick.

It would still help to have your input images to test.

[xinmude]

Just checked mine by using "convert -list format" and found the following:

PNG* PNG rw- Portable Network Graphics (libpng 1.6.18,1.6.21)

A colleague of mine has libpng 1.6.29 and has the same problem as I do with PNG images.

I will look to upgrade my ImageMagick.

Many thanks.

[fmw42]

Try upgrading libpng first. See if that helps.

[xinmude]

I am on a macOS High Sierra Version 10.13.4 and just upgraded my ImageMagick to 6.9.9-40 Q16 x86_64 and libpng 1.6.35. I have just repeated everything I presented in earlier posts, and got exactly the same results: There are gaps between different images in combined PNG images, but not in combined JPG images.

Although the gaps are a bit annoying, I can live with it.

Meanwhile, I also found something baffling about the PNG file sizes. I normally save my plots (of curves, bars, scatters, etc. in different colors) in EPS format and then "convert -density {xxx}" (ImageMagick command) them to JPGs and, lately, to PNGs for their much smaller sizes. However, after I combine two or more PNGs into one (using "convert +/-append"), the resulting PNG is larger, sometimes by nearly 50%, than its JPG counterpart.

[snibgo]

... the resulting PNG is larger, sometimes by nearly 50%, than its JPG counterpart.

For some images, PNG gives better compression than JPG. For others, JPG is better.

But if you are getting added borders around appended PNGs, something is wrong.

[fmw42]

Please post your PNG file so we can test to see what is the problem.

Have you tried adding +repage after reading all the png files? There could be some virtual canvas offset remaining in your files that need removing.

[xinmude]

I have not located a photo service website that would not automatically change all uploaded photos to JPEGs.

Meanwhile, I experimented more with JPEGs and PNGs, and found that this is a more complicated issue.

1.) I save my plots into EPS files and convert (ImageMagick command) them to JPEGs, and then combine ("convert +/-append") them into a single JPEG. In this case, there are no gaps between images in the final combined one;

2.) Same as above except JPEGs are replaced with PNGs. In this case, there are gaps in the final combined image;

3.) I first convert my EPS files to JPEGs, then convert them to PNGs, and then combine ("convert +/- append") them into a single PNG. In this case, there are no gaps in the final combined image. And this makes the final PNG several times larger than in Case 2.);

4.) I save my plots directly into JPEGs/PNGs, and then combine ("convert +/- append") them into a single JPEG/PNG. There are gaps in either the final JPEG or PNG.

(Note: The reason I first save my plots into EPS format and then convert them to other format (e.g., JPEG, PNG) is that it creates far better quality plots than saving them directly into JPEGs or PNGs.)

[fmw42]

Please post your PNG file so we can test to see what is the problem. You can use dropbox.com, which will not change them to JPG and then post the URLs. Or just zip your file and then post the URL of the zip file.

[snibgo]

I have not located a photo service website ...

So, don't use a photo service website. Find somewhere to upload files.

1.) I save my plots into EPS files and convert (ImageMagick command) them to JPEGs, ...

Please show use the exact commands you use, and sample EPS files that have this problem. Perhaps they contain thin black borders that appear in only some rasterised versions.

[fmw42]

Snibgo is correct. We need your starting files and commands to get to PNGs or JPEGs. So the PNGs will not be needed. Post the EPS files say on dropbox.com and put the URLs here or zip all the EPS files and post it and the put that URL here.

[xinmude]

Let me try:

im01.eps
https://1drv.ms/u/s!Au5wxS03IZVjbpvM9uQVkyp4Jys

im02.eps
https://1drv.ms/u/s!Au5wxS03IZVjb5iJyNtvQ0EqBpY

The above are the URLs of the two images in EPS format. Hopefully, they work.

The commands I use to convert them to PNGs:
% convert -density 150 im01.eps im01.png
% convert -density 150 im02.eps im02.png
% convert +append im01.png im02.png final_im.png

[fmw42]

First your syntax is not proper, but likely will work on IM 6, since it is more forgiving. Proper syntax for raster images is to read the images first, then settings, then operators, then the output.

Second, your PNG images have some transparent white around the edges, which is what causes the black likes. Turn off alpha and it works. The transparency is likely from the EPS files.

try

Code: Select all

convert im01.png im02.png -alpha off +append result.png

[xinmude]

Just tried the code you provided (with -alpha off) and it works. If I add the option "-geometry x1000", the gap reappears, though.

However, if I apply the option "-alpha off" in the first step to convert the EPS files to PNGs, then I can use the -geometry option without problems. Here are my codes:

Code: Select all

convert -density 150 -alpha off im01.eps im01.png
convert -density 150 -alpha off im02.eps im02.png
convert -geometry x1000 +append im01.png im02.png final_im.png

As you can see, I do not use "-alpha off" in the last line, and the resulting image no longer has those gaps.

Previously, I did not quite know about the "-alpha off" option. Many thanks for your help.

By the way, the order of the options in the code does not seem to matter in my case.

[fmw42]

By the way, the order of the options in the code does not seem to matter in my case.

It would in ImageMagick 7.

[xinmude]

It would in ImageMagick 7.

Is there a good reason to make the order of options matter?

I'd rather the future versions keep the status quo as far as the order of options is concerned.