Photomosaics

Mosaics are pictures that consist of tiles (from broken pottery originally). These tiles are arranged in a pattern or they form a picture. In Photomosaic these tiles consist of photographs. There are different types of mosaics out there. However, I am only talking about photo mosaics where I follow my own, rather strict set of rules:

No tile may be used more than once
No tile may be mirrored
No tile may be turned
No tile may be broken further
No tile may be colour-adapted (except for use in B&W photo mosaics)

I know some people think this is too tough, but it is my philosophy for photo mosaics. There are several programmes out there that do a really good job in creating photomosaics. A good (but still incomplete) comparison can be found here: www.aolej.com/mosaic/compare.htm. I have had good success with www.djuga.net/retriever.html. Although primarily a picture viewer and organiser, it has a mosaic function that offers some useful options. However, for what I had in mind, none of the software I found was suitable. I wanted to have not only total control over the images, I also wanted to know which files is used as a tile where. So, I programmed my own software.

The 2005 version

But which language to use? As I have not yet(?) learned any of the C languages, I'd be stuck with Visual Basic or JavaScript. Not very suitable for this. Luckily, the third language I know, Matlab, is up to the task. As I am working at university, I have access to Matlab. It required lots of coding as it was surprisingly difficult to find a good algorithm for image similarity. First tries were rather devastating. After I solved that, the next task was making it user-friendly. The process is as follows:

User chooses master image.
User says how many tiles there should be per line [x].
Programme resizes master images accordingly to have no "dead" areas.
Master image gets devided into x-by-y cells.
User chooses [n] source images for the tiles.
User decided between colour or B&W result.
Programme reads n images and computes similarity with x-by-y cells => x-by-y-by-n matrix.
In the order of largest standard deviation within one cell, the cells get filled with resized tile images, always using the best match.
after this has finished, the user is presented the finished photomosaic
the user can now click on any tile and is presented a new window, displaying the ten best matches for this particular cell and the computed similarities.
the user can replace the originally chosen tile with any of these ten tiles.
save mosaic to HDD

Things might stop here, or not...

SuperTiling: a user configurable number of tiles get printed into one SupaTile
LargeScaling: By making use of the large source files, a really large mosaic file is written. This is really only a RAM-saving way of using a large master image - overall the mosaic will be limited by system RAM.
Create a mouse-over image map for HTML (implemented in next version)

Start with the image we are trying to create a mosaic of:

After some minutes of reading in tile images and 1 hour of computing we get a mosaic (of same size):

(original is 2508 x 3483 = 8.75 Megapixel)
You can find some of the used images on my New Zealand webpage.

An example of a downsized Supertile:
(original is 2560 x 3840 = 9.8 Megapixel)

And a look how the final mosaic fits into my flat:

I ordered prints from 60 Supatiles (some where pretty blank, others completely filled), had 8x4 small tiles on each Supertile. Then I bought 4mm wood and glued the Supertiles onto it and trimmed the wood.

The 2008 version

The 2005 code worked well, but it had one really problematic restriction: All the images needed to be of the same aspect ratio. But, after my last trip to New Zealand, I had various aspect ratios I would want to use. So in 2007, I set out to write a new code.
Going completely free with the dimensions of the tiles would be great, but I had no idea how to do this. I therefore opted for identical height and scaled width of the tile images. I reduce all possible tile images to a common height. Then, starting at one row, I compare each tile image with the respective master image and choose the best-fitting one. The "match" is basically the difference between tile and the respective section of the master image, weighted by the tile's area.
As an additional function, the code can generate an html page where the individual tiles link back to webpages that display it larger.

I used this code for the first time to create a mosaic of the "365 days" self portrait project of a friend and I used the extra feature to link back to the flickr photopages using an image map.

All the tiles are links to Keitha's profile and the respective photo. Hover over a tile to see the name of the shot - I am sorry that this way of displaying is not very useable on mobile screens. The tiles and tile source images are copyright by Keitha.

The 2017 version

The 2008 version still was rather restrictive - it was based on rows, which means that vertical photos get less area than horizontal ones. But of course having complete freedom of tile sizes would be a nightmare. Instead, I opted for an underlying grid. For example a square would be 2x2, a standard film aspect ratio would be 3x2, a vertical panorama would be 1x4. If an image does not meet these ratios, the tile will be cropped to fit. There might still be some issues, especially when there are not enough tile-photos available, but it gave me a chance to fill the grid starting ina corner and making the algorithm traverse through the photo.
The problem with that is that it can happen that the first half of the mosaic is very good, but the later half has much worse fit, because the algorithm has run out of all good photos. Think of relatively uniform sky or forest and you can imagine that this might be an issue. Nevertheless, using the full library, the results are pretty good. In the future I hope to improve this and also re-implement one feature of my very first mosaic: The ability to swap a tile against a new one.

rainbow mosaic by Jens Roesner