1

In essence, I'm wondering if there's a solution on the Mac to solve a jigsaw for me. I have several folders of images scraped from a slippy-tile map and want to merge them together into a single image.

One edge should match another edge. If the edges matches several (e.g. they cover a blank white area of the image, deduction from the other edges matching could be used).

I've tried Photomerge in PhotoShop but have come to realise it looks for overlapping areas. This is a distinctly different problem for a computer to solve as the parts that match require a different logic. I've come across some uncompiled CLI tools on GitHub that suggest they do something similar but are way beyond my abilities to get a binary working on a mac.

All my images are at the same resolution. Nothing needs to be scaled or rotated to align. The majority are square ratio images, except for some edge images. Nothing will overlap. The full/sources images (which I can't access) have literally been sliced into many smaller images that I need to reconstruct.

Due to the method jpeg uses to compress, some leeway would be needed for exact pixel matching at edges. In other words, it would need to be able to tolerate approximate pixel matching of areas rather than exact matches, or predict a slight shift in hue or brightness might match as a neighbouring pixel rather than looking for a duplicate. I'm also trying to avoid online solutions as I have dozens of folders containing hundreds of images that need to be aligned and merged.

I think it's easy to understand from the description but here's an example of four images that should clarify the situation I'm in:

enter image description here

Update:

Some further research has found a few CLI tools that provide some solutions in this area for map images. Rather than solving any image matching, they just merge a collection of photos based on clues in the filename about their location.

While my images have been sourced from slippy-map type pages, they aren't actually maps and don't have longitude or latitude relevance that could be extracted from the filename. They do provide clues to their location in their filename but, as mentioned earlier, CLI type programming is way beyond my abilities to create a merged image based on filenames such as:

page=1;zoom=50;rect=512,768,256,256;jpeg.jpg

rect=512,768,256,256 being the pertinent part. It contains the information about where the slice was extracted from, in pixels, from the original. Unfortunately this will become a programming/cli question then, which may be more relevant on the main stackexchange site. I'm hoping there's some existing graphic utility using pixel matching that already solve this. Otherwise I'm in for an even more powerful headache.

Update 2:

I had to abandon this as - with any job - I had only so much time to complete it. For anybody who comes across this in the meantime, you might see from the last update, as well as some comments and answers that the most feasible solution - if you're so inclined as to have a good grasp of programming basics - is to use something like Python or Ruby alongside Imagemagick (or the PIL library if using Python). This is feasible for this situation as the filenames I was using specify the location of where each image has been sliced from the original. We then don't need to concern ourselves with matching image edges at all, we just need to be able to work computer voodoo to make a script that merges images into one based on the coordinates in the filename of each.

With this solution, however, it's beyond graphic design theory or practicalities and into the murky underbelly of programming. If anybody comes across an image utility that manages to avoid this in the future, I'd love if they'd add it as an answer below to help others.

7
  • CLI is not really that difficult, and it's totally worth to learn it. imagemagick can do what you need and they have quite a good help page: imagemagick.org/Usage/montage – AAGD Nov 7 '17 at 13:04
  • @AAGD I use CLI stuff all the time - particularly for GIS - and find it takes me hours to accomplish anything if there's not a similar example I can tweak. I just don't have a natural intuition for it. Funnily enough, I was working on an imagemagick solution just now but was hoping an existing utility was already in place. – biscuitstack Nov 7 '17 at 13:06
  • In PhotoShop you could also try File > Automate > ContactSheet 2 with zero margin and if filenames are in order. – AAGD Nov 7 '17 at 13:21
  • A nice idea, alas, the filenames are as I've shown in the example and provide no sense of order. There's too many files to rename manually. – biscuitstack Nov 7 '17 at 13:29
  • 1
    Sorry, also zero margin wouldn't work anyway... – AAGD Nov 7 '17 at 13:40
0

If they align to a regular rectangular grid, then a quick sort on top, right (512 and 768) would immediately give a tile order. If I was to attempt to automate this, I would probably:

  • run a regexp or write a quick script to to pull the rect=512,768,256,256;jpeg.jpg portion out of the source.
  • remove rect= and find+replace the ; with a , and the path to where the images are
  • import the resultant comma-delimited file into a database

I would now have the information in a form I could process: (select * from table sort by top, right) in order to sort and/or rename the files in a way that allows me to use whatever folder-to-tile image software I choose. It would be fairly trivial to create a query that exports to a text file which I could use to create a command-line to run a process or provide an input file for a process or copy the original files to a temp folder with tile-order filenames (c:\foo\tile_00_00.jpg)

As far as a software option: the montage command for imagemagik might work (http://www.imagemagick.org/Usage/montage/)

1
  • Thanks @Yorik. I think I've got the theory side covered ok. There's many ways of doing this and it's straightforward to think of how to go about doing them, but not how to make workable code in the time I have available (as my programming abilities are pretty horrible). I was hoping there was an existing image matching solution for this, not dissimilar to Photomerge in Photoshop and the reason I put this in a Graphic Design rather than Stack Exchange itself. – biscuitstack Nov 8 '17 at 13:35
0

I realize this is an old question, but it was bumped by the community and doesn't really have a direct answer.

As you know how many images you have in one row , it's pretty simple using imagemagick:

cd "path/to input/folder"
montage -mode concatenate -tile 3x -background 'transparent' *.png ../merged.png
  • -tile 3x defines the number of columns basically. Check the example gif below. 3 images per row.
  • -background 'transparent' is only necessary if you're going from like png to png and you want to retain transparency. Not needed if you're merging jpegs. Remove it if you're going from png to jpeg.
  • *.png makes it look for .png files in the input folder
  • ../merged.png
    • ../ = one folder up from the input folder (image is saved next to input folder)
    • merged = filename
    • .png = output format

Example

I sliced up an image using PS. This is just me making sure we are all on the same page on what the sliced images look like:

enter image description here

Then I ran the command I gave above and this is the result:

enter image description here The slight white fringing was there in the image slices. It's just more apparent in the big merged image against a dark background.

10
  • is this choosing an order based on filenames or actually using some sort of matching algorithm to find neighbouring seams? – biscuitstack Apr 28 '20 at 18:32
  • @biscuitstack just filenames. I feel like you'd need like a sci-fi movie AI to do it otherwise. – Joonas Apr 28 '20 at 18:47
  • I'm afraid the question is concerned with edge-matching rather than filenames. I did cautiously open up the possibility of a solution with filenames but with the caveat that it's pretty impractical (with an example filename) and would be a programming question rather than graphic design then. Interestingly, I disagree with the immensity of the algorithm needed to do this - it wouldn't necessarily even need to be AI - I can think of one logical way of approaching it. – biscuitstack Apr 29 '20 at 9:22
  • @biscuitstack, yea, if whatever exports the slices can't do it in an orderly manner or there's no way to batch rename then afterwards (like by creation date or something), using filenames to decide the order is a no go for sure... Unless you want to manually go through each file renaming them. The issue I see with edge matching is the lack of overlap. There's nothing to really match. I think you said it might have something to do with maps or something and I'm just picturing a map with like a terrain that is basically just a blob of different textures – Joonas Apr 29 '20 at 10:11
  • ...and how it would be just impossible for any kind of algorithm to match the correct edges with 100% success rate. Even an AI or a human would have to guess what goes where. Of course, it does depend on the image a bit, but also if we think of something simpler like the Simpsons logo, the bottom pixels of the first square and the top pixels of the fourth square are not identical because there's no overlap and the S has curves. If we were to divide a plain square into slices, you could probably match the edges, but I don't see it being possible in a real-world scenario. – Joonas Apr 29 '20 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.