Arcimbolder - Image filter

category: general [glöplog]
i'll print the goatse one and put it in my living room....
added on the 2008-11-09 23:05:01 by Tigrou Tigrou
random logo xD
BB Image
crosbow: yeeahhh
added on the 2008-11-10 00:00:26 by texel texel
BB Image

Van Gogh rendered with Van Gogh brush strokes!! ZOMG
added on the 2008-11-10 00:24:57 by doomdoom doomdoom
I reckon that would fool an art teacher.
added on the 2008-11-10 00:25:42 by doomdoom doomdoom
Show us the original! :)
added on the 2008-11-10 00:58:58 by Intrinsic Intrinsic
BB Image

Looks different but the filtered one has a lot of artisticness too.
added on the 2008-11-10 01:01:26 by doomdoom doomdoom
Very neat job texel! This little utility is fun to play with.
added on the 2008-11-10 02:37:07 by decipher decipher
added on the 2008-11-10 08:40:44 by Optimus Optimus
texel: Adok pack aside, I think it's an awesome piece of work. How does it scale with the resolution of the image and the amount of objects in the object-pacl?
You should do that image again, but with an image pack containing the word "twat" ;-)
added on the 2008-11-10 09:41:43 by xeron xeron
Lord Graga: now it renders at 1400x1400, to do fsaa, and I don't think it should be a problem to make it even bigger. It is just in the final object adjust when it should require to use the full resolution.

About the number of objects, now it is done for a contant maximum of 100 (about the same time of the van gogh's pack). But it would not be a problem to make a bigger pack, because it could be "monte carlized", you know, get (for example) 100 hundred random objects from, let say, 1 thousand, and test for the best and draw it. The speed would be about the same in that case, and I suppose the quality would not differ so much from the full range (it is a matter of statistics).

Anyway, the problem with very big amount of object packs is memory. Now it is taking an average of 2.3 Mb per object, so, with 1 Gb of ram there could be... about 300-350 objects (supossing you have to let some free memory for the OS). I can reduce the memory requirements to about 1 Mb per object... So maybe there will be a version able to use 500 or more objects...

I want to release first the 100 max objects developer kit soon. If people want to create their own packs, then I will update it allowing more, but if I'm goiing to be the only person doing it, the number is enough for me :P (a lot of cropping work, even for 50).
added on the 2008-11-10 10:11:35 by texel texel
Very good looking filter there. Put it to some good use :)
added on the 2008-11-10 10:23:10 by psonice psonice
What exactly does it do with the brushes since they're 2.3 MB each?

Anyway, here's a funny idea: how about automatically extracting the object pack from another image? What would that involve?
added on the 2008-11-10 11:16:34 by doomdoom doomdoom
Recursive images made up by parts of themself over and over again. My brain is overloaded with awesomeness.
Command Cyborg: an automated collage. I've thought of it too, but... how to crop the images? Random triangles? Or some kind of random walk crop? maybe some random points and cutting it as lines?

300 kb are for the image data by average (about 200x200 pixels by average, 4 bytes ARGB and duplicated if the reflection option is set)

Then 2 Mb of precalculated "fuzzy color histogram". It is an analysis done to enhance the positions searched for every object. It makes the results to appear much faster, for example, a white object will be much less times tested on a black area than in a white area. It is, to some degree, a kind of feature detection, but based in color and not in edges. Edge feature detection is not very useful for this program.
added on the 2008-11-10 11:32:20 by texel texel
texel: you could select areas by picking a random point in the image and selecting adjacent pixels that are within a certain tolerance of that pixel. Like the select tool in photoshop.. could be slow though, and I don't see how it could run hardware accelerated in a nice way.
added on the 2008-11-10 11:43:18 by psonice psonice
psonice, that way is very fast, the cut is calculated linearly to the silouette lenght. I will try.

I'm thinking... ummm... doing it by frecuencies should give better results, avoiding noise (sharp spikes in the silouette)... so maybe a bit of blur would help :P
added on the 2008-11-10 12:03:09 by texel texel
nice! does your program already support multiple cores?
added on the 2008-11-10 12:42:44 by src src
oh, i didn't see the todo list... my bad
added on the 2008-11-10 12:44:34 by src src
wow, that is nice, i've always like "painter algorithms" very much :)
added on the 2008-11-10 12:58:35 by visy visy
broderick: I'm using some kind of gaussian pyramids, but not exactly. Gaussian pyramids had some problems (object missing), but the method I use is very similar in speed. Anyway, template matching is very slow without feature detection... I've tested, for example, to do face detection using a sightly modified version of the algortihm, and it is very very fast... more than enough for real time with a webcam input. But, in the case of the collages, it is a bit different, features doesn't have to match at all with the objects (for example, edge detection), and since the object collection is limited, the color doesn't even have to be similar... So the search have to be very big. And a big search is slow in any case...
added on the 2008-11-10 13:28:26 by texel texel
BB Image

Working on "Picasso collage" object pack. Very few objects yet and not tuned, but I find the results very pleasing...

I should release the pack developer kit soon, it is much more fun when you can do your own pack.
added on the 2008-11-10 13:56:25 by texel texel