Broken image ordering for OpenCamera subsecond sequences

[blaueente]

Basic information

• Release version: 0.11.1
• System: Linux
• Capture Device: Android OpenCamera

When capturing with OpenCamera, if the app takes photos less than 1 second apart for whatever reasons, it attaches a number in partentheses to the filename. Apparently the files are also sorted wrongly in the file system unexpectedly.
Now, this wrong order is apparently also used when uploading the sequence, resulting in something like three steps forward -- one step backword -- one large step forward -- three steps forward -- etc.
as can be seen in the resulting sequence:
https://www.mapillary.com/app/?pKey=1679786299214859

My speculation is that the file sorting does not properly take the exif subsecond entry into account, specifically if it conflicts with the file order.
In that case, the solution would be to use the exif subsecond entry when sorting, and ignoring the filenames.

excerpt of file listing:

$ ls
...
IMG_20231115_170430.jpg
IMG_20231115_170431 (1).jpg
IMG_20231115_170431.jpg
IMG_20231115_170432.jpg
IMG_20231115_170433.jpg
IMG_20231115_170434 (1).jpg
IMG_20231115_170434.jpg
IMG_20231115_170435.jpg
IMG_20231115_170436.jpg
IMG_20231115_170437 (1).jpg
IMG_20231115_170437.jpg
IMG_20231115_170438.jpg
IMG_20231115_170439.jpg
IMG_20231115_170440.jpg
IMG_20231115_170441 (1).jpg
IMG_20231115_170441.jpg
IMG_20231115_170442.jpg
IMG_20231115_170443.jpg
IMG_20231115_170444 (1).jpg
IMG_20231115_170444.jpg
IMG_20231115_170445.jpg
IMG_20231115_170446.jpg
IMG_20231115_170447 (1).jpg
IMG_20231115_170447.jpg

The exif data is correctly using Sub Sec Time.

$ exiftool IMG_20231115_170444.jpg | grep -i time
File Modification Date/Time     : 2023:11:15 17:04:44+01:00
File Access Date/Time           : 2024:05:20 19:25:16+02:00
File Inode Change Date/Time     : 2023:11:15 22:52:07+01:00
Date/Time Original              : 2023:11:15 17:04:44
Sub Sec Time Original           : 5010
Exposure Time                   : 1/200
Sub Sec Time                    : 5010
Sub Sec Time Digitized          : 5010
GPS Time Stamp                  : 16:04:44
Profile Date Time               : 2016:12:08 09:38:28
Date/Time Original              : 2023:11:15 17:04:44.5010
GPS Date/Time                   : 2023:11:15 16:04:44Z

$ exiftool IMG_20231115_170444\ \(1\).jpg | grep -i time
File Modification Date/Time     : 2023:11:15 17:04:44+01:00
File Access Date/Time           : 2024:05:20 19:25:16+02:00
File Inode Change Date/Time     : 2023:11:15 22:52:07+01:00
Date/Time Original              : 2023:11:15 17:04:44
Sub Sec Time Original           : 8207
Exposure Time                   : 1/200
Sub Sec Time                    : 8207
Sub Sec Time Digitized          : 8207
GPS Time Stamp                  : 16:04:44
Profile Date Time               : 2016:12:08 09:38:28
Date/Time Original              : 2023:11:15 17:04:44.8207
GPS Date/Time                   : 2023:11:15 16:04:44Z

[ptpt]

It prefers GPS Date/Time if it's available. In your case, the GPS timestamp has no subseconds.

We can use Date/Time Original as the secondary key for sorting, i.e. sort images by this tuple (GPS Date/Time, Date/Time Original (with subseconds), filename). Does it solve the issue?

[blaueente]

Your proposal sounds good to me, and I think it would solve the issue.

[blaueente]

Until this is fixed, I use the following workaround to rename the files to include the subseconds in a lexicographically sortable way:

exiftool -d IMG_%Y%m%d_%H%M%S%6f%%-c.%%e "-filename<SubSecDateTimeOriginal" .