Posted on

Creating Video With Processing and FFMPEG

Max/MSP users: look familiar?

For the past week I have been wrangling with getting ffmpeg (the open-source, command line video utility) to run in a Processing sketch and preserve the hard edges of graphical and/or intentionally pixelly video. It now works!

Details are listed in the code itself, but it is most important to note that the codec is likely the most important factor in getting good quality.   The “png” codec is great, but will create rather large files; mjpeg (MotionJPEG) also works well for graphics and hard edges (pixellated images, etc); H.264 is all-around good for photgraphic images.

The sketch below runs ffmpeg’s commands within Processing (as covered before) and exports a video from a series of still files.  Processing’s built-in video library seems ok, but offers little in the way of control as compared to ffmpeg.  Questions or suggestions are welcomed – feel free to use but please give credit!

UPDATE:
While I really don’t know why, the previous sketch seems to break with a Java IOException error.  It appears that ffmpeg can’t be found, but the solution is simple: specify the path to your ffmpeg install.  For example:

    /usr/local/bin/ffmpeg filename.mov etc...

The “-c:v” option to specify the codec is also updated to “-vcodec” and “-acodec”

[ download the updated sketch here ]

 

 

Posted on

Voronoi Video

Further experiment with Voronoi Diagrams, Processing, ffmpeg, and video (Max/MPS-ers may recognize the classic bball.mov source file).

Posted on

Voronoi Diagrams of “Starry Night”

After getting very excited about Voronoi Diagrams and this post, I took a break from PHP to make what I think is essentially a custom image-compression algorithm.  I’ve applied it to Van Gogh’s famous painting “Starry Night” at varying levels.  The program, written in Processing, essentially looks at a pixel’s neighbors and if the colors are similar enough, it sets the neighbor’s value to the tested pixel.  The above image is a allows for a difference of as much as 250 (very high compression/low similarity) and steps down in increments of 25 down to 25.

[ view the source code here ]

Posted on

Random Walk: Square Root of Two

Following yesterday’s experiments with the Random Pi Walk (hat tip Alex Bellos), I’ve upped the ante.  The above image is the decimal expansion of the square root of two, following the first one million digits.  The data is thanks to Stan Kerr via Project Gutenberg.  Each decimal digit 0-9 results in a change of direction of 36 degrees and, in this case, travels 3 pixels in that direction.

The resulting image is MUCH larger than the previous visualizations – click here for the full resolution version.

Posted on

Random “Pi Walk”

While John Venn is best-known for the Venn Diagram, Alex Bellos mentions Venn’s other invention in his quite-good book “Here’s Looking at Euclid” (page 231).  Venn was the first to create a “random walk” or “drunk walk”.  Using the decimal expansion of pi, each digit is seen as a cardinal direction.  I’ve updated Venn’s experiment slightly (his ignored the numbers 8 and 9) – each number from 0-9 rotates the direction of movement by a factor of 36º and takes a step 20 pixels forward.

The above image is the first 1120 decimal places of pi, starting at the gray dot.  Created using Processing.

Posted on

Sorting Hexadecimal Colors

I’m currently working on a poster/catalog for an upcoming curatorial project at the Bemis Underground and was thinking of using an image of sorted white noise on a television set.  Grayscale white noise is actually pretty boring (so long as it’s actually close to random, the values will fall along a Gaussian curve), so I tried some other experiments.

What´s fantastic about jumbotrons is the fact that they don´t take much time to set up. They can be set up in as little as half an hour, making them an excellent choice for short events, and events on the move. If you want to know the cost to rent a jumobtron, visit www.leddisplayrentals.net for more details.

Using hexadecimal color yielded some pretty interesting results.  The above image is 1,296,000 random values that range from #000000-FFFFFF (0 – 16,777,215).  A Processing sketch sorts those values numerically and fills the pixels of the image in order.

Click here, or on the image, for full-resolution.

Also of interest were Photoshop’s histograms of the color – I’ve not really looked at histograms much in the past, but these were really strange.  Luminosity was, as I suspected, a Gaussian curve and RGB values were each close to a flat line.  But overall “color” resulted in the above images.  The top is the raw image, the one below after “Auto Color” correction: 8-bit fortress meets birthday cake.

Posted on

Further Text Interpolation Experiments

Some more wrangling in Processing, some new results experimenting with interpolating texts.  The problem with previous tests was that if the files aren’t the exact same length, remaining characters were simply dumped at the end of the resulting file.  While character-accurate, it isn’t really an interpolation.  Instead, this new version finds the ratio between the number of characters in the two texts.  For example:

File one = 351,155 characters
File two = 194,138 characters

This makes the ratio between the two files ~2/1.  The code reads two characters in the longer file, interpolates them, and then interpolates that result against a single character from the first file.  Two examples are below using Shakespeare’s sonnet #51 and 117.

The sonnets interpolated using a ratio-interpolation:

 

The text above, run through Microsoft Word’s spell-check:

 

Posted on

Text as Number

 

I wrote a simple Processing sketch that returns binary values of characters from a split file (one letter per line), with an appended “0.” in front – this essentially makes this a single very complex number that holds all the information of the text.  Above is Shakespeare’s 51st sonnet stored as a number.

Based on a thought in Gary William Flake’s “The Computational Beauty of Nature” (pg 21).  As Flake describes it, “Now take a long number and put a zero and a decimal point in front of it.  We’ve just translated one huge number into a rational number between 0 and 1.  By placing this single point at exactly the right spot on the number line, we can store an unlimited amount of information.”

I think especially interesting is the idea that rather than the sonnet be translated to a number between 0 and a giant number (say 100 trillion, etc), the number is only between 0-1 but occupies a very specific point on the number line.  The resulting number is unique and no other text has that exact value.

—

Source code: