Pixography: The Idea
Recently, I’ve been making visual art again. Specifically, I’ve been experimenting with something I’m calling Pixography. To help myself understand what Pixography is, I decided to write about it here and share two "in-progress" works I'm currently tinkering with. Those notes are below.
If you know of examples like this in the wild, please share my way. If making something like this is your jam, I’d love to chat. Please reach out.
What is Pixography?
Pixography is an algorithmic art form that transforms a photo into an animated visual display rendered via pixels.
The Constraints
- A Pixograph is not bound to a specific photo, aspect ratio, or photo size. It should accept any photo as input and function correctly.
- A Pixograph always derives its colors from the source photo. No color values should be hardcoded into the algorithm.
- A Pixograph is always animated. Pixels are a dynamic medium designed to change. Fixing a pixel to one color contradicts their essential nature.
Examples
To help illustrate what a Pixograph looks like, here are two examples. As of writing this, these are still works in progress and may change over time. Both examples use the same source image as input.
Example 1: The Algorithm as Sunrise
See full screen
At the time of writing this post, this pixograph changes a good amount based on the size the output is being rendered onto. One place to think about is how the output size should or should not impact the algorithm. This feels harder to control than input size (which can always be scaled in the algorithm).
Example 2: The Algorithm as Trance
See full screen
In this Pixograph the input photo is scaled to 100x100 and those 10k pixels are used to drive the pixograph, creating 10k circles.
The position of the circles comes from the least significant 4 bits of the R and G values (hence a 16x16 grid) and the size of the circles comes from the least significant 4 bits of the B value.
The colors are the most significant bits of the RGB value rescaled up to 0-255 from 0-15.
The animation is driven by a sine function, the size of the circle and frame counter.
FAQs
Can a Pixograph be made from a video?
No. That would be a different art form. I believe a Pixograph should be made from a single photograph. While I can imagine using a set of still photographs as input, I feel uneasy about that approach. I don’t have a strong argument against using two or three photos, but I draw the line at animated sources like videos or GIFs. These shift the animation responsibility from the Pixograph to the input itself.
Some might argue that if a Pixograph generated 100 frames from each frame of a video, it would still satisfy the animation requirement. But that’s not convincing to me. In fact, the possibility of that argument is one of the biggest reasons I hesitate to allow multi-photo sources.
Can a Pixograph define its colors?
No. All color in a Pixograph must originate from the input photo. This means no hardcoded color values are allowed.
However, this doesn’t mean that every color in the output must appear directly in the input. For example, a grayscale Pixograph can be created from a color photo by calculating a luminance value from the pixel data and setting the red, green, and blue values to that value—thus producing shades of gray. What you can’t do is calculate an index and use it to select from a predefined palette of colors.
Why is a Pixograph animated?
Pixographs are a pixel-based art form, and a core characteristic of pixels is that they change color. A static Pixograph would just be algorithmic output, like a digital print, and could be rendered on a non-pixel-based medium.
One might ask: if the animation produces the same result every time, is it still a Pixograph? Well, is someone sitting at a piano and not playing it still making music?
What inputs are expected when calculating a frame?
So far I have been passing in a kind of frame counter to each animate call, allowing my deterministic algorithms to create consistent results and progress. For change to happen, something has to track render progress or randomness has to be added. I don’t like the idea of random algorithms for animations (or any art really) as they put chance into the process. I also have mixed feelings about how I am injecting a frame counter into each animation call. Is there another option?