photonelly.com

It was only last week when I was talking about how life was getting in the way with my photography. Well, that hasn’t really changed, if it hasn’t gotten a little crazier.

The funny this about it, though, is sometimes I get so overwhelmed with everything else that I’m supposed to be doing, I actually take a step back and throw in a few hours towards something totally unrelated. This time around, the lucky beneficiary of that discretionary time was here at the website, with the introduction of the new Portfolio section.

The New Stuff

Admittedly there’s still more I want to do with the new section, but in essence, it’s meant to be simple. Along the same lines of creating my second Flickr account, the purpose of the new Portfolio section is to showcase the best of the best in the vast sea of photo archives I’ve managed to accumulate online up to this point.

Instead of trying to focus a single collection of the wide range of subjects I’ve been shooting (at least until I work on defining my style) I’ve created multiple portfolio sets. For example, there’s the obvious Maui Portfolio which is probably more than 50% of what I’ve shot. There are also portfolios for some of my best Hockey and Astrophotography images, just to name a few more.

Each portfolio still needs a little refinement here and there, but I was just happy to get what I have launched so I have something to work towards in the near future.

The Old Stuff

If all I had posted at this site was the Portfolio, it would probably be enough in and of itself. But since I first setup this site last year, I’ve also had two other somewhat related sections: Viewfinder and Favorites. They may seem redundant, but for now I’m keeping all three. Here’s a sort summary of why each is different.

• Portfolio – The new section that breaks down my best shots in different subjects/locations. The photos speak for themselves.
• Viewfinder – My favorite locations and subjects to shoot that are “in my viewfinder”. Each entry in this section has background as to what about that location or subject makes it interesting to me.
• Favorites – This is a deeper look behind some of my favorite photos over the years. Not so much of the technical aspects of getting the shot, more of the back story of each.

The Code

Again, my love affair with the Flickr API contributed to this new section. It actually started when I was working on the Wall of Aloha page a few months ago. It’s simple from the API side, just listing photos from a predetermined photoset on my Flickr account and just listing the thumbnail and then the larger size with the Lightbox 2 plugin.

The Portfolio section has a few additional hooks into WordPress that I’m just scratching the surface with. At the moment, it’s a new Page Template with the code behind it for pulling the photosetid and other parameters from custom meta tags. Going forward, it would probably be better suited as a plugin instead, but that might have to wait for another life.

Thoughts?

As always, check out the new section for yourself and if you have any questions or comments, I’m all ears.

– Kris

The Problem

So, while working on photos for my online photo calendar, I’ve been using Flickr’s official online photo editor, Picnik. For basic edits, cropping, etc., Picnik has been working just fine for me. However, I noticed early on that whenever I edited a photo using Picnik, the finished product would have it’s Date Taken value reset to the current date instead of when I originally took it.

Maybe that wouldn’t matter to some people, but I prefer to keep good records.

For the photo calendar images, I knew I was okay because I was saving the edit photos as new images (mainly because they were resized to be square). This meant I had two copies of the same photo, the original with the correct Date Taken and the edited calendar version with the date of whenever I edited it. This meant all I had to do was somehow copy over the dates from the original photos back over to the modified versions. Easy enough.

The Solution

All I really had to do for this was to make two simple calls to the Flickr API, the first to get the original photo dates and the second to update the new photo. Pretty simple.

Step 1: Call flickr.photos.getInfo with the original photo id, which you can get from the URL of the photo page. For example, here’s the URL and original version of one of the photos.

http://www.flickr.com/photos/webnelly/2456401712/

In this example, the photo id is 2456401712. Once I have the photo id and call the getInfo method, I can retrieve the Date Taken value back from the response data and save that for the second call.

Step 2: Call to the flickr.photos.setDates method with the photo id of the edited photo and the Date Taken from the original photo. I already mentioned how I got the original Date Taken, and I can get the photo id of the edited photo from the photo page URL the same was as the original.

http://www.flickr.com/photos/webnelly/3039946864/in/set-72157609319927215/

Here, the URL is a little longer because of the “in/set-{id}” part at the end, but that’s only because I saved all of the calendar photos in their own set. The photo id is still in the same place, and the one for this photo is 3039946864. Once I have that, I’m ready to call the setDates method.

Not Mentioned: The setDates method, as well as all the other update methods, require Write level permissions. Acquiring the necessary permissions is an entirely different discussion altogether, which I’m not going to cover here. Check out the API docs for more details.

Matching Up The Photos

Unfortunately, when you edit a photo using Picnik and save it as a new copy, there is no recorded link between the two of them. That means, despite being able to write code using the API to actually copy the dates over from one photo to another, I still had to manually track down the before and after photos.

That wasn’t terribly different for me because I had sort of planned ahead when editing these. I just mentioned that all the calendar (edited) photos are in their own Photoset, which keeps them in one place. For the original photos, I was tagging them as I was editing them, and used a tag dcal. I originally did this for purposes of not duplicating photos in the calendar, which you can imagine would be an easy mistake to make if you’re selecting 365 photos. It turned out to be just as helpful for this purpose as well.

So after I wrote and tested the code, the majority of the time was actually spent pairing up the before and after photos on Flickr, copying down their photo ids, and putting them into my little app. Worked like a charm.

I said it before, I love being a photographer and a web developer. Here’s another reason why.

Making an Online Photo Calendar

What started as an idea in mid-November turned into a relatively easy to make Google Gadget to showcase some of my favorite Maui photos. And all it took was:

• a little preparation,
• some convention,
• and 2 Flickr API methods

Sparing all the minor details, here’s the jist of what I did.

The Preparation
After making a small web prototype of the gadget, just to get the sizing and the HTML/CSS down, I determined that the photos I wanted to use for this would be square. Looking at the different sizes that Flickr offers you, the only “square” option by default is 75 x 75 pixels. Obviously, that wasn’t going to cut it.

So, that just meant I had to do a little cropping for each photo I wanted to use. If I crop the photo to be even on both sides, I now have the choice of 100 x 100, 240 x 240, or 500 x 500. Initially I thought 500 x 500 pixels would be great, but alas, making this fit onto an iGoogle page along side other gadgets meant I had to choose the 240 x 240 pixel size.

Just to keep track of these photos, I threw them in their own photoset on Flickr, which you can view here.

The Convention
I didn’t want to write a heck of a lot of code for this, which meant designing and populating a database full of photo IDs and dates was out of the question. Getting a little creative, I decided to use a naming convention for tagging these photos. Then, using the API methods mentioned later on, I could pull the photo for the current date based on the tag.

The convention I used was to prefix the tag with an arbitrary value (in my case, the letter “c”) followed by the month and day to display the photo on. An example would be this photo, which has the tag “c1117″ and would be displayed on November 17 (11 for the month, 17 for the day). Another convention I chose is to store the text for the calendar as the description of the photo. While this results in a second API call, which I’ll explain next, it was very convenient for having just one place to “edit” my calendar.

Lastly, since the Flickr Community Guidelines state that using a photo hosted on Flickr must link back to the Flickr photo page, I decided to take the opportunity to share more details about the photo by adding a comment on the photo as well. That way, if someone using the gadget likes the photo and clicks on it, they can see more info about that photo and, in some cases, view a link back to my Maui site. And of course, they could also leave a comment themselves (if they’re a member of Flickr, that is).

The 2 Flickr API Calls
Based on the conventions mentioned above, I really only needed the following information about the photo:

• The actual photo for a given day, based on the tag,
• the URL for the photo in the small format (240 x 240 pixels),
• and the description of the photo to display in the gadget.

It turns out the first two items can be returned using the Flickr API method, flickr.photos.search, and specifying the value of the optional Tags parameter as the date formatted in the convention above (i.e. c1117). That returned the 4 pieces of information I needed to build the URL for the photo, which of course are the farm-id, server-id, photo-id, and the secret.

The only thing that was missing was the description, which was just as easy to get with a second API call. This time it was to flickr.photos.getInfo, and merely required the photo-id returned from the first call.

With the data from those two method responses, I was all set to assemble the HTML and tell people what day it was.

The Rest of the Code
I already said I wasn’t going to dive into the minor details, but I did want to mention one other thing about this gadget. While I could have done this gadget completely with JavaScript by calling the Flickr API using the REST requests in JSON format, I chose to implement this logic using the XML format and a PHP script on the server side. The reason I did that was so I could save the responses from the two API calls on the server, so that way I could just use those files instead of calling the Flickr API every single time.

As for the Google Gadget code, that’s an entirely different area altogether and not worth covering here. While I chose to do this as Google Gadget, this can really be done with almost anything.

The Conclusion
Hopefully this was an interesting little article that gave you some ideas on things you can do with the Flickr API that you might not have thought of. For those out there that aren’t full fledged web developers like myself, that initial list of API methods might seem a little intimidating at first. But as you can see here, it’s fairly simple to tackle once you know how you want to approach it.

I have to admit, being both a photography hobbiest and a web developer can lead to some interesting ideas and fun challenges.

With the arrival of my new Rebel XSi yesterday (more details coming), I’ve officially become a 2 DSLR shooter and, in addition to my other cameras, I wanted a way to showcase and browse photos from each camera. With almost all of my photos hosted at Flickr, you think it’d be pretty darn easy, right? Well, yes and no.

Flickr does have the capability to read the EXIF data of your photos automatically, including camerea information, as shown below:

So that’s it, right? All you need to do is click on Canon EOS 20D and you can see all your photos with that camera. Actually, that takes you to everyone’s photos with that camera, not just yours. A little disappointing, and it made me start to think whether I was the only one who wanted this feature.

No worries, since I’ve used the Flickr API before to fix other issues, and knowing that the EXIF data for a photo was at my fingertips when using Flickr, I had myself a new little challenge to play with. The API method flickr.photos.getExif was sitting there waiting for me, and I was off to the races.

Knowing I could access the EXIF data per photo was part of the task, figuring out how to use it for browsing my photos was the other half. It didn’t take me very long to decide on using Tags as the solution to that portion, and I was all set. I cracked open Visual Studio 2008 Express (C#), brushed up on the Flickr.NET API Kit, and started hacking away.

So the overall design of my little hack is simple:

• Map the EXIF make and model values into different tags (i.e. EOS20D, SD890, etc.)
• List photos from my account and read their EXIF values
• Add the appropriate camera tag to each photo based on the EXIF values

And for the most part, that really was it.

One Little Snag

Just like everything, though, there were a few snags. The one worth mentioning is that some photos on Flickr didn’t have any EXIF values. Why? Well, it turns out for some sets that I uploaded when using JetPhoto Studio (just one example) to merge in my GPS waypoints for geotagging, it seems to have wiped out the EXIF data during the upload process. To demonstrate, none of the photos from my Road to Hana ‘08 set have EXIF data. Bummer.

So what to do now? It turns out I was saved by my own laziness.

I still have all the original photos that have all the EXIF data in them, so all was not lost. Unfortunately, Flickr doesn’t retain the original file name of a photo when it was uploaded, but since I have way too many photos to update individually, more than a few still have the original file name as the photo title (such as IMG_6298). While I’m not proud that many of my photos still start with IMG_, I was able to take advantage of it this time by matching the IMG_ file name on my PC to the title on Flickr and make the association that way.

Reading the EXIF data from a file on your local computer is a little bit trickier then just a simple method in the Flickr API, but it’s still doable. I didn’t use this exact code, opting to roll my own instead, but it helped me figure out where to start looking.

The Results

After only about 4-6 hours of coding and testing, the full update itself only took about 20 minutes to read and process some 2,600+ photos on Flickr. The results are individual links below to browse my photos by camera (via Tags).

• Canon EOS Digital Rebel XSi
• Canon EOS 20D
• Canon SD890 IS
• Nikon E5600, my wife’s camera
• Sony Cybershot DSC-P51, the dinosaur
• HTC Mogul, a few from my phone

Not bad for half a day’s work.

Still More To Do

That’s going to be it for now, other than featuring the links on my Cameras page. Another benefit of having this camera data saved as Tags (and also being a web developer), I can take advantage of some existing work I’ve done with the Google Chart API on my Maui site for my Island Tag Match.

Here, I used the Flickr API to search for a specific tag per Hawaiian island and chart the results. For my Cameras page, I plan on doing the same per camera model in my photos on Flickr.

In addition to just having a little chart, I can also use the Flickr RSS feeds to have separate feeds per camera model (again, via tags), and then mashup those feeds in a little preview panel on different parts of my site. Here’s an example of the latest photos I’ve taken and upload with my Canon EOS 20D. Gonna be fun once I start using my new Rebel XSi.

Another leftover from the code I wrote from this little hack is that I know have an XML file I was using between the reading photo data and updating tags portions of my hack that has each photo, it’s PhotoId, a title and the Geo tags if is currently has been placed on my map. One of the things I plan to do with that is add photos the maps section on my Maui site, where most of my photos that have been geotagged were taken anyway. A nice little bonus.

Other Fun with Camera Data

That’s all from me, but I thought I’d share a few links of what Flickr and others have done with the camera information from EXIF data. BigHugeLabs.com, home to fd’s Flickr Toys, has a cool ranking section that shows off the most used cameras on Flickr. Flickr themselves have a nice little camera finder that let’s you not only browse through different makes and models, but also see photos on Flickr taken with those cameras.

If you’ve seen a similar hack or know of a site out there doing something cool with this time of camera EXIF data, please do tell.

Thanks,
– Kris.