Shipped! Kinda ...
I found two shipment notices waiting for me in my inbox this morning from Apple :)
Unfortunately, they were for my printer and my mini-dvi-to-dvi connector :(
But at least its a start.
No updates really ... beyond the fact that I am waiting for the Mac to arrive, and still working on the Mosaic program (Jeff, I will send you the source or find a way to post it soon .... I need to work out a few bugs and clean it up a bit. You can't hold it against me if the code isn't up to Google's standards ;) ... however, I can happily say I coded all of it short of the image read/write APIs. Those are from standard Java api's.)
One interesting thing to note, I worked out a more advanced matchEngine which parses each tile into an set number of "sectors" which it compares individual to the seed tile (instead of comparing the whole tile's avg color, this checks multiple regions of the tiles). I thought this would give me very similar results, but could aid in color boundries being more "correct". An example of the problem I was hoping to avoid would be two library images, one red on the top half, and blue on the bottom ... and the other with the colors reversed. Both would have the same overall avg color (some purple) but if the tile we were matching had more red on top ... one would make a much better choice. My "simple" match engine couldn't distinguish the two. My second one can .... but as it turns out, that obvious case doesn't come up that often unless you have a huge library to pick from. In reality, the mosaics it is producing seem to have a little better color consistency, but it really depends on the image and the library. Most are actually ending up worse in various ways. So, its back to the drawing board on that one.
5 comments:
On your Mosaic thing, what if you keep the simple checking but add border checking? In other words, compare the average color of the whole picture but also compare the average color of a small slice of the borders of the region.
One thing I notice in the mosaics you've generated so far is that you can always see the tiny squares that make up the pics. One reason for this might just be that having the borders match is more important than a simple average color compare gives them credit for. Another reason might be that your engine frequently places the same picture next to itself. That makes it more noticeable to the eye. You might solve that by encouraging your engine to choose a less perfect match if it has already used the perfect match.
Interesting. I hadn't thought about it that way. I had the idea of somehow "blurring" the border by making the edges not regular ... I saw another product that gave you the option of doing a jigsaw like border between the tiles which made the edges not as noticable ... that or having hte tiles overlap so that the edges should match up with the other's around it but couldn't think of a good way to do it. Your idea of just placing more emphasis on the borders and/or trying not to pick the same one in a row could help and would be easier to code.
hrmm
No worries, no judgments :)
This is a project I've never really considered doing, and I find it fascinating. I don't think I ever get tired of looking at code.
well I will post it somewhere soon. yesterday I tried implementing a matchEngine that used overlapping tiles ... it works well on some images and horrible on others. I am hitting a wall with these ideas and need to step back for a bit. I will try to post it by this weekend.
so . . .
what's the update on shipping your new mac ?
Post a Comment