Version: (using KDE KDE 3.5.8) Installed from: Ubuntu Packages OS: Linux I have some pictures converted from RAW which have different dates in the same image. Image -> Metadata -> Edit EXIF shows me the image has a "Creation date", a "Original Date" and a "Digitization Date". Digikam displays the "Original Date" as the Photograph properties -> Created: however the Kipi Time Adjust plugin will only let me adjust the "Creation Date". This does not make any sense as it seems like digikam will not use the "Creation Date" for anything, and will only use "Original Date". Ideally Kipi Time Adjust plugin should look through the exif data and let you adjust any date field found in there...
Created attachment 35949 [details] New design of the timeadjust plug-in dialog
Created attachment 35950 [details] Patch that implements the attached design change
I have exactly the same feeling about the current TimeAdjust plug-in. What I miss the most is the freedom to choose any source timestamp from the file and a freedom to update (or keep) any of them separately. I have implemented and tested an alternative design of the plug-in, which I believe gives the user all of these freedoms, while it still provides all the functions of the original implementation. Enclosed are the screenshot of the dialog and patch that does the change in the code. Any feedback is welcome!
Jarle: The original date and the digitization date take precedence over the "normal" date when reading the creation date. Indeed, there should be an option Karol: Thanks for your contribution. Some remarks on this patch: - please use the "-U 2" formet if you create a patch with diff - a kipi plugin can work with other apps not only digikam, so dont use in "digikam internal" as description. It's the official "creation date" or similar. It's really not an internal value but this is defined as the one and true (per definition) creation date in the current application. - Exif.Image.DateTime is (taken from libexiv2) "The date and time of image creation. In Exif standard, it is the date and time the file was changed.". I wouldn't call it Exif modification date (we read the creation date from it) - have you tested starting the plugin with 1000 images? Is it ensured that we dont read 1000 files' metadata then? Generally, I'll wait for Gilles' (on holidays currently) approval on this.
Marcel, thanks for the comments. - "digiKam internal": the name digiKam is read by KGlobal::mainComponent().aboutData()->programName() so other applications should show their own name. Anyway what this timestamp really refers to, is the KIPI::ImageInfo timestamp. So please suggest a better name for it if you don't like the "<application> internal". - EXIF modification: Is the problem only in the name, or do you want to have it bound with the file modification time? I treat it as an independent timestamp now. - 100 files: to be honest I did not test with so many files (I will do that), but anyway the metadata are only read if you select the particular metadata as the source for your timestamps. In that case they should be read, so that you can see in the Examples how many of them are available and how many are missing.
Karol: Well done, as you can see I have been waiting for this feature for almost two years. Making a plugin like this as versatile as possible is a good thing! A program that only works in one way is the closed-source way of doing things :)
> - "digiKam internal": the name digiKam is read by > KGlobal::mainComponent().aboutData()->programName() all right > so other applications should show their own name. Anyway what this timestamp > really refers to, is the KIPI::ImageInfo timestamp. So please suggest a better > name for it if you don't like the "<application> internal". "<Application> Timestamp"; "<Application> File Date"; "Timestamp from <Application>"; "Date from <Application>"? > > - EXIF modification: Is the problem only in the name, or do you want to have it > bound with the file modification time? I treat it as an independent timestamp > now. No, only the name! E.g. in the Metadata Edit KIPI plugin, the three dates are labeled "Creation date and time", "Original date and time", Digitization date and time". Although the spec suggests differently, Exif.Image.DateTime is more a creation date than a modification date. > > - 100 files: to be honest I did not test with so many files (I will do that), > but anyway the metadata are only read if you select the particular metadata as > the source for your timestamps. In that case they should be read, so that you > can see in the Examples how many of them are available and how many are > missing. ok. Just wanted to bring your attention to this. I sometimes like to test with 30,000 images ;-) (not editing, just opening the dialog). Thanks very much, your contribution is highly appreciated.
Enclosed is the patch, which I generated using the diff modifiers mentioned by Marcel. I have also changed the names of the application and EXIF creation timestamps. I have left the text in lowercase, since this was also the style used in the original plugin dialog. I have run some performance tests, here are the results: 1. Reaction time to a timestamp selection (or plugin window appearance, if the particular timestamp type is selected initially): 100 pictures: metadata: 0.2s, file/application: instant 500 pictures: metadata: 1s, file/application: instant 1000 pictures: metadata: 2s, file/application: instant 2000 pictures: metadata: 4s, file/application: 0.4s 5000 pictures: metadata: 8s, file/application: 1s 2. Modification of 500 pictures: digikam stamp: 10s file modified: instant EXIF created: 25s 3. Modification of 5000 pictures: digikam stamp: 90s file modified: 3s EXIF created: ca. 5 min. I could not test more than 5000 pictures (i.e. ca. 5 GB of data) in a folder due to a limited space of my Linux partition.
Created attachment 36034 [details] New patch with changed texts, generated with diff -U 2
Created attachment 36035 [details] Picture: Comparison of the existing and proposed dialog windows
Marcel, >Generally, I'll wait for Gilles' (on holidays currently) approval on this. new layout is fine for me. I'm agree to include it to 0.6.0. Karol, Thanks for your patch, it's very appreciate Gilles Caulier
Gilles, seems I forgot about this patch and did not apply it. Now we should wait until after the 0.7.0 release planned tomorrow to apply this I guess?
Marcel, If you want to review ths patch, let's go. I can delay a little... Gilles
Karol, this patch does not apply anymore to current SVN (probably because of the patch that added the clock photo button). Can you create us a patch for current SVN?
OK, please give me ca. an hour
Yes, Marcel, that's the reason. This "clock photo dialog" must have been added since I posted my patch. In the meantime, I have synchronized myself to the current status a played a bit with the "clock photo" dialog. I had an impression that it did not work correctly in all cases. Sometimes the dialog calculated the difference to the time shown in the dialog as "The clock date and time:", but most of the time it did not do anything, even though the "clock photo date/time" was different and I pressed OK in the end. Could you please tell me whether this addition is finished? There are 2 things we can do now: 1. I may create a patch, which will remove the clock photo dialog from the plugin and later it must be added again. This may be done quickly. 2. I have to understand the way how the clock photo stuff works, see why it did not work in the cases I tested, and change it to match the different layout of the timeadjust dialog after applying my patch. This may take some time, say a day or two. Which of these options do you guys prefer?
Sorry guys, it seems that I misunderstood the idea behind the "clock photo" dialog. Now it seems to me that it works, although I will have to change the way how it is integrated into the new layout of timeadjust. I will try to finish this in 3-4 hours from now.
Created attachment 37205 [details] Patch against the latest SVN version, incl. clock photo dialog clockphotodialog unchanged, using its existing interface. Selecting no difference in clockphotodialog and pressing OK clears the adjustment (i.e. sets "Copy value" and clears the day/time shift) Layout: re-used the same approach to add the "Determine from clock photo" button as in the original SVN version Hopefully now the patch will work, if there are some problems please contact me asap.
SVN commit 1029549 by cgilles: Apply patch #37205 from Karol Slanina about to adjust more image date. BUG : 151346 CCMAIL: karol.slanina@gmail.com M +637 -346 timeadjustdialog.cpp M +10 -5 timeadjustdialog.h