digikam default options
Locked
12
12
 
|
Makes sense to me now. Thank you Chris and Simon for the explanations. Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: Chris Green <[hidden email]> Date: 2017-01-14 8:51 AM (GMT-07:00) To: [hidden email] Subject: Re: digikam default options > Wanted to add to my message below. > > I think adding any info to metadata should not be considered as "file > modifying". Why would you add any metadata? To get your pictures > organized, right? So why would mess with timestamps then? Original > timestamps should be preserved. > The *files* timestamp (there are three actually) is operating system information and is an indicator to the operating system and is used by other programs and the OS to manage the file. If I modify a file by changing the metadata I *do* want to change the timestamp because this tells the operatiny system (and other software) that the file has been modified and should, for example, be backed up. Quite a lot of backup programs in particular rely on the file timestamps to decide whether a file should be backed up. The times in the metadata are for use by such as Digikam. -- Chris Green |
|
|
In reply to this post by AndriusWild
On Sat, Jan 14, 2017 at 08:44:09AM -0700, Andrey Goreev wrote:
> Cerp > > I think Linux does not save "date created" for files on only keeps > "date modified" instead. So if you are using Linux and updated file > stamps you lost chronological order in the file browser (nautilus, > etc.) Windows keeps both "date created" and "date modified" as well as > its file explorer allows users to sort files by any date including exif > date taken. > Linux has *three* times associated with a file (doesn't care what sort of file):- chris$ lt baby1.jpg Times for file baby1.jpg 2016-02-07 19:31:08.35 Modifed 2017-01-14 15:32:55.71 Accessed 2017-01-13 12:20:53.90 Status changed (lt is a utility I wrote) > So if you are a Linux user you get harmed by digikam for not going > through all the options in the beginning. You can fix the dates using > exiftool (exiv2 will probably do that too) but that's at least 30 min > of your life you will never get back. > I want a picture's "time" to remain with the picture whatever I do to the file containing the picture, therefore it's completely pointless IMHO to use the file system's times to indicate anything about the image contained in the file. If I copy the above image - baby1.jpg - the file system times for the copy will be set to the date when I made the copy. Only the times in the Exif and IPTC metadata will be preserved and indicate when the picture was taken. Also, as I said in another comment, backup programs and such rely on the Modified and Accessed times to decide whether a new backup should be made. -- Chris Green |
|
|
In reply to this post by AndriusWild
Chris, What you are saying does not really work for video files. Digikam can't read "Media created" date from a video file and uses file system's date modified to sort them by date in digikam as well as writes that date to XMP sidecar. Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: Chris Green <[hidden email]> Date: 2017-01-14 9:00 AM (GMT-07:00) To: [hidden email] Subject: Re: digikam default options > Cerp > > I think Linux does not save "date created" for files on only keeps > "date modified" instead. So if you are using Linux and updated file > stamps you lost chronological order in the file browser (nautilus, > etc.) Windows keeps both "date created" and "date modified" as well as > its file explorer allows users to sort files by any date including exif > date taken. > Linux has *three* times associated with a file (doesn't care what sort of file):- chris$ lt baby1.jpg Times for file baby1.jpg 2016-02-07 19:31:08.35 Modifed 2017-01-14 15:32:55.71 Accessed 2017-01-13 12:20:53.90 Status changed (lt is a utility I wrote) > So if you are a Linux user you get harmed by digikam for not going > through all the options in the beginning. You can fix the dates using > exiftool (exiv2 will probably do that too) but that's at least 30 min > of your life you will never get back. > I want a picture's "time" to remain with the picture whatever I do to the file containing the picture, therefore it's completely pointless IMHO to use the file system's times to indicate anything about the image contained in the file. If I copy the above image - baby1.jpg - the file system times for the copy will be set to the date when I made the copy. Only the times in the Exif and IPTC metadata will be preserved and indicate when the picture was taken. Also, as I said in another comment, backup programs and such rely on the Modified and Accessed times to decide whether a new backup should be made. -- Chris Green |
|
|
On Sat, Jan 14, 2017 at 09:08:42AM -0700, Andrey Goreev wrote:
> Chris, > > What you are saying does not really work for video files. Digikam can't > read "Media created" date from a video file and uses file system's date > modified to sort them by date in digikam as well as writes that date to > XMP sidecar. > Well IMHO that's a weakness of the video file format! :-) -- Chris Green |
|
|
In reply to this post by AndriusWild
It is actually a weakness of exiv2 which digikam relies on... Sent from my Samsung Galaxy smartphone. -------- Original message -------- From: Chris Green <[hidden email]> Date: 2017-01-14 9:13 AM (GMT-07:00) To: [hidden email] Subject: Re: digikam default options > Chris, > > What you are saying does not really work for video files. Digikam can't > read "Media created" date from a video file and uses file system's date > modified to sort them by date in digikam as well as writes that date to > XMP sidecar. > Well IMHO that's a weakness of the video file format! :-) -- Chris Green |
|
|
In reply to this post by Chris Green
Le 14/01/2017 à 16:51, Chris Green a écrit :
> On Sat, Jan 14, 2017 at 07:14:54AM -0700, Andrey Goreev wrote: >> Wanted to add to my message below. >> >> I think adding any info to metadata should not be considered as "file >> modifying". Why would you add any metadata? To get your pictures >> organized, right? So why would mess with timestamps then? Original >> timestamps should be preserved. >> > The *files* timestamp (there are three actually) is operating system > information and is an indicator to the operating system and is used by > other programs and the OS to manage the file. > > If I modify a file by changing the metadata I *do* want to change the > timestamp because this tells the operatiny system (and other software) > that the file has been modified and should, for example, be backed up. > Quite a lot of backup programs in particular rely on the file > timestamps to decide whether a file should be backed up. > > The times in the metadata are for use by such as Digikam. > * digikam have to be more clear about what date is modified amoung all the versions possible * this may be quite hard, because *system* dates vary with file system. Being linux or other, what are the dates kept on a FAT32 SD card? jdd |
|
|
On Sat, Jan 14, 2017 at 06:15:33PM +0100, jdd wrote:
> Le 14/01/2017 à 16:51, Chris Green a écrit : > > On Sat, Jan 14, 2017 at 07:14:54AM -0700, Andrey Goreev wrote: > > > Wanted to add to my message below. > > > > > > I think adding any info to metadata should not be considered as "file > > > modifying". Why would you add any metadata? To get your pictures > > > organized, right? So why would mess with timestamps then? Original > > > timestamps should be preserved. > > > > > The *files* timestamp (there are three actually) is operating system > > information and is an indicator to the operating system and is used by > > other programs and the OS to manage the file. > > > > If I modify a file by changing the metadata I *do* want to change the > > timestamp because this tells the operatiny system (and other software) > > that the file has been modified and should, for example, be backed up. > > Quite a lot of backup programs in particular rely on the file > > timestamps to decide whether a file should be backed up. > > > > The times in the metadata are for use by such as Digikam. > > > two things: > > * digikam have to be more clear about what date is modified amoung all the > versions possible > in the file and not rely on any external information whether operating system or a separate database. If I copy an image I want *all* its information to go with it. > * this may be quite hard, because *system* dates vary with file system. > Being linux or other, what are the dates kept on a FAT32 SD card? > Exactly, all the more reason not to rely on or use system dates as having any meaning for the image. -- Chris Green |
|
|
That is why you should all forget about the "modification time issue" -
there is no issue there. Digikam does not rely on modification times (except maybe for unsupported video files, but that is a limitation, not a feature). I don't see why you should care about modification timestamps, leave this option at the default unless you have some very particular setup that requires something else. In the section "Write This Information to the Metadata" you choose which information you want to keep in the metadata, so in the file itself. In the section "Reading and Writing Metadata", where the option "Update file timestamp when files are modified" is located, you configure how this information should be written to the file. These are different things entirely. On 14/01/17 19:08, Chris Green wrote: > On Sat, Jan 14, 2017 at 06:15:33PM +0100, jdd wrote: >> Le 14/01/2017 à 16:51, Chris Green a écrit : >>> On Sat, Jan 14, 2017 at 07:14:54AM -0700, Andrey Goreev wrote: >>>> Wanted to add to my message below. >>>> >>>> I think adding any info to metadata should not be considered as "file >>>> modifying". Why would you add any metadata? To get your pictures >>>> organized, right? So why would mess with timestamps then? Original >>>> timestamps should be preserved. >>>> >>> The *files* timestamp (there are three actually) is operating system >>> information and is an indicator to the operating system and is used by >>> other programs and the OS to manage the file. >>> >>> If I modify a file by changing the metadata I *do* want to change the >>> timestamp because this tells the operatiny system (and other software) >>> that the file has been modified and should, for example, be backed up. >>> Quite a lot of backup programs in particular rely on the file >>> timestamps to decide whether a file should be backed up. >>> >>> The times in the metadata are for use by such as Digikam. >>> >> two things: >> >> * digikam have to be more clear about what date is modified amoung all the >> versions possible >> > Yes, a very good point. For me I want Digikam to store *everything* > in the file and not rely on any external information whether operating > system or a separate database. If I copy an image I want *all* its > information to go with it. > > >> * this may be quite hard, because *system* dates vary with file system. >> Being linux or other, what are the dates kept on a FAT32 SD card? >> > Exactly, all the more reason not to rely on or use system dates as > having any meaning for the image. > |
|
|
On Sat, 2017-01-14 at 19:36 +0100, Simon Frei wrote:
> In the section "Reading and Writing Metadata", where the option > "Update file timestamp when files are modified" is located, you > configure how this information should be written to the file. These > are different things entirely. I suggest this should be worded more unambiguously in the Configure -> Metadata menu. After all, "metadata" does usually refer to EXIF etc stored inside the file. E.g., instead of "Update file timestamp when files are modified" it could say "Update operating system's timestamp of a file when the file is modified" > > On 14/01/17 19:08, Chris Green wrote: > > > > On Sat, Jan 14, 2017 at 06:15:33PM +0100, jdd wrote: > > > > > > Le 14/01/2017 à 16:51, Chris Green a écrit : > > > > > > > > On Sat, Jan 14, 2017 at 07:14:54AM -0700, Andrey Goreev wrote: > > > > > > > > > > Wanted to add to my message below. > > > > > > > > > > I think adding any info to metadata should not be > > > > > considered as "file > > > > > modifying". Why would you add any metadata? To get your > > > > > pictures > > > > > organized, right? So why would mess with timestamps then? > > > > > Original > > > > > timestamps should be preserved. > > > > > > > > > The *files* timestamp (there are three actually) is operating > > > > system > > > > information and is an indicator to the operating system and is > > > > used by > > > > other programs and the OS to manage the file. > > > > > > > > If I modify a file by changing the metadata I *do* want to > > > > change the > > > > timestamp because this tells the operatiny system (and other > > > > software) > > > > that the file has been modified and should, for example, be > > > > backed up. > > > > Quite a lot of backup programs in particular rely on the file > > > > timestamps to decide whether a file should be backed up. > > > > > > > > The times in the metadata are for use by such as Digikam. > > > > > > > two things: > > > > > > * digikam have to be more clear about what date is modified > > > amoung all the > > > versions possible > > > > > Yes, a very good point. For me I want Digikam to store > > *everything* > > in the file and not rely on any external information whether > > operating > > system or a separate database. If I copy an image I want *all* its > > information to go with it. > > > > > > > > > > * this may be quite hard, because *system* dates vary with file > > > system. > > > Being linux or other, what are the dates kept on a FAT32 SD card? > > > > > Exactly, all the more reason not to rely on or use system dates as > > having any meaning for the image. > > > > |
|
|
The option tooltip from Setup Metadata panel is enough clear... Gilles Caulier 2017-01-14 22:57 GMT+01:00 Jim Gomi <[hidden email]>: On Sat, 2017-01-14 at 19:36 +0100, Simon Frei wrote: |
|
|
It's just a suggestion. I agree that the tooltip helps, but still, 1) The wording of the option description in its current context is ambiguous (as this whole discussion has illustrated) and can be easily improved, so why not? 2) Not everyone gets tooltips appearing (I don't; maybe I inadvertently disabled them?) One shouldn't need a tooltip to understand the basic functioning On Sat, 2017-01-14 at 23:09 +0100, Gilles Caulier wrote: > The option tooltip from Setup Metadata panel is enough clear... > > https://www.flickr.com/photos/digikam/31499793873/in/dateposted-publi > c/ > > Gilles Caulier > > 2017-01-14 22:57 GMT+01:00 Jim Gomi <[hidden email]>: > > On Sat, 2017-01-14 at 19:36 +0100, Simon Frei wrote: > > > In the section "Reading and Writing Metadata", where the option > > > "Update file timestamp when files are modified" is located, you > > > configure how this information should be written to the file. > > These > > > are different things entirely. > > > > I suggest this should be worded more unambiguously in the Configure > > -> > > Metadata menu. After all, "metadata" does usually refer to EXIF etc > > stored inside the file. > > > > E.g., instead of "Update file timestamp when files are modified" it > > could say "Update operating system's timestamp of a file when the > > file > > is modified" > > > > > > > > > > > > On 14/01/17 19:08, Chris Green wrote: > > > > > > > > On Sat, Jan 14, 2017 at 06:15:33PM +0100, jdd wrote: > > > > > > > > > > Le 14/01/2017 à 16:51, Chris Green a écrit : > > > > > > > > > > > > On Sat, Jan 14, 2017 at 07:14:54AM -0700, Andrey Goreev > > wrote: > > > > > > > > > > > > > > Wanted to add to my message below. > > > > > > > > > > > > > > I think adding any info to metadata should not be > > > > > > > considered as "file > > > > > > > modifying". Why would you add any metadata? To get > > your > > > > > > > pictures > > > > > > > organized, right? So why would mess with timestamps > > then? > > > > > > > Original > > > > > > > timestamps should be preserved. > > > > > > > > > > > > > The *files* timestamp (there are three actually) is > > operating > > > > > > system > > > > > > information and is an indicator to the operating system and > > is > > > > > > used by > > > > > > other programs and the OS to manage the file. > > > > > > > > > > > > If I modify a file by changing the metadata I *do* want to > > > > > > change the > > > > > > timestamp because this tells the operatiny system (and > > other > > > > > > software) > > > > > > that the file has been modified and should, for example, be > > > > > > backed up. > > > > > > Quite a lot of backup programs in particular rely on the > > file > > > > > > timestamps to decide whether a file should be backed up. > > > > > > > > > > > > The times in the metadata are for use by such as Digikam. > > > > > > > > > > > two things: > > > > > > > > > > * digikam have to be more clear about what date is modified > > > > > amoung all the > > > > > versions possible > > > > > > > > > Yes, a very good point. For me I want Digikam to store > > > > *everything* > > > > in the file and not rely on any external information whether > > > > operating > > > > system or a separate database. If I copy an image I want *all* > > its > > > > information to go with it. > > > > > > > > > > > > > > > > > > * this may be quite hard, because *system* dates vary with > > file > > > > > system. > > > > > Being linux or other, what are the dates kept on a FAT32 SD > > card? > > > > > > > > > Exactly, all the more reason not to rely on or use system dates > > as > > > > having any meaning for the image. > > > > > > > > > > > > > |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |