Category: Computers and Internet

Yesterday, I wrote up a comparison between the current versions of Picasa and Windows Live Photo Gallery. Lying awake in the small hours last night, I thought of additional things that I should have covered in the comparison. So if you read the entry yesterday, I suggest you take another look at it. It’s now been considerably reworked and expanded.

Google’s Picasa and Microsoft’s Windows Live Photo Gallery are free tools for organising, editing and sharing (via the web) collections of photos on your PC. They have both been around for some years, and have each gone through a number of iterations, adding features each time.

I first blogged about Picasa back in 2005, when I compared it (favourably) with Microsoft’s Digital Image Library, a product that was subsequently discontinued by Microsoft, and replaced by Windows Live Photo Gallery, which was released in 2007. As each new version of Picasa or WLPG has been released, I’ve taken a look at them and blogged about my findings. Up until a couple of days ago, the latest versions meant version 3.8 of Picasa and build 15.4.3538.513 of WLPG. These are fairly evenly matched in features, but they both suffer from issues such that I do not make much use of them.

Picasa version 3.8 would not display my geotags correctly, as you can see from the examples I show in this blog post. And once Microsoft had corrected a horrendous geotagging bug in WLPG, I was still left with the fact that WLPG will merrily corrupt Makernotes in Exif metadata if you use it to edit metadata or tag people’s faces. That Makernotes corruption bug was acknowledged by Microsoft a year ago, but it is still there in the latest build of WLPG.

Now, Google have just released version 3.9 of Picasa, so I took a look at it to see what has changed.

Geotagging and Geocoding

Picasa and WLPG handle geographic metadata in completely different ways, and it’s as well to be aware of the distinction.

There are two main approaches to handling geographic data: Geotagging and Geocoding. In short, geotagging is the process of adding coordinate data (i.e. Latitude and Longitude) to an image file’s metadata, while geocoding is the process of using other forms of geographic data (e.g. a street address) to derive the coordinate data for that location.

Picasa has gone down the geotagging route, hence the use of the map interface. When you place a pin on the map displayed in Picasa and associate it with a particular photo, Picasa will write the GPS coordinates of the location’s Latitude and Longitude into the image file’s Exif metadata.

WLPG, so far, does not have a mapping interface for handling geographic data. That’s because WLPG does not do geotagging: you can’t use it to add coordinate data into an image file’s metadata. However, and somewhat confusingly, you’ll see that WLPG has provision for what it calls “geotags” to add geographic metadata into an image file. This metadata is not coordinate data, but textual data, e.g. a street address, and when you add “geotags” to an image, it will store the information as XMP metadata in the image file.

If a file contains GPS coordinates in the Exif metadata when it’s brought in to WLPG, then reverse geocoding will be triggered automatically and WLPG will assign a location address to the file based on the GPS values. It does this by sending the GPS values to an online Bing service, which then returns the location as text strings.

Let me try and illustrate this. Here’s a screenshot of a photo being displayed in Picasa, and I’ve used Picasa to assign a set of GPS coordinates to the image file, by moving the red location pin to the correct location on the map:

When I save this location to the image file, Picasa uses the online Google Maps service to find out the GPS coordinates of the location and writes them into the image file as Exif metadata.

Since the image file now contains GPS coordinates in its Exif metadata, when I look at the same file in WLPG, you can see from this screenshot that WLPG has performed reverse geocoding by using the GPS coordinates to derive the closest address for where the photo was taken, in this case, Energieweg, in Doetinchem, in The Netherlands:

Under certain circumstances, WLPG can store this address information in the image file, using the IPTC Extension LocationCreated metadata fields. Since this is a cross-industry standard, other applications that support this standard should be able to work with the metadata. However, you cannot use WLPG to create GPS coordinates for an image. Perhaps in the next version?

One point to be aware of is that although WLPG will automatically generate its “geotags” from GPS data that has been set by Picasa (or any other geotagging application), Picasa will not do geocoding; that is, it will not automatically generate GPS coordinates from the IPTC Extension LocationCreated metadata fields – it simply ignores them, and will not even display them in the information panel in Picasa. This means that if you use WLPG to set “geotags”, you need to go through the photos again with Picasa if you want to have proper geotag (i.e. coordinate) data in the photo metadata.

I do wish that Microsoft hadn’t called this metadata “geotags”, because it is not, in the generally accepted sense of the term – it’s not coordinate data. It would have been better to name it “Location”, because that’s what it is, and it also refers back to the IPTC LocationCreated metadata standard.

On a more positive note, I’m very pleased to say that the geotag display problem of version 3.8 of Picasa has gone, and geotags are now displayed in their correct locations on the map. Here’s the screenshot I used to demonstrate the bug in my blog post of version 3.8 in September 2010 (click for the full-sized version):

And here’s the same folder of photos in version 3.9 displaying the correct locations of the geotags on the map:

Captions

As the old joke goes: the great thing about standards is that there are so many to choose from. I’ve noticed that Google and Microsoft have interpreted the IPTC Core standard slightly differently in at least one area, and that is in the captioning of photos.

Take another look at the single photo being displayed in Picasa. Notice that it has a caption (showing underneath the photo) that reads: Public art in Doetinchem.

Now take a look at the same photo being displayed in WLPG. I’ll show a new screenshot below, since in the first screenshot, the caption was being obscured by the “geotag” information:

In the information panel to the right, you will see that the caption reads: 20090818-1201-41. In both cases, this is the same photo, so why are the captions different? The answer is that Picasa uses the “Description” metadata field from the IPTC Core standard to display the caption for a photo, while WLPG uses the “Title” metadata field from the IPTC Core standard to display the caption.

Frankly, I think that Google have made the right choice and Microsoft the wrong choice. If I look at the IPTC definitions of the two fields, I read the following:

I’ve followed these definitions for my own photos. I use the filename of the photo to set the Title field (it’s the date and time of when the photo was taken as a reference), and I use the Description field to hold a caption describing the content of the photo.

Also, if I use Flickr to upload the same photo to my Photostream, you can clearly see from this screenshot that Flickr actually displays both the Title and the Description fields under the photo:

Both Flickr and Google seem to me to have made the correct interpretation of the IPTC Core standard, while Microsoft’s WLPG team has got it wrong. However, I think that there’s little chance of them changing now. We’re probably stuck with it. Curiously enough, the WLPG team seem to have struck out on their own here, since they use different terms to those used in Windows itself. Here’s a screenshot of the photo being displayed in Windows Explorer:

Notice how Explorer does actually use “Title” according to the IPTC Core definition, and using “Subject” to align with the IPTC Core definition of “Description”. So Windows is better aligned with the IPTC standard for photo metadata than WLPG…

Descriptive Tags

Both Picasa and WLPG support the use of descriptive tags, and both use the “Keywords” metadata field from the IPTC Core standard to display the keywords, or descriptive tags for a photo. This means that the same photo should be displayed with the same set of descriptive tags in both Picasa and WLPG. And, subject to one slight quirk, that’s what they do.

The quirk is caused by the fact that I use hierarchical tags with my photos. That’s to say that, for example, my tag cows is actually part of a hierarchy that starts Nature/Animals/livestock/cattle/dairy cattle/cows. That way, when I search for photos with the tag cows, it will just show me those with cows in them. But if I search for photos with the tag livestock, it will show me photos of cows, horses, pigs, sheep, and so on. I use a tag hierarchy because I find it more flexible than an enormously long list of single-level tags. See this blog post for more detail of how I tag my photos.

The quirk shows itself by the fact that WLPG displays just the last term in a tag sequence; e.g. for a photo that is tagged with the tag Nature/Animals/livestock/cattle/dairy cattle/cows, WLPG will just display “cows”. For our photo taken in Doetinchem, WLPG displays this for the descriptive tags (see the screenshot above):

Doetinchem
pylon
sculpture
walking

Picasa, on the other hand can’t deal with a tag hierarchy in a friendly fashion, and has to display the whole sequence:

As you can see, this gives rise to problems in handling long tag sequences: the Quick Tags buttons can only display the beginning of a tag sequence, rather than displaying the last term in the sequence.

Mind you, WLPG is not perfect in this area, either. Both could do with improvements. For the moment, I’ll be carrying on doing tagging and other metadata work with my preferred tool: IDimager. (Note: IDimager is no longer available. Its successor is Photo Supreme, which I am now using)

People Tags

Both the current versions of Picasa and WLPG provide face recognition technology, so that you can easily tag people with their names. However, while WLPG used XMP to store the people tag metadata in the image files, version 3.8 of Picasa stored the tag information locally on the PC. This meant that it was very difficult to share tag information across multiple machines, since the tags did not travel with the file. I notice that in version 3.9 of Picasa, there is now an option to store the name tags in the image files themselves. Unfortunately, at the moment, there is no real information available from Google as to what this actually means. Are they using XMP? If so, is the schema documented? Microsoft have documented what they do for people tags, but so far I have not seen anything similar from Google.

I’ll be prepared to bet that the two approaches for people tags are not compatible; that is, if I tag people in Picasa, those tags will not show up in WLPG, and vice versa. It’s been a year since the Metadata Working Group published their guidelines calling for standardisation in the area of people tagging. I doubt that we’ll see fast progress, or any progress at all, given the fact that Google and Microsoft have probably planted their flags in different places.

Update 13 December 2011: Well, there’s a surprise: Picasa version 3.9 is using the XMP metadata fields proposed by the Metadata Working Group for people tags. See this thread on the Picasa Help Forums, where this is stated. I’ve just checked this, and I can confirm it. This is excellent news. It also means that Google has adopted the proposed industry standard ahead of Microsoft, who are still using their own XMP schema. That’s a bit ironic, considering that Microsoft are one of the founding members of the Metadata Working Group. It will be interesting to see whether Microsoft will adopt the same standard for people tags in a future version of WLPG. Then, like descriptive tags, people tags can also be shared by Picasa and WLPG. If Microsoft do adopt the standard, we’ll probably see at least one version of WLPG where both standards are used, in order to provide a transition period.

And here’s a second surprise: it looks as though Picasa 3.9 can read WLPG people tags, so there is at least some degree of compatibility between WLPG and Picasa regarding people tags. I think I’ve lost my bet.

I discovered this because Picasa started assigning names to some faces, without my having to do so. This could only mean that it was getting the names from somewhere, and that turned out to be from the Microsoft people tag metadata in some files – I had used the face tagging capability of WLPG on some files before I discovered that WLPG was corrupting Exif Makernotes.

Unfortunately, Picasa doesn’t use this information to then write back the face tags into the file using the Metadata Working Group schema, but just holds the information in its local database. I’m going to have to find some way of wiping out all trace of the Microsoft people tags, and then apply them exclusively from within Picasa. Since for those files, the Exif Makernotes are already corrupted, I’ll try using WLPG to delete the face tags and see what Picasa does…

Update 14 December 2011: Right, I’ve been playing around with the people tagging feature, and this is what I’ve come up with:

• Picasa 3.9 will read WLPG people tags and create people tags in Picasa’s local database only (they are not written out as metadata to the image files).
• Picasa 3.9 will read people tags created in earlier versions of Picasa that are held in the local database. It will not write pre-existing tags out as metadata to the image files.
• Picasa 3.9 has an option to store people tags as metadata, in addition to holding them in the local database. This option is not retroactive; that is, once selected, Picasa will not write out pre-existing tags to the image files, but only write out metadata on newly-created people tags.
• There seems to be no way to force Picasa 3.9 to write out pre-existing people tags as metadata to the image files.
• The current version of WLPG will not read Picasa’s people tags, either from Picasa’s database, or from the people tag metadata in the image files.

In the end, what I’ve had to do is:

1. Ensure that all people tags were deleted from WLPG.
2. Uninstall previous versions of Picasa, and delete the Picasa database.
3. Search for all Picasa.ini files that Picasa strews through your picture folders, and delete them.
4. Do a fresh install of Picasa 3.9, and ensure that the option to store people tags as metadata in the image files was enabled before starting to do any people tagging work.

Clearly, this is a bit of a pain if you’ve already done extensive people tagging in either WLPG or Picasa, but I see no alternative at the moment. That is, if you want to prepare for the future and hold people tags as industry-standard metadata in your image files.

Update 2, 14 December 2011: Sigh, it looks as though storing the people tags as XMP metadata into the image files with Picasa 3.9 is buggy. I’ve found that, even though the option is selected to write out the metadata, not all the image files have the people tags written out to them. Even though Picasa is showing people tags, the images themselves do not have the XMP metadata written to them. I’ve raised this as a potential bug in the Picasa Help forum.

Update 3, 19 December 2011: I think the comments made by Ben below are worth including here in the main entry (for the benefit of people who read the entry, but not the comments). He has found a few more people tagging behaviours worth noting:

1. WLPG does not read the Iptc4xmpExt:PersonInImage tag.
2. Picasa does read the Iptc4xmpExt:PersonInImage tag, but this information is buried in the properties, labelled “Person Shown”. People tagged in this manner will not show up under the “People” pane or in the “People Manager”. Likewise, you cannot search for people that are tagged using this tag (as far as he knows).
3. WLPG allows you to tag a person without specifying the area they are in. If you tag someone in WLPG without drawing a box to indicate where they are, they will not show up in Picasa. As already pointed out, people tagged in WLPG that DO indicate where they are in the photo will show up in Picasa as expected.

Update 4, 20 December 2011: Another Picasa bug has crawled out of the woodwork. I’ve just discovered that of the 1,895 photos that Picasa has written name tag metadata into, seven of them have had their “Date Taken” and “Date Created” metadata overwritten by the date/timestamp of when the file was modified, i.e. had the name tag metadata written out to them.

I think it’s time to stop using Picasa version 3.9. There are just too many bugs present in the current build (135.80,0).

Synchronisation Between Online and Local Photos

One area where I think Picasa is still ahead of WLPG is the ease of sharing photo albums online, and keeping them synchronised with the photo albums on your PC. With a single mouse click, any folder of images on your PC can be mirrored online and the two kept synchronised. And this is a two-way sync – changes made locally on your PC will be automatically reflected in your online web folders, and vice versa. Very nice.

In the current version of WLPG, while you can publish images from your PC to a variety of online sites (e.g. SkyDrive, Flickr or Facebook), these can’t be automatically kept synchronised. This is a rather surprising omission, particularly since Microsoft have provided online synchronising technology for some years. However, the issue was that they had a couple of competing approaches. I suspect that there is a major technology revamp going on behind the scenes, and that the next versions of Windows Live Mesh and WLPG will provide at least the equivalent of what Picasa is already doing. We may have to wait for Windows 8 to see real results from Microsoft in this area.

Conclusions

Summing up, I think I would have to say that, at the moment, Picasa is clearly ahead of WLPG. This is for three reasons:

• Picasa’s automatic synchronisation of local and online photo albums is a feature that WLPG simply does not yet have.
• Picasa will not corrupt your Exif metadata. As far as I’m concerned, WLPG’s wanton corruption of the Exif Makernotes is a cardinal sin. I refuse to even countenance using WLPG for any metadata work until this is fixed.
• Picasa version 3.9 has adopted the Metadata Working Group’s standard for face tagging.

I’ve held off doing any serious face tagging work up until now; partly because WLPG will corrupt Exif Makernotes if I use it to apply face tags, partly because earlier versions of Picasa only stored face tags in its local database, and partly because IDimager (my main digital workflow tool) has its own standard for face tags. Now that Picasa has adopted the Metadata Working Group standard, I think can finally start tackling face tagging in earnest.

Update 20 December 2011. As noted in the section on People Tags, since I reached the conclusion that I can finally start face tagging in earnest, I’ve discovered bugs in the current build (135.80,0) of Picasa 3.9. As a result, I’ve changed my mind – I’ll wait until Google gets rid of these bugs before I use Picasa for face-tagging work.

Update 27 December 2011. Thomas, in the comments below, has pointed out another major failing of Picasa 3.9 – it will remove Makernotes from any file that it touches. Sigh. I had missed this, because I was just checking to see whether the Makernotes section was being corrupted (this is what WLPG will do). Because ExifTool was not reporting any errors, I thought everything was OK. I simply hadn’t realised that it was not reporting any Makernotes errors because Picasa had bloody well removed the whole damn Makernotes section…

Right, now I need to restore all the 1,895 image files that Picasa has touched (when writing out People tags) from a backup taken prior to unleashing Picasa on my photo collection. It’s at times like these that I really appreciate the backup capabilities of my Windows Home Server.

I see that the Windows Live team has done another blog post on their efforts to redesign SkyDrive. While I appreciate their posts for documenting some of their approaches to design, I sometimes feel that their (often bland) statements can border on the disingenuous.

Here, for example, is the very first bullet point from that post:

In June we overhauled our website and used the latest browser standards to simplify our photos and documents experience, while also making it much faster.

It sounds good, until I found out that what they meant by the verb “to simplify” is that they:

• Removed the slideshow function. Now if you want to display the contents of a photo album on SkyDrive, you have to click through every damn photo manually.
• Removed the display of Tag metadata. Previously, photos containing Tag metadata that were uploaded to SkyDrive would automatically have the Tags transferred and displayed in SkyDrive, now they don’t. Worse, you are invited by SkyDrive to “Add a Tag”, so that means that if you do, you now have two independent sets of Tags to maintain.
• Removed the URLs to individual images; now you have to jump through hoops if you want to provide a link to an original photo or image in blog or forum entries.

Let’s just look at these points in turn.

Removal of the Slideshow Function

According to Microsoft (in a comment from Omar Shahine on this blog post):

In doing our research we found that users preferred controlling playback themselves, and the value of hitting play and sitting back to watch wasn’t all that important relative to other features.

Sigh – this sounds to me like the pitfall of cherry-picking your data to fulfil your own agenda. Some of my online photo albums have over a thousand photos in them; there’s no way I’m going to sit there and click on the mouse a thousand times when I could have clicked once to start a slideshow. These albums will remain on Flickr, which sensibly has a slideshow function built in.

Removal of the Display of Metadata

Let me illustrate this. Here’s a screenshot of the thumbnails of some pictures being displayed in Microsoft’s Windows Live Photo Gallery, an application that is running on my PC. One thumbnail has been selected, and you can see the metadata embedded in the photo being displayed in the information panel on the right hand side of Windows Live Photo Gallery (click on the image to see the full-size screenshot).

You can see that the metadata contains both descriptive tags (e.g. carriage and harness horses) as well as technical and copyright information (e.g. date taken, location, camera details, etc.).

This picture was uploaded to a SkyDrive photo album here. When I look at the picture in SkyDrive, while I see some (but not all) of the technical information, none of the descriptive tags have been transferred. Indeed, I’m invited to add the tags again!

Naturally, all the metadata is transferred and displayed if I upload my photo into Flickr:

Removal of URLs to Individual Images

There was a time when a simple right-click on an image in SkyDrive allowed you to copy the URL for that image, which could then be pasted into a blog or forum entry in order to embed the image in the entry. Alas, this is no longer possible. If you want to do that now, you have to download the image back to your PC once more, then persuade the Download Manager of IE9 to tell you the URL of where it came from. This strikes me, and others, as completely ridiculous.

As you will have guessed by now, Flickr continues to provide a simple URL for images that can be used in blog and forum entries (together with URLs for other sizes of the same images)…

And the Rest…

The rest of that blog post from Microsoft goes on at length about the different groups of users that Microsoft needs to design for, and the challenges that this entails. All true enough, but it seems to me that in the current design of SkyDrive, Microsoft has actually made photographers take a step back rather than a step forward. And that is in contrast to the design of Flickr, which has certainly given me the impression that functionality has kept pace with my needs.

Perhaps this is just a temporary hiccup. The authors of the blog post, Omar Shahine and Mike Torres, promise that they are working on improvements, without actually sharing any specifics. And that brings me to one last thought. I’ve been following the series of blog posts on Building Windows 8 with great interest. Each of those posts goes into detail, and at length, on the design choices and why particular ones are made. It’s a fascinating insight into the kitchen of the Windows 8 team. It’s a great pity that the Windows Live team have not taken a leaf out of the Windows 8 team’s book and given us more insight into what they are planning and doing. Issuing bland posts stating that there are challenges, whilst simultaneously delivering less functionality than previous versions of the SkyDrive service does not fill me with confidence.

Update 30 November 3 December 2011

Since writing the original post, there have been some changes to the SkyDrive service. Most have been in the area of being able to work with multiple files at once. However, one nice thing: the Slideshow function has been reintroduced.

The other two issues I raised in the original post (no Descriptive Tags and a simple method for obtaining the URL for an image) are still there. Perhaps they will be removed in a future upgrade… Update: As Ludwig points out in a comment below, there is in fact now a method of obtaining the URL of an image. Just browse to the image required, click on “View original” and then you will be able to copy the URL from the Address bar.

So, two down, one to go…