Notions

So I played around with the Google Earth integration in Picasa and it is neat. It is very useful if you don’t have a GPS or GPS data for your photos, but it does not automatically correlate the photos with any sort of GPS information.

The best I could do was load my GPS track (GPX file) and view it in Google Earth while I was tagging a photo. It doesn’t correlate the time, but at least you can match the photo with some point on the GPS track. Unless you are in the ocean with no reference points, you can probably get the point within the accuracy of the GPS signal. Unfortunately, it is still a manual process.

I hear a rumour that Google Earth 4 (which I was using) has some sort of time support for tracks but I didn’t see anything with my GPX file. It may require a track that is in a KML format. If that was the case then maybe there is a way to manually find the point in the track that correlates to a specific time (when the photo was taken). This would at least be as accurate as the automated process, but still manual.

Let’s hope the next version improve this functionality.

Picasa 2.5 has recently been released with a few new features. I like the new screen saver that just cycles through your photos (I like the option to view all starred photos). I dislike the prominent placement of the “Save Changes” button that backs up your originals and replaces them with the edited copy. I don’t ever want to use that option but it is too easy to accidentally click on.

The most exciting new option is the addition of geotagging support. I have not yet had time to explore it but it appears to support geotagging of photos from within Google Earth and it recognizes geotagged photos inside Picasa. Unfortunately it looks like the geotagging is limited to manually placing the photos and there is no GPS coordination yet, but at least geotagging was important enough for them to include and takes it one more step into the mainstream. In theory I can view the GPX files in Google Earth and the photos, but I don’t know how useful or automated that will be.

Pros

• Geotagging support
• Picasa Web (for those who might use it)
• Direct ftp upload export
• New Picasa screen saver

Cons

• “Save Changes” button cannot be hidden or removed and is much to prominent.
• There is still no opposite of the “fill light” option in the quick edits. There is nothing equivalent to reducing the exposure, only brightening to increase the exposure.

I’ve updated the Blogger Image Import plugin with the ability to find images with spaces in the name. I had never noticed before, but any images hosted by blogger with spaces in the name were simply ignored because the %20 in the URL was being excluded from my regular expression.

Heather discovered that there was a problem and reported it here. I did some tests and realized that the % character was not being accepted as part of the URL and so any files with space (%20) were being ignored.

After a bit of trial and error I have fixed the plugin so that it correctly copies the files with %20 in their name and puts them on the local server with a space in its place. I have lifted some of the restrictions of the URL matching but it hasn’t caused any problems yet. Please test each import carefully looking for bad conversions and let me know if you find any.

http://notions.okuda.ca/wordpress-plugins/blogger-image-import/

I’ve been recently thinking about some of my goals for my own family web site and why they are not yet completed.

• I like the Blog format for sharing my photos as they get context and a story. Sort of like an online slide show, but better.
• I do have a photo gallery for the times when I want to post a lot of photos and there is too much for a blog. It doesn’t get a lot of use but it has its place. It is run by a very simple gallery script called mg2
• I am totally into GeoTagging my photographs. My ultimate goal has been to be able to show my photos on a map but I have never produced an efficient system for doing that. I have created enough individual pieces to convince myself that it is not difficult but bringing them together takes time that I don’t ever have.

The ultimate goal of all this is to be able to access my photographs in useful and interesting ways. Ways that add context or a story instead of just a bunch of photographs in a gallery. GeoTagging adds information and context to the photos but, by itself, isn’t much use unless it can be visualized correctly. In the end it is all about how that information helps me create a more interesting presence.

There have already been a few applications of online galleries that include maps to view geotagged images. WWMX is the first I always reference as it was way ahead of its time. It was an entirely proprietary system and difficult to use, but it had all the elements. Zoto was one of the first I heard of that merged Google Maps with photo galleries. Recently Flickr has joined the game and produced exactly what I want (with Yahoo maps).

All the commercial photo gallery sites, and even the free gallery applications, are broken up into at least two main parts. The database on the server to keep track of all the information about the photographs and the user interface to visualize that information. The problem that I have with the available applications is that they all do both halves of the work and are completely incompatible. Every photo gallery application that I can find online each have their own way of storing the information about the images (location, file name, interface structure, etc.). Some use a file on the server, some use the directory structure, and some use a MySQL database.

What I want is one system to organize the photos that I have on my site, all over my site. Not just another photo gallery or photoblog or Wordpress plugin, but an underlying system to keep track of everything. I want to separate the database from the distribution; the backend from the frontend. This seems rather logical, is an obvious software engineering practice and, as I said, almost everybody does this already. The difference is that I want to separate the two parts even more. I want to consider just one part of that, the database, and ignore the user interface for the moment.

What I want to build (or steal from somewhere) is a photo organization database and API for accessing that information. No user interface, no front-end, just the information storage. I want it to be extensible so that new information can be added. I want it flexible enough that it can be used by any sort of photo front-end. Something that can be plugged into a blog or gallery or map or some unique presentation system that has not yet been developed.

In a way, the file system on the web server already does this. It stores information about the image files and even helps in organizing them. It has an API that can be used to access information about the files. Unfortunately it only stores the name, date and a few other insignificant items. Ultimately, some more information can be saved in the file (particularly JPEG files with EXIF headers) but even that has limits, not to mention the performance overhead.

Step one – Build an enhanced meta information database
Something that can be used like a generic file system but can store much more information about a file and an efficient way to access that information. The schema for the database is important as it must be extensible for future updates, though upgrading the database in the future should be easy enough. Initially it would contain the location (server and URL), some meta information like width, height, Geocoded location, and some keywords. This would include a server (PHP) API to access that information.

Step two – Populate the database
Fortunately the image files on my server are all in file form on the host operating system. The new database can be populated from the existing database (the file system). A crawler should be written that can crawl a web site or the host file system and catalog every photograph. The actual location of the files in that file system is irrelevant. Think of this like Google Desktop for your server.

Step three – Update it as new files are added
Until every server application (gallery, blog, etc.) is using this API to maintain file details any new files added to the server will need to be added to this database. Rather than crawl the system regularly, a simple API to add the file to the DB should be created that can be used by all the existing upload or editing tools to indicate that there is a new file. Something so simple as to only need the name of the file. It should be very easy to insert a single PHP function call in the appropriate places for a few applications like mg2 and WordPress.

Step four – Convert existing applications to use this API
The ultimate goal of this is to, of course, have a user interface. Even better would be for all different interfaces to use this API to access the data. All the server applications from photo gallery to blog should use the one system. One at a time, either through plugins or larger modifications, this DB could be used to store some of the meta information required by the application. Rewriting the image database in MG2 comes to mind.

Step five – Write new applications using this API
If all we did was convert other image libraries to use this API then it would seem like a waste with minimal benefit. A new WordPress plugin that allows you to select photos from this database in the post editor would be a good start. A map based photo gallery is an obvious application that I want with a focus on geographic location of the images.

There are other things that can be done with this system too, but the ones above are a good start. Creating a system that can be used by a photo gallery, a Blog plugin, and a map based album is all that I want for now, and is my primary focus. These are the applications that I will be considering while designing the database and API. Comments are welcome and more details will follow as I flesh this out.