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

I’ve been a big fan of the photo sharing site Flickr for going on three years now. In fact, I was using Flickr before I knew what Twitter was, had a Facebook account, or even before I put together my original Maui website.

Yup, Flickr and I go way back, even before they hit their 500 millionth photo (we’re talking pre-iPhone photos, people). For grins, I went back and checked and my first photo uploaded to Flickr back then was a shot of me reading a book on a cruise back in Feb’ 07. Wait, a book?!? That can’t be right. There’s not a technical diagram or code listing on those pages. Must have been some vacation.

Nevermind. When I first started using Flickr, I was mostly in shoot-and-share mode, where I would just unload a memory card, pick out the bad ones and basically upload the rest as-is. For example, my first photoset was of the images I shot at the Sheraton Maui Resort on our first visit to Maui. At the moment, that set now has over 100 photos in it. Of just one resort.

But that’s how I started with Flickr, not knowing much about anything.

The Mess

Okay, maybe mess is a harsh word, but I feel know that with over 4,500 photos filed away in over 100 photosets, this has gotten a little harder to manage. Especially now that I’ve taken a more focused approach to my photography, editting, sharing, and promotion. As I network and met other photographers on Flickr and elsewhere, it’s hard for them to find my best stuff buried in everything. Even if I had a photoset named MY BEST STUFF in all caps, that still sits with all the others already there.

This has come in super handy in terms of archiving, tracking my travels, and even hosting photos for my different websites. Not to mention the neat things I’ve done with the Flickr API, like my Maui Day Calendar Photo, some custom site integration work, even the daily photos here on the home page. That stuff has really been a blast to work with.

But alas, it’s time for me to get serious with this and hand-pick the best of my photos, and share and promote the separately from the rest in my archives. Hence…

The Reset

While my original Flickr account will be untouched, I decided to create a new photonelly account on Flickr. The new account, as mentioned, will be home to my very best works, both straight photographs and some other creative techniques I’m working with now.

This is certainly going to take a lot of time and effort until I’m satisfied that everything I want to move over is ready for prime time. After all, I have to go through all those archives and a few “keeper” photosets I’ve stashed my favorites in to dust them off, apply the latest post-production skills I’ve picked up in the last year, and upload/add them to the new account.

To give you an idea of what that’s going to take, I put together a little graphic with the ones I’ve done so far.

Yikes!

So, what will the magic number be when (or if) I ever finish? Who knows. Maybe 60, 100, possibly 120. There’s definitely going to be a balance between shooting and editing new photos vs. going back and edit older ones, that’s for sure. The goal is clear, though. Make sure the images I’m really, truly proud of are easy to share and can be found by as many current and future friends that I make along the way.

Thoughts?

Whatcha think? Am I crazy for trying to take this on, or just crazy for letting it get this bad in the first place (you know my vote). If you have any ideas, tips, or feedback on this type of move, or did something similar yourself, I’d love to hear about it.

Thanks,
– Kris

A quick follow up to an issue with Picnik that I mentioned last week.  One of the folks at Picnik took the initiative and tracked me down on Flickr, requesting details on the issue I was having and how to reproduce it.

At first, I thought I was losing my mind when retracing my steps.  As the rep from Picnik mentioned, he did a few tests and all the EXIF data (including Date Taken) were in tact. For my sanity’s sake, however, I was able to help them isolate this issue down to using the Crop feature in Picnik.

So for now, it looks like I’ll still be using my mini Date Taken update app for some of my post editing needs, but hopefully for not much longer. Kudos to the folks at Picnik for going the extra mile to help identify and correct issues that their users are having. Hopefully we’ll see a fix for this soon.

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.