Pixel By Pixel: Pixel Transformation

This week in Pixel By Pixel, we were asked to delve into the world of pixel transformation.  Put simply, taking the individual pixels in an image, and processing them to change location in the grid. The goal was a result that was "dynamic and interactive".

Part 1: Reflected Pixels
I began the exercise by subdividing both horizontal and vertical pixels by two, and reflecting the pixels to the remaining three quadrants.  The result was a program that is both entertaining and visually dynamic.  As can be seen from the images below, it allows for (particularly with facial anatomy) imagery that instinctually feels deformed or distorted.  However, it can feel pretty simplistic, along the lines of a house of mirrors.

Part 2: Banding
While experimenting with modifying the reflection algorithm, I modified the factor by which the horizontal reflector was divided.  This resulted in the banding pattern seen above.  Observing the pattern caused me think that intentional banding could create compelling imagery, based around the concepts of repetition, patterns, and blending.

Part 3: Banding Grids
I decided to pursue the banding algorithm, and to do so in both the vertical and horizontal dimensions.  I achieved the desired result by grabbing a section of pixels, and then reapplying it using modulo math.  Since the modulo resets every time its argument is reached, the algorithm would then start anew and redraw the desired band.  The result is a "banding" grid of the desired area, as can be seen above.

Part 4: Abstract Banding Grids And Resolution
While a low resolution banding grid can be more compelling in terms of subject recognition, a higher resolution grid can actually yield more unusual and abstract patterns, particularly when it comes to subject blending, and perceived appearance of the subject.

Part 5: Subject Recognition In High Resolution Banding Grids
Perhaps the most counter intuitive part about the high resolution grids is that despite their complexity and abstraction (see above), they are actually simply a grid of a repeated image.  What this means is that if great care is taken, the subject can actually still be recognized, as can be seen from the recognizable lettering in the image below.

The idea of banding grids manages to take a variable chunk of an existing screen, and repurpose it as a tool to build patterns that can be simultaneously abstracted and recognizable.  What's more, it takes a group of pixels and repurposes them on a macro level such that the group itself becomes the implementation of the pixel.  Further developments in this area might include using the mouse to move the selected band, implementing a constant-movement band that iterated across the image, or intelligently selecting bands of the implemented resolution to recreate the image itself, but in recursive bands that had in fact been sourced by the image.

Sound And The City: Orchestra Seating Mk. 2

This week in Sound And The City finds us re-presenting our final project proposals, this time with the addition of an exterior critique.  As such, I've modified my initial proposal to include a specific site, and a more specific implementation plan.  I've also implemented a rudimentary demo in Logic Pro to simulate the effect of the installation.

ppt: orchestraSeating mk. 2

Pixel By Pixel: Experiments In Thermal Imaging

This week in Pixel By Pixel we were asked to embark on a project inspired by light phenomena observed on our recent trip to the New York Hall of Science.  As such, I decided to take the museum's thermal camera a step further, and actually create a thermal pixel grid, seen above.  The grid (in theory) would use peltier junctions behind an insulated grid of copper tiles, which one could then heat individually using a microcontroller.

The paper "canvas" frame

Unfortunately, the project had challenges from the outset.  The first was in the initial concept itself:  Once I started testing the copper tiles with the peltier junctions, I discovered that something about the copper tiles, probably reflectivity, caused them to be invisible to the thermal camera.  I tried aluminum as an alternative, and had the same effect.  However, when I used paper, all seemed well, so that was my new solution.

 The four transistors of the circuit

I created a frame for the paper canvas, and then endeavored to complete the full circuit required to power the four peltier junctions.  This was achieved by creating a circuit consisting of four transistors and an external power source.  The power source was required to adequately heat the junctions, and the transistors were used to control the power source's path to each junction.

The fully wired canvas/box

Once the circuit was complete, I mounted it (and the four peltier junctions) to the back of the canvas/box, thus enabling the entire unit to stand largely on its own, with the only outgoing connections being to a power source and the microcontroller.

Once this was complete, I began to test the unit using test patterns, and then the true problem arose:  the peltier junctions function smoothly for 20-30 seconds, but as they begin to retain heat, they begin to lose their ability to turn "off" as pixels, and they simply become a grid of pixels stuck in the "on" position. What's more, the thermal camera itself creates recurring (and irritating) scan lines.  These effects can be seen (along with ITP in-lab antics) in the video grab from the thermal camera above. 

While the end result was ultimately a disappointment, the endeavor was not.  The idea still seems feasible, even if peltier junctions are maybe not the appropriate solution.  What's more, before the pixels fail, one gets a general conception of the idea trying to be achieved, and it's actually quite visually pleasing.  What's more, I feel that the addition of a color camera could further the project to an even greater extent.  Put simply: there are still many aspects to explore.

Little Computers: Fun With Drawing

This week for Little Computers, we were asked to use iPhone drawing techniques to create an app that utilized them in an interesting or animated way.  Given the weather, I decided to use precipitation for inspiration, and made an app based around rain.  

The app starts out (as above) with some clouds and a low lying body of water.  As you shake your iPhone, the accelerometer detects the movement, and the app generates water drops in response.  As the drops reach the body of water, it rises accordingly.

Once the body of water has risen to the edge of the clouds, it detects this, and holds off creating rain so it can have a moment to recede.  After that, you can start all over again!

The shapes in the application were rendered in Quartz, the 2D rendering engine native to Mac OS.

github: FunWithDrawing

Sound And The City: New Japanese Underground

This week for Sound and the City, Mark Triant, Igal Nassima, and I were asked to present on some aspect of sonic history.  We collectively decided upon Japanese noise music, sometimes known as the "New Japanese Underground".  Below is our presentation (complete with graphics and sound) to the class.  Enjoy!

pdf: New Japanese Underground Presentation

Nature Of Code: Midterm Proposal

For the Nature of Code midterm, we were asked to do the following:  

Develop a proposal and a prototype for a "midterm" project. The scope of the project can be quite large (trial idea for a final, for example), however, you will not be expected to implement the entire project. For the proposal, include a description, relevant links, and a quick Processing sketch of the first step towards the idea. Link your proposal from the wiki. Next week, we will look at a selection of proposals and then on Mar 2/3, the results for all midterm projects will be presented.

As such, I've decided to continue my work on modeling popcorn using the Box2D library.  While the original attempt was moderately successful, there are a number of aspects that I'd like to modify and enhance so that the simulation will be more realistic.  Specifically, they are to:

• Enhance the geometry of the popcorn so that the kernels and popped corns are not uniform in shape and size.
• Work with density variables to create more realistic behavior as the corn pops and expands out of the kettle.
•  Work with kernel placement and velocity so that the kernels don't breach the kettle walls upon popping.
• Allow for user interaction and variability with the simulation, including: amount of popcorn, turning the kettle on an off,
• Create more realistic visualizations to associate with the simulation as a whole.

These changes will also serve to further familiarize me with the Box2d library, and its ramifications for geometry and particle systems in a modeling context.  The project will not be the prototype for a final project, but rather the final iteration of an earlier project before I embark on a final.

Nature Of Code: Popcorn Modeling

This week in Nature Of Code, we were asked to use the Box2D library to implement a model of some real world phenomena.  Box2D is a physics system that manages the physics of a given system, which you can add various physical "bodies" to.  This allows you to create a realistic physics model for a given 2D system with very little coding overhead.  For whatever reason, when I heard this, my mind immediately went to popcorn.

For a smaller number (100) of kernels, my model (with a small amount of tweaking) actually works quite well.  The kernels pop somewhat naturally, and the system generally handles the physics of the situation how you would expect it might:  just like a real popcorn popper!  You can see the effect of 100 kernels in the first two illustrations of this post.

However, from there I started adding more kernels, and got into some trouble.  At 150 kernels (above) the physics started behaving a bit erratically, and areas with a lot of popping density would cause kernels to move through solid objects.

When I increased the number of kernels even further, to 300, this behavior became almost ubiquitous in the system.  Kernels were popping out of the kettle left and right, and the walls of the kettle seemed almost meaningless.

I have yet to discover what the cause of this behavior is, but my guess is that it's an inability of Box2D to handle the sudden transition from kernel to popped kernel.  A few ideas I've had include increasing the time of the "pop" from one step of the physics engine to say, 3 or 4.  This might allow the engine to handle the change more intuitively.


One of the challenges of Box 2D is that it has no graphical output, so everything you draw is based upon a Box2D object, but isn't actually a Box2D object.  What this means is that errors in one's graphics code can appear to be Box2D errors, when in fact they are coding errors on the users end.  This is unquestionably one of the downsides of using a "black box" engine, but hardly enough of a problem to avoid using such a versatile tool.


source: Popcorn Model