Clicky

fcharron
I have just noticed (what I think is) a bug in HoudahGeo (still present in 1.4.4)

After having geotagged and imported some JPG images in Aperture, I noticed the timestamps for the geotagged images was off. What was weird, was that iPhoto showed the correct time stamp for the same geotagged picture.

I tracked down the problem to two tags:

[B]Date Time Digitized[/B] - Used by iPhoto and HoudahGeo to display timestamp)

[B]Date Time Original[/B] - Used by Aperture to display timestamp

I compared the EXIF from an original image to its geotagged version and discovered the following:

[U]Original[/U]
Date Time Digitized: 2007:05:04 19:54:05
Date Time Original: 2007:05:04 19:54:05

[U]Geotagged[/U]
Date Time Digitized: 2007:05:04 19:54:05
Date Time Original: 2007:05:04 18:54:00

Upon further investigation, it appears that HoudahGeo changes the "Date Time Original" metadata by subtracting 1 hour and setting the seconds to 00.

Anybody seen this before?
.:FLC:.
0 0
houdah
Hi!

This is not a bug. It is intended behavior.

Digital cameras record date and time in whatever time zone they were set to. They however do not usually record the time zone offset. Thus the value for "Date Time Original" is ambiguous: you don't know which time zone it refers to. That's why HoudahGeo asks you for the camera time zone.

When you write out EXIF, HoudahGeo gives you the option to write out the time stamp with the corrections you have applied (time zone and clock error). When you chose so, HoudahGeo will write the "Date Time Original" in GMT time zone and add a "Timezone Offset" property telling the reader how to interpret the time information.

In effect, the time is unchanged. It just no longer is ambiguous.

The seconds however should not be zeroed and I have no explanation for that - unless you set a clock error of 5 seconds.

BTW, HoudahGeo used "Date Time Original" for time display. I suspect most other applications do to. The question is if they apply the time zone offset when displaying or if they display it as GMT (Z) time.

Best,
Pierre Bernard
Houdah Software s.à r.l.
Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0
fcharron
Thanks for the prompt reply!

Since I always ensure my camera is synchronised with my GPS, I now uncheck the "Write Timestamp" checkbox when writing the EXIF and all is well. The image will keep the camera time in both EXIF tags, but I can live with that ... especially if it helps me sort images in Aperutre:

The issue I was having in Aperture occured when I was displaying pictures that were taken in different time zones and sorting them by time. Since Aperture uses [B]Date Time Original[/B] it sorts the pictures by local time and not absolute time and this messed up pictures that were taken in the overlapping hour when going to a lesser time zone. (ex: from -4.00 to -5.00, -5 to -6, etc...)

I'll have to play with the time zone options in Aperture.
I haven't seen the Time Zone Offset tag in HoudahGeo tagged images. Does it use it? Without it, how does a software know the actual "Absolute time" a picture was taken?


-- Second issue (no pun intended) --

[QUOTE]The seconds however should not be zeroed and I have no explanation for that - unless you set a clock error of 5 seconds.
[/QUOTE]

Like I mentionned above, I always kept my camera clock in sync. with my GPS, so I am certain I have never set the clock error in HoudahGeo to anything other than 0. I've actually attached a sample image and a matching gpx track log so someone can witness the 00 bug.

Here's what I do
1. Open HoudahGeo, drag in Original.JPG
2. Camera time zone: Canada/Atlantic; Clock error: 0
-->Time shown is 04/05/07 19:54:43
3. Load GPS data from file -> TrackLog.gpx
-->HoudahGeo correctly matches the picture to its coordinates
4. Write exif tags: Everything selected except XMP sidecar
5. Quit HoudahGeo
6. Open newly tagged file with Preview.app, command-i, more info inspector, Exif tab, DateTime Original tag has 00 for seconds.
7. Quit preview.app
8. Launch HoudahGeo and drag in the newly tagged file.
-->Timestamp shown has correct seconds: 43. Where does it take this 43 if DateTime Original has 00 for the seconds?

0 0
houdah
Hi!

You seem to have found a fascinating bug in Preview.app

HoudahGeo does not zero the seconds. You may verify this at the command line:

[CODE]pierre% /Applications/HoudahGeo.app/Contents/Resources/exiftool -DateTimeOriginal -TimeZoneOffset IMG_0455.JPG
Date/Time Original : 2007:05:04 22:54:43Z
Time Zone Offset : -3
[/CODE]

The above tells me the picture was taken at 10:54:43 PM in GMT time an that I need to shift that by 3 hours to display local time (Canadian Atlantic).

It seems like Preview.app drops the seconds when applying that shift.

Best,
Pierre Bernard
Houdah Software s.à r.l.

Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0
fcharron
Ahhhh ... hadn't thought of checking with exifTool ... You're correct, all seems OK!

I was taking Preview.app by granted... The thing is ... Aperture does the same thing (zero the seconds). Try importing the picture in Aperture if you have it. What's weird, is that iPhoto does keep the seconds.

I might just have to file in a bug with Apple.
0 0
fcharron
What I find weird, however, is that non geotagged images seem to keep their seconds in the Date Time Original tag when shown in Preview.app and Aperture.

The only differences I noticed between the original and the geotaged files are:
- geotagged file has a different values for DateTimeOriginal and DateTimeDigitized
- geotagged file has a value for the timeZoneOffset tag

I suppose either one of thoses (or both) can cause weird things with OS X...

.. which brings me to the following question: Can anybody replicate this on Tiger? I'm all-Leopard now, as are all of my friends.
0 0
houdah
This is getting weird. I can no longer reproduce the problem. Neither on Leopard nor on Tiger!

??

Pierre Bernard
Houdah Software s.à r.l.
Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0
fcharron
I am currently at work and am not able to try anything other than terminal commands. Running Aperture through ssh doesn't work too well ;-)

Will look further into this in a couple of hours.

Thanks for the support, Pierre!
0 0
houdah
Actually, I modified the image on Tiger first and then copied it over to Leopard. Maybe that's why I am not seeing the problem.

Guess I'll have to give it another try.

Best,
Pierre Bernard
Houdah Software s.à r.l.
Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0
fcharron
I've spent a couple of hours looking into this and haven't found much.

I did a comparison of all tags that were different between the original and the tagged images and came up with a list of about 20 tags that get added by HoudahGeo. Thinking that maybe Aperture and Preview.app don't like one of those added tags, I removed each of those tags individually in 20 versions of a tagged file (thank god for shell scripting !). Maybe importing these 20 files in Aperture would yield one with the correct seconds, identifying the responsible tag. No; each of the images were showing times with 00 seconds. At least I know it's not a single new tag that is causing this problem ... and I'm definitely not trying all permutations ...

I have noticed, however, that all problematic files are images that have a "Z" at the end of their DateTimeOriginal tag as shown by exiftool. This Z appears during the geotagging and I assume it's indicating a UTC 0 time zone (is that correct?). Is this Z displayed by exifTool only for information purposes, or is the character "Z" actually part of the metadata?

If the latter, could this "Z" confuse some applications like Aperture and Preview.app during their parsing of the image metadata?
0 0
houdah
Hi!

The Z means that the time is set in the GMT time zone.

Your camera records time, but doesn't say which time zone it was in. Thus the recorded information is of reduced value. That's why HoudahGeo has to ask you for the time zone.

When you ask for HoudahGeo to write out the timestamp, it writes it out in GMT. The value is now unambiguous. Additionally it writes out the time zone offset to use in order to display this timestamp in local time.

Client applications like iPhoto, Aperture or Preview have the choice of either displaying time as GMT or of adding the offset and displaying the time in local time zone. Both choices are equally correct.

I get the impression that Preview.app makes the effort of adding the offset but loses seconds in that calculation.

Best,
Pierre Bernard
Houdah Software s.à r.l.
Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0
fcharron
Hi Pierre!

I am currently writing a bug report to Apple on this issue. When you tried this on Tiger, did the same 00 second issue occur with preview/Aperture?

Like I mentionned earlier, I don't have (easy) access to Tiger so I can't test it myself.

Thanks,
.:FLC:.
0 0
houdah
Hi!

I have only tested Preview on Tiger and did not see the same problem.

Thanks for writing the bug report to Apple.

Best,
Pierre Bernard
Houdah Software s.à r.l.
Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0
panders
I just have started using HoudahGeo and have encountered a timestamp problem. I am using version 1.4.10 of HG and Mac OS X 10.5.3. I geocoded 1313 images with HoudahGeo, and on checking the first file I found a 38 second discrepancy between the original date and the modified DateTimeOriginal tag. After reading this thread, and looking at the data with Photoshop CS3, Preview, GraphicController, and EXIFTool, I found the following:

1. HoudahGeo re-stamps the file with the GMT time, based on the camera offset set at the time of image import, so camera time 11:25:48, with an offset of -6 (CST), results in a timestamp of 17:25:48.

2. It appends to the timestamp the offset to the current time on the computer, so the example above becomes 17:25:48-5:00 (i.e., 12:25:48 CDT).

3. The TimeZoneOffset is set to -6.

4. Apparently, Preview applies both the offset included with the timestamp and the TimeZoneOffset when it displays the Original Date, resulting in the time displaying as 6:25:48. (I haven't imported the pics into Aperture yet, so I don't have any observations about it.) I have not seen any problem with the minutes or seconds being wrong in Preview.

5. When I exported all 1313 files, the first 3 had the timestamp of the 4th file (38 seconds after the first); the rest were okay.

6. When I re-exported only the first 3, the timestamps were correct.

These last two observations lead me to think that there might be some kind of array size problem in HoudahGeo that needs to be checked out.

This whole exercise was made even more confusing because my camera is set to Central Standard Time, I shot the pictures in Greece (Eastern European Summer Time), and now on my computer at home it is Central Daylight Time. Once I sorted out what the times should be in each location, I was able to decipher what HoudahGeo was doing.

Hope this helps anyone who is still confused about the timestamps. I'll check back to see if there is any response concerning the possible array size problem.


0 0
houdah
Hi!

2. This should not happen. HoudahGeo should not append a suffix to the timestamp. The computer's time zone should have no influence on the whole process. I suppose this suffix was appended by the software you are using to view EXIF data.

Could you send me a file affected by this so I can verify?

5. & 6. Are you using the registered version of HoudahGeo? The demo version would export only 3 images at a time.

A discrepancy should appear only if you specified one as camera clock error. Otherwise the timestamp should remain unchanged. The only thing that "happens" to it is that it is written out along with the time zone information.

Best,
Pierre Bernard
Houdah Software s.à r.l.
Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0
crfrancis
I have a different time-stamp problem.

On importing my images into Aperture I have manually changed the time-stamp and time zone by batch change of meta-data. I was on a trip spanning many time zones (from +2 to +8 to +10 to -12 and back again). Also, although I changed the camera's time I didn't always do it in synchronism with the actual time zone changes.

Furthermore, both my wife and I took pictures with 2 different DSLR's (with non-identical time settings) and all images were imported into Aperture (at least they are distinguishable, both by the camera model and by the file naming convention).

I had to change the image time stamps otherwise they got way out of sequence.

When I look at the EXIF data in Aperture all looks fine, e.g. a sequence of images at
07/06/2008 18:02:33 HST [NB: I use the standard notation dd/mm/yyyy]
07/06/2008 18:02:42
07/06/2008 18:08:45
07/06/2008 18:09:03
07/06/2008 18:36:54

The images, after import (with a -167 second camera offset) into HoudahGeo are timetagged thus:

[file name | original timetag | HoudahGeo timetag]
RF 082539 | 07/06/2008 18:02:33 | 9/06/08 04:05:20
RF 082540 | 07/06/2008 18:02:42 | 9/06/08 04:05:29
RF 082541 | 07/06/2008 18:08:45 | 8/06/08 06:11:12 <- huh?
RF 082542 | 07/06/2008 18:09:03 | 9/06/08 04:11:50
RF 082543 | 07/06/2008 18:36:54 | 9/06/08 04:39:41
...
RF 082554 | 07/06/2008 18:44:13 | 8/06/08 06:47:00 <- another odd one
...

What's going on?

cheers,
Richard



0 0
houdah
Hi!

HoudahGeo's camera time zone settings apply only if the image's EXIF does not contain time zone offset information.

Thus if Aperture has written time zone offset information to the files, you amy safely ignore HoudahGeo's setting.

If Aperture has only changed times to be uniform, but not written time zone information, you need to tell HoudahGeo the time zone the images had been changed to.

HoudahGeo needs all images in a project to have the same camera time zone.

As you have batches with differing settings, you may want to create separate HoudahGeo projects, each with the appropriate settings. You may then, in each project, chose to write the time stamp and time zone information to the EXIF tags.

Now you may import the updated images into a common project. The time zone information in the EXIF tags will take precedence over that merged project's settings.

Best,
Pierre Bernard
Houdah Software s.à r.l.
Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0
crfrancis
Well I did sort of guess that I could only handle consistent sets of images ;-) So obviously I chose a subset with consistent times. There was no time zone set in the EXIF data for those examples I gave, except that "Image Date" had HST appended. The 2 odd images had no apparent inconsistency in the EXIF data (this is all according to Aperture).

So essentially I'm seeing inconsistency in treatment of some images compared to others, and I see no reason why.

By the way, the time and time zone manipulations I made were after import to Aperture, using Aperture's tools (maybe that was obvious).

cheers,
Richard

0 0
houdah
Hi!

Could you please email me a sample of an image that is handled as expected as well as a sample of an image that causes problems?

The support email address is support.houdahspot [at] houdah [dot] com

Best,
Pierre Bernard
Houdah Software s.à r.l.
Houdah Software s. à r. l.
https://www.houdah.com

HoudahGeo: One-stop photo geocoding
HoudahSpot: Advanced file search utility
Tembo: Easy and effective file search
0 0