Arcimbolder - Image filter
category: general [glöplog]
i'll print the goatse one and put it in my living room....
random logo xD
crosbow: yeeahhh
Van Gogh rendered with Van Gogh brush strokes!! ZOMG
I reckon that would fool an art teacher.
Show us the original! :)
Looks different but the filtered one has a lot of artisticness too.
Very neat job texel! This little utility is fun to play with.
WOW!
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?
@texel
You should do that image again, but with an image pack containing the word "twat" ;-)
You should do that image again, but with an image pack containing the word "twat" ;-)
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).
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).
Very good looking filter there. Put it to some good use :)
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?
Anyway, here's a funny idea: how about automatically extracting the object pack from another image? What would that involve?
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.
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.
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.
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
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
nice! does your program already support multiple cores?
oh, i didn't see the todo list... my bad
wow, that is nice, i've always like "painter algorithms" very much :)
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...
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.