Thing-a-day.com

Monday, 25 Feb 2008 - Yesterday I got around to finishing up the project of swapping out the algorithm that I was using for the previous two “pure color” transformations for one that I think actually works.  I ran into a couple of unexpected issues, but finally got it squared away.  The following animation shows the results of 320 small transformative steps using the new algorithm.  I really prefer how you can tell that it’s behaving in a more understandable way based on the colors that you see.  (Also, it has red, green, blue, cyan, magenta, yellow, black and white to choose from each time it colors a rectangle over some pixels.)

This is sadly less different from yesterday’s effect than I was hoping.  It is larger and longer and allows the destructive algorithm to proceed much further, but it’s kind of just more of the same.

I also modified the algorithm for determining the “pure” color so that it’s more flexible and works right, but it isn’t reflected here.  I have an idea for my next iterative image mod that will base the size and/or placement of the next rectangle to modify on the attributes of the color of the current rectangle prior to the current mod.  But I’m not sure how that’ll work.

Today I got to work on my image-manipulation suite — Doink, but just a little.  I altered the checkerboard-generation routine to create a checkerboard and then alter the size of the checks.  (I’ve only played with reduction but I wrote the math so that it should enlarge them too — so that’ll be fun to hack around with when I get the chance.)  Then, I fed the size-reduced, semi-random, small checks into the code I wrote last week that isolates primary-color trends (where “primary” means any of: RGBCMY, y’know, “primary”) so that it just punctuates the image with rectangles colored in with the underlying prominent color.  Then I did it over and over and kind of had fun watching the change.  And it occurred to me that I could make that into an animation.

But, uh, I don’t know how.  So I spent the time to figure out how to do that with the ancient version of Photoshop/ImageReady I have at home (I ran out of time at work to figure out how to do it with The GIMP).  So here I am displaying two things: the animation of 64 steps applying this exact same Doink to an image and watching the effects accrue, and then the first three frames pulled out just to demonstrate slowly what it’s doing.  (I did this so small because I thought the animation would be huge — now I with I’d kept it at 500px wide.  Next time…)

(OK, I’m posting three notes quickly to sort of catch up.  I’ll edit pictures into them later when I get the chance.)

Friday, 15 Feb 2008 - I continued work on my graphcis app project which I’m calling Doink.  This is really perfect for doing software on the time-budget that thing-a-day promotes because I can get real functional results and call them a unit of productivity in an hour.  I wrote routines to merge two images of the same size (which I’ll adapt to handle differently sized images) and one to identify whether an image is mostly of one of the following: red, green, blue, cyan, magenta or yellow and a set of routines that work together to reduce the number of colors used in an image.

So, the variables that the user can set with this doink (the first one I made user-configurable) are: the total number of colors to use, whether to force black and white and whether to force the most prevalent of the six colors mentioned above.  So continuing to use my daughter’s halloween picture as a model (previous parts 1 and 2), the following illustrates some results:

This one is just black and white.  The application looked at every pixel and tried to determine whether it was closer to black or closer to white.  I’d guess that sophisticated programs have more clever algorithms to maintain texture, etc, but this is what I have.

This one didn’t mandate black and white but did mandate the pure form which turns out to be cyan.  I really dig finding the tonal areas that the app IDs as closer to cyan than white that it IDed in the image above as being closer to white than black

This one uses the “pure” color (which will always be cyan, for this original image) and then finds four other tones that are very common and not so close to one another as to be silly. 

Finally, this one forced the use of pure cyan and black and white and then seventeen other tones.  You can really see detail at this point.

the algorithm that determines which tones to use selects the most frequently occurring colors, one after the next and tests it to see if it’s far enough away from the other colors that have thus far been selected for use.  It does that by looking at the difference between the red, blue and green factors (scale is 0-255) and adding the squares of the differences.  If that sum is less than 300, it discards them as too close and grabs the next one and so on.  I think I’ll update the app so that the user can change that 300.

I had a chance to hack around with my image manipulation code today and developed a few new effects/filters which I’m calling “tweaks” and also some “doinks” which is what I’m calling algorithmic application of a series of tweaks. 

You can see my post from two days ago to see the earlier stuff and the original of the photo that I’m distorting.  I’m still really far from the kind of effects that I’m trying to reach, but I guess it’s baby-steps.

A blur effect that I get by averaging colors from surrounding pixels (over and over).

This also blends pixel colors but it’s based on the location of the image and blends the image into magenta in the upper right and cyan in the lower left and kind of grey through the diagonal.  It’s a good effect except for the grey.  I’ll mess with it more.

The inversion or negative of the image.  All of these three are pretty standard filters or effects if you use Photoshop or the GIMP and while they’re not rocket-science to program, it takes both figuring out and doing.

This doink combines blurs and checkerboard shifting – two different tweaks.

This one combines the Verve tweak with the checkerboard shift.  In each of these there is some randomness so I could run it a thousand times and get (somewhat) different results.

This is using an iterative shrinking checkerboard shift while inverting the colors every time to generate the black and white gaps.

So, spurred to action by my playing the other day with some algorithmic image manipulation toys I found on the web (documented here at thing-a-day), I wanted to build some of my own.  And actually, after spending more than the hour that we are encouraged toward, I only have some rudimentary abilities built.  But it’s the start of a framework onto which I can add and just hacking through the ability to doink with graphics programatically took me some time.  While it may not seem like much, I’m pretty pleased with my progress.  The series of images below, demonstrates some of the algorithims that I’m playing with.  Each of these is one operation (from the perspective of my application) performed on the base image — which appears first in the series.  Incidentally, this is my darlin’ daughter posing as Medusa for ‘07 Halloween.

When I have something that actually generates interesting imagery, I’ll package it up and make it available on my blog and link to it from a thing-a-day post in case anyone else wants to play with it.  This is all done with GDI+ in VB.NET written in Visual Studio 2005.

So, mostly for fun, I decided to build an application to which you could feed a URI and have it explore the returned HTTP stream, extracting any URIs and optionally explore those too — with as much recursive depth as you care to have it explore. I’m not sure when I’ll fill in the logic behind the UI, but I spent about an hour getting the UI tuned the way I like. As you resize it or divide the form’s width between the text (left) and browser (right) panes, the position and size of the text and text boxes change following some logic that I worked out to make sure that it would always be readable. Following are three images demonstrating how it responds to manual adjustment (images are at 1/4 actual size):

Default Appearance:

Browser Pane Reduced Considerably:

Tall and Skinny: