Windows Live Photo Gallery 2011 – A Status Report

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:

Microsoft test1

Microsoft test2

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.

About Geoff Coupe

I'm a British citizen, although I have lived and worked in the Netherlands since 1983. I came here on a three year assignment, but fell in love with the country, and one Dutchman in particular, and so have stayed here ever since. On the 13th December 2006 I also became a Dutch citizen.
This entry was posted in Computers and Internet, Photography. Bookmark the permalink.

48 Responses to Windows Live Photo Gallery 2011 – A Status Report

  1. Pingback: More Problems With Windows Live Photo Gallery 2011 | Geoff Coupe's Blog

  2. JL says:

    OK, 3rd great-grandmother, Nancy, and I are now here. Speak, O Great Ones.

  3. Ludwig Keck says:

    JL, does the 3ggma decompress to the original quality? That certainly would be a welcome turn. Let me get the situation right: The problem occurred on a Windows 7 machine when WLPG was installed. Prior to that, had those images been on that machine for an extended period? After the “happening” you noticed a decrease in file size, messed up metadata, and noticeable decrease in image quality, is that a correct recap? This was on TIF files. What were the results on JPG files. Did any files remain unaffected? With WLPG removed has there been any indication of “malop”, if I may coin a phrase?

  4. Ludwig Keck says:

    Sorry about my oversight. I jumped in here after that invitation for the great ones to speak. I do not consider myself to qualify for that title, just one who keeps learning and tries to share.

  5. Geoff Coupe says:

    JL, a question for you: is there any correlation between files that have been compressed and their orientation (portrait or landscape)? In particular, are all the compressed files in Portrait, while no Landscape files show compression? Thanks.

  6. Geoff Coupe says:

    JL – I think you can ignore my last question. Following further tests here (added above) I don’t see any correlation between orientation and compression on my system.

  7. JL says:

    Guys, great or not, it’s early in the morning here, I’m on my way through breakfast and then out to an appointment. My life seems to be in one-step forward/2 steps back mode. Yesterday, one of my precious two monitors burned out so I’m having to add ‘order a replacement’ to my to-do list and stagger on with one in the meantime. The temperature has dropped about 30 degrees in the past few days; I’m freezing and have to jump up and down all day to keep from going into hypothermic insanity.

    Briefly, and then I have to go for away for awhile – Yes, no orientation issues. Ludwig, my sense from looking across my thousands of photos is that every single one was affected in some way. “Some way” might mean ‘only’ metadata changes. ExifToolGUI allows me to export a text document of the entire list. Then I use a program called “WinMerge” (portable edition) to compare the output from a photo subjected to WLPG and one that I’ve retrieved from backup. I’ve done this on a handful of photos that made me curious for one reason or another and they’ve all shown changes of some kind. In an email from Carmen yesterday, he said that the pending update to WLPG will ‘reduce’ the EXIF damage but not eliminate it. I don’t know what ‘he’ means by “EXIF damage”. That was my term.

    On October 15th I received a new computer with Windows 7. I’d never seen W7 before. I’d never used Photo Gallery before. WLPG was already installed as part of W7. A few days later I accepted the relentless pop-up box offering an upgrade to 2011. I believe that’s when the problems began but I don’t know because I’ve never used any of this before.

    At first I only noticed the GPS damage, then I continued reading Geoff’s posts where he went on to write about compression and EXIF ‘alterations’ and I went back to look and, sure enough, that too. This all happened over a week or so. Then I uninstalled all of Windows Live Essentials. I don’t see any re-occurrence of ‘malop’ since then.

    I haven’t tried to decompress a tif yet. I’ll have to go looking for instructions. I have to get on with other things but will check back in again later.

  8. Geoff Coupe says:

    Erm, JL, I think Carmen is a “she”. Admittedly, I draw this conclusion from googling the name and coming up with a reference to Carmen “living with a wonderful hubby” in Seattle, and I do realise that I’m not one to talk, what with me living with a wonderful husband in the Netherlands. Nonetheless, I suspect that Carmen is female…

  9. JL says:

    Sorries all around. I’m an aged female and get taken for a young boy on a regular basis. Even in person. I’ve leave all the other details to the imagination.

    Sorry, Ludwig, I know I haven’t answered all your questions yet but will return momentarily.

  10. Geoff Coupe says:

    Ach, nothing to be sorry about – just me being pedantic as usual…

  11. JL says:

    Ludwig, I’m back home now with my brain only about 25% thawed out, so still not at my best. In fact, I’m in a state of considerable disarray. I have unread email going back as far as August when my computer crashed.

    Geoff has written several posts on this blog about his discoveries after installing WLPG, in fact he was also using the beta version so his experience goes back much further than mine. He’s taken the time to document his findings with a delicious degree of fine detail. I’ve been able to confirm all of his experience by looking at my own photos and their metadata. We are in complete agreement so far.

    I probably cannot follow any more of this for at least the remainder of today as I’m far beyond swamped with catch-up lists. My overwhelming temptation is to pull a down quilt over my head and pretend I was born an hour ago.

  12. JL says:

    Ludwig, What do you use for decompressing tif’s? I had a look but, being unfamiliar with this concept, I don’t know what or who to trust. Do you have an old favorite and reliable method?

    • Ludwig Keck says:

      Afraid I am not of much use on this, I use TIFFs rarely. When I do I work almost exclusively in Paint Shop Pro PHOTO. This loads TIFFs, compressed or not and can save them with the option to save uncompressed or compressed (LZW). This gives me the ability to go back and forth – as I said, I don’t use this much. There are stand-alone decompressors available, but I have no experience with any of them. I would be happy to experiment with a copy of one of you files, but others here can probably be more helpful, and more knowledgeable.

  13. JL says:

    I took one of the LZW-compressed photos and re-saved it through Adobe Elements as an uncompressed tiff and the original file size came back. Hallelujah!

    Then I exported the metadata from ExifToolGUI, as well as for the restored version and used WinMerge to compare them side-by-side. There are differences but I’m in over my head here as to how important those differences are.

    Geoff, could you please do a metadata analysis if I send you over the text files?

  14. Geoff Coupe says:

    BTW, I’ve had a message from Carmen, there’s a new version of WLPG 2011 available. I’ll be blogging about the changes later today, as well as reporting on some more data I’ve found out about the file compression issue.

  15. Pingback: Windows Live Photo Gallery 2011 – Status Report 2 | Geoff Coupe's Blog

  16. JL says:

    Making progress here, albeit slowly. Today I clicked through over 2,000 tif’s, decompressing where needed. Not every single photo. Some folders were completely compressed save one or two photos, other folders half and half, and some not touched at all. In total maybe 800 LZW’s out of the 2,000. I’d love to be able to tell you the difference but I don’t know what it is.

    Right now I’m getting ready to tackle 2,469 jpg’s and I’m looking for dead give-away clues. Is a decrease in size the most obvious? What percentage of your jpg’s did you find compressed? I’ve seen clues like ‘big-endian’ and ‘Invalid EXIF text encoding’ but in some cases those warnings also exist on my backup files. Obviously, some of the damage was done previous to WLPG and possibly prior to arriving on my computer.

    Any way to cut through the haze?

  17. Geoff Coupe says:

    I didn’t use compression as the search criterion. My rationale was that WLPG was going through my files setting GPS coordinates, and while it may have been compressing the files as an unwanted side-effect, the primary drive was the setting of GPS.

    So I used Geosetter to reveal which files had Geodata set. By using the presence of GPS coordinates as the search criterion, that gave me the subset to examine in the second stage, which was to discard those files where I had set the GPS myself.

    I noticed that WLPG was only setting Latitude and Longitude, whereas the tool I use to set GPS also sets altitude and timestamps it. So that gave me a quick method of sorting the subset.

    • JL says:

      This has been going on for so long my mind needs a refresher course. 🙂

      Waaay back in the day when the topic of jpg’s was on deck…

      It doesn’t sound like that will work here since I already ‘fixed’ the GPS. Maybe I’ll assume everything is messed up and restore old files across the board.

      • Geoff Coupe says:

        Ah, right. Yes, I fixed the files by restoring the originals, rather than deleting the unwanted GPS coordinates.

        Perhaps you could use the presence of a “JFIF” section as the flag that they’ve been touched by WLPG? I think that was the case for me. I think that files that have been compressed by WLPG will have the JFIF marker…

        • JL says:

          OK, I remember. Only the files with location metadata and without GPS had GPS added plus whatever else happened to them. So the damaged photos, or perhaps I could call them ‘altered’, are the ones that had the GPS added. So, that’s what I need to think about.

          Just before all this started for me I had been adding states and countries to a lot of photos so I’m not terribly familiar because I didn’t have time to get used to the new data.

          I would assume from that pretty much everything has been touched. What I was thinking, though, was that maybe not everything touched needs to be construed as ‘damaged’. Kind of like the LZW tif’s or perhaps that’s too hopeful.

          • Geoff Coupe says:

            The thing about LZW is that it’s lossless. JPEG compression ain’t. So, my theory is that any file where WLPG has added in GPS is also highly likely to have been compressed by WLPG as a side-effect. And since the compression isn’t lossless, the only real solution is to revert to a previous version of the file restored from a backup.

  18. JL says:

    Right. As I recall this came in stages of discovery.

    I first heard about the GPS, went and fixed all that, and then you wrote a post about the next round; the compression and metadata changes.

    I’m back to square one here where the errant GPS is no longer there as a clue. Very few of those photos had legitimate co-ordinates but I think a lot of them had addresses of some kind. Sounds like I’m looped. I did see JFIF as I was clicking through in ExifToolGUI.

    Right now I have 14.4 GB of backup photos from several sources so this is going to be fun. The original photos are spread through 105 folders (genealogists do projects!) And there are about 1,000 other files unaccounted for; a mix of png’s, gif’s, text, rtf and pdf.

  19. JL says:

    Looking at two folders of digital jpg’s, from different sources:

    The restored ones are smaller by 2-10K which indicates to me there’s extra metadata added to them by WLPG. The WLPG have IPTCext.

    All have JFIF. Oddly the restored ones are 96 dpi in the JFIF block, the WLPG ones are 200 dpi. And yet under the Photoshop resolution they all say 200.

    The WLPG ones have byte order of Big-endian; the restored ones don’t say.

    It’s all coming back to me now: IPTCext and Big-endian …

    • Geoff Coupe says:

      OK,if Photoshop also uses JFIF, then that’s not a discriminator. But it does look as though IPTCext can be used as a clear flag that the file has been touched by WLPG, since nothing else uses it in your workflow…

  20. JL says:

    Just when you think you must have seen it all, here’s another one:

    Png’s with WLPG-added XMP data but no updated modification dates. If I was trying to double-check by dates (and I was) that one goes out the window. They both say April 8, 2005.

    Tsk. Sloppy, sloppy, sloppy …

  21. JL says:

    The Big-endian situation is interesting because I see it all over the place; pictures I’ve downloaded from the Internet, (that could be anything) photos straight off my cousin’s digital camera … Is there a camera setting for reversing byte order? Maybe the software that’s ‘assisting’?

    Everything I never wanted to know about metadata, this is the close-up course.

    • Geoff Coupe says:

      Don’t worry about the Big-endian vs Little-endian thing – it’s as futile as the eponymous originals. The point I was making was that, according to metadata guidelines, editing software should leave the order alone, whereas WLPG 2011 is flipping it. You don’t need to look for means of flipping it back, just shake your head at the irony of WLPG 2011 flipping it in the first place, in defiance of the very guidelines that Microsoft helped to write.

  22. JL says:

    OK, now you’re making me look up words in the dictionary. Eponymous?

    Just curious – I have originals straight off my cousin’s camera with Big-endian. I’m wondering what software she’s using to download them.

    Yesterday I discovered the folder that houses half of the jpg’s; 1300 of them. The ‘easy’ restore, where I bring back an entire folder at once, only got 400. I had to restore the other 900 one at a time from earlier restore dates.

    Next step is to open them in Photo Mechanic and copy and paste the IPTC 1,300 times.

    • Geoff Coupe says:

      Ah, sorry – are you familiar with Gulliver’s Travels? That’s the origin of the big/little endian wars…

      Re your cousin’s camera – the endianess is set by the camera itself. The software used to download it will just leave it alone. The issue comes in when something reads in metadata, makes a change, and then writes it back out to a file. Such apps are called “Changers” (for obvious reasons). WLPG 2011, when it changes metadata is therefore a “Changer” app.

      Now, break’s over, back on your head (alas, another reference – this time to a very old joke)

      • JL says:

        Some of the photos are Big-endian and some are little-endian and they’re both off a Nikon camera. Maybe she has two of them? More questions.

        I don’t read enough … obviously, as I’m missing your jokes. The thought of 1,300 copy ‘n paste’s is deteriorating my mood.

        • Geoff Coupe says:

          Not having a Nikon, I couldn’t say which endian camp they belong to. It’s possible that a Changer has got hold of some, resulting in some being flipped.

          I’ll leave you to your copy and paste work. You have my deepest sympathy, and this time, I’m not joking.

  23. Anonymous Jason says:


    Just found the new (old) site. Useful as always. Noted today that Picasa 3.8 is claiming that “Picasa now supports XMP along with EXIF data.” Haven’t looked into what “support” means, precisely. But I’ve been using Picasa for several months now, after having my data trammeled once to often by WLPG. WLPG is such a frustrating program – I mean, it looks good, it’s free, it respects the “Windows” GUI – but damn, every version starts as the bummest of bum steers.

    Anon. Jason

    • Geoff Coupe says:

      Hi Jason, yep, I share your frustration. WLPG could be so good (and I was quite happy with the last version), but WLPG 2011 took a major leap backwards, while ostensibly offering new features. At least the GPS issue has now been addressed. As I note elsewhere, it’s possible that the Makernotes issue may get addressed in a future release, so then I’ll feel comfortable about using it for face recognition.

      However, there are a couple of “improvements” in 2011 that will probably never get addressed: the poor slide show quality, and the clunky workflow introduced because they took out the “Fix” button and introduced the “Edit, share and organize” button in its place.

  24. Lilla says:

    Jason says
    “But I’ve been using Picasa for several months now, after having my data trammeled once to often by WLPG.”

    You might be interested in this thread…
    Is Picasa 3 silently modifying exif info and dropping exif data!!! – Picasa Help:

    At this point, neither program seems safe to use.


    • Geoff Coupe says:

      Thanks, Lilla. That’s an interesting thread on the Picasa Help forum. If I’m reading it correctly, the Makernotes corruption may be fixed in the 3.8 version, but extraordinarily, it appears that when Picasa modifies metadata, it does not update the “File modified” date/timestamp. If this is so, then I find this astonishing – it’s breaking a fundamental rule of file behaviour in an operating system. Even more astonishing is that Brian Rose, the Google employee, doesn’t even seem to think that this is wrong behaviour. Absolutely incredible!

  25. Pingback: 2010 in review | Geoff Coupe's Blog

  26. JL says:

    Geoff, this is so old and yet so not forgotten. I’ve just discovered that all my digital files have wrong time-stamps, not entirely but fairly consistently off by 8 hours.. My saved-just-in-case restored-from-Carbonite files last Fall have correct time stamps. I suppose there could be other things that have happened between then and now, so have you heard anything about WLPG also changing time-stamps? I thought I had but didn’t pay attention because I thought by then I had left this @#%^ situation behind.

    • Geoff Coupe says:

      JL, you wouldn’t happen to be in a Timezone that differs from GMT by 8 hours would you?

      I remember a while back that I saw photos displayed in one tool being timeshifted by 1 hour (my TZ difference with GMT). It turned out that the tool did not, at the time, account for TZs. It could be that somewhere in your workflow, one of your tools is not accounting for TZs, dropping the TZ shift, and writing back the wrong time as a result…

      • JL says:

        As a matter of fact, I am.

        I’m trying to figure out which software is to blame. Or rather my ignorance of how to use it properly. Post-WLPG would be GeoSetter. And nothing else I can think of. I’ve used GeoSetter quite a bit for adding addresses and GPS to photos over the past year so maybe that.

        • Geoff Coupe says:

          JL, I see that Geosetter has a checkbox to “save Time Zone to Exif data”. I’m curious to know what happens with that – if it doesn’t save the TZ data, does it restamp the time?

          Might be an idea to ask Friedemann about this…

          • JL says:

            I saw that option too, and it may mean what it says: save Time Zone to Exif data”.

            I tried turning it on, then editing and re-saving one photo. It didn’t affect the time at all and I couldn’t find TZ listed in the Exif.

            I did some time adjustments using Photo Mechanic but it didn’t translate to GeoSetter which has it’s own option under ‘Date’ for changing time. I haven’t tried yet the other way around.

            It looks like I’m going to have to carefully pick through these 3,250 photos in small
            batches. Not every single one is off by 8 hours.

            • Geoff Coupe says:

              That is not a barrel full of fun. Sorry about that. I have the feeling that the problem is being caused by a combination of tools, rather than by one alone. I think that it will be the passing of data between one and another where the ball gets dropped. I hope that you find it, otherwise it may strike again…

  27. JL says:

    I found about 120 photos yesterday that were ahead by 3 hours due to having recently sent my camera for repair in a different time-zone. They didn’t reset the time before shipping it back. I ‘fixed’ the time in Photo Mechanic but it’s not fixed in GeoSetter. Interesting, though, it did not put them off by another 8 hours, just kept the original 3 hour difference.

    The only other software I use, although rarely, is XnView and it’s showing the correct time as I fixed it to be in Photo Mechanic.

Leave a Reply to Geoff Coupe Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.