Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3
Why so many image date/time variations?
The DAM Forum
Welcome, Guest. Please login or register.
October 21, 2020, 08:08:43 PM

Login with username, password and session length
Search:     Advanced search
28033 Posts in 5147 Topics by 2903 Members
Latest Member: kbroch
* Home Help Search Login Register
+  The DAM Forum
|-+  Software Discussions
| |-+  ImageIngester and ImageVerifier
| | |-+  Why so many image date/time variations?
« previous next »
Pages: [1] Print
Author Topic: Why so many image date/time variations?  (Read 6800 times)
David Anderson
Sr. Member
****
Posts: 287


View Profile
« on: July 24, 2006, 02:34:42 AM »

The ImageIngester website provides a list of what the program can do, including the following statement:

"File modification times (even for DNGs) set to match corresponding times on card. (Modification time of file on card to the second—almost always close to, but not necessarily identical to, EXIF Date Time, Date Time Original, and Date Time Digitized.)"

This confirms my understanding that there are at least 4 variations of date/time associated with an image file.

   1. The date/time the file was created, as set by the file system lurking inside a digital camera (as used by ImageIngester)

   2. The EXIF Date Time

   3. The EXIF Date Time Original

   4. The EXIF Date Time Digitized


My question is this, why are there so many variations of what is 'normally' the same date/time? Under what circumstances would they differ from one another? It's not a major issue. I'm just curious to know.

David
Logged
Marc Rochkind
Hero Member
*****
Posts: 1136


View Profile WWW Email
« Reply #1 on: July 24, 2006, 05:43:06 PM »

[Back from vacation.]

David--

I don't know. These field definitions have a long history and lineage behind them. I think of them as a glossary from which items can be taken, rather than as a form to be filled out.

Anyway, ImageIngester doesn't use any of the fields, since it never looks inside the image file for any data at all. It does look at the file's date and time.

--Marc
Logged

jomilo75
Newbie
*
Posts: 6


View Profile Email
« Reply #2 on: July 26, 2006, 04:07:45 PM »

Marc

It seems to me, of all the image date-times stored, the only one that matters is the EXIF DateTimeOriginal. That is when the photo was taken and never changes. The file date time (modified or created) can all be changed to values that are meaningless with respect to the photograph.

I understand the problem from a programing view with respect to the RAW image formats. But, the EXIF datetime values as stored in JPEGs and DNGs should be standard enough to offer that option. I would encourage a rule that follows along lines of "all image and directory names based on date and time will be derived from the EXIF DateTimeOriginal for JPEG, TIF and DNG files. All other formats will rely on the file system date-time". I agree with other comments I have seen about the slippery slope of trying to decode RAW files of varrying formats.

In reality, if you use image ingester to rename files on download from the card, the issue is minor. However, I have been involved in a process to move and rename archived photos from a server on our LAN. On June 2, 2004, the server had to be restored from a tape backup and all of the file system date-times were set to June 2, 2004. The EXIF DateTimeOriginal is preserved, but I cannot use image ingester for this process because it uses the file system time.

Cheers
Josh
Logged
Marc Rochkind
Hero Member
*****
Posts: 1136


View Profile WWW Email
« Reply #3 on: July 26, 2006, 07:04:11 PM »

Josh--

I don't disagree with anything you've said. If one has adopted a DNG-based workflow, then "re-ingesting" should indeed see only those formats, which means that such a feature would be useful for a large enough group to make it worthwhile.

Alas, I have a computer with 2 CPUs, and just got one with 4, but there is still only one of me... no telling when I'll be able to get to this, although I already know that the fairly new DNG toolkit from Adobe makes the job much more striaghtforward for DNGs.

--Marc
Logged

David Anderson
Sr. Member
****
Posts: 287


View Profile
« Reply #4 on: July 27, 2006, 01:10:58 AM »

It seems to me, of all the image date-times stored, the only one that matters is the EXIF DateTimeOriginal. That is when the photo was taken and never changes. The file date time (modified or created) can all be changed to values that are meaningless with respect to the photograph.

I understand the problem from a programing view with respect to the RAW image formats...........

I totally agree with Josh's view, as I am also looking at image ingestion programs for the purpose of 're-ingesting' an archive of 5000 images. The file dates are often wildly different from the actual image capture date. However, unlike Josh, I don't understand "the problem from a programing view with respect to the RAW image formats" and therefore didn't really understand the relevance of Marc's subsequent comments. Please clarify.

David
Logged
Marc Rochkind
Hero Member
*****
Posts: 1136


View Profile WWW Email
« Reply #5 on: July 27, 2006, 06:53:06 AM »

David--

The problem is reading the EXIF information out of the file. For JPEGs, DNGs, and a few others, the file format is well documented and there are toolkits that make things fairly easy for developers. For the dozen or so raw formats out there (e.g., NEF), there is a lack of documentation and toolkits. Even if there were, each raw format has to be dealt with separately. And, the formats change with new cameras, which causes a continuing maintenance problem. So, the task, while not impossible, is very difficult.

Josh is suggesting doing it only for JPEG, DNG, and maybe one other. That is practical.

--Marc
Logged

David Anderson
Sr. Member
****
Posts: 287


View Profile
« Reply #6 on: July 27, 2006, 07:44:29 AM »

Digital Image Mover (DIM) from www.alanlight.com/dim/Dim.htm can exploit the EXIF info from all the common Raw formats. Like your program, DIM is a freebie from a one-man band. Perhaps the author might share some of his secrets! Or then again, perhaps he might not....

BTW, I'm well aware that making feature requests for software that is free is always a little presumptuous! You have a right to spend your time as you choose and us users should be thankful for what we get.

David
Logged
Marc Rochkind
Hero Member
*****
Posts: 1136


View Profile WWW Email
« Reply #7 on: July 27, 2006, 09:34:12 PM »

Regarding feature requests for free software:

If other authors are like me, we very much want these! Essentially all I know about professional workflow I learned from my users... without that feedback, I wouldn't have a clue about what ImageIngester should be doing. I'm a programmer, not a photographer.

Over time, I do learn to apply critical thinking to feature requests. Some are outside the scope. I never confuse a request with a demand... don't worry, I am not your spouse/parent/child. ;-)

--Marc
Logged

David Anderson
Sr. Member
****
Posts: 287


View Profile
« Reply #8 on: July 28, 2006, 01:13:35 AM »

Marc,
You would never want me as a spouse/son/father. I'm far too demanding! Seriously, though, I'm sure everyone here appreciates the effort you put in on our behalf.

David
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!