After rotating an image with Microsoft Photo Gallery, it adds metadata. After this many original fields disappear and in a "-r -csv" extra bogus output lines may be produced.
I'll mail a zip with the original, the rotated picture and the csv file produced on a directory with just the 2 .jpg files.
I used:
- Windows 7 Ultimate SP 1 64 bit to run ExifTool
- ExifTool 9.62 (Windows exec and Perl version on ActiveState Perl v5.16.3 give same result)
- Microsoft Photo Gallery 2012 build 16.4.3528.331
- C:\>perl Image-ExifTool-9.62\exiftool -csv -r "bug_folder" >out_bug.csv
I don't have to look at these. It is well documented that Microsoft products cause corrupted metadata in images. This is a long standing problem that Microsoft doesn't seem to care about:
"Vista 'Mangles' Metadata" (http://forums.camerabits.com/index.php?topic=1011.0) - Feb. 2007
"Corrupt meta data after annotation sync" (Microsoft Expression Media) (http://social.msdn.microsoft.com/forums/expression/en-US/306466ad-8d4f-43b4-bed7-88542e467166/corrupt-meta-data-after-annotation-sync) - May 2010
"That Makernotes corruption bug was acknowledged by Microsoft a year ago, but it is still there in the latest build of WLPG." (http://gcoupe.wordpress.com/2011/12/10/picasa-versus-windows-live-photo-gallery/) - Dec. 2011
"WLPG Creates Bad Exif Metadata" (http://answers.microsoft.com/en-us/windowslive/forum/gallery-files/wlpg-creates-bad-exif-metadata-the-saga-continues/0c65bb55-39f0-4f76-ba1a-f4528167abd4) - Feb. 2012
"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" (http://gcoupe.wordpress.com/2013/10/05/photo-metadata-tools-the-saga-continues/) - Oct. 2013
- Phil
Thanks Phil, fortunately I have the originals on back-up.
Think there is a related bug in ExifTool though.
If I inspect a Microsoft-PG mangled .jpg file with exiftool -k, I get mostly correct results with some warnings like: "Warning : [minor] Possibly incorrect maker notes offsets (fix by 3752?)".
However, if I use exiftool -csv -r, I get far less correct data, plus some extra lines of garbage in the output CSV file following the line for the faulty file. See the .csv I have e-mailed.
Yes, I saw this CSV file. It looks fine to me. There is a (corrupted) value containing funny characters including newlines, but it is properly quoted so it should be valid CSV.
- Phil
Edit: Oh, wait. You're saying you get less data. I'll take a look again...
The only thing I can see that could be a problem is the CSV output contains null characters (binary zeros). Why do you say you get "far less correct data"? How are you viewing the CSV data?
My Excel 2013 reads it as 4 lines.
Must be the Microsoft .csv locale problem. MS has decided a .csv file in Dutch should use semicolons as a field separator.
No override in Excel, you have to change the locale for the PC. So in NL we split fields in Excel with tekst-2-columns afterwards. New line escapes won't work in this case.
Thnx, Gijs
Checked the csv in notepad++.
Turned out the "missing" stuff was in one of the subsequent lines at the far end.
So its just CR or LF messing things up due to the locale problem.