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:
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.
