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.