GNOME Bugzilla – Bug 520725
f-spot messes up Time and Date information
Last modified: 2008-03-07 08:25:40 UTC
Please describe the problem: Time and date of a picture as displayed in the browser of f-spot does not match the time&date of when the picture was taken. Steps to reproduce: 1. Download http://s3.amazonaws.com/public-files.askwar/f-spot/photos-20080306.tar 2. Untar it 3. Import picutres to f-spot Actual results: On my system, I see http://farm4.static.flickr.com/3237/2313733891_2a41999593_b.jpg This means, f-spot shows the date of the picture as 23.02.2008 20:37. The picture was taken on 24.02.2008 06:37 (and no, I did not change the time zones...). Expected results: Correct date should be shown - ie. 24.02.2008 06:37 Does this happen every time? I think so, yes. Other information: I /think/ that f-spot originally displayed the correct time (ie. 24.02.2008 06:37). But after modifying the image some (just adding/removing meta data), f-spot managed to "mess up" the time and date information. I generated this picture with my digicam. It stored the correct date & time. I then copied the file to my local harddisk and renamed the file using GThumb - GThumb read the time and date information from EXIF and stored it in the file name. After that, I just used to f-spot to tinker with the image. So it was f-spot, that changed the time and date information. This might be somewhat related to bug #517811. In Bug #517811, I just wanted the exif field "Date and Time (digitized)" to be shown (I still would like that, to be honest). This bug here is now about the fact, that f-spot messes up what it stores in the EXIF field "Date and Time (original)" and thus displays in the browser. I'm using SVN r3736.
(In reply to comment #0) > I generated this picture with my digicam. It stored the correct date & time. I > then copied the file to my local harddisk and renamed the file using GThumb - > GThumb read the time and date information from EXIF and stored it in the file > name. > > After that, I just used to f-spot to tinker with the image. So it was f-spot, > that changed the time and date information. are you sure it wasn't gthumb who messed up "datetime original"? can you check the exif step by step? and if your test confirm it's f-spot messing up, can you upload the picture BEFORE the import in f-spot, so that it's possible to reproduce the datetime change? > This might be somewhat related to bug #517811. In Bug #517811, I just wanted > the exif field "Date and Time (digitized)" to be shown (I still would like > that, to be honest). This bug here is now about the fact, that f-spot messes up > what it stores in the EXIF field "Date and Time (original)" and thus displays > in the browser. you better wait for timezone support, which shouldn't be far away.
(In reply to comment #1) > (In reply to comment #0) > > I generated this picture with my digicam. It stored the correct date & time. I > > then copied the file to my local harddisk and renamed the file using GThumb - > > GThumb read the time and date information from EXIF and stored it in the file > > name. > > > > After that, I just used to f-spot to tinker with the image. So it was f-spot, > > that changed the time and date information. > > are you sure it wasn't gthumb who messed up "datetime original"? Very much, yes, because Gthumb just renamed the file. I'm not 100% sure, thoough. Just 99%. > can you check > the exif step by step? No, since I don't have the original image anymore. > and if your test confirm it's f-spot messing up, can you upload the picture > BEFORE the import in f-spot, so that it's possible to reproduce the datetime > change? I'll take some new pictures and see if I can make f-spot misbehave again. > > This might be somewhat related to bug #517811. In Bug #517811, I just wanted > > the exif field "Date and Time (digitized)" to be shown (I still would like > > that, to be honest). This bug here is now about the fact, that f-spot messes up > > what it stores in the EXIF field "Date and Time (original)" and thus displays > > in the browser. > > you better wait for timezone support, which shouldn't be far away. Fine. So I suppose there's no easy way to make f-spot use the "Date and Time (digitized)" exif field?
(In reply to comment #2) > I'll take some new pictures and see if I can make f-spot misbehave again. that would be good. > Fine. So I suppose there's no easy way to make f-spot use the "Date and Time > (digitized)" exif field? exactly. :)
(In reply to comment #1) > (In reply to comment #0) > > I generated this picture with my digicam. It stored the correct date & time. I > > then copied the file to my local harddisk and renamed the file using GThumb - > > GThumb read the time and date information from EXIF and stored it in the file > > name. > > > > After that, I just used to f-spot to tinker with the image. So it was f-spot, > > that changed the time and date information. > > are you sure it wasn't gthumb who messed up "datetime original"? can you check > the exif step by step? Now I'm 99.9999% sure. I found some original, unmodified file (in my trashcan). Here's a diff of the "exif" <http://libexif.sf.net> output of before and after the import: --- 1-orig 2008-03-06 14:07:03.066070017 +0100 +++ 2-f-spot 2008-03-06 14:07:13.614070386 +0100 @@ -8,8 +8,8 @@ x-Resolution |72.00 y-Resolution |72.00 Resolution Unit |Inch -Software |1.00 -Date and Time |2008:03:02 15:36:34 +Software |f-spot version 0.4.2 +Date and Time |2008:03:06 14:06:16 YCbCr Positioning |centered Unknown | Compression |JPEG compression @@ -20,7 +20,7 @@ FNumber |f/4.9 ExposureProgram |Portrait Exif Version |Exif Version 2.21 -Date and Time (origi|2008:03:02 15:36:34 +Date and Time (origi|2008:03:02 14:36:34 Date and Time (digit|2008:03:02 15:36:34 ComponentsConfigurat|Y Cb Cr - Compressed Bits per |4.20 @@ -30,7 +30,7 @@ Light Source |0 Flash |Flash did not fire, auto mode. Focal Length |24.0 mm -Maker Note |16880 bytes unknown data +User Comment | FlashPixVersion |FlashPix Version 1.0 Color Space |sRGB PixelXDimension |2816 @@ -50,4 +50,3 @@ InteroperabilityVers|0100 --------------------+---------------------------------------------------------- EXIF data contains a thumbnail (5488 bytes). - As you can see, f-spot modified "Date and Time (origi". It's now showing a broken value. Given the fact that f-spot already modifies that field, I'm *VERY* much intrigued to believe that it might be buggy and go on modifying that field. > and if your test confirm it's f-spot messing up, can you upload the picture > BEFORE the import in f-spot, so that it's possible to reproduce the datetime > change? Original: http://public-files.askwar.s3.amazonaws.com/f-spot/cimg5222.jpg After f-spot import: http://public-files.askwar.s3.amazonaws.com/f-spot/cimg5222_f-spotted.jpg > > This might be somewhat related to bug #517811. In Bug #517811, I just wanted > > the exif field "Date and Time (digitized)" to be shown (I still would like > > that, to be honest). This bug here is now about the fact, that f-spot messes up > > what it stores in the EXIF field "Date and Time (original)" and thus displays > > in the browser. > > you better wait for timezone support, which shouldn't be far away. Until then, would it please be possible to make it so, that f-spot at least does not change "Date and Time (original)"? Ie. make it so, that it reads stuff from that field, but don't change that field (which makes this part of the bug a dupe of bug #340903).
(In reply to comment #1) > are you sure it wasn't gthumb who messed up "datetime original"? Yes, I'm now almost 100% sure. I took the picture which I uploaded to S3 and used gthumb to rename it. I compared the exif output from before and after. No changes.
(In reply to comment #1) > (In reply to comment #0) > > I generated this picture with my digicam. It stored the correct date & time. I > > then copied the file to my local harddisk and renamed the file using GThumb - > > GThumb read the time and date information from EXIF and stored it in the file > > name. > > > > After that, I just used to f-spot to tinker with the image. So it was f-spot, > > that changed the time and date information. > > are you sure it wasn't gthumb who messed up "datetime original"? I now reached 100% certainty. I checked out an "old" revision from SVN (r3730), build it and installed it. I then renamed cimg5222.jpg to "[2008-03-06--14.06.16] (cimg5222) Verwackelt, Zu Hause, Straße, Bürgersteig {2.8 MB}.jpg", so that there are those nasty UTF-8 charcters as well. Complete path of the picture: /home/askwar/Desktop/My Pictures/Photos/Kategorien/Verschiedenes/Test 2008-03-06/[2008-03-06--14.06.16] (cimg5222) Verwackelt, Zu Hause, Straße, Bürgersteig {2.8 MB}.jpg I then imported this directory multiple times, so that f-spot created many duplicates of this picture. After some cycles, the EXIF field is now at "2008:03:02 08:36:34". The problem is, that f-spot modifies the field, so that the Date and Time field is supposed to be UTC. This should not be done (I think I mentioned that already, didn't I? :]). Now that bug #517234 is (hopefully) fixed for good, it might not be possible to re-create the bug. Well - it will be possible, because f-spot will modify that EXIF field after each successful import (and because of that, the field should not be modified - I think I'm repeating myself *G*). So, if somebody manages to re-import a file, f-spot will keep on messing up the information. What can I do now, so that the time and date, as displayed by f-spot, is correct again? Would it be sufficient to modify this EXIF field of all my images? Or what I need to do something to the f-spot photos.db database as well?
this bug is nothing new! it's just a join of two bugs! we know f-spot shouldn't store UTC, and there's an open bug for that. and we know f-spot shouldn't import the same identical picture twice, and there's a bug for that. obviously, if you reimport the same pictures MANY times, since f-spot doesn't know he already imported it and since it doesn't even know the timezone, will continue adding +1h at every import. but this is nothing new to me! this is either a duplicate of bug 169646 or bug 340903. talking about your latest question, to restore the original value you must set it to the exif, but also yes fix it to the db. if you need further help on this please use irc or the mailing list! :) *** This bug has been marked as a duplicate of 169646 ***