Teeny Tiny Pictures, II
This is a continuation of my previous post about photo mosaics, a project of Fish and I.
What do you get when you cross Flickr, GD Graphics Library, and a bunch of perl code?
In our case, something like this:

That is made from a corpus of 10,000 thumbnail photos from Flickr's "colorfields," "urbanabstracts," and "flowers" pools. Each tile is partitioned into a 5 by 5 grid and each of those is indexed by colours (RGB currently, HSV to come). The resulting data is stored as a 75-dimension vector.
We reduce the source image to a smaller size, such as 250x200, and each 5 by 5 grid is turned into another 75-dim. vector, which is compared with each of the tile vectors in the corpus. The closest vector is added to the image, subject to a few constraints such as not repeating nearby. A 5 by 5 grid works surprisingly well. Here is the top-left portion:

I love how the diagonal white line on the left travels across the tiles.
I assumed there would be mostly awful matches, cause y'know, what's the chance you've got an image with the proper colours in most of the parts of the tile? But the vector comparison choses the best fit overall, and 10,000 photos help. We're working on getting that to 30,000 or more.
This is the original photo, which I took in a huge indoor market in Budapest from

We're using Flickr's public API and only grabbing thumbnails, each only 1 or 2k, so it's not even a resource-hog. And the mosaic generation is quick- this image took me about 30 minutes to generate on an 800mhz computer.
We could've used ImageMagick as many of the other simple mosaic programs out there do, but we liked the interface of GD much better and it does everything we need for this. So- thanks

no subject
no subject
This one is 3750x2850, which I figure could be just high enough resolution for an 18x12 print, which also seems to be the largest wall space I can spare..
For the sake of argument, what sort of resolution/size were you thinking? :)
no subject
But the large one is 42" x However-long-you-want.
no subject
So, do photographic plotters really use that sort of data-density? If you want something to come out looking good, what sort of dots per inch does it need?
Maybe I'm asking the wrong questions here, but photographic plotters have always confused me. :)
no subject
no subject
I mentioned this to Fish/eric and he's quite excited about the idea. We'd like to work on the code a bit before-hand; can we maybe send you a file in a week or so?
no subject
no subject
A printer will use perhaps 8x8 dots (or more?) to make one screen pixel, as the intensity of ink is varied by coverage. A printer dot doesn't have 256 gradiations per channel like a screen, so it makes up for it by using smaller dots and supersampling, as it were. :)
no subject
That's very cool and thanks for the offer. :)
no subject
Also, then, depending on your priorities, you can put more weight on the Luminance channel (which using, say, the JPEG equations for the colour transformation for YCbCr, would come automatically, as Y tends to be much larger than CbCr).
YUV!
(Anonymous) 2006-03-29 02:19 am (UTC)(link)So far, my HSV attempts have been less useful than RBG. (fishbot)
Re: YUV!
(Anonymous) 2006-03-29 02:23 am (UTC)(link)Re: YUV!
YUV as described in Wikipedua has the same equations as the Jpeg YCbCr (which is the very last box in the wikipedia YCbCr article.
In the YUV article they're treated as floating point numbers between 0-1.
In the YCbCr, they're treated as 8 bit numbers.
This is the relevant bit:
Either way, you shouldn't have too much difficulty with it, and it's likely to be much more useful than HSV. :)
no subject
no subject
...Eric's main blog is elsewhere, but I added a feed at
no subject