Photo Metadata Tools – The Saga Continues

A couple of weeks ago, I blogged about the tools I use to manage my collection of photos and the metadata contained in them.

In it, I noted that interoperability issues between metadata editing tools was a problem. Never was a truer word spoken (or written).

One of the complaints I have had for a long while about Microsoft’s Windows Photo Gallery (WPG) is that, in my experience, it corrupts the Makernotes metadata in images produced by my Canon cameras. That led to an interesting discussion in the comments of that blog post with Mike Lee. He said that he wasn’t seeing the metadata corruption when he used WPG. We established that we were both using the same version of WPG (build 16.4.3508.205), so then we had a mystery: why was I seeing metadata corruption, and he wasn’t? A further surprise was when he said that a sample file that I had uploaded to SkyDrive to share with him contained metadata errors, whereas I was positive that it was error-free.

So I set out to investigate. I took a photo using my Canon EOS 450D camera, and copied it onto my Desktop PC. This original file has the name IMG_7383.jpg:

Using Mike’s MetadataMirror tool (which uses Phil Harvey’s most excellent ExifTool under the covers), I obtained a listing of all the metadata present in this original file. As expected, the only metadata present in the file (other than the Windows metadata) is the Exif data inserted by the camera itself. This is in three groups: standard Exif, Canon Makernotes and Canon Composite tags. Here’s a link to the file (IMG_7383.txt) containing the metadata listing:

http://sdrv.ms/1aVOMkn

The next step was to use Photo Supreme (PSU) on a copy of the image (IMG_7383 – PSU.jpg) to stamp in my usual boilerplate of metadata: e.g. my name and copyright information. The file (IMG_7383 – PSU.txt) listing the metadata resulting from using PSU on this image file is here:

http://sdrv.ms/1a16hx6

PSU has preserved the original metadata, while adding some new items. This new metadata is both XMP-based and IPTC-IIM (for backwards compatibility). PSU also writes XMP equivalents for many of the original Exif items. So for example, if you look in the file, you will see items such as:

[EXIF] Make: Canon
[EXIF] Model: Canon EOS 450D
[EXIF] Orientation: Horizontal (normal)
[EXIF] XResolution: 72
[EXIF] YResolution: 72
[EXIF] ResolutionUnit: inches
[EXIF] ModifyDate: 2013:10:04 21:06:31
[EXIF] YCbCrPositioning: Co-sited

PSU creates XMP equivalents:

[XMP] Make: Canon
[XMP] Model: Canon EOS 450D
[XMP] Orientation: Horizontal (normal)
[XMP] XResolution: 72
[XMP] YResolution: 72
[XMP] ResolutionUnit: inches
[XMP] DateTime: 2013:10:04 21:06:31.300+02:00
[XMP] YCbCrPositioning: Co-sited

PSU also adds in the boilerplate that I use in XMP, e.g.:

[XMP] Title: IMG_7383 – PSU
[XMP] Rights: 2013 Geoff Coupe, Creative Commons
[XMP] Creator: Geoff Coupe
[XMP] CreatorWorkURL: https://gcoupe.wordpress.com
[XMP] UsageTerms: Creative Commons Attribution Non-commercial Share-alike

It also includes a notification that it has been used to edit the file, together with a timestamp. This is all as it should be, according to metadata standards.

[XMP] CreatorTool: IDimagerSU (1.9.5.170)
[XMP] MetadataDate: 2013:10:05 10:03:31.353+02:00

In summary, there is absolutely nothing untoward about the resulting image file, as far as I can see. The structure of the Exif metadata is preserved, and XMP-based metadata has been added correctly.

The next step was to take a copy of this file and add one item of metadata using WPG. This file is IMG_7383 – PSU+WPG.jpg and the corresponding file listing the metadata is IMG_7383 – PSU+WPG.txt:

http://sdrv.ms/16pxkoF

Immediately, you can see there’s a problem – errors are being reported:

[ExifTool] Warning: [minor] Possibly incorrect maker notes offsets (fix by 4476?)
[ExifTool] Warning: Invalid CanonCameraSettings data
[ExifTool] Warning: Invalid CanonShotInfo data
[ExifTool] Warning: Invalid CanonFileInfo data
[ExifTool] Warning: [minor] Suspicious MakerNotes offset for DustRemovalData
[ExifTool] Warning: Invalid CustomFunctions2 data
[ExifTool] Warning: Invalid ProcessingInfo data
[ExifTool] Warning: Invalid MeasuredColor data
[ExifTool] Warning: Invalid SensorInfo data

And indeed, whole chunks of the Canon Makernotes are missing from the image file (left is the metadata in IMG-7383 – PSU.jpg and right is that in IMG_7383 – PSU+WPG.jpg):

There are also two other possibly significant things about this image file, captured in the metadata. The first is that when WPG writes back to the image file, it reverses the byte order of the Exif data structure. Originally, the Exif is in Little-endian order as shown in this line from both the original IMG_7383.txt and the IMG_7383 – PSU.txt files:

[File] ExifByteOrder: Little-endian (Intel, II)

However, once WPG has changed the file, the byte order is now Big-endian:

[File] ExifByteOrder: Big-endian (Motorola, MM)

Now, this may, or may not, be a problem, but it is definitely contrary to the advice given by the Metadata Working Group, which states that byte order should be preserved by tools that operate on image files.

Secondly, WPG introduces an offset in the Exif data structure when adding the changed metadata:

EXIF] Padding: (Binary data 2060 bytes, use -b option to extract)
[EXIF] OffsetSchema: 4476
[EXIF] XPAuthor: Geoff Coupe 2
[EXIF] Padding: (Binary data 2060 bytes, use -b option to extract)

So, at this point in the saga, I believe that I’ve established that for any given image that contains Canon Makernotes data, using PSU followed by WPG to edit metadata will result in the corruption of the Makernotes data. This is repeatable for all such image files that I’ve tested.

What happens if I use WPG followed by PSU to edit metadata? Let’s find out.

I used WPG to add myself as author to a copy of the original image: IMG_7383 WPG.jpg. The metadata listing (IMG_7383 WPG.txt) is here:

http://sdrv.ms/1e16G6W

You’ll notice immediately that ExifTool gives a warning about the Makernotes structure:

[ExifTool] Warning: [minor] Adjusted MakerNotes base by 4176

Also, the byte order has been changed, and padding introduced:

[File] ExifByteOrder: Big-endian (Motorola, MM)

[EXIF] Padding: (Binary data 2060 bytes, use -b option to extract)
[EXIF] OffsetSchema: 4176
[EXIF] XPAuthor: Geoff Coupe
[EXIF] Padding: (Binary data 2060 bytes, use -b option to extract)

However, there is no Makernotes corruption.

Now let us use PSU to edit the metadata in this file (I changed the Title to read IMG_7383 – WPG+PSU). The resulting image file is IMG_7383 – WPG+PSU.jpg and the corresponding listing of the metadata is IMG_7383 – WPG+PSU.txt, and can be found here:

http://sdrv.ms/GEzvu1

The interesting thing here is that the byte order has been switched back to Little-endian, and the padding removed:

Other than that, the metadata looks fine; no Makernotes are missing, and ExifTool reports no errors.

So far, so good, but now if I go back and use WPG once more, I get Makernotes corruption again. The image file is IMG_7383 – WPG+PSU+WPG.jpg and the metadata listing is IMG_7383 – WPG+PSU+WPG.txt:

http://sdrv.ms/192O5V7

The byte order has been switched again, padding introduced, and ExifTool reports:

[ExifTool] Warning: [minor] Possibly incorrect maker notes offsets (fix by 4428?)
[ExifTool] Warning: Invalid CanonCameraSettings data
[ExifTool] Warning: Invalid CanonShotInfo data
[ExifTool] Warning: Invalid CanonFileInfo data
[ExifTool] Warning: [minor] Suspicious MakerNotes offset for DustRemovalData
[ExifTool] Warning: Invalid CustomFunctions2 data
[ExifTool] Warning: Invalid ProcessingInfo data
[ExifTool] Warning: Invalid MeasuredColor data
[ExifTool] Warning: Invalid SensorInfo data

And once again, chunks of Makernotes have gone:

So it seems that using PSU first, followed by WPG, will trigger a corruption of Canon Makernotes; however, using WPG followed by PSU does not.

But there is one more twist to this saga.

Remember that Mike had said that a sample file that I had uploaded to SkyDrive to share with him contained metadata errors, whereas I was positive that it was error-free?

I know that the image files IMG_7383 – PSU.jpg and IMG_7383 – WPG+PSU.jpg do not contain errors. I have the metadata listings to prove it. And yet, if you download these files from SkyDrive, you will find that the Makernotes have also been corrupted. By comparison, if you download the same files from this set on Flickr, you’ll find that they are error-free.

What’s going on here? I can only surmise that SkyDrive is doing some metadata processing on the images stored on the service, and that a similar, or the same, code library has the processing fault that triggers the Makernotes corruption on images that have already been processed by PSU.

The SkyDrive folder containing these test images and their metadata files is here.

The Flickr set containing the same test images is here.

I like both PSU and WPG, but using them together can be dangerous.

Addendum 7 October 2013

I’ve been doing some further investigation and established the following

WPG definitely doesn’t like something about the metadata structures that PSU creates
None of my other metadata tools complain about PSU
ExifTool shows nothing amiss with the metadata that PSU creates.

I can have an image file that has had metadata edited by a whole series of tools, but if at any point I have used PSU followed at some point further down the chain by WPG, then WPG will corrupt my Makernotes metadata.

For example, I created two examples of chained metadata operations on files. The first was the sequence: Geosetter, XnViewMP, Lightroom 5, and WPG. At each stage I added a keyword identifying which tool I was using. The final result is given in the metadata listing: IMG_7383 – G+X+LR+WPG.txt, and there’s no corruption; here’s the start of the listing (but note the final offset, and the reversed byte order):

[ExifTool] ExifToolVersion: 9.35
[ExifTool] Warning: [minor] Adjusted MakerNotes base by 4236
[File] FileName: IMG_7383 – G+X+LR+WPG.JPG
[File] Directory: F:/Users/Geoff/Pictures/2013/2013-10/2013-10-07
[File] FileSize: 3.9 MB
[File] FileModifyDate: 2013:10:07 18:10:04+02:00
[File] FileAccessDate: 2013:10:07 18:10:03+02:00
[File] FileCreateDate: 2013:10:07 18:09:27+02:00
[File] FilePermissions: rw-rw-rw-
[File] FileType: JPEG
[File] MIMEType: image/jpeg
[File] ExifByteOrder: Big-endian (Motorola, MM)
[File] CurrentIPTCDigest: f042c8560b6fafea9c47a1c0249baec1
[File] ImageWidth: 4272

The second was the sequence: PSU, Geosetter, XnViewMP, Lightroom 5, and WPG. Again, at each stage I added a keyword identifying which tool I was using. At each step, the metadata was as expected. Then in the last step, WPG is used to add another keyword, and bang – corruption occurs . The final result is given in the metadata listing: IMG_7383 – PSU+G+X+LR+WPG.txt. Here, WPG will corrupt the Makernotes metadata; here’s the start of the listing:

[ExifTool] ExifToolVersion: 9.35
[ExifTool] Warning: [minor] Possibly incorrect maker notes offsets (fix by 4526?)
[ExifTool] Warning: Invalid CanonCameraSettings data
[ExifTool] Warning: Invalid CanonShotInfo data
[ExifTool] Warning: Invalid CanonFileInfo data
[ExifTool] Warning: [minor] Suspicious MakerNotes offset for DustRemovalData
[ExifTool] Warning: Invalid CustomFunctions2 data
[ExifTool] Warning: Invalid ProcessingInfo data
[ExifTool] Warning: Invalid MeasuredColor data
[ExifTool] Warning: Invalid SensorInfo data
[File] FileName: IMG_7383 – PSU+G+X+LR+WPG.JPG
[File] Directory: F:/Users/Geoff/Pictures/2013/2013-10/2013-10-07
[File] FileSize: 3.9 MB
[File] FileModifyDate: 2013:10:07 18:25:07+02:00
[File] FileAccessDate: 2013:10:07 18:25:07+02:00
[File] FileCreateDate: 2013:10:07 18:24:37+02:00
[File] FilePermissions: rw-rw-rw-
[File] FileType: JPEG
[File] MIMEType: image/jpeg
[File] ExifByteOrder: Big-endian (Motorola, MM)

WPG is sniffing out something that PSU puts in a file, and throws a fit… I’ve asked the developer of PSU for help, but he can’t guess what WPG chokes on. Right now, without input from Microsoft, it’s all guesswork and that could take forever.

Microsoft were informed about this a couple of years ago, but since acknowledging that there was an issue, there’s been complete silence.

October 5, 2013

Categories:

Computers and Internet, Photography

33 responses to “Photo Metadata Tools – The Saga Continues”

Sharing Photos | Geoff Coupe's Blog

October 6, 2013

[…] Photo Metadata Tools – The Saga Continues […]

Reply
Ludwig

October 7, 2013

Well, Geoff, I think you have devoted more time to investigate these bugs than Microsoft has spent on maintaining or improving Photo Gallery. With you presenting them with the details on a silver platter, maybe there is one person still left who can implement a solution.

Reply
Arunas

October 10, 2013

Geoff, you don’t mention Picasa in this post, but previously I believe you said that Picasa was also corrupting makernotes metadata. Is this related to PSU as well, or Picasa corrupts metadata on its own?

Reply
1. Geoff Coupe
  
  October 10, 2013
  
  Arunas, as far as I know, the Picasa issue is independent of any use of PSU. What happens with Picasa is that it strips out the Makernotes entirely from the Exif section. This has been reported by others, who may or may not be using PSU.
  
  Reply
Hert

October 14, 2013

I’d like to make it clear that ExifTool doesn’t report anything wrong with metadata that was written with PSU. The corruption that ExifTool reports occurs *after* the metadata was written with WLPG. If there’s something that PSU wrote to the file and what, for some unclear reason, chokes WLPG then I’d be more than happy to help provide a workaround so that WLPG no longer chokes on it.

This is what ExifTool reports about Makernotes that are written with Microsoft tools;
http://owl.phy.queensu.ca/~phil/exiftool/standards.html#PhotoInfo

Reply
1. Geoff Coupe
  
  October 14, 2013
  
  Hert – I agree, the metadata written by PSU looks fine. However, WPG clearly doesn’t like something about it, and I don’t mean to imply that that is PSU’s fault.
  
  I know that you are willing to provide a workaround, but unfortunately we first need Microsoft to identify what the issue is, and so far they clearly can’t be bothered to provide any assistance. I’m waiting to see if I can get any reaction from them via an approach to the Microsoft representative on the Metadata Working Group. Thus far, there’s been no reaction from that quarter either.
  
  Reply
Norm

June 3, 2014

I currently use Picasa, love the facial recognition but have never used it to add tags or make corrections to my photos. I’ve use it for facial recognition and cataloging only. I only shoot jpeg and have never altered any of my photos with any program. Since my old naming convention includes a lot of info in the name of the photos, I have not added any Tags to the Metadata either. I recently bought a new OM-D E-M1 M43 camera and thought it would be nice to start simplifying my photo naming conventions and switch over to using Tags as well as doing some post processing. So, I started doing a little Google searching and came across your blog. I had remembered reading a little of it a couple years ago and just assumed most of the problems had been fixed by the various software companies. Boy was I surprised. I’ve been reading through your blogs for a while now and this whole mess is really disheartening. I have no idea what to do.

I was thinking of switching over to LightRoom but after a little research I found that the company may only provide their CLOUD version on their next release. Anyway, I have no idea what product to use that will keep my Metadata safe while adding Tags, allow facial recognition and store it in the Metadata and allow me to perform some very simple post processing. I don’t use geo data yet.

In preparation to migrating away from Picasa, I was also going to try to move the facial recognition information in Picasa from the .ini files to the XMP Metadata of each photo. In Picasa under Tools, Options, Name Tags, there is an option to Store Name Tags in Photos. This is for all faces found after the check box is checked. If you want to have Picasa go through all of your older photos you have to go into Tools, Experimental and run the Write Faces to XMP tool. I can only assume this will corrupt the heck out of all of the metadata?

Any words of wisdom? Is there a single program that will do what I’m asking without corrupting Metadata and still provide facial recognition? Is there a clean way of migrating the facial info in Picasa over to the Metadata so it can be used by other programs?

Norm

Reply
1. Geoff Coupe
  
  June 3, 2014
  
  Norm, I haven’t been running Picasa on my system for a while now (I’m waiting for a major upgrade from Google before I take another look). However, I think that the current version will store the facial recognition data into the image metadata (using the MWG standard) without problems.
  
  The only issue that you might have is that Picasa will remove Makernotes from your images, but frankly, if you are using JPG files, this may not be relevant for you. It’s only for anal types like me who insist that the original files remain pristine in all cases that it starts to be an issue. I think you’ll be OK going with Tools, Experimental and running the Write Faces to XMP. Then you’ll have facial recognition data written using the MWG standard in your images, which should be future-proofing for a possible future move away from Picasa to some other tool of your choice. If you don’t mind losing Makernotes from your files, then this is not an issue.
  
  My main application for metadata handling continues to be Photo Supreme. This also supports the MWG facial recognition standard, so it would read in, and display, the metadata written by Picasa for facial recognition.
  
  Reply
  1. Norm
    
    June 3, 2014
    
    Geoff,
    
    Thanks so much for your prompt reply. This stuff is so confusing to me and I don’t want to have to try to repair everything months from now if I can help it.
    
    I’m not trying to be cheap and am willing to pay for a product that works and adheres to the standards that have been established. Although I don’t typically use maker notes at this time, I may want them in the future and although I’m currently using jpeg, I may end up messing with raw as well – not likely but possible. I just cringe at the fact that several programs stomp on this data and the authors have not made any attempts to fix it. Once it is gone, it is gone forever.
    
    Can you tell me if Photo Supreme has facial recognition built into the product? In other words will it detect faces and associate names with them and populate the Metadata or do you have to run a separate product like Picasa to populate the data and after that Photo Supreme recognizes it?
    
    Do you know if Lightroom adheres to these standards? Is it safe to use and does it do facial recognition?
    
    Norm
    
    Reply
    1. Geoff Coupe
      
      June 3, 2014
      
      Norm,
      Photo Supreme does not have automatic facial recognition; only manual (you place a rectangle over a face and assign a name to it). As you say, it will recognise MWG face metadata that has been created by Picasa. It also knows about the Microsoft People Tag metadata used by Windows Photo Gallery. So either Picasa or WPG can be used to populate face recognition metadata, which will then be read in by Photo Supreme for subsequent management.
      
      The current version of Lightroom does not support face recognition, either manual or automatic. If an image contains face metadata (either the MWG or the Microsoft standard) then it will just ignore it, and leave it alone.
      
      Reply
      1. Norm
        
        June 3, 2014
        
        Ok, say I decide to go with Photo Supreme. As I’m seeing it, there is not a way to get Picasa to populate the faces and location of faces without corrupting the maker data.
        
        WPG on the other hand doesn’t corrupt the maker data but then again doesn’t put the faces and location of faces into the proper areas within the Metadata. There may be other problems with WPG that I’m not aware of.
        
        So should I go with Photo Supreme and NOT use any facial recognition until someone figures out how to do it without corrupting the maker data? That’s terrible because I really like facial recognition.
        
        I’ve been in limbo for a while now and have not done any tagging or post processing because the process seems to involve using several different programs, one for each function – cataloging, facial recognition, tagging, rotating, post processing, etc. This is confusing and I’m not sure exactly what application to use for each function.
        
        Sorry I come across as a newbe but that’s exactly what I am and I want to get started off down the right path. I really appreciate your blog and all the research you’ve put into this.
        
        Norm
        
        Reply
        
        Geoff Coupe
        
        June 3, 2014
        
        Norm,
        
        I’m afraid that it’s a little bit different to what you’ve written…
        
        Picasa doesn’t “corrupt” the Makernotes metadata – it just removes them completely from your image files.
        
        The situation with WPG is a bit more complicated. Normally, it will leave Makernotes alone. It twiddles about with the metadata (in more technical terms, it switches the byte order). However, and most unfortunately, there is the interaction between PSU and WPG described in this post – if PSU has been used on an image file, and WPG is used subsequent to this, then if WPG writes back metadata into the file, it will corrupt the Makernotes metadata.
        
        I, and the developer of PSU, have never been able to get to the bottom of this. Microsoft refuse to help, despite acknowledging that there is an issue, so we are stuck with it.
        
        What you could do (and it’s a kludge, I admit), is to first use WPG to do face recognition on your files. That would add Microsoft People Tags into your metadata. From that point on, use PSU to do all the rest of your metadata management. PSU will read in the Microsoft People Tags, and convert them to the MWG standard, and the original Makernotes will be preserved. You can also use PSU for simple post-processing (rotating, cropping, colour balance).
        
        PSU, like Lightroom, is a non-destructive editor in post-processing, so your original file can be preserved at all times. You can apply a post-processing recipe to a file and export a finished, changed file if you want, but it’s not required. I happen to use Lightroom in addition to PSU, but that is simply because Lightroom has more flexibility in image processing than PSU for RAW/DNG files. However, for metadata management, nothing comes close to PSU.
        
        Reply
        
        Hondor
        
        July 12, 2014
        
        There’s one catch to using WPG before importing into PSU, though.
        
        The area tags in my experience are not in their correct places after import, and manual correction leaves the original (misaligned) WMP-MP tags – undeleteable from PSU.
        
        I have reported the issue to the PSU team, but I have also subsequently de-installed WPG, since I don’t really like the way it pokes around in all my Photos folder without me being able to exclude any from it’s sticky metadata-corrupting ways.
        
        Since facetagging really is a chore, I’m still on the lookout for a non-makernote-destructive way of using a facetagging program like WPG or Picasa in combinatation with PSU – which I really like and have recently bought. I’m wondering if makernotes could be merged back into the picture from a backup-copy of the picture, so that Picasa could be used after all – their facetags are not misaligned when imported.
        
        Your blog is a delight to read BTW – I’ve been doing it for the better part of a year.
        
        Reply
        
        Geoff Coupe
        
        July 16, 2014
        
        Hondor, you wrote:
        
        “I’m wondering if makernotes could be merged back into the picture from a backup-copy of the picture, so that Picasa could be used after all”
        
        This sounds like something that could be done using Exiftool and some clever scripting. I’m afraid it’s well beyond my capabilities to come up with such a script. Perhaps you could ask on Phil Harvey’s Exif forum?
        
        Thanks for the compliment, BTW 🙂
        
        Reply
        
        Hondor
        
        July 31, 2014
        
        Just an update – the problem with misaligned imported WMP-MP has been corrected in the latest build of PSU.
        
        Reply
        
        Geoff Coupe
        
        July 31, 2014
        
        Hondor, thanks for letting me know. Hert is very good at supporting PSU – the next version (V3), currently being beta-tested, has some good new features as well.
Norm

June 4, 2014

Thanks Geoff,
It bothers me that PSU and WPG don’t play well together. It really makes me reluctant to use them. I’m guessing WPG is the culprit.

I’ve done some more investigating and came across a program called AvPicFaceXmpTagger to search for .picasa.ini face definitions. If face definitions are found for a file, they are added as XMP tags. Optionally, you can also have the program add the persons names as IPTC Keyword tags.

The actual tagging of the JPEG files is done using ExifTool which provides good makernotes handling.

What do you think of using Picasa for facial recognition, management and viewing. Then run AvPicFaceXmpTagger to populate the XMP tags and IPC keyword tags. I’d still need to find a good program (PSU) for post processing photos and adding any additional tags. Not a simple solution though……

Norm

Reply
1. Geoff Coupe
  
  June 4, 2014
  
  Norm,
  
  I wouldn’t use AvPicFaceXmpTagger if I were you. It was developed for earlier versions of Picasa that did not store Face regions in the metadata, but only in the local Picasa database on your computer. It actually uses the Microsoft People Tag standard (the same standard used by WPG). Now that Picasa stores face regions in metadata using the MWG standard, the time of AvPicFaceXmpTagger has passed, as far as I’m concerned. I think as far as the developer, Andreas Vogel, is concerned as well. I don’t think that there have been any updates for several years now.
  
  Just use Picasa for facial recognition, management and viewing. Turn on the writing of face regions into the metadata and you’re set. PSU has a free trial, give it a whirl. That should give you the link between the face regions and the IPTC Core Keywords that you’re looking for.
  
  The only thing is that Picasa will remove Makernotes, so if that’s really important to you, then you’ll have to go down the AvPicFaceXmpTagger route, and not use Picasa for ANY keyword management. Once Picasa writes metadata into a file, your Makernotes are gone.
  
  Reply
Pieter Roggemans

August 22, 2014

Hello!
Regarding makernotes and Picasa… to be more precise:
– Picasa never explicitly removes the makernotes
– Picasa preserves the makernotes correctly for quite some camera’s
– For some camera’s, Picasa doesn’t identify the (proprietry) makernotes correctly and so they are written back to the file in a wrong format… and they become unreadable.

In the latest version of Picasa support has been added for some additional camera’s… it might be a good moment to test it again.

If not ok yet, it would be great if you post the problem in the picasa forum and mention the brand and the model of the camera and upload a (zipped) before and after version of the test picture.
https://productforums.google.com/forum/#!forum/picasa

Reply
1. Geoff Coupe
  
  August 22, 2014
  
  Hallo Pieter, it’s been a while since I tested Picasa, so perhaps things have changed in the latest builds. But certainly, the last time I looked (six months ago?), Picasa was definitely deleting the Makernotes created by my Canon 450D.
  
  I’ll try and find time to re-examine the latest build and post results in the next month or so.
  
  In any case, thanks for the comment.
  
  Reply
  1. Pieter
    
    August 22, 2014
    
    Thanks,
    As far as I know it wasn’t fixed for that camera model, so most likely it will be still broken for you… but if you post in the picasa forum with an original picture containing the markernotes, there is at least a reproducable example, and that is the start of any possibility for a solution. Mind: I’m not a google employee, just a Picasa enthousiast, so I cannot guarantee it will be solved nor can I give any ETA.
    
    Same message ofcourse to anyone having any camera that gives makernotes problems in Picasa at the moment…
    
    Thanks.
    
    Reply
    1. Geoff Coupe
      
      September 1, 2014
      
      Pieter, this issue has been around since at least 2011. Like Hondor, I have little confidence that the Picasa team will address it successfully. I’ve just done a quick scan of the product forum and when I come across threads such as this, then I really wonder whether the team has either the will or the competence to address the issue satisfactorily. That sounds harsh, but that’s what I see. Other software vendors (and Phil Harvey) seem to be able to preserve Makernotes, but not the Picasa team it would seem.
      
      Reply
      1. Pieter
        
        September 1, 2014
        
        Geoff,
        That thread is actually not the best example… the conclusion of that thread was that the “Gallery” on Android strips all exifdata, so Picasa didn’t strip anything…
        https://productforums.google.com/d/msg/picasa/d3iRdl0jOm8/U5_ZVOIg-nsJ
        
        But… no problem of course, you are free to supply example files or not.
        
        Reply
Hondor

August 31, 2014

Full of hope, I re-installed the latest Picasa 3.9.138 and hesitantly tried writing XMP facetags out to 4 test pictures of mine taken each taken with a different camera. I used a pictue from an oll Canon P&S, an newer Panasonic compact, and two Canon DSLR’s including my current 6D.
Same result every time.
All Makernotes and not a few EXIF notes were completely wiped out.
Much as I yearn for having automatic face tagging back in my workflow, I simply cannot trust Picasa anymore…

Reply
1. Geoff Coupe
  
  August 31, 2014
  
  Ah, not good. Thanks for letting us know, at any rate.
  
  Reply
2. Pieter
  
  August 31, 2014
  
  Hondor,
  That’s not good. Could you please post example pictures of the different camera’s in the Picasa forum? No guarantees, but example photos are the first small step towards a possible solution…
  https://productforums.google.com/forum/#!forum/picasa
  
  Reply
  1. Hondor
    
    September 1, 2014
    
    I’m afraid I can’t trust the Picasa team anymore to address this matter adequately. I was particularly dismayed to see Picasa fail on each and everyone of my cameras. AvPicFaceXmpTagger contrarily got it right the first time friggin’ 5 years ago. I have just checked that AvPicFaceXmpTagger will not remove anything, and will just add the XMP tags non-disruptively. Makernotes preservation as far as I can see doesn’t seem to be a priority to the Picasa team.
    
    Reply
    1. Pieter
      
      September 1, 2014
      
      Hondor,
      OK, at least we have the camera models that give troubles for you, probably we’ll be able to find example files from those camera’s on the web somewhere to get test cases.
      
      FYI: AvPicFaceXmpTagger only adds name tags in the XMP section of the file, so it doesn’t need to touch the EXIF section… and the EXIF section is the nasty one as it is there that the proprietry makernotes are put.
      But, even if it is not a fair or relevant comparison, you are right that it is a pity Picasa doesn’t do a better job…
      
      Reply
      1. Hert
        
        September 12, 2014
        
        @Pieter; that’s not entirely correct. For embedded formats, XMP is written as a tag in EXIF. And so in order for a tool to write embedded XMP it needs to rewrite the entire Exif section of the file (padding aside). For AvPicFaceXmpTagger to write the XMP it needs to touch the EXIF section too.
        
        Reply
        
        Pieter
        
        September 18, 2014
        
        @Hert: OK, sorry, I haven’t studied XMP and EXIF that deeply, and aparently I made a wrong assumption :-(.
        
        Reply
nogginthenog

July 9, 2015

Very interesting, both the blog entry and the comments. I have just spent an afternoon tracking the extent to which XnViewMP is trashing my metadata, including Makernotes.

I was interested to hear of Mike Lee’s MetadataMirror. It doesn’t seem to be there any more. Has it moved? Does anyone know a good alternative?

Reply
1. Geoff Coupe
  
  July 9, 2015
  
  Hi nogginthenog. Probably the best thing is to contact Mike directly via his web site?
  
  Reply
  1. nogginthenog
    
    July 9, 2015
    
    Wil ldo. Thanks.
    
    Reply