A while back, I was a frequent visitor to the Microsoft support forum for Windows Live Photo Gallery. There was a particularly bad bug in WLPG that I was bitten by, back in November 2010. Since that was fixed, I’ve been only an occasional visitor to the support forum. I go there mainly to see what sort of issues are being reported, and also to see what the quality of support from Microsoft is like.

The last couple of visits have made me think that there’s yet another bad bug in WLPG that Microsoft have not yet realised is present.

It started with this statement being posted by a user back in December 2011: Windows Live Photo Galley doesn’t write metadata to the file, only to the database.

The response from the Windows Live Support person was misleading and wrong:

Currently, Live Photo Gallery’s slideshow doesn’t support embedding captions or other metadata in the photo. If you feel that such a feature can improve the product, I suggest you submit this as request to our product team. You may post it in our feedback page at https://feedback.live.com/.

Misleading, because the original statement had nothing to do with the Slideshow feature in WLPG, and wrong, because as I posted on the forum thread: with one exception, WLPG does write metadata into JPEG files. WLPG will save Descriptive Tags, Captions, Geotags, People Tags (if you’ve identified faces in the image) and Ratings as metadata into JPEG files, as well as holding this information in its local database. However, WLPG does not save Flags as metadata in the image files, but only in its local database.

There was, alas, no further follow-up from Windows Live Support to the issue.

Then I noticed another thread in the forum that concerned an issue with metadata: Lost metadata from Photo Gallery. This time, it concerned someone who had bought a new PC and transferred the photo files from his/her old PC, only to find that all the “Date taken” metadata of the photos was wrong.

Once again, the Windows Live Support person jumped to the wrong conclusions, and gave irrelevant advice. There then followed much to-ing and fro-ing between the original poster and a succession of Windows Live Support people. Not one of them cottoned on to the salient fact that the cause of the issue was that the WLPG running on the old PC had not been writing out metadata into the photo files as it should have been doing. So when the photos got transferred to the new PC, all the metadata changes that the user had done got left behind in the local database of WLPG on the old PC.

I pointed this out in the thread, and someone else chimed in saying that he was seeing it on one of his PCs – WLPG was not writing out metadata into the photo files as it should do. Together, we came up with a simple test for this issue. In WLPG, select a photo, right-click and select “Properties”. This brings up the Properties window of the file itself. Many of the fields in this window are directly editable, e.g. the “Date taken” field. If everything is working correctly, you should be able to edit these fields, and the changes are being written into the file’s metadata directly. If, however, WLPG is not working correctly, then these fields cannot be changed. It’s as though WLPG thinks the files are Read-only, and hence all metadata is being held only in the local database and not written out to the files themselves.

We then asked for a response from Windows Live Support, and, once again, the response was misleading and irrelevant to the issue at hand. Sigh.

So, to summarise, it looks as though, under some circumstances, WLPG is not writing out metadata into photo (JPEG) files, but merely recording the metadata in its local database. It’s difficult to say how widespread this is, because most people will not be aware that things aren’t working properly. Not until, for example, they transfer their photos across to a new PC and discover that all of the metadata is missing or wrong.

WLPG users are being lulled into a false sense of security.

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:

Description	A textual description, including captions, of the item’s content.
Title	A shorthand reference for the digital image. Title provides a short human readable name which can be a text and/or numeric reference

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…

Almost a year ago, in July 2010, I blogged about something that I had noticed in the beta of Windows Live Photo Gallery 2011: the quality of the slideshows it displayed was noticeably poorer than in the previous version.

It turned out that WLPG 2011 uses Windows Live Movie Maker to display slideshows, and this was what was causing the poorer quality. This was unchanged in the final release of WLPG 2011. Because of this poor quality, when I wanted to display a slideshow on my PC, I used the slideshow function in Windows Explorer. It doesn’t have any fancy transitions, but it displayed the images at a far higher quality than WLPG/WLMM 2011.

And there the matter has stood, until now. Yesterday, I received an email from someone with the nickname tuxplorer, describing a simple change in the Windows Registry that will stop WLPG 2011 from using WLMM to display slideshows, and use its own built-in slideshow capability (that has been left in there from the previous version!).

All you have to do is use Regedit to go in the registry to HKCU\Software\Microsoft\Windows Live\Photo Gallery and change the value of the “AutoMoviePlayerSlideshow” value to 0.

That stops WLPG 2011 from using Windows Live Movie Maker, and makes it use its own slideshow capability. That slideshow engine has a number of transition effects, but if you choose the “Classic” theme, then you will get the same high-quality slideshows as in Windows Explorer.

Hat-tip to tuxplorer!

Just over a week ago, I gave a status report on the issues that I was having with Windows Live Photo Gallery 2011. In summary, there are three major issues that I’m concerned with at the moment:

1. Unwanted, and often inaccurate, GPS coordinates being inserted by WLPG 2011 into the Exif of images that have IPTC location metadata present, but no GPS coordinates currently set.
2. Corruption of Makernotes in the Exif section of JPEG image files by WLPG.
3. Unwanted compression of the file, even if only metadata is being changed by WLPG 2011.

Microsoft acknowledged issue (1), and have now produced a fix. If you go to the Download page of the Windows Live Essentials software, and re-download, you’ll get the updated version. The build number of the WLPG 2011 that was released on the 30th September was 15.4.3502.922. The updated version is now 15.4.3508.1109.

In summary, Microsoft have told me the changes are:

• GPS coordinates on a file are read-only inside of WLPG.  WLPG will never add, change or delete the GPS coordinates.
• If a file contains GPS coordinates when it’s brought in to WLPG, reverse geocoding will be triggered and location strings are displayed in the info pane, users can rename or remove the strings but GPS coordinates won’t be touched. Users may Rename a location but it will then leave a mismatch between the coordinates and the string since the coordinates are read-only.
• If a file does not contain GPS coordinates, users will be able to geotag by adding a string (that gets validated against Bing as it does today) but no GPS coordinates are added to the file.  The user can remove the string or rename it.
• If the file contains a geo name only, there will be no GPS coordinates calculated for it.

I’ve done a few quick tests, and I think I can point to a couple of additional behaviours:

• If a file contains IPTC Location metadata when it’s brought into WLPG, then WLPG will behave in a similar fashion to the second point above. That is, WLPG will use the IPTC Location data to set the location strings in the geotag field of the info pane. If the geotag is deleted or changed in WLPG, then there will be a mismatch between the IPTC Location metadata and the geotag because the IPTC Location metadata will be left untouched.
• Changing a geotag in WLPG, while it leaves the IPTC Location metadata untouched, will also cause WLPG to write out the contents of the geotag as IPTC Extension LocationCreated metadata. In other words, the file will now contain different location metadata in two places: the original location recorded in the IPTC Location metadata elements, and the new location now recorded in the IPTC Extension LocationCreated metadata elements.

So as far as I can see, I can use this latest version of WLPG 2011 safely, provided that I do all my geotagging and geocoding work outside of WLPG 2011. That way, WLPG 2011 is only ever reading GPS and IPTC Location information, and it will never write out GPS or geocodes into my files.

Microsoft acknowledge that there’s room for improvement here in future versions of WLPG and will be revisiting this feature. For example, I think that if they were to provide a mapping interface within WLPG itself, then users could check or modify the GPS coordinates and use WLPG to write them out into the files.

So long as WLPG 2011 never writes out any metadata to my files, then I won’t get hit by issue 2 (Makernotes corruption) or issue 3 (file compression).

What’s the current status of those issues?

Well, Microsoft also acknowledge issue (2), but currently treat this as a lower priority. I see that today the issue has been escalated, so perhaps they’ve begun to work on it. Until it’s resolved, I personally don’t want to use WLPG 2011 to do any tagging (e.g. people or descriptive tags), because then metadata gets written out to the files, and that will trigger the Makernotes corruption.

As I noted in my last status report, issue (3) is interesting, because not everybody is being affected by this. As I reported last time, it does seem to be caused by some kind of interaction between WLPG 2011, the Windows Imaging Component library in Windows itself and third-party Codecs that some of us need to install to handle non-JEPG image formats.

I’ve been doing some more investigation, and I think I have a workaround for my particular case.

I’m using the FastPictureViewer Codec Pack, because the codecs handle a wide range of image formats, which Windows and WLPG cannot do by themselves. One of the codecs is designed to handle auto-rotate of JPEG images. It looks as though that if this is installed into the WLPG/WIC/Codec pipeline, then I get the unwanted file compression. So my workaround is to de-install this particular codec in the FastPictureViewer Codec Pack. Hopefully, this issue will get resolved in a more robust fashion in the future.

So, of the three major issues that I started with, the first has been satisfactorily resolved (with room for future improvement), the second is being worked on, and the third has been identified and perhaps Microsoft and the third-party Codec developers will come to some sort of resolution in the future.

This all means that while I won’t be using WLPG 2011 to do any tagging work, It can safely be used as an easy-to-use photo browser by family members. And it can also be used by family members to edit photos, since the original files get preserved. It’s a major step forwards from the geotag disaster that hit me back in August. My thanks to the WLPG team for their work in addressing the issue.

Addendum, 12 July 2011: Last week, a new version of WLPG 2011 was released; build number 15.4.3538.0513. However, even though Microsoft acknowledged the MakerNotes corruption bug back in December 2010, this new build of WLPG still has the bug. Sigh.

In view of the issues I’ve been having with WLPG 2011, I thought that it would be worthwhile to report that Microsoft are listening to those of us who are reporting tales of woe caused by using WLPG 2011. I’ve had a number of emails from the lead Project Manager of the WLPG team on the subject.

It seems to me that there are three major issues being reported at the moment:

1. Unwanted, and often inaccurate, GPS coordinates being inserted by WLPG 2011 into the Exif of images that have IPTC location metadata present, but no GPS coordinates currently set.
2. Corruption of Makernotes in the Exif section of JPEG image files by WLPG.
3. Unwanted compression of the file, even if only metadata is being changed by WLPG 2011.

Microsoft have acknowledged issue (1), and are working on a fix. I’ve been told that they hope to roll out an update soon for WLPG 2011 that may resolve the issue going forward.

Microsoft also acknowledge issue (2), but currently treat this as a lower priority. I think that’s understandable, because unlike the case for RAW files, Makernotes are not vital for JPEG files.

Issue (3) is interesting, because not everybody, it seems, is being affected by this. Some people are reporting that no compression occurs, whereas others of us are plainly seeing it. Indeed, I had an email from Microsoft stating that this reported compression was of utmost concern to them, but expressing confusion that they also weren’t seeing compression in their tests.

After thinking about this, it seems to me that one possible hypothesis to account for the difference is that those of us who are seeing file compression are using third-party codecs.

Most professional photographers (and many keen amateurs) are probably taking their digital photos in a RAW format. Windows and WLPG will not display such images out of the box; they require a codec to be installed to do this. Codecs are available from either the camera manufacturers or other third parties.

Now, it just so happens that I have a number of photos held in RAW or DNG formats in my collection, so I need to have a codec installed to view these in Windows and WLPG. I’m using the FastPictureViewer codec to do this, because it handles a wide range of image formats, which Windows and WLPG cannot do by themselves.

I noticed a thread in the PC Talk forum on the Digital Photography Review site where the original poster reported that he was also seeing this compression of files with WLPG 2011. Interestingly, there’s a number of contributions to the thread by Axel Rietschin, the developer of the FastPictureViewer codec. He claims that the Windows Imaging Components (WIC) library and Microsoft’s own JPEG codec use private and undocumented interfaces that are not available to any third party codec:

The underlying problem is that lossless transcoding, where a file is reconstructed to make room for new metadata, is not possible with the normal Windows Imaging Components codec interfaces: there is nothing that would allow anyone to retrieve the packed data, only pixels. Microsoft implemented this feature in their own JPEG codec using an undocumented interface called IMILCJpegDecoderFrame that WIC uses internally, but no 3rd-party JPEG codec (or 3rd-party codec for any other lossy formats) is able to provide this functionality.

And in a later message on the same thread:

Just to clarify: Microsoft worked around the limitation of the(ir own) API by implementing a private interface in their JPEG codec that presumably let them read/write the pixel data without decompressing it, and as a result both Windows and WLPG are able to perform lossless metadata updates and rotations on JPEG files when using the stock codec.

The problem starts only when replacing the default codec with a 3rd-party one which cannot possibly implement the internal (and undocumented) interface they use privately.

I think that this is what must be happening. Because I need to have a third party codec installed to handle my RAW and DNG images, this is also being used by WIC for JPEG images, and hence I’m seeing the file compression. Those people who only use JPEG formatted images have no cause to install an additional codec, so they are not seeing the compression.

This compression will only occur when WLPG 2011 touches an image file to write back information into it.

To date, I’ve been pretty lucky – I use IDimager to do my cataloguing and metadata work, and this does not use WIC. So all the image data is left untouched in the file, even though the metadata may have been edited. This is as it should be. (Note: IDimager is no longer available. Its successor is Photo Supreme, which I am now using)

Previous versions of WLPG I’ve been using were (mostly) just reading these files to capture the metadata for their internal databases. I say “mostly”, because I’ve seen some earlier files that have had Microsoft-specific metadata written into them, and some of them have been compressed. Those that weren’t would have been written before the time that I got a digital camera capable of using RAW format – so the built-in Microsoft codec with its undocumented private interfaces would have been used. Those that are compressed will be examples done after I had installed the third-party codec to handle RAW formats on my PC. There aren’t many of them, because it was rare that I used WLPG directly to edit metadata.

However, with the advent of WLPG 2011, and its current habit of writing GPS and IPTC Extension metadata into files (issue 1 above), then I’ve had a deluge of files that have been compressed, because when WLPG writes out the metadata, the file gets compressed.

In one sense, of the three issues, only issue (1) can be laid squarely at the door of WLPG 2011. Issue (2) is probably down to the implementation of WIC itself, and is independent of any application such as WLPG calling it.

However, issue (3) is somewhat more messy. It would seem to be caused by the architecture of WIC, and the fact that there are private interfaces being used by Microsoft that are not available to third party codec developers. It also has the result of making WLPG 2011 lie to the user whenever third-party codecs are installed. If the user sets WLPG to have no compression, then WLPG assumes that WIC will follow suit, but it doesn’t, and file compression will still result.

This leads me to a concern about the possible solution Microsoft are working on for issue (1). Originally, I had suggested that a simple solution would be to offer the user a way of turning off the writing of GPS coordinates into the Exif of a file. But now I realise that that is not sufficient. If WLPG 2011 goes ahead and constructs a geotag because it finds IPTC Location metadata in a file, then it will also use WIC to write out new IPTC Extension “LocationCreated” metadata into the file as part of its geotagging/geocoding function. And if a third-party codec is installed, the file will be compressed.

So really, the only immediate solution is to be able to turn off geotagging/geocoding entirely, otherwise metadata gets written, and the file gets compressed.

It’s the same with the face recognition features of WLPG 2011. I can’t use them, otherwise when the metadata gets written, WIC will compress the file. As far as I can see, the bottom line is that whenever WLPG writes out metadata into the file, it uses WIC, and if there’s a third party codec installed, the file will be compressed.

The only real solution, it seems to me, is for Microsoft to document the currently private interfaces of WIC, so that they can be used by third-party codec developers. In the meantime, it looks as though my only option is to install the Windows XP version of Windows Live Essentials. That way I’ll get a version of WLPG which will only ever read my image files and never be used to write to them.

Update 24 November 2010

I’ve just been using my laptop as a test system to see if I can reproduce the conditions under which issue (3) (the file compression) will occur. I think I can convincingly show that it is, as I suspected, the combination of WIC and the third-party codec.

First, on the laptop, I uninstalled the third-party codec (FastPictureViewer) that I had on there, and also, for the sake of completeness, Picasa 3.8.

The system was then Windows 7 Home Premium, with WLPG 2011 (build 15.4.3502.922), together with the built-in codecs of windows.

I then copied a folder of photos taken in May 2007 across from my Windows Home Server into the My Pictures folder of the laptop. These are the photos that are showing in the screenshots of the “24 Hours Later” section of this post. I also chose these photos to test, because one of them I had included in a batch sent to Microsoft to test. When Microsoft checked the size before and after the images had been geotagged, they found little or no difference in size:

Yet when I had done the same thing on my PC, I got a reduction in size of about 50%.

So I repeated the test on the laptop (which remember now has no third-party codecs installed).

I first used Geosetter to examine the metadata and size of the files. The files had IPTC Location metadata and the particular file illustrated above (20070524-1234-56) was 3.10MB in size.

Then I opened WLPG 2011, and let it discover the new folder of files. I waited a few minutes, and then went back to Geosetter to examine the files, and the above file in particular.

As expected, all the files now had GPS metadata added to them (this is issue (1) in action), but the interesting thing was that, just as Microsoft had found, the file sizes were very little different than they had been. This seems to suggest that, with the built-in codecs, no compression will occur.

Now I deleted the test folder, waited for this to be registered in WLPG and then installed the FastPictureViewer codecs. I then got a fresh copy of the folder from my Windows Home Server and repeated the test. This time, once WLPG 2011 had added the GPS coordinates, I found that the files had been shrunk by about 50%.

So it definitely seems to be a combination of the third party codec and WIC that triggers the file size reduction. One further interesting thing: since all the pictures are JPEGs before and after, then really only the built-in Windows JPEG codec should be used. There is a FastPictureViewer codec that handles JPEG rotation, but I wasn’t doing this, just adding metadata. So why is there a file size reduction?

Update 2 December 2010

There’s an update to WLPG 2011 that addresses the geotagging issue. See here for more information.

As you may be aware, I’m not very happy with the current version of Windows Live Photo Gallery at the moment. I believe strongly that it has problems that desperately need to be fixed.

There are other, less pressing, issues with WLPG 2011 as well. These include the fact that slideshow quality is degraded in comparison to earlier versions. Another is the fact that people are finding that their workflow performance has taken a nose-dive since upgrading to WLPG 2011.

However, apart from all that, there are other things that niggle. These days most people are unaware of how much of their identity is available online. That almost certainly includes me, even though I think I’m being careful. Thus, here’s another example from WLPG 2011. It has automatic face recognition in it. People are probably happily tagging (identifying) their friends in photos using WLPG 2011, which in turn is squirreling away metadata containing this information into the photos. If these photos are subsequently uploaded to online sites where they can be viewed by anyone, then this metadata is often equally available to all.

And what is this metadata? Well, it is at minimum, the names of the people in the photos. But if those people are also known to you as email contacts, or have a Windows Live identity, then this information is also included as metadata in the uploaded photos. True, the metadata will not spell out their email addresses for all to see – they are at least encrypted. However, after reading this comment, (from a Microsoft employee) I do wonder about the Windows Live ID:

PersonLiveCID is the unique ID generated for everyone with a Windows Live ID, it might be possible to use this and I’ll be playing with some of the Azure Services sometime to see if you can resolve this to a contact. That could create some very interesting possibilities.

That would be “interesting” in the Chinese sense, I think.

Yes, I know that I’ve said before that Windows Live Photo Gallery 2011 is a disaster, but more problems caused by using it just keep crawling out of the woodwork.

The first problem I stumbled across was that if you are a photographer who uses IPTC metadata to record information about where your photos were taken, then WLPG 2011 will write false GPS data into your photos without telling you that it is doing so.

I, and others, have reported this issue to Microsoft, and I understand that they are looking into ways of correcting it. Meanwhile, I’ve become aware of another issue with WLPG 2011. It also screws up the Exif section of the metadata in images.

While trying to scrub my images clean of the false GPS data inserted by WLPG 2011, I noticed ExifTool was reporting that many of my images had problems with their Exif metadata. Often it was a simple warning that the Makernotes in the Exif section have been damaged. This is a warning from ExifTool that another utility has written to the Exif section and damaged the structure in some way.

In many cases, however, ExifTool is reporting that more serious damage has occurred and some of the data written into the original Exif section by the camera that took the image has been corrupted.

Here’s a screenshot that shows an example of an image exhibiting both types of issue (warnings and corruption). The screenshot is of Geosetter, and the highlighted image shows errors being reported by ExifTool (Geosetter uses ExifTool under the covers to do all the heavy lifting). Click on the image to open it full sized in a new window.

You’ll notice that the thumbnail, and some of the others, have a dark blue marker pin in the top left corner. That indicates that the image contains GPS information. But the interesting thing is that, for that particular image, I did not supply GPS data; WLPG 2011 has inserted it by itself.

Now here’s a screenshot of one of the other thumbnails that Geosetter is indicating have GPS information. For these thumbnails, I explicitly inserted GPS information myself, in other words, WLPG 2011 has not had cause to write anything out to the files. Notice that for this thumbnail, ExifTool is not reporting any errors or warnings. That’s the case for all the images where I have explicitly added GPS information.

By the way, even though these two shots were taken at the same place, the GPS inserted (without my knowledge) by WLPG 2011 is wrong, and is located 500 metres distant.

I’m now going back through my images, and as far as I can see, all those which are being reported by ExifTool as having problems with their Exif metadata are ones that have had GPS information inserted by WLPG 2011.

The really irritating thing about this discovery is that WLPG has a track record of not dealing correctly with Exif metadata. Previous versions of WLPG have been reported as corrupting the Makernotes (data written by the camera manufacturer) in Exif.

It would appear that nothing has been done with WLPG 2011 to address this issue. So not only does it insert gratuitous, and false, GPS data into your images, it will also screw up their Exif metadata.

I repeat, this is a disaster.

24 Hours Later

So, I’ve been looking into this a bit more, but the more I look, the more I think: OMFG. The damage that has been done appears to be quite extensive, and will take some time to repair.

Today, for example, I decided to examine just one folder of photos and compare the contents with the contents of the same folder as it was in a backup taken on the 1st June 2010 – a date chosen because it was before any of the betas of WLPG 2011 had been released to the public. On that date, I would have had the previous version of WLPG installed and running. The first beta of WLPG 2011 wasn’t available to the public until the 24th June.

I looked for a folder that had photos containing entries in the IPTC Extension “Location Created” metadata fields. These fields are used by WLPG 2011 to store textual information for a location (e.g. the street address, city, state and country) in the image files. I don’t use these fields; I use the older IPTC Core “Location” fields for this purpose. So if I find an image file that contains IPTC Extension “Location Created” metadata, then I know it has been touched by WLPG 2011.

I chose a folder containing 24 photos that had been taken back in 2007, and which had IPTC Extension metadata present. I then got the same folder from the 1st June backup to compare the two side by side.

Here’s a screenshot of the folder, as it was on the 1st June, being displayed in Geosetter, with the metadata of the selected photo being shown (click on the screenshot to see it full-size in a new window):

Now here’s a screenshot of the same folder as it currently exists in my computer. The same image file has been selected to show its image metadata:

I’ve expanded some of the more interesting metadata sections. As you can see, the metadata has changed substantially. Let me list the ways:

1. ExifTool is now listing a warning about a possibly incorrect Maker notes offset, together with three warnings about invalid camera data in the Exif section.
2. While the original (backup) file had 98 elements of camera maker data in Exif, the current file has now only 11 left.
3. The current file now has GPS metadata present in the Exif. This has been inserted by WLPG 2011, not by me. You will note from the other thumbnails in the second screenshot, that all the other files are also showing that they now have GPS data in them. None of the original files had GPS data. By the way, the GPS data is also incorrect by 300 metres.
4. The original file had its Exif byte order in little-endian fashion; in the current file it is big-endian. According to the guidelines of the Metadata Working Group (of which Microsoft is a founding member), the “endianness” should be preserved, not reversed.
5. The original file had a filesize of 3.1 MB; the current file has shrunk to a mere 1,553 KB.
6. The current file now contains a JFIF block, which is not present in the original file. It also has changed YCbCr values, possibly as a result of this.
7. The current file now contains an IPTC Extension metadata section, which lists textual information for the “Location Created”. This section is not present in the original file.
8. The original file is showing that it was last modified on the 27th November 2009. The current file is showing that it was last modified on the 30th September 2010, which also happens to be the date of the final release of WLPG 2011. This is not a coincidence.

There may be other, more subtle, differences between the original and current versions of the files, but I’m already disheartened enough by the above list, particularly by the Exif corruption and by the fact that my JPEGs have been compressed in size without my knowledge or permission.

I suppose I can cut my losses by doing a full restore of the photo folders from the backup taken on the 1st June, but this will still not take account of new files that have been created since that time, or of older files that I have been working on.

What a mess. Thanks, WLPG 2011.

48 Hours Later

Oh gawd, it just keeps getting worse… I had hoped that WLPG 2011 was only corrupting Exif metadata when it actually changed the metadata, for example when it added (false) GPS coordinates to the Exif section.

After further examination of files today, I have discovered that WLPG 2011 will merrily corrupt Exif metadata even when it doesn’t need to change any of the Exif content.

You see, one of the new features of WLPG 2011 is automatic face recognition. When it discovers what it thinks is a face in a photograph, it will ask the user to confirm the person’s name. Once it gets confirmation, it will then write XMP metadata into the image file. This XMP metadata is structured according to Microsoft’s People Tag. However, when WLPG 2011 writes this XMP metadata out to the file it will also (a) corrupt the Exif metadata section and (b ) compress the JPEG image.

I’m afraid that I’ve been confirming face tags suggested by WLPG 2011. And now, every single one of those images that contain face tags has also had its Exif corrupted.

What a f*cking mess. Thanks, WLPG 2011.

Update 23 November 2010

I thought that it would be worthwhile to report that Microsoft are listening to those of us who are reporting tales of woe caused by using WLPG 2011. Please see here for a status report on where I think we are…

Update 2 December 2010

There’s an update to WLPG 2011 that addresses the geotagging issue. See here for more information.

I see that Adobe has recently released Photoshop Elements 9. I last used Photoshop Elements when it was at version 4, and stopped using it because the Organizer part of the package had too many limitations for me. I did like the features of the Photoshop Editor, but I hated the Organizer with a passion.

Still, time passes and now we’ve arrived at version 9, so I thought I’d just take it out for a test drive and downloaded the trial version.

Since the Organizer was the weak point the last time around as far as I was concerned, I fired that up first to take a look at it. I imported a subset of photos taken this year and started kicking the tyres.

The first thing I noticed was that the Organizer had successfully imported the IPTC Keyword metadata from the files and used this to create Keyword Tags. However, it did not, unlike Windows Live Photo Gallery, recognise that these were hierarchical tags and create the Keyword Tag hierarchy automatically. Take a look at this screenshot (click on the image to open a larger version in a new window):

You can see the imported Tags under the “Imported Keyword Tags” category, but notice how the Organizer has simply imported them all as a flat list – it has not grouped them into a hierarchy. Also notice how a Tag with multiple levels is too long to be displayed properly.

Now, it is possible for the Organizer to have a Keyword Tag hierarchy, you can see the start of one in the screenshot above, with the first levels being “People”, “Places”, “Events”, “Other” and the “Imported Keyword Tags”. So, having imported all my tags as a flat list, I would have to manually, and laboriously, re-create my tag hierarchy in Organizer to match the hierarchy described in my files’ metadata. This would not be a quick job…

The next question would be, having got a tag hierarchy created in Organizer, what happens when I write out Tags into files as metadata? Does it store them in a hierarchical manner?

To test that, I created a simple hierarchy under People (People/Family/Test level 1/Test level 2/Family member 1) and assigned that tag to a test image in the Organizer:

Here is a screenshot of what the Organizer tells me about the IPTC metadata of this image before I applied the tag:

You can see that there are two hierarchical Keywords already present in the file’s metadata. Here’s what the file’s metadata becomes after I tell Organizer to write out the Tags to the file:

Not good. Although the Tag “Family member 1” is in a hierarchy in the Organizer, it’s just been written out as a flat, single level, tag to the IPTC metadata.

From this I conclude that the Organizer does not support hierarchical tags in file metadata. That was the case back with version 4. It’s disappointing that it’s still this way.

One other thing I looked at with the Organizer is how well it plays in a multi-tool workflow. Like many digital photographers, I have a number of different applications that I use for different purposes. It’s extremely important that these will all play together, and do it as transparently as possible, with little or no effort on my part.

So, for example, what happens if the metadata of a file gets changed by another tool outside of Photoshop Elements 9?

I tested this by first importing some image files into the Organizer. I then added a tag to a selection of the files using another tool (IDimager). Both Picasa and Windows Live Photo Gallery will pick this change up and update their Tag list to reflect the new one and the files that contain it. Not the Organizer, though. It just sat there and insisted that the tags associated with the files in question were as originally imported, and nothing had changed.

I thought I’d try and reimport the files to see if Organizer would then realise that a new tag had been added. Not a bit of it – it simply insisted that it already knew about these files and did not realise that the metadata had changed:

As far as I’m concerned, this is a showstopper. The Organizer in Photoshop Elements 9 just doesn’t play at all well in a multi-tool digital workflow. It was the same back in the days of version 4. Plus ça change…

And just in case you think I’m being unnecessarily hard on the Organizer here, which is intended for ordinary mortals rather than professional photographers, just consider this… If you have a family and you have a number of computers in your household, then you had better make sure that just one computer is devoted to cataloguing your photo collection. These limitations of the Organizer mean that you can’t have Photoshop Elements installed on multiple computers, and expect the metadata and Keyword Tag hierarchies automatically synchronised between the family PCs. That is one of the plus points about Picasa and Windows Live Photo Gallery. I do all the heavy lifting of cataloguing and Keyword maintenance on my main computer using IDimager, and all the other computers in the household running Picasa or WLPG pick up the changes automatically. That will not be the case with Photoshop Elements. It may export the Tags as metadata, but it doesn’t export the tag hierarchy.

Oh, one other disappointing thing about the Organizer: geotagging. It uses Yahoo Maps in the geotag interface. The satellite coverage of Yahoo maps in comparison to Google or Bing Maps is but a pale shadow. For the majority of my photographs, I get a plaintive “imagery not available” message if I try to place a geotag accurately.

After all this, I haven’t had a chance to look at the editor in Photoshop Elements 9. I’m sure it will be powerful, but frankly, my dears, I don’t give a damn… On the odd occasion when I need more capability than my usual tools give, I can always fire up the editor from Photoshop Elements 4. I see no reason to upgrade to version 9.

This is a bit of a rant. This is a bit of a rant about Microsoft software. This is a bit of a rant about Windows Live Essentials 2011.

Windows Live Essentials (WLE) is a suite of utilities from Microsoft that began life back in 2006. WLE 2011 is the fourth major iteration of the suite, and was released in its final version on 30th September 2010. It now contains a number of utilities:

• Windows Live Family Safety
• Windows Live Mail
• Windows Live Mesh
• Windows Live Messenger
• Windows Live Messenger Companion
• Windows Live Movie Maker
• Windows Live Photo Gallery
• Windows Live Writer

Of these eight utilities, I really only made extensive use of four of them (Mail, Messenger, Photo Gallery and Writer). With the release of WLE 2011, and the acquisition of a camera that can shoot HD video in addition to photos, I had expected to start making use of Movie Maker.

Instead, I’ve found that the 2011 versions of both Movie Maker and Photo Gallery have surprising limitations that represent a step backwards from earlier versions. Worse still, Windows Live Photo Gallery 2011 has a showstopper of an issue that means that I cannot use it until it is resolved in a satisfactory manner by Microsoft.

Windows Live Movie Maker

Windows Live Movie Maker (WLMM) is a complete re-write of an earlier effort by Microsoft: Windows Movie Maker (WMM). Unfortunately, in the rewrite, Microsoft’s desire to make easy-to-use software has resulted in the dumbing-down of the software to the point where functionality has been removed.

Windows Movie Maker had both a “storyboard” view and a “timeline” view for editing and assembling videos. Windows Live Movie Maker 2011, on the other hand, has dropped the timeline view and only offers a storyboard view for editing. That’s a great pity, because having the timeline view makes some operations very easy to do, and they can only be done with difficulty, if at all, in the storyboard view. For example, in WMM’s timeline view, you could edit the audio of a video clip. You simply can’t do this in WLMM’s storyboard.

Limitation number two is that, as far as Microsoft is concerned, we all live in either North America or a few other places. That’s because when you produce your finished video, WLMM will produce it in the NSTC standard. Much of the world (over 120 countries and territories) uses the PAL standard, but Microsoft does not support this in WLMM by default. You can cook up your own custom settings, but this is not always straightforward. Take a look at this discussion on the WLMM Help Forum to get an idea of some of the issues involved.

One would think that since Microsoft is apparently trying to make easy-to-use software that they would offer a simple “NTSC or PAL” switch in WLMM, just as practically every other video editing software does, but no; for some reason they have concluded not to do it, leaving us to hunt for information as to how to set it up for ourselves. Two steps back…

Windows Live Photo Gallery

Windows Live Photo Gallery (WLPG) has had more functionality added to it in each of the major releases. WLPG 2011, for example, now has automatic face recognition, geotagging, and a “photo fuse” feature added to it over the features that were in WLPG 2010.

However, there is at least one limitation that I’ve found in comparison with WLPG 2010, so it’s not just a simple move forward. WLPG 2010 had a slideshow function – select your photos, click on the Slideshow button, and you got an instant slideshow of your selected photos. WLPG 2011 seems to offer the same functionality, but when you click on its Slideshow button, what is actually happening is that it passes the job over to Windows Live Movie Maker 2011 to do the work of producing and running the slideshow. And here’s the limitation: the quality of the slideshow produced by WLMM 2011 is noticeably poorer than that which was produced by WLPG 2010.

When I raised this issue in the WLPG Help Forum, the first response back from Microsoft was to deny that anything had changed between WLPG 2010 and WLPG 2011. They then conceded that things had in fact been changed and that “photo quality in slide shows in Windows Live Photo Gallery Beta is indeed a bit degraded when compared to the original file source”. The reason given was that “since videos have been incorporated to the feature, high definition photos in the slide show are forced to level with the resolution capacity of a video format”.

While Microsoft may think that slideshow quality has been “a bit degraded”, I see it as noticeably degraded – to the point where I consider it unacceptable in quality, and a step backwards from what was available in WLPG 2010.

And then we come to the showstopper in WLPG 2011: geotagging.

Unlike every other application I’ve seen (IDimager, Picasa, PhotoShop Elements, Lightroom, Microsoft Pro Photo Tools, Geosetter) that offers geotagging either directly or via a plug-in, WLPG 2011 does not offer a map-based interface to position geotags. Instead, it uses a text-driven database to assign geotags. The problem with this, as I’ve pointed out here and here, is that this is very prone to errors of interpretation.  If Microsoft had left it at simply a textual description of a geotag, I could have lived with it. But no, they go a step further: they also write out GPS coordinates into the Exif metadata of the image. In effect, WLPG 2011 is guessing the GPS coordinates based on text contained in the contents of the IPTC metadata fields that deal with information about location. Microsoft are really doing geocoding, rather than geotagging. The problem is that very often, these guesses turn out to be wildly wrong. Even that I could live with, if WLPG 2011 had given me an option to stop it writing out these GPS coordinates into my images; but it doesn’t, and that is an unforgivable showstopper in my book. WLPG 2011 has entered false GPS data into thousands of my images.

It’s really odd, the automatic face recognition feature of WLPG 2011 asks the user to confirm its guesses as to who the person in a photo is each and every time. Yet the geotagging feature is making guesses about GPS coordinates and writing these out to image metadata without even notifying the user that it is doing this.

I, and others, have raised the issue in the WLPG Help Forum here and here. The worrying thing is that so far, while the issue has been acknowledged by Microsoft, the manner of their replies are, to my eyes at least, rather along the lines of “it’s not a bug, but a feature…” Sorry, Microsoft, it’s not a feature, it’s a disaster. One that could have easily been avoided if they had given us the option to turn off the writing of GPS coordinates into image metadata. And if they had given us a map-based interface, like any decent geotagging application, then users could have checked WLPG’s guesses, confirmed those that were correct, and rejected the false ones.

WLPG 2011, despite the fact that it uses the term “geotag” in the application, is actually doing geocoding, rather than geotagging if you follow the strict definition of the terms. There’s probably a reason that everyone else does geotagging in their applications, and that is probably because it isn’t so prone to horrible errors as Microsoft’s geocoding approach has turned out to be.

This issue makes WLPG 2011 not so much two steps back in comparison to WLPG 2010, but more of a step off the cliff…

Update 2 December 2010

There’s an update to WLPG 2011 that addresses the geotagging issue. See here for more information.

So the final version of Windows Live Essentials was released today. I see from this blog post by Chris Jones that apparently 95% of the bugs that were present in the beta version have been addressed by this final release.

I suppose it was inevitable that I would find myself continuing to be bitten by one of the remaining 5% of bugs.

Windows Live Photo Gallery still continues to write false GPS coordinates into my images.

This is unacceptable behaviour as far as I’m concerned. I can’t afford to have it running on my computers and introducing garbage into my image metadata.