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 302567 - Ability to Edit Date & Time of Photos
Ability to Edit Date & Time of Photos
Status: RESOLVED FIXED
Product: f-spot
Classification: Other
Component: General
0.0.x
Other Linux
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
: 315565 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-04-30 18:10 UTC by Jose Alberto
Modified: 2009-07-27 13:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (14.17 KB, patch)
2005-08-07 05:08 UTC, Gabriel Burt
none Details | Review
Updated Patch (14.93 KB, patch)
2005-08-16 04:11 UTC, Gabriel Burt
none Details | Review
Flexible patch to modify timestamp (57.07 KB, patch)
2005-08-18 08:49 UTC, Bengt Thuree
none Details | Review
Patch (58.01 KB, patch)
2005-08-19 14:07 UTC, Bengt Thuree
none Details | Review
Glade-shot (28.40 KB, image/jpeg)
2005-09-30 06:49 UTC, Gabriel Burt
  Details
Updated Glade-shot (29.74 KB, image/jpeg)
2005-09-30 22:08 UTC, Gabriel Burt
  Details
Dialog mockup (89.95 KB, image/png)
2005-10-04 00:25 UTC, Ian McIntosh
  Details
Screenshot (115.75 KB, image/jpeg)
2005-11-14 23:07 UTC, Bengt Thuree
  Details

Description Jose Alberto 2005-04-30 18:10:27 UTC
exif edit (to change wrong date for example)
Comment 1 Hubert Figuiere (:hub) 2005-05-18 21:44:22 UTC
isn't that a dupe of bug 155869 ?
Comment 2 Gabriel Burt 2005-08-07 05:08:07 UTC
Created attachment 50340 [details] [review]
Patch

This patch fixes this bug.  Bug 155869 is for editing all kind of exif data
(though it does mention date/time specifically), so I would say this bug is a
subset, but not a dupe exactly.  I think 155869 is really requesting a full
blown EXIF editor.
Comment 3 Gabriel Burt 2005-08-16 04:11:04 UTC
Created attachment 50758 [details] [review]
Updated Patch

This patch should apply cleanly to HEAD, including the added EditDateTime.cs
file.
Comment 4 Bengt Thuree 2005-08-17 09:34:47 UTC
Working on an enhancement for Gabriels patch. Should be ready in a day or two.
Comment 5 Bengt Thuree 2005-08-18 08:49:44 UTC
Created attachment 50896 [details] [review]
Flexible patch to modify timestamp

Allows user to simply adjust the time (+/- 24 hours), or set it to a new date,
new date & time, new date & time & autoincrement time

Teaser gui : http://www.thuree.com:8080/bt/testing/F-Spot-ChangeTime.jpg
Comment 6 Bengt Thuree 2005-08-18 08:58:21 UTC
Comment on attachment 50896 [details] [review]
Flexible patch to modify timestamp

Based upon Larrys explanation regarding EXIF and DateTimeDigitized, perhaps the
following line should be commented out.
+					jimg.DateTimeDigitized	= setTo;
Comment 7 Bengt Thuree 2005-08-19 14:07:45 UTC
Created attachment 50986 [details] [review]
Patch

Patch to add a method of changing the time and date in a flexible way.
Screenshot : http://www.thuree.com:8080/bt/testing/F-Spot-ChangeTime.jpg

This updated patch have been changed so
1) We only store the time to DateTimeOriginal when we adjust the time.
2) If the EXIF tag DateTimeOriginal is empty when the picture is imported, we 
	add this tag to the file with either (DateTimeDigitized, DateTime, or
File Creation time)
	This is needed for the users who do not have a DateTimeOriginal value
in their pictures,
	but have a DateTime field (which will constantly be overwritten by
F-Spot).

This patch will provide base for
http://bugzilla.gnome.org/attachment.cgi?bugid=170771, and
http://bugzilla.gnome.org/attachment.cgi?bugid=309436

170771 (use file creation if no exif tags)
309436 (EXIF value for DateTimeOriginal do not exist, but DateTime do)
Comment 8 Gabriel Burt 2005-09-11 05:15:04 UTC
*** Bug 315565 has been marked as a duplicate of this bug. ***
Comment 9 Gabriel Burt 2005-09-11 05:16:39 UTC
Mattias Holmlund has posted a proposal for fixing this bug at (duplicate) bug
315565.
Comment 10 Mattias Holmlund 2005-09-11 07:52:04 UTC
Is it possible to change the title of this bug to better reflect the contents? I
looked through bugzilla before I filed bug 315565, but I couldn't find any bug
with time or date in the title. 

To me, editing the time and date associated with a photo is orthogonal to
editing the exif-information. It isn't really necessary to edit the time and
date in the exif-information, we might as well leave the exif-information
untouched and only change the time and date in the database. If f-spot adopts
the design principle that "the exif-information must always be updated to be in
sync with the information stored in the database" then the exif information
should be updated as well, but I haven't seen that design principle spelled out
anywhere.

My UI proposal in bug 315565 is available at 

http://bugzilla.gnome.org/attachment.cgi?id=51983&action=view

The glade-file for the dialog is at 

http://bugzilla.gnome.org/attachment.cgi?id=51984&action=view
Comment 11 Larry Ewing 2005-09-29 06:59:34 UTC
My first impression is that the dialog presents too many options at once and
there isn't a clear task flow.  By that I mean instead of feeling like I know
what to do next when I see the the dialog I need to page through the options. 
Is there some where the dialog could be more linear where everything is on one
page but the options you choose limit the choices that follow.
Comment 12 Larry Ewing 2005-09-29 07:32:37 UTC
Ok looking over this excellent patch i have a few comments.

1) I don't like that the get accessors for all the properties return a failback
if they aren't there.  There is is a difference between being set and not being
set.  

2) If you are going to have the helper functions already, you should use them in
the Date property instead of duplicating code,   This is probably done this way
because of #1, but if so that is more reason to fix #1.

3) the patch solves the problem for jpegs but nothing else.  Now while editing
support would be hard to do in any other loader at the point several of them
support multiple date settings as well.  It would be nice to address those
problems as well.

Other than that the patch looks pretty good.  However I'm going to mull it over
for a while longer though because I'm in the process of completely overhauling
the metadata system and these changes should be more simple to implement one
that is done.  

Bengt, If I haven't closed this bug within a week, bug me about it again.  And a
huge huge thank you Bengt and everyone else involved.  This is ver nice work,
and I appreciate it a lot.
Comment 13 Mattias Holmlund 2005-09-30 05:39:00 UTC
Regarding comment 11:

Yes, I agree that the "flow" of the dialog isn't perfect. I don't think that
putting all the controls into a single page and disabling/enabling them based on
the method selected is going to be any clearer. Both "Absolute" and "Relative"
contains a Date-entry field, but on the Absolute tab there is a checkbox that
enables/disables it whereas on the Relative tab the Date-field is always enabled.

How about a Wizard type of dialog with two pages? On the first page you select
the type of adjustment only ("Relative Adjustment", "Absolute Adjustment" or
"Timezone Conversion") and the second page shows the contents of the appropriate
tab (without showing the tab-bar of course). This would also give room for
explaining what the different types of adjustments do on the first page.
Comment 14 Gabriel Burt 2005-09-30 06:01:45 UTC
It seems to me that having one dialog could work very easily, and quite well.

Your UI for Absolute (eg Set the time) vs Relative (Shift the time) are
practically identical, and the Timezone tab is very sparse.  I would suggest
combining all three.

To do this, allow the user to change the date/time/timezone for one picture, and
have a checkbox to the effect of "Apply this relative change to all selected
photos" -- which then calculates the offset for that picture and applies it to
all of them.  The timezone could just be put at the bottom of all this.

I am confused by your mockup, the relative tab in particular, allowing the user
to "set" a time ... how would the user shift back by a year, say?  Any way, if
you like the idea above, that will be a moot point. :)

Storing the timezone information in a way that is transferable will be a trick,
I think, since EXIF doesn't support it.
Comment 15 Gabriel Burt 2005-09-30 06:49:31 UTC
Created attachment 52845 [details]
Glade-shot

To better explain what I meant in my last comment, I've attached a Glade-shot.

I would imagine this would come up and have the current values of the
date/time/tz filled in for the first selected picture.	The user can modify
those values, and/or switch to another picture (and if any changes to the
values have been made, if the relative checkbox is selected the
relatively-shifted values for the new image will appear, else the same
absolute/set-to values will remain).

Also, the thing I was confused about in the previous post was a
misunderstanding.
Comment 16 Gabriel Burt 2005-09-30 07:01:23 UTC
The functionality my mockup doesn't provide that Mattias's does it the increment
feature...which I think would confuse users more than anything, even if it does
serve a practical purpose.

The common principle of allowing the user to put the shown image in a
consistent/correct state is very good.  Note that the image in my mockup is that
shape/size b/c I couldn't figure out how to make it more F-Spotish in Glade. 
And the ffoward icon is b/c there are two _Forward stock icons and Glade can't
tell the difference. :)

Also, just to note, if the user selects multiple images that have already been
set to different time zones, then the timezone select box should notify the user
of that (with a "Differing Timezones" item selected, perhaps), and by default
not change the timezone, but still allow absolute/relative changes within each
image's respective timezone to occur.
Comment 17 Mattias Holmlund 2005-09-30 20:12:55 UTC
Your mockup looks very good Gabriel. A lot simpler than mine. Some comments:

What happens if you don't select the "Change all..." checkbox? Does it just
change the time for the currently shown picture, or does it set the same time
for all images?

In my opinion, the most common operation will be to change all images a relative
amount. So the "Change all..." checkbox should probably be selected by default.

As you say, there is no auto-increment feature in your dialog. I'm not
particularly fond of that setting myself, but what happens if we assign the
exact same time to a set of images? How will f-spot sort them in the timeline?

In my dialog, there is a difference between setting the timezone and performing
a timezone conversion. Setting the timezone means that the time-value will be
unchanged and only the timezone will be changed, e.g. from 12:31:29+0200 to
12:31:29+0400. Converting the timezone means that the time will actually be
unchanged, only the timezone representation will be changed, e.g. from
12:31:29+0200 to 14:31:29+0400 (both times equal 10:31:29 UTC). Let me explain
why I need both these operations:

I have my camera set to UTC. When I import my pictures into f-spot, f-spot
assumes that the times are local. This means that a picture that I took at
10:31:29 UTC will be imported into f-spot as 10:31:29+0200 (my local timezone is
+0200). To do a proper conversion to the correct time and timezone that takes
daylight savings time into acocunt, I need to first set the timezone to +0000
and then convert the time to Europe/Stockholm.

How can we express both these timezone operations in your dialog?
Comment 18 Gabriel Burt 2005-09-30 22:08:57 UTC
Created attachment 52891 [details]
Updated Glade-shot

Thanks Mattias.

I changed the label for the checkbox to hopefully be more clear.  The intent
was that if the checkbox is selected, then the relative date/time change for
the current picture is applied to all selected pictures, and if not, then all
pictures are set with the exact date/time/tz in input fields.

If you assign the exact time to a set of photos, things won't break down or
anything, but their ordering may be whatever sqlite returns (I think the query
sorts on datetime only).  I understand what you're trying to do with that
feature, but I think it would be confusing.  On second thought, all that
feature does it make sure the selected photos don't have exactly the same
datetime -- which isn't important.  I was thinking for a second that it would
allow you to give chronological order back to a set of photos..but it doesn't,
as your auto-increment feature could only auto-increment in the order the files
are selected/already ordered.

To address the issue of setting the timezone versus changing it, I added a
Gimp-scale-image like "link" widget to my Glade-shot.  It would default to
unlinked, so the user can simply set the timezone, but if linked, and the user
modifies the timezone, it will change the date/time.  If they change the
date/time when it's linked, it won't change the timezone as who would ever want
it to do that? :)
Comment 19 Mattias Holmlund 2005-10-01 06:16:33 UTC
What the auto-increment feature does is make sure that there is a consistent
ordering for the pictures after the times have been changed. It doesn't allow
you to reorder the pictures. I agree that it isn't very useful. However, my fear
is that if sqlite sorts only on the datetime and the datetime is equal for a set
of pictures, then the ordering of the pictures might change each time you look
at them. If the order relies on the order of the pictures in some internal index
in sqlite, then this might happen. Perhaps we can sort on DateTime + filename?
This will however mean that setting the time on a set of pictures might reorder
them once.

Regarding the "link"-widget: Brilliant!

When I had a second look at your dialog, I realised that I didn't really
understand the first line of widgets: Why do you have both a Date and a
Calendar? Why do you have two Time-fields? Are these Before/After-values?

I think it would be very useful to see the Before and After-values explicitly.
This allows you to quickly scroll through all images and check that they make
sense, especially if you do a relative conversion including timezones.
Comment 20 Gabriel Burt 2005-10-02 02:27:32 UTC
Mattias,

I think having that ensuring a constant ordering by also ordering by filename
the best solution.

The first line of widgets it the standard Gnome edit date/time widget.  I agree
it is subobtimal...the most confusing part I think is that it effectively shows
two times, although it's only the text-entry part of the widget that actually
matters...the drop-down list is only for rapidly picking common times (eg on 15
min intervals).  It is is fact so bad we probably wouldn't want to use it.  I
don't like the widget you used mostly b/c it takes up lot of space and doesn't
allow you to just type your date.

For the before/after times...I don't think it's useful to see the before time,
because that is the one that is wrong and user knows what the time should be, or
they wouldn't be on this screen.  In terms of viewing the relative changes for
the other photos, the idea in my mockup is that if you press the arrow button to
view a different picture (and have the relative button selected) it will change
the values in the date/time widgets to what you would expect - the relatively
adjusted values.  And again, I think if the user is changing the date/time for
some images, that means they know the true values, and don't need to be bothered
with the old, wrong values.  Thanks for all the feedback, I think we're going to
have a very well thought-out dialog when we're done. :)
Comment 21 Mattias Holmlund 2005-10-02 08:48:26 UTC
> I think having that ensuring a constant ordering by also ordering by 
> filename the best solution.

It just struck me that this means if you have a set of pictures with different
timestamp, they will be ordered by their timestamps. If you then set the
timestamp for all of them to the same value, they will be reordered according to
their filenames. But on the other hand, if the original timestamps were wrong,
then the original order was arbitrary anyway...

Regardnig the before times: I think they are very useful. I know that my
before-times are valid UTC-times. I will not look at the picture and know when
it was taken. The before-time also allows the user to modify the first picture
and then flip between the other pictures. He can then see what the before/after
time is on each picture and understand better what it is that the dialog will
actually do. Otherwise, the user can only see the before time of the first image
(the original value of the controls), and then he will just have to trust that
the dialog does the right thing to the other images. I think that even though
your dialog looks very simple, the action it performs is actually quite complex
and we need to give the user as much help as we can in understanding what it
actually does.

Regarding storing the timezone in exif:

Some applications allow storing the timezone in DateTimeOriginal by simply
appending it to the time ("+0100"). This is in violation of the exif standard,
but it seems like a pretty good idea anyway. I think that the perl-module
Image:ExifTool does that but I can't find a reference right now. 

There is also a TimeZoneOffset field in Exif. See 

http://www.map.tu.chiba-u.ac.jp/IEC/100/TA2/recdoc/N4378.pdf

Unfortunately it only allows the timezone to be +/- whole hours and some
countries use half fours.

I don't know which direction the metadata handling is moving in f-spot right
now. Maybe there is another solution than exif?



Comment 22 Ian McIntosh 2005-10-04 00:25:11 UTC
Created attachment 52999 [details]
Dialog mockup

I see three use-cases and I propose that f-spot react slightly differently for
these three cases.

1.Changing the times of several photos from a camera with an incorrect time
set.

This is common for those of us who leech photos off of others (while traveling,
for example).

See attached mockup.  My goal was to make it painfully obvious what to do, and
also to make it clear that all selected photos are modified.  Some verbiage
like "update series" or "set" may help the user understand the operation, as
would an icon showing a group of items moving *together* to a new place on a
calendar.

A timezone selector could go after the time, if necessary.

A more ambitious solution to this problem is to actually show all the photos on
a timeline or on a calendar, and let the user drag them where they belong (as a
group) or change date/time control and have the graphics change appropriately.

2.Changing the time of one photo.

This one is common and easy to solve: show a dialog with date and time
controls, defaulted to the date of the photo, or "now" if none is present.  I
think the attached mockup works for this case if you change the Save button to
"Save" or "Update".

3.Changing the times of a random collection of photos with incorrect or missing
times.

This one gets very complicated very fast.  I propose keeping it simple: take
the mockup and replace the photo with vertical scroller of all photos (as used
in export dialogs).  Changing the date/time sets ALL photos.  Because,
realistically, most of us have no idea when all our random undated photos were
taken, so a ballpark time is probably good enough.

Alternatively, change the save button to something like "Save and Next". 
That's it.  Do them one at a time, no way to go "back".  I think putting
back/forward buttons in a dialog like this is far too complicated and
confusing.

Another possibility is for F-Spot to recognize a set from a bad camera and say
"These photos seem to be from the same set/group/roll, would you like to modify
them as a set/group/roll?"  Yes would show the dialog in the mockup, no would
show the dialog with "Save and Next".

Just some ideas.  Hope they're helpful.
Comment 23 Bengt Thuree 2005-11-14 13:15:32 UTC
Larry, Regardin comment 12. Do you have any more comments on this one or?

I know I put in a lot of work on my patch, and I also know that a few other guys
are also putting a lot of work on another solution.
I know my web server is down, so I will attach the gui to this bug tomorrow
instead. (in 12 hours or so).

If there is any problems with the gui, would like to know more about it. I
thought it was fairly straight forward since it enabled/disabled the things you
could enter in a nice way. Then again, I designed it and am most likely biased :)

Thanks for your comments anyway, and sorry I missed them...

/bengt
Comment 24 Bengt Thuree 2005-11-14 23:07:46 UTC
Created attachment 54756 [details]
Screenshot

Since my web site is down (totally dead) I attach the screen shot here instead.


The key points were
1) Easy to adjust the hours with +/- x amount of hours. (Time zone change in
reality, since EXIF and F-Spot do not store TimeZone information for the
moment)
2) Easy to set the Date if just the date is wrong, but the time is correct.
3) Easy to set the Date and Time, if both are wrong.
4) If you have a batch of pictures that are all taken during more or less the
same timeperiod (a few hours), you can combine 3 with an automatic incresement
of Minutes and Seconds for each picture.

The last one is good for
1) Ensure that you get a unique timestamp (possible file name)
2) Possibility to set the timestamp of a batch of pictures, by ensuring that
each picture is 10 seconds (or 1 minute) later than the previous one.
But, I agree, it is not something that will be used often, but good to have I
think.
Comment 25 Bengt Thuree 2005-11-14 23:47:49 UTC
Some other comments... Sorry for beeing late to this thread, but I forgot to
subscribe to it...

This task has a few rather distinct options.
In my case, I can see the following actions I would like to be able to perform.

1) Just adjust the hours/minutes with X hours and Y minutes.
     This would in effect be when you change timezone, and forgot to 
     update your camera, or your cameras date have been modified, or 
     you got some pictures from a friend, or ....

2) The date is wrong, but the timestamp is correct.
     Here you only want to change (set) the date on all selected pictures, 
     but not the timestamp it self.

3) Both date and time is wrong.
     Here you want to set the date and time on selected pictures to 
     a fix date/time.

4) In addition to 3) (setting both date and time), also auto increment time.
     This to ensure that each pictures timestamp is unique.
     Not often this feature is needed, but good to have just in case.

You also want to see the original timestamp, and the to be new timestamp, 
     to get a visual verification of what you are doing.


My patch handles all this, but I agree that the GUI is not the best, as well as
the code could use a lot of tidying up etc etc.

One way to solve this and make it much easier for everyone, is to create a
wizard/druid window with simple tasks per window. And perhaps an advance windown
with everything on it if needed. Oevrkill? perhaps. 
My gui definitely should have a list of all pictures to be modified, like the
various export gui's.

As far as timezone goes, it seems that with XMP we can handle it.
http://www.w3.org/TR/NOTE-datetime
(http://dublincore.org/documents/1999/07/02/dces/)
(1994-11-05T08:15:30-05:00, 1994-11-05T13:15:30Z (UTC))

As long as f-spot will show my lunch meal picture (at 12:00 local time) I have
in Melbourne, London and in NewYork all at noon (12:00pm) and not the picture
time converted to my Melbourne time.

Hope we can continue with this patch, and soon see something in CVS...
Myself have a lot of pictures from different timezones from the past few months
which I need to change the date/time on.....
Comment 26 Bengt Thuree 2005-11-15 04:59:44 UTC
Small addition to comment #25
4) Auto increment time.
If you have a set of 20 pictures with the wrong date/time but all of them taken
within a few hours of each other. And if you are not to concerned with the
getting the exact time, then you can easily autoincrement the time with 10
minutes per photo or so.

One other option for this, is to 
a) first set the DATE, but skip the time
b) adjust the time on these pictures...
But this is a two step action. Perhaps it can be combined into a one step
action, but is it worth it.
Comment 27 Mattias Holmlund 2005-11-16 17:45:53 UTC
Bengt,

Did you see Gabriel's proposal in comment #18? In my opinion, that is the best
dialog yet. It handles both absolute and relative changes and it allows you to
convert between different timezones as well as changing the timezone and time
individually. The only things that are missing from that dialog is

1. The "before"-time for the picture.
2. Your auto-increment feature.

Item 1 is very easy to add. Item 2 is harder to do in a way that doesn't confuse
the user. In my opinion, auto-increment will be of very limited use. If the user
doesn't care about the exact timestamp, why would he be happier if all the
pictures are ten minutes apart rather than exactly the same? What is important
is to make sure that we get a consistent ordering of the pictures in case we set
the timestamp on a set of pictures to the same value. This can be achieved by
ordering them after timestamp+filename. This will mean that the order of the
pictures can be changed if we set the timestamp to the same value on a set of
pictures taken with different cameras, but if that is what we are doing, then th
pictures were probably not in the correct order to start with.

One very big advantage to your proposal over all the other proposals is of
course that you have a patch. But maybe you (or someone else) could update that
patch to match comment #18?
Comment 28 Bengt Thuree 2005-11-16 21:25:45 UTC
Mattias, Gabriel

I was a bit hesitant to start with, it took a while before I managed to
understand the relativ button. Hope that it is a bit easier for the end user in
the end. 
But this solution seems to cover more or less everything.
Only thing I am missing is the original/new timestamp which is very easy to add
if we want.

Not promising anything here, but if no-one is working on this patch, I might be
able to do some work on it next week.
Comment 29 Gabriel Burt 2005-11-27 00:19:30 UTC
*** Bug 322528 has been marked as a duplicate of this bug. ***
Comment 30 Gabriel Burt 2005-11-27 00:21:47 UTC
Renaming this bug so people can search for it more easily.
Comment 31 Jonas Bergler 2006-01-10 06:24:43 UTC
inactive for a month and a half!
whats the story with this bug? has this made it into cvs (then close)? or is it waiting for more changes, if so maybe this should be worked on, its a useful feature and shouldnt be too much work if the base is already there.
Comment 32 Bengt Thuree 2006-01-10 07:04:33 UTC
I heard that Larry is working on something, so I did not do anything more.
Eagerly awaiting it though.....
Comment 33 Jonas Bergler 2006-01-11 09:21:06 UTC
*** Bug 155869 has been marked as a duplicate of this bug. ***
Comment 34 Ruben Vermeersch 2006-02-02 11:19:09 UTC
Time adjusting is in CVS, so I'm closing this one. Please re-open the bug if needed.