GNOME Bugzilla – Bug 532668
Photos get date from file changed time?
Last modified: 2010-09-18 16:40:22 UTC
Please describe the problem: I convert my .RAW files using Bibble. All imported photos get the wrong date and time, namely the date and time when the file was changed or created - not the date in the metadata. The metadata seems to contain the correct date-time info. Up until the beginning of this year, this had not been a problem. In the time period that the problem appeared, I changed From Ubuntu Gutsy to Ubuntu Hardy, with F-Spot 0.4.2, and from Bibble 4.9.8 to 4.9.9. Steps to reproduce: 1. Convert .RAW with Bibble to JPEG, with exif-data included 2. Drag JPEG to F-Spot Actual results: Photo gets imported, with date-time same as when the JPEG was created - not when the photo was captured. Expected results: Date-time should be set to when the photo was captured. Does this happen every time? This happens every time. Other information:
Created attachment 110736 [details] File info (Nautilus) JPEG file created 11th May 2008
Created attachment 110737 [details] Image meta data (Nautilus) Photo captured 2008:04:20
Created attachment 110738 [details] F-Spot screen shot. Photo date-time: 2008-05-11
Created attachment 110739 [details] Exif meta data (from exiv2 -p v filename)
I am experiencing exactly the same problem. I am using f-spot svn and I am not sure when this strange behavior started but I am quite sure that it worked in december.
@paul: So the photos you import have been converted using Bibble? I tried converting a .NEF using RawTherapee, and it was imported ok... Don't know why. I will attach both the Bibble converted and the RT converted JPEGs.
Created attachment 110865 [details] Converted with Bibble 4.9.10 - wrong date on F-Spot import This photo is imported in F-Spot with the date that the JPEG was created, instead of when the photo was captured, as set in the metadata.
Created attachment 110866 [details] Converted with RawTherapee 2.3 - correct date on F-Spot import This photo is imported in F-Spot with the correct date, i.e. when the photo was captured, as set in the metadata.
I just noticed that a photo converted with Bibble, then opened and resaved with the GIMP gets imported correctly. Attaching one of these as well...
Created attachment 110867 [details] Converted with Bibble 4.9.10, resaved with the GIMP - correct date on F-Spot import The Bibble converted JPEG was opened and resaved with the GIMP. F-Spot imports with the correct (capture) date.
I will check the f-spot console output when I reach at home, this afternoon. Perhaps Bibble does some strange exif things and f-spot is not able to read it and instead of going on reading it throws an error. Would not be the first time Bibble is writing some non standard exif in the converted JPG. So I will have to contact the Bibble team another time -- if this is the reason.
This is the output loading the attached photo. Seems to be the same thing as last year. The error is similar, so the Bibble guys did not correct the error although they promised it. What is the problem here? With some details I will contact the Bibble guys again. But anyway I think F-Spot should handle this exception. It is able to read the exif dates in the exif window (Ctrl+I) so why not while loading it? open uri = file:///home/paul/Photos/2008/05/01/dsc_5075.jpg Error loading Subdirectory ExifIfdPointer at 8 of 25582bytes: System.Exception: recursive ifd at FSpot.Tiff.SubdirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] System.NullReferenceException: Object reference not set to an instance of an object at FSpot.JpegFile.get_Date () [0x00000] open uri = file:///home/paul/Photos/2008/05/01/dsc_5075.jpg Error loading Subdirectory ExifIfdPointer at 8 of 25582bytes: System.Exception: recursive ifd at FSpot.Tiff.SubdirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] System.NullReferenceException: Object reference not set to an instance of an object at FSpot.JpegFile.get_Date () [0x00000] System.NullReferenceException: Object reference not set to an instance of an object at FSpot.JpegFile.get_Description () [0x00000] open uri = file:///home/paul/Photos/2008/05/14/dsc_5075.jpg Error loading Subdirectory ExifIfdPointer at 8 of 25582bytes: System.Exception: recursive ifd at FSpot.Tiff.SubdirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] System.NullReferenceException: Object reference not set to an instance of an object at FSpot.Tiff.Header.SelectDirectory (FSpot.Tiff.ImageDirectory dir, StatementSink sink) [0x00000] at FSpot.Tiff.Header.SelectDirectory (FSpot.Tiff.ImageDirectory dir, StatementSink sink) [0x00000] Stopping open uri = file:///home/paul/Photos/2008/05/14/dsc_5075.jpg open uri = file:///home/paul/Photos/2008/05/14/dsc_5075.jpg Error loading Subdirectory ExifIfdPointer at 8 of 25582bytes: System.Exception: recursive ifd at FSpot.Tiff.SubdirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] Query: SELECT photos.id, photos.time, photos.uri, photos.description, photos.roll_id, photos.default_version_id, photos.rating FROM photos WHERE photos.roll_id IN (228) AND photos.id NOT IN (SELECT photo_id FROM photo_tags WHERE tag_id = 2) ORDER BY photos.time Reloading Query: SELECT photos.id, photos.time, photos.uri, photos.description, photos.roll_id, photos.default_version_id, photos.rating FROM photos WHERE photos.id NOT IN (SELECT photo_id FROM photo_tags WHERE tag_id = 2) ORDER BY photos.time item changed open uri = file:///home/paul/Photos/2008/05/14/dsc_5075.jpg Error loading Subdirectory ExifIfdPointer at 8 of 25582bytes: System.Exception: recursive ifd at FSpot.Tiff.SubdirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000] open uri = file:///home/paul/Photos/2008/05/14/dsc_5075.jpg Query: SELECT photos.id, photos.time, photos.uri, photos.description, photos.roll_id, photos.default_version_id, photos.rating FROM photos WHERE photos.roll_id IN (228) AND photos.id NOT IN (SELECT photo_id FROM photo_tags WHERE tag_id = 2) ORDER BY photos.time Reloading Query: SELECT photos.id, photos.time, photos.uri, photos.description, photos.roll_id, photos.default_version_id, photos.rating FROM photos WHERE photos.id NOT IN (SELECT photo_id FROM photo_tags WHERE tag_id = 2) ORDER BY photos.time open uri = file:///home/paul/Photos/2008/05/14/dsc_5075.jpg open uri = file:///home/paul/Photos/2008/05/14/dsc_5075.jpg Error loading Subdirectory ExifIfdPointer at 8 of 25582bytes: System.Exception: recursive ifd at FSpot.Tiff.SubdirectoryEntry.LoadExternal (System.IO.Stream stream) [0x00000]
Created attachment 110928 [details] Photo causing the bug
I'm also using Bibble (version 4.9.9) and stumbled across this bug. This bug was introduced with the update from 0.4 to 0.4.2 (update to hardy with me). I did not change the Bibble version at the same time, so there was no change. The problem is that on import the exif tag DateTimeOriginal (0x9003) is changed to the file creation date by f-spot. I double checked this on the imported (copy to /photos turned on) and the original file with gqview. The DateTimeDigitized tag is still ok. Why f-spot changes the DateTimeOriginal tag is beyond me.
I just tried to find the error. The JFIF Version tag is missing in the Bibble processed JPGs. But opening and saving this image with The Gimp this exif tag is there. Is this a mandatory tag? As I did not get it yet to add the JFIF version tag with exiftool ("not writable") to a test image I am not 100% sure that this is the reason of the problem but I think this is the reason. Is this possible?
Hm... trying to debug this: System.NullReferenceException: Object reference not set to an instance of an object at FSpot.JpegFile.get_Date () [0x00000] System.NullReferenceException: Object reference not set to an instance of an object at FSpot.JpegFile.get_Description () [0x00000] Where exactly are get_Date () and get_Description ()? I did not find it anywhere in the code? Is this a lib* error?
This bug is annoying me so I tried to find workarounds and I am searching for the cause of this bug. I found a workaround: The date is recognized well by F-Spot if the image file is modified with exiv2 or exiftool before importing it. There is no need to change any values, just to overwrite an exif tag with the existing value, for example. No I have two photos. F-Spot does not recognize the date of the original (original.jpg), but it recognizes the date of the modified (modified.jpg) one. What is the decisive difference between the two files? If someone has a little hint or an idea to diff the meta information more precisely or whatever... would be great. I have no idea. The diff of the exiftool output is following: $ diff original.exif.txt modified.exif.txt 2c2 < File Name : original.jpg --- > File Name : modified.jpg 5c5 < File Modification Date/Time : 2008:06:02 21:24:32 --- > File Modification Date/Time : 2008:06:02 21:39:57 39c39 < Preview Image Start : 7582 --- > Preview Image Start : 312235 102c102 < Thumbnail Offset : 7820 --- > Thumbnail Offset : 7844 I uploaded the files here (and I attached them): http://www.purecodes.org/f-spot/date-bug/
Created attachment 111992 [details] original.jpg
Created attachment 111993 [details] modified.jpg
It really seems to be a Nikon Preview Problem... The diff of the exiv2 output: $ diff -a original.exiv2.txt modified.exiv2.txt 9c9 < 0x8769 Image ExifTag Long 1 8 --- > 0x8769 Image ExifTag Long 1 202 48c48 < 0x0011 Nikon3 Preview Long 1 7006 --- > 0x0011 Nikon3 Preview Long 1 6990
It is the same for Canon. My workaround right now is to copy all exif data from the RAW-file to the jpg using exiftool. This solves the problem for now.
Hi Thomas. Ok, good to know. So this is not a Nikon issue. I got some Nikon Preview warnings with exiftool after adding an exif tag with exiv2, but that seem to be another thing. I wouldn't copy all the RAW exif to your JPGs. There are some tags you don't need in the JPG and which can be wrong for the processed file. Size, for example. Just use exiftool like this: find -name '*.jpg' -exec exiftool -overwrite_original -Software="exiftool" {} \; Instead of Software you can use -Make="CANON" or whatever. Something that doesn't hurt. The photos touched by exiftool are imported fine by f-spot, too.
I'm working on bug http://bugzilla.gnome.org/show_bug.cgi?id=166038 and I don't really remember how I got to this bug when looking for a solution to a problem with date/time processing in F-Spot. Anyway, I can confirm that F-Spot is messing up the EXIF DateTimeOriginal of my photos :-S I'll try to have a look at the involved source code if I have some time.
to correct my line given before: find -name '*.jpg' -exec exiftool -overwrite_original -Software="exiftool" {} {} \; (a "{}" missing)
Still present in 0.6.0
Created attachment 147450 [details] Another jpg causing the bug, produced with very latest Bibble preview. Still buggy in 0.7. Attached a reduced jpg produced by the very latest Bibble 5 Preview.
Still buggy with Bibble 5 1.0, on Karmic.
Should be retested with git master (or the upcoming 0.7.1). Metadata handling has been overhauled.
So we believe this bug to be FIXED. Please reopen if this is not the case.