After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 454082 - Import dialog modifies Exif.Photo.DateTimeOriginal of jpeg
Import dialog modifies Exif.Photo.DateTimeOriginal of jpeg
Status: RESOLVED DUPLICATE of bug 340903
Product: f-spot
Classification: Other
Component: Import
0.3.0
Other All
: Normal normal
: ---
Assigned To: F-spot maintainers
F-spot maintainers
: 593002 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-07-05 20:48 UTC by Arjen Bax
Modified: 2010-03-23 14:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Arjen Bax 2007-07-05 20:48:41 UTC
Please describe the problem:
f-spot's import dialog when importing from a directory adjusts the Exif.Photo.DateTimeOriginal timestamp to 2 hours earlier, corrupting the correct timestamp. This happens even when the import is canceled.

Steps to reproduce:
1. start the import dialog (Ctrl-N)
2. select a directory with some new jpeg-images in it; the thumbnails show up in the dialog
3. press Cancel (or Import).


Actual results:
The Exif.Photo.DateTimeOriginal is put back by 2 hours (I suspect that this is some heuristic to convert to UT or GMT). The incorrect timestamp is also shown in the information panel in the bottom-left corner of f-spot's main window when the image is selected.

Expected results:
The Exif.Photo.DateTimeOriginal timestamp shouldn't be modified at all during import, but only when the program is explicitly instructed to do so (via the Adjust Time option in the Edit menu).

Does this happen every time?
Yes, it is repeatable.

Other information:
Before the import dialog a issued the following command:
$ exiv2 -pt img_2277.jpg | grep DateTime
Exif.Image.DateTime                          Ascii      20  2007:07:05 21:12:18
Exif.Photo.DateTimeOriginal                  Ascii      20  2007:07:04 18:43:18
Exif.Photo.DateTimeDigitized                 Ascii      20  2007:07:04 18:43:18

Immediately after pressing 'Cancel':
$ exiv2 -pt img_2277.jpg | grep DateTime
Exif.Image.DateTime                          Ascii      20  2007:07:05 21:12:18
Exif.Photo.DateTimeOriginal                  Ascii      20  2007:07:04 16:43:18
Exif.Photo.DateTimeDigitized                 Ascii      20  2007:07:04 18:43:18
Comment 1 Stephane Delcroix 2007-07-06 13:42:50 UTC
you're located in Western Europe, right ? (or in the same timezone ...)
Comment 2 Arjen Bax 2007-07-06 18:52:41 UTC
> you're located in Western Europe, right ?

Yes, on my computer TZ=Europe/Amsterdam, at the moment time difference with UT = +0200 (Middle European Summer Time). My camera's clock is set to local time, which is the same as my watch.
Comment 3 Carwin 2008-06-17 12:10:24 UTC
I've got the same problem with version 0.4.3.1

Given that this is corrupting image data and no visible progress has been made in almost a year, can this at least be given some priority instead of being listed as unconfirmed?
Comment 4 Marcus Sundman 2008-11-18 21:57:20 UTC
Severity of this should be set to 'Critical' since it causes loss of data.
Comment 5 Silvano 2009-02-03 13:16:32 UTC
Version 0.5.0.3 still suffers this unexpected behavior. I would also set this bug to 'CRITICAL'.

Stephane, you said on the mailing-list, that you would fix it. Is it already fixed somewhere? I mean, a newer version, the SVN repository or something like that. Or are you working on it?
Comment 6 Markus Amersdorfer 2009-06-08 21:42:22 UTC
I can as well confirm this problem on F-Spot 0.5.0.3 (Ubuntu 9.04 package).

It has been nearly two years now since this bug was filed. Can you please update this issue with a status information?
Is someone working on it? What is the expected fix date?
Also, I support the previous posters that the severity of this issue should be increased to at least 'MAJOR'.

(EXIF's "DateTimeDigitized" still holds the camera's actual date/time information. While this can somehow be used to manually fix the date/time after having imported the images, at the moment we lose the correct data from a user's point of view. Not only in F-Spot, but also when using the JPG-files in other common programs subsequently.)
Comment 7 Adal Alom Rodríguez 2009-08-11 02:16:11 UTC
Still happens in 6.0.0
Comment 8 Kevin R. Page 2009-08-24 21:02:14 UTC
This is probably a duplicate of bug #340903 ?
Comment 9 Adal Alom Rodríguez 2009-08-24 21:28:44 UTC
(In reply to comment #8)
> This is probably a duplicate of bug #340903 ?

I think it is.
Comment 10 Maxxer 2009-08-25 11:39:40 UTC
*** Bug 593002 has been marked as a duplicate of this bug. ***
Comment 11 Daniel Bartholomew 2009-10-30 04:56:35 UTC
Please mark this bug as a duplicate of bug #340903 as both bugs share the same problem: F-Spot is changing EXIF date tags without being asked to and without telling anyone.

Both are big no-nos. F-Spot should never change an EXIF date tag on its own. The user should specifically request any changes to be made and only then should F-Spot be allowed to change the EXIF tags and it should only change the tag it has been asked to change.
Comment 12 Robin Stocker 2010-03-23 14:00:01 UTC

*** This bug has been marked as a duplicate of bug 340903 ***