Yesterday, flicker gave us two new shiny toys to play with. The big one, collections, has been in demand for a long time, and as a overactive set user, I’m very pleased to see that this is now available. The smaller one allows flickrites to change the layout of their entry page. The choice is fairly limited but I am certainly not complaining.

To change the layout of my “You” page, I went thru the menus: You->Your Account. There is now a new option added to allow me to pick out which layout I wanted. The choices are small images only, small images plus sets (the original default), small images plus collections, medium images only, medium images plus sets, or medium images plus collections. Since I promptly sorted all my sets into collections, I chose the small images plus collections option which worked a treat.

To create collections, use the Organizr. The “Sets” tab is now “Sets and Collections.” It’s all pretty intuitive to use: when I choose to create a new collection, all my sets are displayed to one side, and I can drag and drop (and reorder, etc) sets into the collection.

Sets use a particular picture within the set to create its visual identification; collections use a mosaic of nine pictures to create its visual identification. I believe there are still some bugs with creating the mosaic representations. In several cases, the mosaic insisted on using pictures from one particular set within the collection, instead of a nicely distributed random set. In one case, the pictures chosen are from a set not even in the collection!

Collections are not available to free flickr accounts. This makes sense as free accounts are also limited in the number of sets they can create, as well. However, choosing different layouts is available, with the small/medium pictures + collections options omitted.

The announcement of the new features are up at Flickr’s Blog.

In another quick and simple process, I personalized my About page a little with a bit of flickr html/java that they supply. Of course I’ve worked directly with their API, but in this case that’d be using a sledgehammer, since the good folks at flickr also provide a nice little javascript snippet to randomly select a couple of pictures/thumbnails to drop right in. I went to flickr’s badge generation page (logged in as moi, of course) to get started.

First I chose HTML. This is because I have serious issues with flash, although I admit the boxy thing it comes up with is pretty cool. On the next page, I was asked to choose which pictures to display. I chose to display any of my public photos although it’s possible to choose one or more tags or a particular set from which to select pictures for display. That could be useful for something fairly strong-themed: animal pictures for an animal focused blog, for example. Since I don’t have sexy computer photo shoots, I didn’t use either of those options. In the third step, flickr asked me questions about the layout: usage of buddy icon, number of photos, the size of the photos, and vertical or horizontal (or other, using personal style options) orientations. Finally flickr allowed me to specify colours and background for the snippet and gave me the code, which I dropped into my About page.

From there I made two modifications. The first was to add display:inline; and float:right; attributes to the table wrapper around the pictures so that it would display as I wished on the page. But I also cut out the <style> included with the snippet and put it in my css style file. That last is optional, and possibly not what someone else would want to do because changing the theme could lose the styling in that page. (Of course, I have my own workaround this situation, since I use a common.css that’s independent of theme styling which I accomplish via a private plugin that I should clean up and make available one of these days.)

I have been playing around with the Linux version of Picasa for the last week or so, as the need to organize my pictures in some way became more urgent.

Installation

The Linux version of Picasa is available for download on this page. There are several options — rpm, deb and bin packages, each with instructions. I had no trouble downloading and installing the deb package on my Ubuntu 6.06 setup.

Unfortunately, Google does not include instructions for using the package manager on these pages; they are to be found in the FAQ instead and if I were to do this over, this is how I would install:

Add the Google Picasa for Linux repository:

deb http://dl.google.com/linux/deb/ stable non-free

and now apt-get can be used:

sudo apt-get update
sudo apt-get install picasa


The Good

When Picasa starts up, it immediately begins to scan the hard disk drive for pictures. It will scan everything for anything remotely image-worthy. This can lead to some interesting results as it will pick up images used by various installed applications.

Under the Tools->Folder Manager menu, I found a dialogue to mark which directories to look at or ignore. I can tell it to scan particular directories once or always; or to ignore them altogether. I chose to have it continually scan only my home directory and this got rid of many of the spurious images.

The really cool part was finding photos I had completely forgotten about and which were lost in the general directory disorganization resulting from having migrated from about three or four hdd’s and two or three computers in the last seven years.

One thing I like quite a bit about Picasa is that it leaves the original images alone (except for red eye fixes) unless I tell it otherwise. (Some people will file this under “The Ugly;” it’s going to be a matter of personal opinion.) I have discovered, in going over something like seven years of pictures that having the original “raw” (not to be confused with RAW format) upload makes all the difference in recovering the original quality of the pictures.

Pictures downloaded from digital cameras are in JPG, which is a lossy compressed format. The practical consequence of this is that each edit to a JPG file (depending on the software used, sometimes even something as simple as rotation) usually results in loss of quality in the saved version. So I want to always keep the original files around as the baseline for going back to especially if I mess up a series of edits.

I organize my pictures by year, with each event or topic getting its own sub directory within that year. Last year, I started including a “raw” directory which is supposed to be where I upload all the camera images and then copy them over to the organized sub directories. So for example, the year 2005 might contain the following directories: raw, january family dinner, easter, home improvements, fourth of july, rome trip, thanksgiving, and christmas. The “raw” has all photos taken, ever, in 2005; the remainder are the best pictures for that event, sorted out, rotated, color corrected, with blurry or bad pictures omitted. Now I admit I’ve been a bit piecemeal about that approach, but after working with Picasa for a while and being able to see all of my photos over the last seven years at a go, I’m an enthusiastic convert now.

Picasa works perfectly with this approach. Let’s say my next set of pictures is from my brother in law’s birthday party next weekend. I’ll upload all the pictures into my “raw” directory, and then go over them with Picasa — correcting, rotating, etc. Then I will export the chosen pictures into “A’s B-day” directory within the 2006 folder. Voila!

Picasa arranges the photos it finds by date, within the name of the folder it’s found them in. This has some drawbacks, as it creates a flat list. Therefore several of my directories which each had “web” subdirectories (holding smaller versions for various websites) showed up as multiple “web” folders in Picasa, which is a bit confusing. But either I can rename the directories themselves, or tell Picasa to use a different name for the folder. Still it can be a bit confusing to see multiple instances of the same filename occurring. This was especially bad with one set of trip pictures I had — the main directory was named “Red River” and then under that it had a directory for each day we were there, and then under each day-directory, there were three folders, one for each photographer with a camera, since we pooled all our pictures together. So in the end, I had multiple folders each with the photographer’s name. Each “leaf” directory within a particular year should have as unique a name as possible, or else the folders can be renamed in Picasa.

Picasa supports tagging of each picture, and that builds up a list of labels above the folders. Clicking on any of the labels (tags) pulls up all the pictures so tagged, which is a great way to help keep pictures organized.

When viewing individual pictures, Picasa offers a number of “editing” options. As I’ve mentioned, changes aren’t actually made (with the exception of red-eye fixes) to the files themselves. These corrections are more like overlays maintained by Picasa and include the basics like rotation, color correction, fill lighting, saturation and so on. It’s very fast and snappy when working with files, and it does a very good job at cleaning up files. I found the “I’m feeling lucky” button to work particularly well when involving photos of statuary and paintings. If I want to save these changes to actual files, all I need to do is to export them to another directory.

The Bad

Because of issues with driver support, Linux Picasa cannot burn to CD. This isn’t a show stopper for me; I prefer to use my own software for this, but it’s a pity this isn’t integrated into Picasa since it’s usually a timesaver.

Also related to the lack of uniformity across Linux installations, Linux Picasa is a bit wobbly with handling some issues such as which browser or email program to use, or how to access directories and files. There are template files intended to provide such specific information on what to do in a particular installation. The FAQs reference these files in passing, but unfortunately not in detail. They are:

picasa/desktop/picasa-hook-filemanager.sh.template
picasa/desktop/picasa-hook-urlhandler.sh.template
picasa/desktop/picasa-hook-email.sh.template


I first had to find the template files in question. Finally by using

locate picasa | grep desktop

I was able to determine the files resided in /opt/picasa/desktop. The file is not terribly helpful though. I copied the template file into my own ~/bin directory and played with a couple of settings. I tried a couple of things, here’s my final list:

#/usr/bin/nautilus "$1":h
#/usr/bin/konqueror --profile filemanager "$1"
#nautilus `dirname "$1"`
nautilus "${1%%$(basename "$1")}"

I did google for any examples anyone else may have constructed from these files, but the best I found was this, which was interesting, but not the level of detail I was looking for.

But the real problem wasn’t the contents of the script. The problem was in getting Picasa to recognize and hence execute the script! Like a good little unix weenie, I copied the file from its opt home into my local bin directory, chmodded it to 755, made my additions, and restarted Picasa. Nada. Checked my path with printenv. The bin dir was listed. Executed the script directly with a couple of path names, everything started up fine. In desperation, tried copying the file back to the picasa/desktop directory, still no dice.

The only thing that finally worked was to drop the script into /opt/picasa/bin. However, the Google documentation on this point is at best misleading, since it implies that the file need only be somewhere in the path, but clearly it’s only looking in one of a few places such as the bin directory. Grrr.

The Ugly

For some unknown reason, the Linux version of Picasa does not come with an export button to the Picasaweb site. As a result, I’m forced to upload pictures manually using the browser. Which is rather like shovelling coal in the nuclear fusion age.

I also found out that it’s not a good idea to change permissions on directories (or to rename or move them) after one has made extensive “changes” and tags to those directories. Ahem. From Picasa’s point of view those files are gone, and so it discards the meta data it’s got on those files.

However, I can’t really think of a good way for Picasa to handle this kind of thing. If a directory is suddenly inaccessible, what else can it do but assume the files are gone? The only way around this would be for Picasa to store the metadata (tags, etc) with each picture file itself and I can’t see that being done. It’s a possible argument that Picasa should at least save the edits to the file but there are two ways around that: either export a modified folder to a physical folder or tell it to save the actual changes to those files. If the metadata is saved within each folder, all that has to happen is for someone to move the files to another directory, rather than renaming the directory.

So it seems to me to be a fairly nasty situation with no good work around. And since the real issue is the meta data, I don’t even consider this a side effect of the no-modification-to-original philosphy that people either love or hate because the meta data question remains whether or not edits are saved to the files or not.

Flickr versus Picasa Web

Ironically enough, since Linux Picasa does not have the web export button that Windows Picasa does, it’s much easier to upload pictures to Flickr. Since overall I prefer Flickr’s options and interface to Picasaweb’s, this turned out to be a plus for me. To send pictures to Flickr is quite easy, especially when I use my gmail account. In the past few days I’ve sent almost 2000 pictures to Flickr!

I first set up an email address at Flickr. The folks over there will generate a random email address for their users. I can email pictures to this address along with various options in the subject line and they will show right up in my Flickr photo stream.

Now I select the pictures I want to send. I can send up to six pictures at once if I have set the email options (Tools->Options->Email: from here, set the gmail account, size of picture and so on).

Since Picasa is a google product, it interfaces very nicely with gmail. Once I log in with my gmail password, I can select up to six medium sized pictures, choose File->Email (or the handy ^E). I can tab through gmail’s known email addresses to the Flickr-generated one, choose that, and then set the subject line to what I want as the title for those pictures. I then add after the title (still in the subject line) a tags: tag1 tag2 which lets me set the tags for those pictures. Then I clear out the message body and either leave it blank or write something appropriate to all the included pictures and send it off.

Voila!

In contrast, the only alternative way I could find to upload to my Picasaweb site was a browse/upload page provided by picasaweb itself which was so painfully slow, I don’t want to bother with it again. I’ll revisit Picasaweb once the upload button is included in the Linux version of Picasa. On quick scrutiny, though, Picasaweb has very few features at the moment and not very much storage space as compared to Flickr.

Oh, you wanted to know where my Flickr photostream is? Right here If I know you in real life, drop me a note and I’ll add you as a friend contact if you really want to see all 2K pics . Otherwise, feel free to look over my public photos and add me as a contact if you like which I will reciprocate. I always enjoy browsing pics…

Summary

Overall, I’m impressed with this program despite the fairly extensive “bad” and “ugly” sections. I do not understand why some features were left off the Linux version, and I hope that this will be fixed in the future.

I really dislike having to install perl modules locally. But sometimes that’s the set of cards I get dealt. And in all honesty, once it’s properly set up in an account, it’s easy to add on any others at a later date. So. I generally start with a local perl directory, in $HOME/perl, to keep things tidy. Otherwise I wind up with a more generic bin and lib sitting out there, and there’s lots that use bin & lib that have nothing to do with perl.

I add env variables:

if [ -d $HOME/perl/lib/perl5 ]; then
        PERL5LIB=${PERL5LIB:+$PERL5LIB:}$HOME/perl/lib/perl5
fi
MANPATH=${MANPATH:+$MANPATH:}$HOME/perl/share/man
export MANPATH PERL5LIB

(or if you prefer csh style — which I do, but I haven’t bothered to switch these bash shells around yet — I may, if I get irritated enough)

setenv PERL5LIB      $PERL5LIB:$HOME/perl/lib/perl5
setenv MANPATH     $MANPATH:$HOME/perl/share    

You can use printenv in most shells to double check the settings and make sure they “stuck”.

There really doesn’t seem to be any one place that combines all the info I use for a local install. I usually start out with this one which is almost complete but it leaves out salient details such as exactly how to start up cpan (which I always forget, it has such forgettable syntax) and doesn’t really contain tips for troubleshooting (there’s always troubleshooting).

However, it provides a perfect MyConfig.pm file to get started with, so I copy that into the ~/.cpan/CPAN/MyConfig.pm and follow the instructions it has in the comment section at the top. After the localizing alterations, I can run perl -c MyConfig.pm in order to make sure I haven’t done something boneheaded.

Now I’m ready to rock and roll. Get into cpan via perl -MCPAN -e 'shell' and now I can start installing. The help file I listed before suggests checking the changes I make to MyConfig.pm via a make on Text::Autoformat. I don’t really bother anymore but it’s a handy way to check that the variables are all correct.

Let’s say I want to install Flickr’s API. So I go with install Flickr::API. It will ask me some questions. What I have found out about CPAN is that most of the time (as in 99% of the time), the default is a perfectly good way to go when it asks questions. Quite often when I install something, it will suggest other things that should be installed or updated, etc. I just go with the flow on all that.

When I nibble around this article you’ll see more tips and such on unprivileged perl installs. Obviously installing your entire local copy of perl isn’t the way to go for the most part (and neither am I actually trying to install Bugzilla, at least not in this little essay), and they discuss a slightly different way of setting up the MyConfig.pm file, but there’s other goodies such as force install which I can try if I get nasty messages after attempting a plain install. Also what frequently helps me is to try installing the noted dependency packages on their own. Take the Flickr::API — it also wants XML:: Parser::Lite::Tree:: XPath and will inform me of that while installing the Flickr stuff. And sometimes it will take care of it, and sometimes it won’t; doing a separate install on that often works.

The last bugaboo I generally wind up dealing with, especially since I mostly write perl for cgi scripts is the transition from running on the command line to calling it from a web page. All the previously mentioned steps get the perl working on the command line, but then it can still turn into a big ol’ Internal Server Error mess when I try to go online.

The problem is, of course, that the http client isn’t accessing my pretty MANPATH and PERL5LIB paths for the extra info. This is where tweaking the @INC array helps: I can be all perl hacky and do something like BEGIN{unshift @INC, "$HOME/perl/lib/perl5"} (note that $HOME itself won’t actually work here, I use it for shorthand notation — replace this with the full value of $HOME in this case). But I just discovered this tidbit when googling and trying the use "$HOME/perl/lib/perl5"; worked like a charm! I’ve posted this previously only at another location: the flickr slideshow. Because www.sclrr.org is on a different server than is www.io.com/~sclrr, I had to re-install the perl libraries, and find a different solution to the path problem.

One of the problems with the SCLRR’s main page is that “slideshow” on it. It’s really an animated gif. Now there’s tons of (mostly Windows based) software out there for creating gif type slideshows as any google search will show you. But remember that I try to make this site pretty easily usable by the average volunteer. So for example that Dog of the Month you see is pulled out of the database with a bio that’s all done in the volunteer only section of the website. They don’t have to do anything more than check off the dog they want displayed and voila!

So I wanted something similar for the slideshow. I also wanted some way of uploading the pictures pretty easily. So I got the bright idea of using flickr. They’ve got an API. So the idea went something like this: I create a perl script that uses flickr’s API to pull out a list of pictures with a certain tag and then I rotate through those pictures in the file. So from the volunteer’s point of view. all they have to do is manage a set of pictures on flickr — which has a nice easy to use interface, and to which access can be given without compromising the shell account. Hey I love these people dearly, but I cringe at the thought of a non-technical person stomping all over the files in the account by accident. (I mean I have everything regularly backed up but still.)