GNOME Bugzilla – Bug 302567
Ability to Edit Date & Time of Photos
Last modified: 2009-07-27 13:20:16 UTC
exif edit (to change wrong date for example)
isn't that a dupe of bug 155869 ?
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.
Created attachment 50758 [details] [review] Updated Patch This patch should apply cleanly to HEAD, including the added EditDateTime.cs file.
Working on an enhancement for Gabriels patch. Should be ready in a day or two.
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 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;
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)
*** Bug 315565 has been marked as a duplicate of this bug. ***
Mattias Holmlund has posted a proposal for fixing this bug at (duplicate) bug 315565.
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
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.
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.
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.
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.
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.
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.
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?
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? :)
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.
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. :)
> 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?
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.
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
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.
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.....
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.
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?
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.
*** Bug 322528 has been marked as a duplicate of this bug. ***
Renaming this bug so people can search for it more easily.
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.
I heard that Larry is working on something, so I did not do anything more. Eagerly awaiting it though.....
*** Bug 155869 has been marked as a duplicate of this bug. ***
Time adjusting is in CVS, so I'm closing this one. Please re-open the bug if needed.