MovieMaker Processing Library

Update: MovieMaker is now part of Processing’s core video library so this post is now irrelevant!

Based on some code from Shawn Van Every and Dan O’Sullivan, I’ve created a Processing library that allows you to take any pixel array (from the window or from a PImage) and create a quicktime movie.

  • It might be buggy if the movie file already exists. In theory, it should delete the file and rewrite a new one, but this is not always working.
  • You must call finishMovie() yourself. You might try calling it in stop() or destroy() but it doesn’t seem to work consistently so in my example below, I just call it in mousePressed(). Ultimately, I’d like to have the library call it automatically when the applet quits. . .
  • Need to implement more codecs (you can actually pass in any available constants, i just made nice little variables for a few.)
  • This needs to be tested on Windows. In theory, the library checks your OS and flips pixels if you are using Windows, but haven’t tested it yet. Oh, and there might be a problem on intel macs if they think like windows in terms of pixels.
  •  
    E-mail me bug reports, questions, comments, etc.!

    Example code:

    import moviemaker.*;
     
    MovieMaker mm;
    float theta = 0;
     
    void setup() {
      size(200,200);
      mm = new MovieMaker(this,width,height,"p5test.mov", MovieMaker.JPEG, MovieMaker.HIGH,30);
    }
     
    void draw() {
      background(sin(theta)*127+127,255,cos(theta)*127+127);
      theta += 0.05;
      loadPixels();
      mm.addFrame(pixels,width,height);
    }
     
    public void mousePressed() {
      mm.finishMovie();
    }

    Available constants:
    code: RAW, JPEG, CINEPAK, SORENSON, VIDEO
    quality: LOW, MEDIUM, HIGH, BEST

    Simple JPG creation from Processing

    By popular demand. . .

    // Daniel Shiffman
    // http ://www.shiffman.net
    // May 2006
     
    // Create JPG
     
    import javax.imageio.*;
     
    PImage img;
     
    void setup() {
      size(200,200);
      // Draw a blank PImage
      img = new PImage(200,200);
      img.loadPixels();
      for (int i = 0; i < img.pixels.length; i++) img.pixels[i] = color(100,50,250);
      img.updatePixels();
      saveJPG(img,"image.jpg");
      image(img,0,0);
      noLoop();
    }
     
    public void saveJPG(PImage img, String f) {
      String filename = f;
      // Create BufferedImage from PImage
      BufferedImage bImg = new BufferedImage(img.width, img.height, BufferedImage.TYPE_INT_RGB);
      bImg.setRGB(0,0,img.width,img.height,img.pixels,0,img.width);
      String filepath = sketchPath + "/" + filename;
     
      File file = new File(filepath);
      try {
        ImageIO.write(bImg, "jpg", file);
        System.out.println("Created JPG: " + filepath);
      } 
      catch (IOException e) {
        System.out.println("Problem creating JPG: " + filepath);
        e.printStackTrace();
      }
    }

    Optimize this

    If you look at my nature of code flocking example, you’ll notice that the algorithm involves calculating the distance between all of the system’s elements, i.e. for every “boid”, check and see how far away it is from every other boid. This works quite well for, say, around 100 elements.

    100 x 100 = 10,000 cycles. No problem.

    To check 1,000 elements:

    1,000 x 1,000 = 1,000,000 cycles. Ok, but getting a bit slow. . .

    Let’s try 2,000 elements:

    2,000 x 2,000 elements = 4,000,000 cycles. Now, we’re really getting slow. Really, see how slow it is.

    What if we could divide the screen into a grid of arbitrary size, take all 2,000 elements, and each object’s location within that grid? Then, we could simply test the objects that were in the same relative area at any given moment. Imagine a 10 x 10 grid. In a system of 2,000 elements, on average, approximately 20 elements would be found in each cell (20 x 10 x 10 = 2,000).

    Each cell would then require 20 x 20 = 400 cycles. With 100 cells, we’d have 100 x 400 = 40,000 cycles, a massive savings over 4,000,000.

    Here’s an example that implements this optimization. It’s a great deal more efficient than this slow, pathetic version. The code could use some fixing up and could be improved to be more modular / object oriented, but it’s a nice start for solving these types of problems. We could also use a potentially more efficient data structure than an ArrayList for every cell.

    download source for both examples

    Vector3D Library

    So I’m really a doo-doo head for not bothering to demonstrate this sooner. . . but you can now use my Vector3D class as a library. Of course, this isn’t nearly as sophisticated as what you might, say, be able to do with traer.physics, but since this class is used in virtually all of my Nature of Code examples, it’s not such a nice thing to have to keep adding it to each project over and over and over and over again. . .