In the process of building this simple example I came across a strange phenomenon where the GPS data wasn’t being preserved if the original iPhone image was altered in any way. This was happening whenever I saved an edited version of the image in Photoshop CS4 including the creation of a thumbail. Even with the preserve metadata flag selected when saving for web.

This was especially annoying because I typically like to use the popular CameraBag app to easily treat my images before saving them on the phone. An explanation from their website suggests that Apple does not allow third party applications to preserve the EXIF data on save. Seriously? Not sure if this is true although a very quick search through Apple’s iPhone dev portal hasn’t yielded any suggestions one way or the other.

Nonetheless, Apple’s own photo editing application Aperture does preserve the EXIF data when exporting out a version however this is a less than optimal solution as I find cropping and exporting batch sequences of thumbnails to a be a clumsy and tedious operation in Aperture.

So what to do? After some searching for a solution I came across Phil Harvey’s impressive ExifTool which can read/write/copy image metadata across files ala the command line.

After going here and installing the package and adding it to my path I can run the following script and copy the GPS data from my source iPhone image1.jpg to my treated version or thumbnail image2.jpg.

exiftool -overwrite_original -tagsfromfile image1.jpg -gps:all image2.jpg

Awesome, and there are a whole list of tags, arguments, etc that you can pass into the tool all outlined in the documentation. One thing to note though is that I have been unsuccessful in copying over the data that describes when the source image was created & last modified. Having tried all of the following commands without success I’m still searching for a solution to copy the timestamp over. If anyone has any ideas I’d love to hear how you did it.

# none of these worked for me...
exiftool -overwrite_original -tagsfromfile image1.jpg -all:all image2.jpg
exiftool -overwrite_original -tagsfromfile image1.jpg -createdate image2.jpg
# attempt to alter the existing date by a few hours...
exiftool -overwrite_original -createdate+=3 image2.jpg
exiftool -overwrite_original -alldates+=1:30 image2.jpg

So after treating the images and banging out some thumbnails, I added the GPS data back in via the ExifTool and pushed everything up my server to try working with the metadata inside of Flash.

The larger project that I am building this prototype for will require the image data to come to Flash via a DB which is why I wrote up a PHP solution instead of reading the image headers right out of the jpeg file using the methods of the AS3 ByteArray.

In my test case here I am communicating with the backend using AMFPHP and wrote a simple service class that includes the main ExifReader class, collects all the EXIF data and sends the results back to Flash.

class AMFDirectoryReader{
 
   public function __construct()
   {
   // relative path to the ExifReader script //
     require_once '../../php/gmaps-gps-images/ExifReader.php';
   }    
 
   public function getEXIFImageData($args)
   {
     $target = $args[0];
     $params = explode(',', $args[1]);
 
     $exif = new ExifReader();
     if (is_file($target)) return $exif->readImage($target, $params);        
     if (is_dir($target)) return $exif->readDirectory($target, $params);
 
     return array('ERROR: Target Does Not Exist');
   }     
}

I can then call getEXIFImageData() from Flash using my RemotingCall class passing in the $target file or directory I want to read and an array of strings that describe what metadata tags I want to get back.

import flash.display.Sprite;
import com.quietless.remoting.RemotingCall;
import com.quietless.events.HTTPRequestEvent;
 
public class AppMain extends Sprite {
 
private var _rc	        :RemotingCall;
private var _params	:Array = ['gps', 'date', 'size'];
private var _target	:String = '../../php/gmaps-gps-images/thumbs';
 
   public function AppMain()
   {		
     _rc = new RemotingCall('http://quietless.com/amfphp/gateway.php');
     _rc.call('AMFDirectoryReader', 'getEXIFImageData', [_target, _params.join()]);
     _rc.addEventListener(HTTPRequestEvent.COMPLETE, onRequestComplete);
   }
 
   private function onRequestComplete(e:HTTPRequestEvent):void
   {
     var exif:Array = e.target.response;
   }
}

The real work happens inside of ExifReader where the target image or all images in a target directory are read using calls to exif_read_data(). Currently the class only supports the $params arguments ‘gps’, ‘date’, ’size’ but if you take a look at what’s going on and reference the method’s man page you can easily extend this to send back what you need.

 
class ExifReader{
 
  public function __construct() { }
 
  /**
  * Returns an array of EXIF data objecta for all jpgs in the target directory 
  **/	
  public function readDirectory($dir, $props)
  {
  // $dir points to this directory from amfphp //
    $files = scandir($dir);
    $images = array();
  // loop over the files array and look for images
    for ($i=0; $i < count($files); $i++) { 
      if (stristr($files[$i], '.jpg')){
  // if the jpeg has gps data add it to the images array //	
      $img = $this->readImage($dir.'/'.$files[$i], $props);
      if ($img) array_push($images, $img);
      }
    }
    return $images;
  }
 
/**
* Returns the EXIF data object of a single image 
**/	
  public function readImage($image, $props)
  {
  $exif = exif_read_data($image, 0, true);		
  if ($exif){
    $data = array();
    $data['name'] = $exif['FILE']['FileName']; 
    foreach($props as $val)
    {				
  // return an array [lat, lng] //
      if ($val=='gps') $data['gps'] = $this->getGPS($image);
  // return date value in milliseconds //
      if ($val=='date') $data['date'] = $exif['FILE']['FileDateTime']*1000;
  // return size in kilobytes //	
      if ($val=='size') $data['size'] = floor(($exif['FILE']['FileSize'] / 1024 * 10 )/10)."KB";
    }
    return $data;
    }	else{
    return null;
    }
  }
 
/**
* Returns GPS latitude & longitude as decimal values
**/	
  private function getGPS($image)
  {
    $exif = exif_read_data($image, 0, true);
    if ($exif){
      $lat = $exif['GPS']['GPSLatitude']; 
      $log = $exif['GPS']['GPSLongitude'];
      if (!$lat || !$log) return null;
  // latitude values //
      $lat_degrees = $this->divide($lat[0]);
      $lat_minutes = $this->divide($lat[1]);
      $lat_seconds = $this->divide($lat[2]);
      $lat_hemi = $exif['GPS']['GPSLatitudeRef'];
 
  // longitude values //
      $log_degrees = $this->divide($log[0]);
      $log_minutes = $this->divide($log[1]);
      $log_seconds = $this->divide($log[2]);
      $log_hemi = $exif['GPS']['GPSLongitudeRef'];
 
      $lat_decimal = $this->toDecimal($lat_degrees, $lat_minutes, $lat_seconds, $lat_hemi);
      $log_decimal = $this->toDecimal($log_degrees, $log_minutes, $log_seconds, $log_hemi);
 
      return array($lat_decimal, $log_decimal);
      }	else{
      return null;
    }
  }
 
  private  function toDecimal($deg, $min, $sec, $hemi)
  {
    $d = $deg + $min/60 + $sec/3600;
    return ($hemi=='S' || $hemi=='W') ? $d*=-1 : $d;
  }
 
  private function divide($a)
  {
  // evaluate the string fraction and return a float //	
    $e = explode('/', $a);
  // prevent division by zero //
    if (!$e[0] || !$e[1]) {
      return 0;
    }	else{
    return $e[0] / $e[1];
    }
  }
}

At some point in the future I’d like to write an elegant way to load a batch of thumbnails and just extract the image metadata right from within Flash. This solution does allow you to read the image tags first though before you load them, ideal for querying a DB to collect a result set of images that meet a specific requirement say like falling within a coordinate boundary, before actually loading them into Flash.

As always downloads of the above classes.
Comment and suggestions are most welcome.

The following function takes the date returned by Twitter, converts it to local time and formats it to :
Tue Apr 07 • 10:52 PM

// pass in the 'created_at' string returned from twitter //
// stamp arrives formatted as Tue Apr 07 22:52:51 +0000 2009 //
function parseTwitterDate($stamp)
{		
// convert to local string and remove seconds and year //		
	var date = new Date(Date.parse($stamp)).toLocaleString().substr(0, 16);
// get the two digit hour //
	var hour = date.substr(-5, 2);
// convert to AM or PM //
	var ampm = hour<12 ? ' AM' : ' PM';
	if (hour>12) hour-= 12;
	if (hour==0) hour = 12;
// return the formatted string //
	return date.substr(0, 11)+' • ' + hour + date.substr(13) + ampm;
}

Of course there are plenty of other ways to do this, including parsing it on the server using php or .net.
If you have a better implementation or suggestion go ahead and post it in the comments below.

To use this class download the source files and create a new BitmapSnapshot object passing in the DisplayObject you want to create an image of as well as an optional file name, width and height. If width and height are omitted BitmapSnapshot will use the full width and height of the object you are passing in.

Note : BitmapSnapshot will generate a jpg or a png based on the extension of the filename you pass in.
The default output will be a png because it’s encoding algorithm is much faster than that of jpeg’s.

private function saveToDesktop():void
{
var img.BitmapSnapshot = new BitmapSnapshot(_canvas, _filename);
    img.saveToDesktop();			
}
 
private function saveOnServer():void
{
var img:BitmapSnapshot = new BitmapSnapshot(_canvas, _filename);
    img.saveOnServer(_phpscript, _destination);
}

A note on dependencies : BitmapSnapshot does rely on the fantastic jpeg and png encoder classes written by Tinic Uro as part of the AS3CoreLibrary. These files are included in the ‘libs’ directory along with BitmapSnapshot so be sure this folder is in your class path when you go to compile.

To see the generated image saved to the server, be sure to clear your cache and view the image here.

As always please leave any questions or problems in the comments below.

When I have more time I’ll come back to this and attempt an animation which as I understand it will easily be an overnight render.

The Communication Arts Webpick of the Day

If you have a Flash / AS3 background like me you’ll quickly find that the two languages are vastly different not just in their syntax but in the way you structure a project and setup its dependencies.

With that in mind, this post will hopefully ease the process and help you sidestep some potentially confusing pitfalls especially if you are coming to OpenFrameworks from an AS3 background and have experience with Object Oriented Programming.

So first off, if you don’t already have oF download it from here and follow this guide to setting up your IDE and compiling an example test project to make sure everything works.

Assuming you got through that ok, (if you didn’t I suggest hitting the oF forums for more help on getting setup), let’s walk through a very simple example that builds a basic particle emitter / starfield.

Anatomy of an oF project.

While there are probably many different ways you can approach structuring a C++ project, I like to follow the conventions of Object Oriented design and place code definitions into separate class files in an effort to keep things legible and easy to maintain. While this approach is probably overkill for such a simple example, using separate header and class files will help you get into the practice of organizing your code in such a way that will make your life much easier as you start developing more complex projects.

So first things first.

The first concept to grasp when starting out with OpenFrameworks is understanding how your program initializes.

Just like in Java, Every C++ program has an entry point in the form of a function called Main. This is analogous to the constructor of your ‘Document Class’ in AS3. If your AS3 document Class is called ‘MyFlashApp’ which subsequently links to a class file called ‘MyFlashApp.as’, the constructor in ‘MyFlashApp’ will be the first function that is called when your application starts. It is here you can place calls to other functions that will execute after your program has initialized.

Typical Document Class Constructor in AS3

public function MyFlashApp()
{
    // trace("hello world"); 
    // NowDoSomethingElse();
    // NowDoSomethingAfterThat();
}

Every oF project should start with a main.cpp file that defines the Main function that will serve as the entry point to the program

int main( ){
    ofAppGlutWindow window;
    ofSetupOpenGL(&window, 1280, 720, OF_FULLSCREEN);
    // this kicks off the running of my app
    // can be OF_WINDOW or OF_FULLSCREEN
    // pass in width and height too:
    ofRunApp( new ParticleEmitter());
}

The above snippet is just boiler plate code that every OpenFrameworks program should start with. Basically we’re just creating a window object to draw our program into and setting up the OpenGL graphics engine before we get rolling.

Notice the last line of the function where we call the oF function “ofRunApp” and pass it an instance of our ParticleEmitter. This is where we point OpenFrameworks to the custom ParticleEmitter program we are about to build thus linking the two together.

Creating the Particle Emitter – Header Declarations and Class Definitions

In C++ we build class objects using two files. Header declarations(.h) and class definitions(.cpp). While you can get away with declaring everything in one .cpp file, I feel that using separate header and class files helps keep the project organized and easier to maintain and read.

That said consider the following code inside of the header file “ParticleEmitter.h”

#ifndef _EMITTER
#define _EMITTER
 
#include "ofMain.h"
#include "Particle.h"
#define size 5000
 
class ParticleEmitter : public ofBaseApp{
 
	private:
 
	int centerX;
	int centerY;
	float rotation;
 
	public:
 
	void setup();
	void update();
	void draw();
 
	Particle* p[size];
};
#endif

The #ifndef, #define, and #endif statements are what is called a “header guard” which is used by the C compiler to check if our ParticleEmitter class has already been included in the program. If it has not, the compiler registers the header file for us which in turn allows us to create instances of the ParticleEmitter class. If you attempt to include a header file more than once, the compiler will complain and your program will probably crash. Header guards help prevent against this. You can read more about them here.

After the header guards we have two include statements. The first includes the “ofMain.h” header file which gives us access to the entire oF framework. This is necessary as you’ll see in a moment because our Particle Emitter is going to extend the class “ofBaseApp”, a fundamental base object of the oF library that provides us with access to a number of core oF properties and commands.

The second include just gives us access to a Particle class that we will define here in a moment.

It might help to think of “ofBaseApp” as similar to the AS3 Sprite object in that both typically serve as the necessary base class to their respective programs. In AS3 any class that extends Sprite automatically gains access to the x and y properties of the Sprite class for instance. Similarly, since our ParticleEmitter class extends ofBaseApp we will gain access to the frame rate and background color properties of the ofBaseApp class via inheritance as we’ll see in the ParticleEmitter class definition in a moment.

Looking at the ParticleEmitter class declaration itself inside of ParticleEmitter.h

class ParticleEmitter : public ofBaseApp {

Translates in AS3 to:

public class ParticleEmitter extends ofBaseApp {

Once we’re inside the class declaration we define all the properties and methods that our class will use. Notice how the private and public properties are grouped together. Further note that the ‘Private’ keyword is entirely optional, by default any member variables or methods in a class declared before the ‘Public’ keyword will automatically be assigned a private scope by the C++ compiler. If you are new to member access specifiers you can read about them here.

class ParticleEmitter : public ofBaseApp{
 
	private:
 
	int centerX;
	int centerY;
	float rotation;
 
	public:
 
	void setup();
	void update();
	void draw();
 
	Particle* p[size];
};

So within our ParticleEmitter declaration we’ve declared that we’re going to have an x and y value to position our emitter on the screen and a rotation value to rotate the emitter over time. We also declare three methods, setup, update, and draw that will define what our emitter will do every time the application cycles through a frame. Lastly we declare an Array called “p” that will store all of the Particles that are currently on the screen. The pointer syntax(*) that declares the “p” array is out of the scope of this article, however you can learn about pointers and how they work in C++ via this excellent tutorial here.

Lastly, note the hanging semicolon after the closing brace of the class declaration. For some reason the closing brace is not enough by itself to tell the C compiler you’ve finished your class declaration. If you are experiencing strange errors or your compliler starts throwing EXC_BAD_ACCESS statements at you, ensure that this guy is hanging on there.

Setup, Update and Draw.

Now that our ParticleEmitter class is declared, we move on to write its class definition.

One way to think about C++ header and class files is that headers declare the member variables that a class will define. It is like a contract between the two files where anything declared in the header must be defined in its accompanying class file. This is very similar to how interfaces work in AS3. Note however that in C++ headers you are also declaring instance variables where as AS3 interfaces are limited to only method declarations and final static variables.

So with all that said consider the following skeleton code for ParticleEmitter.cpp

#include "ParticleEmitter.h"
 
void ParticleEmitter::setup()
{
    centerX = 0;
    centerY = 0
    rotation = 0;
    p[0] = new Particle();
}
void ParticleEmitter::update()
{
 
}
void ParticleEmitter::draw()
{
 
}

If you look back at Main.cpp you’ll remember we created an instance of our ParticleEmitter class within the call to ofRunApp() with the line :

ofRunApp( new ParticleEmitter() );

The “new” keyword is used to call the class’s constructor which creates and returns a new instance of that class, however notice that inside our ParticleEmitter class definition no constructor method is ever defined. It’s important to note that, like in AS3, constructor methods are entirely optional. However if your class extends ofBaseApp and you chose not to provide a constructor for it, you MUST declare the setup method which gives your custom class the chance to initialize the variables you declared in its header file.

An example of how to use a constructor method inside of a class will be shown in the Particle class coming up.

AS3 onEnterFrame vs C++ Update and Draw

Once we’ve created our ParticleEmitter and have initialized its variables via the setup method, we’re ready to start calculating expressions and drawing to the screen.

In AS3, once a Flash program initializes we’re automatically given an onEnterFrame listener that runs in the background listening for changes in application state such as user input. This is essentially what allows things like Event Listeners to work by comparing whether the mouse was up on one frame or was down on another. When the change in state is heard an event is dispatched by the Flash player which allows us to write handlers and execute code based on the new conditions.

In OpenFrameworks this is accomplished a bit differently via two methods of the ofBaseApp class called update and draw. Basically the idea is both of the functions are called every frame and you want to evaluate your expressions in the update method and execute commands that render the screen from within draw.

In AS3 the following code would create a ball and move it 1 pixel to the right every frame.

private var ball;
// constructor 
public function MyFlashApp()
{
    ball = new Ball();
    this.addEventListener(Event.ENTER_FRAME, onEnterFrame);
}
private function onEnterFrame(e:Event):void
{
    ball.x +=1;
}

This same code written in a C++ class file using oF could be written as follows:

void MyOFApp::setup()
{
    x = 0;
    ball* = new Ball();
}
void MyOFApp::update()
{
    x +=1;
}
void MyOFApp::draw()
{
    ball.xpos = x;
}

As you can see in C++ we get a little more granular by placing expressions into their own separate update method that is executed right before the draw method where the screen is redrawn.

Adding in the details of ParticleEmitter.cpp

First lets fill in our setup method by setting the framerate, background color, telling OpenGL to smooth our particles and hide the cursor. centerX and centerY just capture the center point of the screen which we’ll want since we told oF in Main.cpp to open in Fullscreen mode. Next we initialize rotation to zero so we can add to it and the last line is a for loop that fills our ‘p’ array with a number of particles equal to the constant ’size’ as defined in the ParticleEmitter.h header file, which in our case is 5000.

void ParticleEmitter::setup()
{
    ofSetFrameRate(100);
    ofBackground(0, 0, 0);
    ofHideCursor();
    ofEnableSmoothing();
    centerX = ofGetScreenWidth() / 2;
    centerY = ofGetScreenHeight() / 2;
    rotation = 0;
    for (int i=0; i<size; i++) p[i] = new Particle();
}

Now that we got some 5000 particles stored in our ‘p’ array, we can define inside of update what to do with them on every frame that ticks by. Here our update method is going to loop over all the particles in the array calling each particles ‘update’ method and checking if its ‘dead’ property evaluates to true. If it does the ParticleEmitter will delete it from the ‘p’ array and create a brand new particle to store in its place. This ensures that we always have a constant number of particles in the ‘p’ array at all times, again a value equal to whatever we define ’size’ to be in the header file. Lastly we increment our rotation var that keeps track with the current rotation of the emitter.

void ParticleEmitter::update()
{
    for (int i=0; i<size; i++) {
        p[i]->update();
	if (p[i]->dead==true) {
	    delete p[i];	
	    p[i] = new Particle();
	} 
    }
    rotation+=.05;
}

After our array of particles is updated we are ready to refresh the screen.

void ParticleEmitter::draw()
{			
    ofTranslate(centerX, centerY);
    ofRotate(rotation);
    for (int i=0; i<size; i++) p[i]->draw();
}

ofTranslate is special method of the oF graphics package that allows up to reposition the current ‘display object’ on the screen, In this case our ParticleEmitter. Since our ParticleEmitter does not come with a baked in x and y property as we would have with a display object in Flash, we need to use ofTranslate(x, y) to position it in the center of the screen. We then call ofRotate() and pass in the rotation value we incremented in the update method to slowly rotate the emitter around the center of the screen. Lastly we iterate over all of the particles in our ‘p’ array calling the draw method on each one which is what actually redraws them to the screen.

With that our Particle Emitter is complete so we can now set up and define the Particle objects themselves.

The Particle Header Declaration – Particle.h

#ifndef PARTICLE
#define PARTICLE
 
#import "ofMain.h"
 
class Particle {
 
	private:
	float x;
	float y;
 
	int color;
	int radius;
	int age;
	int maxAge;
	float speedX;
	float speedY;
 
	public:
	Particle();
 
	void update();
	void draw();
	bool dead;
};
#endif

Once again we wrap the declaration in header guards and import the oF framework via the command #import “ofMain.h”. Next within the actual class declaration we’ll define some private instance variables so the particle knows where it is. After that we explicitly declare a public constructor method which allows us the opportunity to customize each particle before we start calling its update and draw methods. Then after the constructor we have public declarations for update, draw and the boolean variable ‘dead’ which will let our ParticleEmitter class know when to remove one particle and replace it with another.

The Particle Class Definition – Particle.cpp

The Particle Class definition itself should hopefully be pretty straightforward. Notice the syntax of the first method Particle::Particle which is the constructor method where we can initialize the variables we declared in the header file.

#include "Particle.h"
 
Particle::Particle()
{
	x = ofRandomf();
	y = ofRandomf();
	speedX = ofRandom(0,4);
	speedY = ofRandom(0,4);
	radius = ofRandom(0,4);
	color = ofRandom(0, 0xff0000);	
 
	age = 0;
	dead = false;
	maxAge = ofRandom(0, 50)+250;
}
 
void Particle::update()
{
	age++;
	x += (x>0) ? speedX : speedX*-1;
	y += (y>0) ? speedY : speedY*-1;
	if (age >= maxAge) dead = true;
}
 
void Particle::draw()
{
	ofSetColor(color);
	ofCircle(x, y, radius);
}

ofRandomf() is an oF function that returns a random number (float) between -1 and 1. We use random values here in the constructor to ensure that every particle has a slightly unique starting position, color, radius and speed. maxAge is simply a variable to contain a duration value of how long this particle should exist. A value that we’ll be counting up to every time ‘update’ is called which increments this particles current age.

As the application runs the update method is called on every frame incrementing this particles age, its x and y position and checking to see if its current age is >= the max age in which case it sets it ‘dead’ property to true.

void Particle::update()
{
    age++;
    x += (x>0) ? speedX : speedX*-1;
    y += (y>0) ? speedY : speedY*-1;
    if (age >= maxAge) dead = true;
}

Next in the draw method, which is called immediately after update, we set the application’s color to the color of this particle and draw the particle to its new x and y position on the screen.

void Particle::draw()
{
    ofSetColor(color);
    ofCircle(x, y, radius);
}

So in linear terms the running of the application can be thought of as such :

• function main() called inside of main.cpp to start (bootstrap) the application
• ofRunApp(new ParticleEmitter()) creates a new instance of the Particle Emitter class and passes it to our running OpenFrameworks application
• When the ParticleEmitter is created its setup() method is automatically called by oF which initializes its variables and creates 5000 particles to store in the ‘p’ array
• ParticleEmitter.update() is automatically called by OpenFrameworks.
• ParticleEmitter.update() loops over the ‘p’ array and calls the update method on each of the particles which calculates their new x and y position.
• ParticleEmitter.draw() is automatically called by OpenFrameworks.
• ParticleEmitter.draw() positions the emitter in the center of the screen, rotates it slightly, and again loops over all the particles in the array and redraws each one at its new x and y position

And that’s about it. Note that this is still very much a learning process for me so any feedback or suggestions on how to improve is always welcome in the comments below.

Download xCode project and source files here

To use the attached files, place the ParticleEmitter folder inside of the directory in which you keep your oF programs. This should be a folder inside of the ‘apps’ directory where you installed OpenFrameworks.
Ex. OpenFrameworks->apps->myApps->ParticleEmitter.

Now that we’re somewhat stabilized and are starting to grow a small group of good friends, I feel like I can take a moment to reflect and revisit some of the reasons why I moved to SF in the first place.

For those of you who know me, you know about my background in Film and my experiences in Portland working with the crew of blueprintfilms. Having gone to school for English Lit. and then for Film, I was never privy to a formal education in low-level computing, a subject I have always had a real curiosity in since hacking programs on my Commodore 64 back when I was a kid. Suffice to say everything I know about Flash and web application development I learned from reading books and of course from various sources online.

So I have been programming Flash for about 7 years now during which time I have taught myself maybe half a dozen other scripting languages that are all commensurate with a career in Interactive Design. While writing Flash programs has always been a blast, I can’t continue to ignore my growing interest and passion to explore the rapidly expanding space of physical computing. The space that languages like processing and toolkits like openframeworks are really starting to allow access to.

Years ago when I was in Film school and just getting started with Flash, I remember being inspired by the work of Craig Swann and Eric Natzke and being blown away by what those guys were doing back in the day. Now I’m seeing a new generation of talented designers emerge that are creating interactive physical experiences that go way beyond the boundaries of what I believe the desktop and mobile platforms can inherently provide.

This is not to suggest that Flash does not continue to hold vast potential for what it is, nor am I abandoning it as I still believe it will continue to dominate as a fantastically expressive technology to create rich desktop experiences. Given its ubiquity and the solid R&D that Adobe continues to dedicate to the platform, I wholeheartedly believe that Flash is here to stay. I merely state that I believe a tremendous amount of untapped potential exists in the aforementioned technologies which I, for some time now, have been very excited to explore.

So with all that having been said, after 7 months and three award winning projects with the good people of Ordinary Kids, I have decided to step out of my full-time role at OK and venture back out on my own to pursue new opportunities to collaborate with others interested in exploring this space.

If you share my feelings and want to collaborate please reach out. If you live here in the SF Bay area, let’s go grab a beer. I’m siked to finally start developing with these technologies and look forward to publishing my findings and explorations here on this blog.

Cheers and thanks for reading.
Stephen

Implementation is simple.

// create an array of string hex values
var colors:Array = ['0xFFFFFF', '0xF57E04', '0xC64D18', '0xA95354'];
 
// constrains width to height, convenient for radial gradients
// to keep them circular, default is true
var constrain:Boolean = true;
 
// valid types are FullScreenGradient.RADIAL
// or FullScreenGradient.LINEAR, default is RADIAL
var type:String = FullScreenGradient.RADIAL;
 
var grad:FullScreenGradient =
--> new FullScreenGradient(colors, type, constrain);
addChild(grad);

You can use the tool below to drop in color values using the pickers to preview your gradient and check for ‘banding’ which seems to be a weird phenomenon that occurs on linear gradients when Flash attempts to interpolate between color values that are too far apart.

Enjoy.

Download the Class File

In this being a utility I have been meaning to improve on for awhile, this post attempts to tackle two tasks that are especially common in Flash Platform development. 1st the need to load in a batch of images sequentially and 2nd the ability for Flash to be able to ’see’ inside of a directory on the filesystem and load all the available images within.

As is common knowledge, Flash by itself cannot measure the contents of a directory but PHP conveniently can and report back to Flash its findings. This is all accomplished by loading the included PHP script ‘directory-reader.php’ into an AS3 URLLoader object and capturing the variables PHP echoes back to it.

Consider the following:

public function ImageLoadManager ()
{
   var dr = new DirectoryReader(_pathToDirectory,  '*');
   dr.addEventListener(HTTPRequestEvent.COMPLETE, onDirectoryRead);
}

We create a DirectoryReader object and pass into it the path to the directory we want to read relative to the location of the php script on the filesystem. (We’ll talk about where that script goes in a second). It should be noted that many PHP installations have URL file-access disabled in the server configuration by default which may throw errors if you try to provide absolute URL’s. You many need to change your config file to get around this or just use a relative URL as the sample files provided do instead.

Since this utility was designed to gather all of the image files from a directory that Flash supports, (jpg, png, and gif), it will do just that if you leave the second parameter blank. If you are interested in seeing every visible file in the directory (not including sub-directories) you can pass in a wildcard flag ( * ) as shown in the example above. Note the array of file names this returns will include non-image filetypes which will throw IO errors if you pass them into the ImageBatchLoader in the next step.

After we’ve created our DirectoryReader we’ll want to listen for the ‘HTTPRequestEvent.COMPLETE’ event that gets fired when the PHP script is successfully executed. In the onDirectoryRead function below we can access the array of file names that came back from PHP through the data property of HTTPRequestEvent object.

private function onDirectoryRead(evt:HTTPRequestEvent):void
{
  _files = evt.data as Array;
}

We can then take this list of files and pass it into a new ImageBatchLoader object that will naturally go and load up our images.

private function onDirectoryRead(evt:HTTPRequestEvent):void
{
  _files = evt.data as Array;
// load a batch of images //
  _loader = new ImageBatchLoader(_files, _swfToImages);
  _loader.addEventListener(ImageBatchEvent.IMAGE_PROGRESS, 
   onImageLoadProgress);
  _loader.addEventListener(ImageBatchEvent.BATCH_PROGRESS, 
   onImageBatchProgress);
  _loader.addEventListener(ImageBatchEvent.BATCH_COMPLETE, 
   onImageBatchComplete);	
}

An instance of the ImageBatchLoader class expects at least one parameter, an array of file names to load. Once it has this it will load each image one by one and trace out a whole slew of loader event info to the console so you can monitor each image load’s progress. (Note: To view this output set the debug property of _loader to true) The second parameter is a relative path to the directory where the images to be loaded reside. It should be noted that this path will almost always be different from the path you fed to DirectoryReader since it needs to be relative to the location of the published SWF on the filesystem, NOT the location of the PHP file as we noted above.

Of course you can create a list of files names via a remoting call that polls a database or by reading in an XML file. The purpose of this technique to address those situations where you need a fast and lightweight solution to ‘peek’ inside a directory and grab however many images are in it.

This can all be accomplished with the following sample of code:

package {
import flash.display.Sprite;
import flash.events.MouseEvent;
 
import com.quietless.utils.DirectoryReader;
import com.quietless.bitmap.ImageBatchLoader;
import com.quietless.events.ImageBatchEvent;
import com.quietless.events.HTTPRequestEvent;
 
public class ImageLoadManager extends Sprite
{
private var _loader:ImageBatchLoader;
private var _files:Array; // all files names returned by php //
private var _bitmaps:Array;// all bitmaps successfully loaded //
// path from the published swf to the image folder //
private var _swfToImages:String = 'images/';	
// path from the php script to the directory you want to browse //	
private var _phpToImages:String = '../images';	
 
public function ImageLoadManager ()
{
   var dr = new DirectoryReader(_phpToImages, '*');
   dr.addEventListener(HTTPRequestEvent.COMPLETE, onDirectoryRead);
}
 
private function onDirectoryRead(evt:HTTPRequestEvent):void
{
   _files = evt.data as Array;
// load a batch of images //
   _loader = new ImageBatchLoader(_files, _swfToImages);
   _loader.debug = false;
   _loader.addEventListener(ImageBatchEvent.IMAGE_PROGRESS, 
   onImageLoadProgress);
   _loader.addEventListener(ImageBatchEvent.BATCH_PROGRESS, 
   onImageBatchProgress);
   _loader.addEventListener(ImageBatchEvent.BATCH_COMPLETE, 
   onImageBatchComplete);			    
}
 
private function onImageLoadProgress(evt:ImageBatchEvent):void
{
   var bl:Number = evt.data.loaded;
   var bt:Number = evt.data.total;
   log( 'Loading Image # '+evt.data.position+' : '+bl+' of
   --> '+bt+' Bytes Loaded = '+Math.ceil((bl/bt)*100)+' %' );
}
 
private function onImageBatchProgress(evt:ImageBatchEvent):void
{
   log('Successfully Loaded '+evt.data.loaded+' of 
   --> '+evt.data.total+' Images In This Batch');
}
 
private function onImageBatchComplete(evt:ImageBatchEvent):void
{
   _bitmaps = evt.data as Array;
   var img = _bitmaps[0]; 		
   addChild(img);
   log('Image Batch Load Complete!!');
}

As for the business of where to put the PHP script that can actually read the directory you specify? I have it set as a constant variable inside of the DirectoryReader class:

private static const PATH_TO_DIRECTORY_READER:String =
   'http://localhost:8888/php/directory-reader.php';

My Mamp installation points to my project root folder which contains a ‘php’ folder (containing ‘directory-reader.php’), an ‘images’ folder that contains my images and of course the published swf and an html page. Note you will need to have a server running PHP 5 locally if you want to test the sample files from the Flash IDE.

If you have any questions please post in the comments below.

Sample Files

Very special thanks to Jason, Adam, Sanaz and Hampus at Ordinary Kids and of course Tracy and Gretchen for making it happen. What a great Xmas present!!

After getting back in the states in late September I shuffled down to SF in search of work and while hustling out of hotel rooms all over the city I worked with the brilliant team over at Ordinary Kids to produce the new Tracy Chapman site. The site leverages a simple painting engine that I wrote which lets you paint the elements onscreen as you cruise around the site. I think a great addition in V2 would be to add functionality to save your creation to a gallery or maybe write a cookie that saves your painting for the next time you return.

As for being in SF. I am loving it here and siked to finally be able to pour myself into my work again. I am currently taking on freelance projects while searching for the perfect F/T opportunity.
If you think we’d be a great fit, hit me up.

In a future version I will combine scale and rotate into one mode eliminating the need to select between them.

View the documentation here
View the source files here

Update 11/24/09 : This class has been refactored for improved legibility. Also added now is the ability to register specific targets on the stage via an internal _targets array. See documentation for details.

Update 11/24/08 : There was a syntax bug that was confusing placement of the transform handles which subsequently was throwing the selected object off screen at times. This has been fixed.

Here is a very simple wrapper class I wrote last night that allows you to take a BitmapData snapshot of a Display Object on the Stage, convert it to a .png or .jpg and upload it to your server in a directory you can specify at runtime. All in about 10 lines of code.

The technique is quite simple. You instantiate a new ‘DynamicBitmap’ and pass in the target DisplayObject you want to snapshot as well as a string of the filename you want to call it. e.g. ‘MyBitmapSnapshot.png’

In the following example I created two buttons on the stage which snapshot and upload the bitmap separately however you can combine this all into one action if you like.

private var _dbmp:DynamicBitmap;
private var _uploadScript:String = 'uploads/upload.php';
private var _uploadDirectory:String = 'images/'; // optional //
private var _target; // some display object on the stage //
private var _filename:String = 'myBitmapSnapshot.png';
 
public function ApplicationMain ()
{
     snapshot_btn.addEventListener(MouseEvent.CLICK, takeSnapshot);
     upload_btn.addEventListener(MouseEvent.CLICK, uploadSnapshot);
}
 
private function takeSnapshot(evt:MouseEvent):void
{
     _dbmp = new DynamicBitmap(_target, _filename);
}
 
private function uploadSnapshot(evt:MouseEvent):void
{
     _dbmp.upload(_uploadscript, _directory);
}

Underneath the _target DisplayObject is drawn into a BitmapData object and then based on the file extension you give it in the filename it is converted into either a JPEG or PNG byteArray using the AS3CoreLib encoding classes by Tinic Uro.

These encoding classes return a raw byteArray which by itself cannot be uploaded to the server as the MIME protocol requires precisely defined headers to accompany the raw image data and instruct the server what to do with it.

Enter the URLRequestWrapper class which is a slightly modified version of the UploadPostHelper class written by Jonathan Marston which adds in the necessary headers required by the server:

--pfhchaivbrmxhcighexxsspxpxhepeea
 
Content-Disposition: form-data; name="Filename"
 
myBitmapSnapshot.png
 
--pfhchaivbrmxhcighexxsspxpxhepeea
 
Content-Disposition: form-data; name="dir"
 
images/
 
--pfhchaivbrmxhcighexxsspxpxhepeea
 
Content-Disposition: form-data; name="Filedata"; filename="myBitmapSnapshot.png"
 
Content-Type: application/octet-stream
 
‰PNG

The URLRequestWrapper is simply a modified URLRequest with a data property that contains the image data and all the necessary headers required by the server, including the optional destination directory you specified for the image. When this URLRequest is loaded into a URLLoader object it arrives at the server via the global $_POST array.

I’ve included a simple upload script ‘uploads.php’ that looks for a ‘dir’ property in the header information which contains the _uploadDirectory variable you specified in Flash. It is entirely optional, if no directory is specified it will install the image in the default directory as specified in the upload.php script. This may prove handy in an application where the you’d like to be able to change the destination directory of the newly created image at runtime.

Note: If you specify a directory that does not exist on the server it will be created via the new recursive flag introduced in php5. Be sure to have php5 installed and enabled on your server or the script will throw an argument error and possibly not run.

Source Example Files Here

Now safely back in Portland and reflecting on the experience, I have realized there are some immutable facts one must know before taking on the open road.

Top Five Things You Need to Know Before Driving Across America.

01. Maintain at least a half-tank of gas at all times.
America is BIG, very big, and there are huge empty pockets of nothingness with signs that announce ‘No Services’ at what might misleading seem like a safe pull-off from the interstate to re-fuel.

If you do not maintain at least a half tank of gas in your car at all times, you are asking for pain.

02. Check the Weather and Road Closures Report Daily.
Depending on the time of year you are traveling, the weather can change dramatically within a few hundred miles. On the morning I left Lincoln, NE heading west on I-80 I hit a road closure just past the Wyoming border that forced me to take a 300 mile detour south into Colorado and into a blizzard that almost stranded me atop the Rocky Mountains. While I’m usually all about the unexpected adventure, in this case I had a plane to catch in 48 hours back in Portland and was still 1500 miles away from the airport!

03. Plan your destinations in advance.
I used to be of the school “we’ll figure it out when we get there” then I arrived in St. Louis and spent over two hours looking for a room that was less than $200 a night. Get a listing of hotels/motels/hostels that are in your price range and print out a map of their locations to bring with you. While it might seem tedious, the 20 minutes you spend now before you leave will save you hours of searching when you arrive in a city exhausted from having just driven hundreds of miles to get there.

04. Decide what you really want to see and what you can pass on.
It is impossible to get any real impression of a city by just staying the night there and getting coffee the next morning before you hit the road again. You’ll think you’ll have all this energy to explore, but trust me after you drive 5 hours to get there and have been on the road for a few days your ambition to explore wanes in favor of a drink and a hot shower. If you want to see a city and remember something about it, plan to stay at least one full day there by booking two nights of lodging before you leave town. We did exactly this in St. Louis and had a blast.

05. Pack a survival kit.
Again, this might seem overkill, but if you break down in a blizzard at 9,000 ft you’ll be happy to have a few extra blankets to keep you company until help arrives. Also don’t rely solely on AAA as I found that there were plenty of pockets along my drive where I didn’t have cell-phone service (thanks to Sprint) so I wouldn’t have been able to call them if needed.

The Essential Cross-Country Road Trip Survival Kit

• Spare tire, jack, and tire iron to take off lug nuts
• Road flares (available at most auto part stores for a dollar or so each)
• A flashlight in case you breakdown at night
• A real road atlas, not a $3.99 map of the US from 7-11
• Sunglasses!
• Snow chains that you’ve tested to fit your car.
• A credit card that earns you points for gasoline purchases
• $200 in emergency cash for the mechanic in Wyoming who doesn’t take Amex.
• A fifth of Jack Daniels (for the hotel room)
• And a digital camera to remember it all.

Bonus: Expense Recap of Entire Trip

• One-Way Plane Ticket from Portland, OR – Charlotte, NC : $149
• Cost to totally tune-up the car for the drive : $614
• Gasoline (14 fill-ups) : $340
• Hotel/Motel/Hostel Accommodations (total 4 nights) : $370
  The rest of the time we stayed w/ family and friends
• Restaurants and Supermarkets : $590
• Alcohol / Bars : $100
• Random Fun, Misc Crap, etc.. $270

Total length of trip : 3 Weeks / 3700 Miles
Total cost of the whole sha-bang : $2433

Happy Travels!

I’m starting this blog of sorts to document this process as now, working for myself, I will once more have total control over my days allowing me to spend my time as I see fit. So in the spirit of experimentation, I intentionally come at this without a plan but to simply record and keep organized the various projects and conversations I will participate in over the next few months.

Furthermore expect colorful bitch sessions if I encounter any terrorists along the way.
Woot Woot! Go me!!