da: A smiling human with short hair, head tilted a bit to the right. It's black and white with a neutral background. You can't tell if the white in the hair is due to lighting, or maybe it's white hair! (Default)
da ([personal profile] da) wrote2006-03-28 09:13 am
Entry tags:

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 [livejournal.com profile] melted_snowball's and my trip in 2003.



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 [livejournal.com profile] boutell!!

[identity profile] epi-lj.livejournal.com 2006-03-28 05:30 pm (UTC)(link)
You know, if you can generate those in sufficiently high resolution, I have access to a very large colour plotter.

[identity profile] da-lj.livejournal.com 2006-03-28 06:15 pm (UTC)(link)
I'm holding off on my impulse to rush out to make big prints yet, since there are code-tweaks that should improve things.

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? :)

[identity profile] epi-lj.livejournal.com 2006-03-28 06:17 pm (UTC)(link)
Well, if you want 18x12, I can do it on photo paper on the little colour inkjet.

But the large one is 42" x However-long-you-want.

[identity profile] da-lj.livejournal.com 2006-03-28 08:59 pm (UTC)(link)
I've never used a large photographic-quality colour plotter before, and there's one thing that confuses me. The descriptions I've seen say that they can print at something like 2000 pixels per inch. x 42 inches = 168 megapixels per inch of output. Or approximately 50mb/inch at so-so quality jpg. so, for a 2-foot swath, that's 1gb of data. I also know that photographic prints require a certain dpi density or they will look awful close-up.

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

[identity profile] epi-lj.livejournal.com 2006-03-28 09:03 pm (UTC)(link)
Honestly, we've printed promotional material at between 1280 and 2048 pixels across for a 17" wide print and had it come out looking fantastic. That's a very low DPI rating. It's not really critical. (That's mostly if we use the reall nice paper, though.)

[identity profile] da-lj.livejournal.com 2006-03-28 09:05 pm (UTC)(link)
addendum to previous, which I should've said first:

That's very cool and thanks for the offer. :)

[identity profile] da-lj.livejournal.com 2006-03-28 09:30 pm (UTC)(link)
Awesome.

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?
chezmax: (Default)

[personal profile] chezmax 2006-03-28 11:42 pm (UTC)(link)
I imagine you'll find the results will be even more remarkable in another colour space (I would probably suggest YUV or YCbCr over HSV./HSL)

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).
chezmax: (Default)

[personal profile] chezmax 2006-03-28 11:45 pm (UTC)(link)
Note that printer DPI and screen DPI don't go hand in hand.

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. :)
chezmax: (Default)

[personal profile] chezmax 2006-03-28 11:46 pm (UTC)(link)
Oh, in case this didn't come through: that's awesome. :)

[identity profile] epi-lj.livejournal.com 2006-03-29 12:11 am (UTC)(link)
Yeah, sure. I'm going on vacation after tomorrow -- Thu, Fri, Mon off -- so anytime after that, whenver you want. Note that anything over 13x19 will be on plain paper. I only have the photo paper up to that size.

YUV!

(Anonymous) 2006-03-29 02:19 am (UTC)(link)
Thanks, those are two spaces I hadn't considered. YUV looks particularly promising... the V in YUV seems way more useful than the V in HSV, without being much more complicated to calculate (infact, easier than HSV, I think). YCbCr makes my eyes glaze a bit, I'm afraid, though that is possibly because I don't think the Wikipedia article for it is very well written.

So far, my HSV attempts have been less useful than RBG. (fishbot)

Re: YUV!

(Anonymous) 2006-03-29 02:23 am (UTC)(link)
Sorry, I meant the Y in YUV, which is similar-but-different from the V in HSV. The V in YUV doesn't relate to the V in HSV at all.
chezmax: (Default)

Re: YUV!

[personal profile] chezmax 2006-03-29 02:57 am (UTC)(link)
You've forgotten to log in.

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:
Y' =       + 0.299    * R'd + 0.587    * G'd + 0.114    * B'd
Cb = 128   - 0.168736 * R'd - 0.331264 * G'd + 0.5      * B'd
Cr = 128   + 0.5      * R'd - 0.418688 * G'd - 0.081312 * B'd


Either way, you shouldn't have too much difficulty with it, and it's likely to be much more useful than HSV. :)

[identity profile] da-lj.livejournal.com 2006-03-30 12:46 am (UTC)(link)
Thanks. Eric and I have been having fun with it, certainly. We like hte YUV idea. :)

...Eric's main blog is elsewhere, but I added a feed at [livejournal.com profile] emaki, just in case you're interested in seeing more pics/ what he's thinking about.
chezmax: (Default)

[personal profile] chezmax 2006-03-30 06:15 pm (UTC)(link)
Nifty. Glad to have been able to help :)