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.