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:
- 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.
- Corruption of Makernotes in the Exif section of JPEG image files by WLPG.
- 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.
Geoff Coupe's Blog 
Leave a comment