GNOME Bugzilla – Bug 408183
Patch: EXIF date field added to change date dialog
Last modified: 2007-07-03 12:36:41 UTC
I use three digital cameras (big Nikon, small Minolta and my SonyEricsson mobilephone) and also a scanner for b/w negatives and color slides. - Filenames based on their own series for each camera/scanner - Sometimes the clock is not set resulting in 0000:00:00 00:00 EXIF time stamps - When scanning the scan date is reflected not the actual date of the exposure of course. This results in difficulties when sorting pictures on date to merge pictures from different sources. I have started to work on a solution adding an EXIF checkbox in the dialog for change date tool allowing me to set the EXIF date on a series of pictures. I intend to follow up with a stepper value also so not all pictures get the same date/time.
Created attachment 82592 [details] [review] Patch to add EXIF checkbox in Change Date Tool dialog Should be applied to gthumb 2.9.1
Some comments: 1) Take a look at the set_orientation_in_exif_data function. This is a little bit different than your functions, because it resets the orientation tag in EVERY ifd that has an orientation tag. The main image and the thumbnail can both have orientation tags (see bug 333102). The same is true about the date tags. (If you are curious, see tables 14 and 18 of the Exif standard at http://www.exif.org/Exif2-2.PDF.) I think it would be best to update DateTime tags in all IFDs, otherwise the main image and thumbnail dates could be different - and someone will almost certainly file a bug report :-) I suggest that you consider modifying the set_orientation_in_exif_data to make it more generalized, suitable for setting orientations and dates, so that we can re-use code. The orientation tag is the only tag that we write too, at the moment. (It would be nice to add full exif tag editing in the future, though). 2) I haven't checked - does gThumb report the failure through a dialog if the tags can not be set? (I see the printf - that's only OK for debugging.) - Mike
Thanks for the pointers, I will take a look at it. For the future adding an EXIF edit dialog I wonder if you have looked at the libexiv2? Event though its C++ it has a very nice API paradigm for manipulating META data like EXIF and IPCT. I am not sure how difficult it is to interface to it from C but it should be possible with some wrapper layer I guess. It is 4-5 times larger than libexif too so it might not be the way to go...? The debug output is just a stub, sooner or later I'll add an alert there. Preferably I will first try to add the Date TAG but that might fail too and then trigger the error message. // Joakim
Joakim, No one has looked at libexiv2 in detail. It will have to be considered in the future. Full exif tag display was only added in 2.9.1, and iptc support is pretty minimal right now. There is lots of room for improvement! (Patches welcome, of course...) - Mike
Joakim, Let me clarify my last comment. For now, please implement your date-changing scheme using the existing libexif code. If you would like to try migrating gthumb to libexiv2 in the future, let me know. We would probably make a branch in svn to experiment with. gThumb is in a "feature freeze" right now anyway, until 2.10 is out (which is supposed to be a few weeks after gnome 2.18). - Mike
Joakim, There is another issue to be aware of. The exif/jpeg routines do not support gnome-vfs URIs (like smb://... or ssh://...) directly, so a wrapper layer has to be added around them. See for example src/dlg-jpegtran.c:apply_transformation, where obtain_local_file and copy_cache_file_to_remote_uri are used to copy and return remote VFS files. The exif/jpeg operations are performed on a local copy of the remote file. I just added the same wrapper code to src/dlg-reset-exif.c:apply_transformation as of svn rev 1378, because it was missing. Oops. If that's too complicated, don't worry, I can add it to your patch later. But please add it yourself if it makes sense to you... - Mike
Created attachment 82708 [details] [review] Patch adding EXIF checkbox in Change Date Tool dialog in gthumb 2.9.1 - Added support for multiple date EXIF tags (ie main picture and thumbnail) - Added 1 second steps for multiple pictures to enable date sorting
Mike, I am not into Gnome specific stuff so I didn't attempt to add the wrapper thing, it looked too Gnomish to me ;-) // Joakim
Joakim, I'm not going to commit the patch yet, because of the MakerNote corruption issue. Remind me about this patch after libexif has been fixed, or I have re-worked the metadata system to use exiftool, or exiv2, or whatever... - Mike
The MakerNote corruption is identified and it appears that the corruption is unrelated to both the above patch and the "Reset Exif orientation" tool and only affect some older Nikon models. I think the patch is very useful but it is up to you to decide what to do with it of course. The corruption is caused by libexif and the lack of support for some Nikon cameras in the E9xx series and the D1. libexif instead applies a Maker Note format that is used in newer cameras, causing corruption in the Maker Note field only. No data is actually lost but references to data longer than 4 bytes (like 3 or 4) are errornously recalculated. This *only* casues problems for these older Nikons. I have a submitted a static patch for libexif 0.6.13 to fix the problem for users of these older Nikon models. libexif however did not have an established way of supporting the two offset schemes required and I can't verify that any development I do does work on other cameras than mine, so I left it up to the libexif team to include the patch and develop the necesarry code to support other Nikon cameras dynamically if they want to. // Joakim
OK, I'll look at after the feature freeze is over (next month). - Mike
Created attachment 83394 [details] [review] Trunk SVN patch for write EXIF date dialog SVN generated patch for trunk version of gthumb. It adds an EXIF checkbox in the change date dialog allowing changing the EXIF date. A generic non-destructive write function for EXIF tags is provided.
This discussion is continued in bug 408185. Closing this bug. - Mike *** This bug has been marked as a duplicate of 408185 ***
*** Bug 452802 has been marked as a duplicate of this bug. ***