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)
[personal profile] da


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!!

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

Date: Tuesday, 28 March 2006 06:15 pm (UTC)
From: [identity profile] da-lj.livejournal.com
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? :)

Date: Tuesday, 28 March 2006 06:17 pm (UTC)
From: [identity profile] epi-lj.livejournal.com
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.

Date: Tuesday, 28 March 2006 08:59 pm (UTC)
From: [identity profile] da-lj.livejournal.com
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. :)

Date: Tuesday, 28 March 2006 09:03 pm (UTC)
From: [identity profile] epi-lj.livejournal.com
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.)

Date: Tuesday, 28 March 2006 09:30 pm (UTC)
From: [identity profile] da-lj.livejournal.com
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?

Date: Wednesday, 29 March 2006 12:11 am (UTC)
From: [identity profile] epi-lj.livejournal.com
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.

Date: Tuesday, 28 March 2006 11:45 pm (UTC)
chezmax: (Default)
From: [personal profile] chezmax
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. :)

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

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

Date: Tuesday, 28 March 2006 11:42 pm (UTC)
chezmax: (Default)
From: [personal profile] chezmax
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).

YUV!

Date: Wednesday, 29 March 2006 02:19 am (UTC)
From: (Anonymous)
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!

Date: Wednesday, 29 March 2006 02:23 am (UTC)
From: (Anonymous)
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.

Re: YUV!

Date: Wednesday, 29 March 2006 02:57 am (UTC)
chezmax: (Default)
From: [personal profile] chezmax
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. :)

Date: Tuesday, 28 March 2006 11:46 pm (UTC)
chezmax: (Default)
From: [personal profile] chezmax
Oh, in case this didn't come through: that's awesome. :)

Date: Thursday, 30 March 2006 12:46 am (UTC)
From: [identity profile] da-lj.livejournal.com
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.

Date: Thursday, 30 March 2006 06:15 pm (UTC)
chezmax: (Default)
From: [personal profile] chezmax
Nifty. Glad to have been able to help :)

December 2024

S M T W T F S
12 34567
891011121314
15161718192021
22232425262728
293031    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Wednesday, 24 December 2025 11:20 pm
Powered by Dreamwidth Studios