PDA

View Full Version : Canon EOS - subsecond timing data in Exif metadata


Doug Kerr
June 4th, 2011, 09:13 PM
The Exif file specification provides for three "subsecond" timing tags, one for each of the basic timing values: file modified date/time, image capture date/time, and image digitized date/time.

According to the specification, the subsecond timing value is to be interpreted as decimal digits in the seconds value of the time. Thus, if one of the date/ time tags shows:

2011.06.04 21:52:26

and the corresponding subsecond tag shows 17, the date/time is:

2011.06.04 21:52:26.17

If the date/time tag shows:

2011.06.04 21:52:26

and the corresponding subsecond tag shows 170, the date/time is:

2011.06.04 21:52:26.170

(the same time, actually, to the second decimal place).

Now, as I examine the Exif metadata for my EOS 40D files, I find that the preponderance of them show "00" for the three subsection values. (I would expect them to be uniformly distributed between 00 and 99.)

But a few have other values. I have in fact seen a 99.

Now, when I recently fired some a sequences of shots, I find that the subsecond tags typically are 00 for teh first shot in the burst and then advance by perhaps 15 to 17 from shot to shot (0.15 to 0.17 sec). These seem reasonable considering that the rated maximum burst speed of that body is 6.5 fr/s, which would be an increment of 0.153 sec (15 units in the subsecond tags).

But when I fire single shots, the preponderance give subsecond tags of 00. But not all.

Do we know what this means?

Perhaps the subsecond clock does not run all the time - only once a burst begins. After all, its only real significance is probably in connection with bursts of frames - sorting out in what sequence they were taken (if the filename somehow does not tell us that, or is not accessible).

Best regards,

Doug

Doug Kerr
June 4th, 2011, 11:01 PM
Here's what seem to be going on.

Assume things have been quiet. When we fire a shot, a "work clock" is started. Its seconds value is the same as the seconds value of the real clock, and its fractional seconds value is 00.

So suppose the actual time we fire that shot is (I will only use minutes and seconds):

08:27.63

Of course the main clock only works in seconds, so it doesn't know that - it thinks the current time is:

08:27

But we do (that is, the main clock actually turned over from 08:26 to 08:27 0.63 sec ago).

Nevertheless, at that instant, the work clock is started and set to:

08:27.00

All times are recorded from the work clock (the basic values carry only down to the seconds part, and the fractional part goes in the subsecond tags).

The work clock keeps running and in effect until there have been no shots for some period of time (it might be about 2 seconds). Then the work clock is retired. The next shot that is fired will start the work clock afresh, carrying the time ss.00.

This means that first shots always carry times of ss.00, and any following shots (unless there is a lapse in shooting) carry times (to two decimal places, considering the subsecond tags) consistent with that (to a precision of 0.01 sec).

Sometimes the first shot carries a recorded time of ss.01. It may be that the work clock is set and started when we full press, and if there is a delay in firing (AF, etc.) that might be the result. This will take a little more work here (I'm too tired just now).

I think this is done so:

The main clock need not continuously deliver an output to finer than 1-second resolution. (That may be to reduce battery drain with the camera idle or "off".)

But if we tried to start an ongoing bona fide 0.01 second aspect of the main clock when shooting was about to commence, we would have to wait for the next carry of the main clock seconds to start that, which could take up to almost a second. By that time the shot might be off.

So we start the 0.01 sec aspect right away - at ss.00.

A possible other advantage of this is that the first shot of a series will carry a time of ss.00, making it easier to reckon how long the sequence is, etc.

But we cannot compare the times of two shots first a few seconds apart to a precision of finer than 1 second (even though both carry subsecond values - they will both likely be 00).

Time for bed here.

Best regards,

Doug

Bob Latham
June 5th, 2011, 04:10 PM
If I understand you correctly Doug, then the following test scenario would show your theory to be correct.

Shoot a series of images of an LCD stopwatch having a displayed resolution in 1/100th's. A series of single shots would show an EXIF delta of 1 sec (or multiples of) whilst the captured image delta would be as random as one could reasonably expect.
Repeat the test in burst mode and the deltas in the EXIF and image would match (or be very close).
The camera and stopwatch clearly would not be synchronised...hence using deltas.

The results of the single shot test might even show that camera's internal scan will only permit the capture an image at a certain point in the program scan (maybe 1/10th second) and so all the image deltas will show the 1/100th figures closely matched. Alas, I don't have a suitable timepiece to test the possibilities on.

Bob

Doug Kerr
June 5th, 2011, 06:06 PM
Hi, Bob,

If I understand you correctly Doug, then the following test scenario would show your theory to be correct.

Shoot a series of images of an LCD stopwatch having a displayed resolution in 1/100th's.
I did something similar but not that. That's a great idea. I'll try it.

I have a nice "sports style" stopwatch ($12.95 at Walmart) that reads to 0.01 sec.

A series of single shots would show an EXIF delta of 1 sec (or multiples of) . . .
Yes, since their Exif times would all be ss.00 (or maybe once in a while ss.01).

. . .whilst the captured image delta would be as random as one could reasonably expect.
Repeat the test in burst mode and the deltas in the EXIF and image would match (or be very close).
The camera and stopwatch clearly would not be synchronised...hence using deltas.

The results of the single shot test might even show that camera's internal scan will only permit the capture an image at a certain point in the program scan (maybe 1/10th second) and so all the image deltas will show the 1/100th figures closely matched.
I'll let you know what shows up!

Thanks so much.

Best regards,

Doug

Doug Kerr
June 6th, 2011, 11:04 AM
Hi, Bob,

As you well know, often we go to investigate one mystery, and in making sure of our tools and premises and such, discover other mysteries. It is no different in this matter of subsecond timings.

Before I begin, let me review three different date/time "tags" in the Exif metadata from my EOS 40D. I will first give the formal Exif field name, followed (in square brackets) with the label for the value in ExifToolGUI.

1. DateTime [ModifyDate]
This is supposed to be the time that will be put in the file header as date/time modified. (The date/time created would ordinarily be the same.) We might expect this to be essentially the same as (3).

2. DateTimeOriginal [DateTimeOriginal]
This is supposed to be the time at which the original image data is captured.

3. DateTimeDigitized [CreateDate]
This is supposed to be the time at which the image was digitized. We would generally expect this to be essentially indistinguishable from (2).

For each of these there is a subsecond time tag:

1a. SubSecTime [SubSecTime]

2a. SubSecTimeOriginal [SubSecTimeOriginal]

3a. SubSecTimeDigitized [SubSecTimeDigitized]

These (for the 40D) give the fractional parts of the seconds value of the corresponding date/time in 1/100 second units (subject to the "work timer" notion).

Now, to the actual story.

Before further exploring the details of the working of the subsecond timing tags and the "work timer", I felt I needed to be certain what event instants the times being recorded refer to. I considered three basic possibilities (there are of course possible subtle wrinkles for each).

a. The instant of full press

b. The instant of shutter release.

This could of course be substantially different from (a), depending on how long it took for AF to play out.

c. The instant of the end of exposure (when the shutter had fully closed).

I decided to determine this in a way not dependent on precise timing. I provided for about a 5 second difference between (a) and (b) by frustrating the AF for about 5 sec after full press, and I used a 10 sec exposure time.

The finding was that all three times seemed based on instant (b): when the shutter is released.

The modified (and created) times on the file proper seemed essentially consistent with instant (c): when the shutter has closed (as we might well expect).

Thus none of the Exif times seem to fulfill their "chartered" purpose.

Now, back to the actual subsecond testing!

Best regards,

Doug

Bogdan Hrastnik
June 6th, 2011, 11:52 AM
Hi Doug,

I've noticed this "strange" SubSec behaviour a while ago. On my camera (450D), in 95% cases (estimated) there's a value 03. It happens there's 05 or some (can't recall) value between 51-59, but that's very rare -btw. I always use single shot mode (never burst).
That is, for me, SubSec tags have no value for me -nor have they something common with Exif specification, though.
...Just for info.

Greetings,
Bogdan

Doug Kerr
June 6th, 2011, 12:07 PM
Hi, Bogdan,

Nice to hear from you.

I've noticed this "strange" SubSec behaviour a while ago. On my camera (450D), in 95% cases (estimated) there's a value 03. It happens there's 05 or some (can't recall) value between 51-59, but that's very rare -btw. I always use single shot mode (never burst).
Yes. I'm beginning to think that this is a small "wrinkle" on the "work timer" concept I discuss above. Perhaps the work time is not zeroed/started by the actual event that causes the time to be captured, but on some event that closely precedes it (perhaps in the matter of closing out the AF job etc.)

Thus, as the first shot is about to happen, the work timer is reset to ss.00, but the time is grabbed when the shutter actually trips (after a little more housekeeping), maybe 0.00-0.03 sec later.

When you see, for example, 51, is it possible that you made another shot about 0.5 sec earlier? Then the work timer would still be running, not reset to ss.00. (It looks now as if the work timer resets if there has been no shot fo about 2.5 sec (but if a burst is in effect, even with a shutter speed of 5 sec, the timer keeps running).

For readers who may not know, Bogdan is the developer of ExifToolGUI, the Windows front end for ExifTool.

Bogdan, what's new with ExifToolGUI?

Best regards,

Doug

Bogdan Hrastnik
June 6th, 2011, 12:29 PM
Hi Doug,
Nice to see you remember me :)
About SubSec... I don't believe it's "a shot was made shortly before", as I never take rapid subsequent photos -I always need some time inbetween. To be honest: I have no idea what's being written into SubSec....

About ExifToolGUI... I must admit, I haven't "promote" it much lately. But in case you haven't noticed, since March 2010, GUI is available for download at Phil Harvey's forum:
http://u88.n24.queensu.ca/exiftool/forum/index.php/board,7.0.html
-you're welcome guest there (and whoever reads thse lines, of course).

Bogdan

Doug Kerr
June 6th, 2011, 07:19 PM
This is further to the matter of subsecond times on the EOS 40D.

Work timer retirement

To determine fairly precisely the length of time required for the work timer to "retire" when there is a lapse of shot activity is a bit tedious.

Crude tests done here suggest that this time is about 2.5 seconds.

Basically, if the has been no shot for that length of time, the work timer "retires". On the next shot, the work timer is restarted, at ss.00, where ss is the current seconds part of the camera's real-time clock value.

If we are in a burst, with the shutter release steadily in full press, the work timer soldiers on, even if the time between shots is greater than the timeout value (as could be if a very long shutter speed were in use, for example, 4.0 seconds).

Consistency of Exif times

I tried Bob Latham's technique of shooting the face of a stopwatch to get accurate "real-time" correlation to the recorded Exif times. It is very clever. However, because of the lag time of the LCD display of either of the watches I have, the reading of the 0.01 sec place was not practical. Thus they were not really suitable for this technique.

I do however have an instrument with a a hand that rotates once per second on a big dial with a high resolution scale. Its image can easily be read to a precision of 2 ms. (I built it to look at shutter lag issues a few years ago.) So I used it to get "real time" correlation to the recorded Exif values in a burst of shots. Since the work timer never reset during the series, relative Exif times could be reckoned.

To the two decimal point (0.01 sec) resolution of the Exif times, there was exact correlation between the relative real time indicated in the shot and the relative Exif times.

The actual intershot times in the burst, by the way (shutter speed here was 1/250 sec) were 0.163 sec from the first shot to the second and were then in the range 0.157-0.160 for the rest of the shots until the speed dropped after the 7th shot (card write limit, I expect - I was not using anything especially fast).

Best regards,

Doug

Bob Latham
June 6th, 2011, 10:40 PM
Thanks for doing the tests Doug...it would appear that the time stamp is good within the 2.5 second reset limit.

Another thing we can see from your test is the burst rate. You used 1/250th which happens to be the 40D's sync speed and hence closely tied to the potential minimum fully exposed sensor time (faster shutter speeds cannot improve the burst rate). The 40D's advertised maximum burst rate is 6.5fps (0.154s) which is only about 5ms faster than your results.
Assuming that the published specs are pushing things to the limit then a 1ms pulse (a 580EXII on full power) leaves little more than a 3ms safety margin to sync the flash.

Bob

Doug Kerr
June 7th, 2011, 07:14 AM
Hi, Bob,

Another thing we can see from your test is the burst rate. You used 1/250th which happens to be the 40D's sync speed and hence closely tied to the potential minimum fully exposed sensor time (faster shutter speeds cannot improve the burst rate).
Well, conceptually they could a little. I'll give a highly-idealistic illustration.

Suppose that the full-height travel time of the shutter blades was 3 ms. Then the shortest "fully open all at once" shutter operation would have the second curtain release 3 ms after the first curtain (a shutter speed of 1/333 sec) - just as the first curtain came fully open. The total time of curtain operation would be 6 ms.

For a shutter speed of 1/1000 sec, the second curtain would be released 1 ms after the first curtain.

Then the total time of curtain operation would be 4 ms, 2 ms less than in the 1/333 case. Assuming that rewind time and so forth was constant, I would think that thus the total shutter cycle time would be decreased by 2 ms.

For a shutter speed of 1/8000, we would expect a reduction in total shutter work time of almost 3 ms.

This is of course simplistic but I think the conclusion is valid.

I just did a quick test (pre-breakfast) using bursts at shutter speeds of 1/250 sec and 1/8000 sec. I did not shoot the "big hand clock" since it has been put away and in any case, at 1/8000 sec I could not get the needed exposure in the ambient illumination I used (my desktop). Thus, shot times were taken from the augmented Exif times, to a precision of only 0.01 sec. I could only use 6 intershot times; later burst shooting slowed down.

That all having been said, the mean intershot time at 1/250 sec was 0.160 sec; at 1/8000 sec, it was 0.157 sec - a shortening of 3 ms.

How about that!

Best regards,

Doug

Bob Latham
June 7th, 2011, 06:48 PM
I guess I should have inserted the word "significantly" into my statement :)

Either way, your 40D is under-performing the spec by 0.1 shot/second. Assuming that you've had it for around 3 years then you've been deprived of somewhere shy of 10 million potential shots.....any or all of which could have earned you a small fortune in royalty payments.

Manipulating numbers to prove an absurdity leads me to wonder about moving into politics at some point.

Bob

Doug Kerr
June 7th, 2011, 08:28 PM
Hi, Bob,

I guess I should have inserted the word "significantly" into my statement
Sorry - I thought you meant there was some conceptual reason that below 1/250 it wouldn't change at all.

It has nothing to do with the maximum X-sync speed. It's just that if the second curtain delay is only 4 ms to start with (at 1/250), you don't get much advantage by reducing it to almost zero (at 1/8000 sec, for example). If it only 2 ms to begin with ( at 1/500), you get even less advantage by reducing it to almost zero. If it is 5 ms to begin with (1/200) you get a bit more advantage.

And it doesn't matter whether the curtain travel time is 1/300 sec or 1/100 sec (that is, what the X-sync speed limit is).

That was my point.

Best regards,

Doug

Bob Latham
June 16th, 2011, 10:13 AM
The x-sync reference was certainly a faux pas....I pictured the simultaneous curtain moves as being the point of no gain....think twice, write once!

Bob

Doug Kerr
June 16th, 2011, 11:14 AM
Hi, Bob,

The x-sync reference was certainly a faux pas....I pictured the simultaneous curtain moves as being the point of no gain....think twice, write once!

I understand. Seemed like a good idea at the time!

Thanks for the note.

Best regards,

Doug