[digiKam-users] digiKam "date"s and times
Locked
 
|
Hi. digiKam newbie here. Please bear with me as this may get a little
long... I've started testing digiKam (6.1), looked at settings, looked at the website, docs, Nabble forum, & even tried reading some code. But I haven't found the specifics I'm looking for... (Hopefully they're in a spec document or user document somewhere, and not just in the code...) digiKam makes reference to "date" often; and in one place in the docs it talks about "EXIF date" as being the 1st choice. But even within EXIF there isn't just 1 "date"... So what does "date" really mean? digiKam seems to use "date" in at least 3 places: 1) Importing. Which drives Properties & Metadata. I seem to get these results: 1a) Properties->Photograph Properties->Created comes from EXIF-Spec:DateTime. What ExifTool calls ModifyDate. The last time the picture was modified (not created). 1b) Metadata->EXIF->Image Information->Date and Time also comes from EXIF-Spec:DateTime. 1c) Metadata->EXIF->Photograph Information->Date and Time (Digitized) comes from EXIF-Spec:DateTimeDigitized. The time that the image was first digitized. 1d) Metadata->EXIF->Photograph Information->Date and Time (Original) comes from EXIF-Spec:DateTimeOriginal. The "taken" time - when the camera shutter was actuated. 2) View menu sorting. This seems to use the filesystem dates. 3) Left side Dates & Timeline. These seem to use either the Created or the Date and Time above - in either case ultimately EXIF-Spec:DateTime. Hopefully someone(s) can help with these questions: a) Is the above correct as to what dates digiKam is using for what purposes? b) In a recent forum thread there was talk of a date needing to appear multiple times before it's used - is this correct? If so, what is the reason for this rather than using each date per the spec? c) Why isn't the Original date used for sorting, selecting, etc.? As the "taken" date, this would seem to be the most appropriate choice rather than a date which can be changed later by other software... d) I think in the same forum thread there was talk of a coming ability for the user to specify what datetime fields should be selected in what order to be used for each purpose? Is that correct? If so, is there a timeframe for when this might be implemented? e) The latest EXIF spec includes Offset fields to (finally) include Timezone. However, digiKam only lists 1 of the 3 EXIF Offset fields. Is this a work in progress? Will digiKam include the other 2 (when?) and use these Offset fields to correctly sequence pictures from multiple Timezones? f) Is there a Best Practice for when & how to use UTC time in digiKam? g) Or is there some other Best Practice for how dates and times and the related fields should be handled in digiKam? Thanks for your help! |
Re: digiKam "date"s and times
|
|
Hi, Take a look in this C++ method which parse the date time stamp tags from image metadata to populate the date i database : As you can see, exif, or iptc, or Xmp are parsed. and if XMP side car is present, it also parsed. And again this depend of the settings used from DK metadata setup. As ou can see this depend of plenty of cases, and it's a big puzzle. The good news is : we have an advanced metadata configuration panel where we can customize the source to handle metadata information. See Setup DK/Metadata/Avanced view... The bad news is : the date time information is not yet available in this configuration panel. We have a file in bugzilla about this topic : Best Gilles Caulier Le lun. 10 juin 2019 à 09:58, Jim Todt <[hidden email]> a écrit : Hi. digiKam newbie here. Please bear with me as this may get a little |
|
|
As someone who has struggled with date metadata before, just some advice.
If you want o keep things simple, use the "EXIF Original Date and Time" for assigning a creation date/taken date. It's the tag most commonly used by most digital cameras (together with digitization date and time), and most software suites recognize it as the creation date. The "EXIF Creation date and time", and "XMP Creation date" often get overwritten by other picture manage software, and are used as a Modification Date, so I tend to avoid these two. But that is just personal experience. -- Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
|
|
Unfortunately the problem is not simple, the current function uses a ranking
for the date. And based on the experience of many bug reports. What if a user has not set his camera date and later corrected the date in a software via XMP metadata? Then the stubborn use of "EXIF Original Date and Time" would be a problem. The current function pretty much determines the correct date. Maik Am Montag, 10. Juni 2019, 13:13:35 CEST schrieb woenx: > As someone who has struggled with date metadata before, just some advice. > > If you want o keep things simple, use the "EXIF Original Date and Time" for > assigning a creation date/taken date. It's the tag most commonly used by > most digital cameras (together with digitization date and time), and most > software suites recognize it as the creation date. > > The "EXIF Creation date and time", and "XMP Creation date" often get > overwritten by other picture manage software, and are used as a Modification > Date, so I tend to avoid these two. > > But that is just personal experience. > > > > -- > Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
|
|
In reply to this post by Gilles Caulier-4
Thank you all for the prompt replies!
@Gilles: "read the code" is unfortunately of limited value - many (like me) either can't or can't with any reasonable facility; reading a code snippet only reveals that snippet, not the whole picture; reading code can only show what the code does, not what it is _supposed_ to do; etc. To me, that last is key: I would like to know what digiKam is supposed/designed/spec'd to do - because that is how I should arrange my workflow. Agreed, this is a complex issue - all the more reason to know explicitly what is supposed to happen... I looked at the bug but it doesn't seem to have any detail? Neither exactly what might be implemented nor when? @woenx: I agree the EXIF Original date should be used. Unfortunately in my tests so far digiKam ignores it. :( @Maik: Is there a (non-code :) ) description of how this ranking is supposed to happen? And once this date (THE date) is determined, is it then supposed to be used everywhere for all functions within digiKam? Or are other dates involved in different places/functions? I don't understand the logic of your example. In that scenario, the user hasn't "corrected" either their mistake nor the date. The user has in fact _added_ another date and increased the problem. Admittedly I don't have knowledge of all the bug reports or other scenarios - all the more reason I'd like to understand how digiKam is trying to resolve these issues. If one believes that the user, at least from their perspective, "corrected" the date, then wouldn't a simpler, better approach be to confirm that with the user and then use this date for EXIF Original, as the user intended in the first place? @all: Would also appreciate your comments on the other questions: View sorting uses filesystem dates? Is there any plan/schedule for the EXIF Offset Timezone fields to be used? Best Practices for dates, including UTC? Thanks! |
|
|
Hi. What is the protocol/etiquette here - what is the timeframe that
one should wait for response before asking again? Thanks. On 6/10/19 3:17 PM, Jim Todt wrote: > Thank you all for the prompt replies! > > @Gilles: > > "read the code" is unfortunately of limited value - many (like me) > either can't or can't with any reasonable facility; reading a code > snippet only reveals that snippet, not the whole picture; reading code > can only show what the code does, not what it is _supposed_ to do; > etc. To me, that last is key: I would like to know what digiKam is > supposed/designed/spec'd to do - because that is how I should arrange > my workflow. > > Agreed, this is a complex issue - all the more reason to know > explicitly what is supposed to happen... > > I looked at the bug but it doesn't seem to have any detail? Neither > exactly what might be implemented nor when? > > @woenx: > > I agree the EXIF Original date should be used. Unfortunately in my > tests so far digiKam ignores it. :( > > @Maik: > > Is there a (non-code :) ) description of how this ranking is supposed > to happen? And once this date (THE date) is determined, is it then > supposed to be used everywhere for all functions within digiKam? Or > are other dates involved in different places/functions? > > I don't understand the logic of your example. In that scenario, the > user hasn't "corrected" either their mistake nor the date. The user > has in fact _added_ another date and increased the problem. > > Admittedly I don't have knowledge of all the bug reports or other > scenarios - all the more reason I'd like to understand how digiKam is > trying to resolve these issues. If one believes that the user, at > least from their perspective, "corrected" the date, then wouldn't a > simpler, better approach be to confirm that with the user and then use > this date for EXIF Original, as the user intended in the first place? > > @all: > > Would also appreciate your comments on the other questions: > > View sorting uses filesystem dates? > > Is there any plan/schedule for the EXIF Offset Timezone fields to be > used? > > Best Practices for dates, including UTC? > > Thanks! > > |
|
|
Well, there is no timeline to answer. We are all very busy at the moment as
well, we supports students as part of GSoC2019. The EXIF original date has a double priority. If you have a image that you believe digiKam detects the wrong date, send it to me by e-mail. Maik Am Sonntag, 16. Juni 2019, 18:04:22 CEST schrieb Jim Todt: > Hi. What is the protocol/etiquette here - what is the timeframe that > one should wait for response before asking again? > > Thanks. > > On 6/10/19 3:17 PM, Jim Todt wrote: > > Thank you all for the prompt replies! > > > > @Gilles: > > > > "read the code" is unfortunately of limited value - many (like me) > > either can't or can't with any reasonable facility; reading a code > > snippet only reveals that snippet, not the whole picture; reading code > > can only show what the code does, not what it is _supposed_ to do; > > etc. To me, that last is key: I would like to know what digiKam is > > supposed/designed/spec'd to do - because that is how I should arrange > > my workflow. > > > > Agreed, this is a complex issue - all the more reason to know > > explicitly what is supposed to happen... > > > > I looked at the bug but it doesn't seem to have any detail? Neither > > exactly what might be implemented nor when? > > > > @woenx: > > > > I agree the EXIF Original date should be used. Unfortunately in my > > tests so far digiKam ignores it. :( > > > > @Maik: > > > > Is there a (non-code :) ) description of how this ranking is supposed > > to happen? And once this date (THE date) is determined, is it then > > supposed to be used everywhere for all functions within digiKam? Or > > are other dates involved in different places/functions? > > > > I don't understand the logic of your example. In that scenario, the > > user hasn't "corrected" either their mistake nor the date. The user > > has in fact _added_ another date and increased the problem. > > > > Admittedly I don't have knowledge of all the bug reports or other > > scenarios - all the more reason I'd like to understand how digiKam is > > trying to resolve these issues. If one believes that the user, at > > least from their perspective, "corrected" the date, then wouldn't a > > simpler, better approach be to confirm that with the user and then use > > this date for EXIF Original, as the user intended in the first place? > > > > @all: > > > > Would also appreciate your comments on the other questions: > > > > View sorting uses filesystem dates? > > > > Is there any plan/schedule for the EXIF Offset Timezone fields to be > > used? > > > > Best Practices for dates, including UTC? > > > > Thanks! |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |