One of the most useful features of this very interesting application is its capacity to catalog photos based on GPS position and date, which it - taking it together - translates into “events”. Problem is it does not utilize the correct DATE. The “correct” date - the one to be used - should - OF COURSE - be either “ EXIF image acquisition date” OR (less desirable) “ GPS date/time”. But - as it looks - Tonfotos uses something else (NEITHER the GPS date/time NOR the EXIF acquisition date/time). Therefore some photos get classified into a wrong “event”.
I took my photos I took with my Samsung S 9, and several - taken on the same day and around the same location - get classified into TWO different events, just because Tonfoto “thinks” they were taken on different dates, based on something which is NEITHER their EXIF date/time NOR their GPS date/time.
Photos archived by "Event" based on wrong date
For example, a photo I took in Lugo (Spain) on 28/07/2022 at 19:47:20 (EXIF data) , identified by the following GPS date/time: 2022:07:28 17:47:11 gets classified by Tonfoto under “Lugo 29 july”.
Well, first of all the file (photo) I mentioned is just ONE of the MANY which get archived incorrectly (wrong date). Therefore, there are several places where I stayed for just one day, but their photos get splitted into two following “events” (based on wrong date for some). And I was never taking photos late in the evening (where GPS date and Exif date might differ). In any case, going back to the file I mentioned, the “File Information” provided by Tonfoto is:
Created: 28/7/2022 21:47:20
Modified: 28/7/2022 19:47:20 (this is the date/time the photo was shot, according to its EXIF and my own memory)
DateTimeOriginal 28/7/2022 21:47:20 (this is totally untrue; the GPS timestamp is 17:47:11 according to ACDsee)
CreateDate 28/7/2022 21:47:20
Notice that all data point to July the 28th, whereas Tonfoto puts this photo under the event “July 29, 2022 Lugo”.
Of course I can send you this photo, or any other of the MANY photos which are “misplaced”. But to do that I need an email address: I was not able to add an image to this post (I understand I should upload it first, to some online server; so I’d rather send it by email). Thanks, Marco
- Edited
jk1772 interesting, so problem is not in the picking right date of many, looks like there is mistake in parsing EXIF.
Yes, photo samples would definitely help. Please send couple to andrey @ tonfotos.com
(update)
Well, actually there seems to be two problems: EXIF parsing, as well as events clusterization. I’m looking forward for samples. Thanks!
- Edited
jk1772 thank you very much for providing photo samples.
Now I can examine them myself. I don’t have ACDsee, I am using exiftool as a reference, which highly popular open source script for EXIF examining, it can be definitely considered as THE reference for such cases.
First of all, it is clear that data in EXIF of those photos are not consistent. Let’s take one from Lugo you referred above.
ExifTool Version Number : 12.30
File Name : 2022-07-28 --- 19-47-20.jpg
Directory : .
File Size : 1692 KiB
File Modification Date/Time : 2022:08:04 18:15:31+03:00
File Access Date/Time : 2022:08:05 10:36:19+03:00
File Inode Change Date/Time : 2022:08:05 10:36:18+03:00
File Permissions : -rw-r--r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
Exif Byte Order : Little-endian (Intel, II)
Orientation : Rotate 90 CW
Y Cb Cr Positioning : Centered
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Make : samsung
Camera Model Name : REDACTED
Software : REDACTED
Modify Date : 2022:07:28 19:47:20
Exposure Time : 1/50
F Number : 1.5
Exposure Program : Program AE
ISO : 200
Exif Version : 0220
Date/Time Original : 2022:07:28 19:47:20
Create Date : 2022:07:28 19:47:20
Shutter Speed Value : 1/50
Aperture Value : 1.5
Brightness Value : 0.61
Exposure Compensation : 0
Max Aperture Value : 1.5
Metering Mode : Center-weighted average
Flash : No Flash
Flashpix Version : 0100
Components Configuration : Y, Cb, Cr, -
Focal Length : 4.3 mm
Sub Sec Time : 0425
Sub Sec Time Original : 0425
Sub Sec Time Digitized : 0425
User Comment :
Color Space : sRGB
Exif Image Width : 4032
Exif Image Height : 1960
Scene Type : Unknown (.)
Custom Rendered : Normal
Exposure Mode : Auto
White Balance : Auto
Digital Zoom Ratio : undef
Focal Length In 35mm Format : 26 mm
Scene Capture Type : Standard
Contrast : Normal
Saturation : Normal
Sharpness : Normal
Image Unique ID : REDACTED
Interoperability Index : R98 - DCF basic file (sRGB)
Interoperability Version : 0100
GPS Version ID : 2.2.0.0
GPS Latitude Ref : North
GPS Longitude Ref : West
GPS Altitude Ref : Above Sea Level
GPS Date Stamp : 2022:07:28
GPS Time Stamp : 17:47:11
GPS Processing Method : CELLID
Compression : JPEG (old-style)
Thumbnail Offset : 1179
Thumbnail Length : 54091
Image Width : 4032
Image Height : 1960
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Time Stamp : 2022:07:28 20:47:20+03:00
MCC Data : 214
Aperture : 1.5
Image Size : 4032x1960
Megapixels : 7.9
Scale Factor To 35 mm Equivalent: 6.0
Shutter Speed : 1/50
Create Date : 2022:07:28 19:47:20.0425
Date/Time Original : 2022:07:28 19:47:20.0425
Modify Date : 2022:07:28 19:47:20.0425
Thumbnail Image : (Binary data 54091 bytes, use -b option to extract)
GPS Altitude : 497 m Above Sea Level
GPS Date/Time : 2022:07:28 17:47:11Z
GPS Latitude : 43 deg 0' 35.64" N
GPS Longitude : 7 deg 33' 39.79" W
Circle Of Confusion : 0.005 mm
Field Of View : 69.4 deg
Focal Length : 4.3 mm (35 mm equivalent: 26.0 mm)
GPS Position : 43 deg 0' 35.64" N, 7 deg 33' 39.79" W
Hyperfocal Distance : 2.48 m
Light Value : 5.8As you can see, Date/Time Original and Create Date do match, but they differ from Time Stamp and GPS Date/Time
Clearly Tonfotos takes one of first two as a reference and assumes it as image taking time (Created). The difference that you observe is coming from the fact that Created is displayed in your local time zone, while EXIF data is displayed in this table in ISO format (GMT time zone).
Same discrepancy I see on other photos you provided - difference is about 2 hours and 2 minutes between regular timestamp and GPS timestamp.I don’t know the reason, but I can guess that the phone had wrong time zone setup during shooting (it was displaying correct local time, but wrong GMT time was used anyway).
Does this make sense to you? Before getting to second part of your question (wrong Event time) let us first finish with this part.
Andrey
Hi, Andrey. Well, I had not changed the time-zone of my phone because I never do that (it adjusts authomatically, when needed), and - in this case - there was no need (I was in Spain, which is in the same time-zone, CET, of my home-country, and daylight saving is just the same).
As to the timings appearing in the EXIF data you attached, the difference between camera (phone) time (Date/Time original) and GPS date/time appears to be 2 hours. Which is fine, since GPS date/time should be Greenwich time (UT),
and now CET (normally UT+1h) is affected by daylight saving. So 1h+1h.
As to “Time Stamp” I don’t know what it is: it is explicitly indicated as the result of the addition of 3 hours to the GPS date/time. Which does not make any sense to me.
In any case, nowhere and nothing indicates that the photo was taken on the following day (July 29th), therefore why does Tonfotos classify it under the Lugo Jul 29 “event” remains unexplicable to me.
Sorry for being this useless … Hope you can fix it nonetheless.
If you like, I can take some further photos with my cellphone at different times in the afternoon, download them to my PC and leave them completely untouched (no filename change), for Tonfoto to organize them. This would rule-out any hidden issue related to file-renaming by ACDsee. But I don’t think ACDsee can accidentally corrupt EXIF data.
Kind Regards, Marco.
jk1772 after some research, I can see the issue. Tonfotos considers that Create Date is in UTC, but apparently, this is not always the case and standard is pretty vague on that part. Obviously in your case it is in local time, and what is more, OffsetTime is not specified, so this time is useless, since we just don’t know its real Time Zone. In this situation GPS time should be getting a priority. This will be fixed in next version.
jk1772 In any case, nowhere and nothing indicates that the photo was taken on the following day (July 29th), therefore why does Tonfotos classify it under the Lugo Jul 29 “event” remains unexplicable to me.
That is a separate issue. Tonfotos groups photos together into events, and this event actually take some time. It can last up to 6 hours. In your case, I guess, it joined together several photos from July 28 and July 29, since they were taken not far away from each other both in space and in time. And for some reason it decided to assign 29th as the main date for this event, probably because mosts of photos were taken on 29th.
Please check if that is the case.
Andrey I guess, it joined together several photos from July 28 and July 29, since they were taken not far away from each other both in space and in time. And for some reason it decided to assign 29th as the main date for this event, probably because mosts of photos were taken on 29th.
Please check if that is the case
I did check: my photos/videos were all taken in Lugo on July 28th. But tonfotos puts about 90 (all taken after exif hour 19:00) under the label “Lugo jul 29th” and another 75 (taken between 12:00 and 17:50) under “Lugo Jul 28th”.
Regarding Tonfotos “Logics” in creating an “event”, as a compulsive traveller I would suggest (wishing is so much easier than actual programming, of course …) that Tonfotos created a NEW “event” each time that the time-interval between last image and the next one is more than 6 hours AND/OR the GPS distance between one image’s location and the next one is more than 10 Km.
Putting no limits to my wishes, I would also wish that such time/space intervals determining “events” were “settable” by the user.
Finally, I would wish that the “Title” assigned to each event by Tonfoto, would just be a generic “Date … Event #”, leaving it to the user to edit such Title according to her/his taste/needs.
Best Regards, and my compliments for your very promising software in any case !
Marco
jk1772 thank you for your thoughts! Your ideas are quite similar to ones we discussed in another topic here. I keep all these in mind and keep thinking about ideas how to improve clusterization algorithm.
Anyway, wrong recongition of EXIF dates - is a separate issue, and it is planned for fix in nearest release. Please stay tuned.
Andrey
Thanks, Andrey ! I saw that - in the topic you mentioned - the “clusterization” issue had not only been discussed, but you possibly solved it already, though just “experimentally” ! If possible, I would be glad to try that software, me too. Unless Tonfotos’ next Beta iterations will very soon include it. Of course I am staying tuned ! Relyable and adjustable clusterization woud be a winner. Good luck !!
New version contains fixes regarding dates and time zones, both the way it is displayed in File Info pane (now you can view raw data from EXIF without post-processing), and the way those dates have been used for determining actual photo creation time.
In order for changes to take effect, you need to:
- Update application to latest version
- Reindex your photos. The easiest way is to select them with Ctrl+A and then chose “Re-index photos” from context menu.
That should at least fix wrong photo creation time. Please check. I would really appreciate your feedback. Also please check if you still experience wrong clusterization issue in the new version.
I have to close this topic as it was mostly addressed with last release. If there will more issues on that topic, please feel free to open new discussion with more specifics.