[PATCH] in new version (11427) of josm images with geo-tags sort by names, but not by time in exif

[progserega@…]

Steps to reproduce:

1. Open josm
2. Open images with geo-tags (created by osmand ​http://osmand.net/ on android smartphone)
3. select image on map
4. press key "next" on sub-window with image.
5. result - next image selected NOT by time modificaton (by name?). Next image showing in other place, not as sequence.

It is very bad.

I find old version of josm (9329) - try reproduce - and in this version all work fine: key "next" show next image in sequence by time modification of image. Image showing as sequence - how I shot it - step by step.

[Don-vip]

@holgermappt: I have applied #14181, maybe you would like to give a look at this one? :)

[holgermappt]

The images are sorted in the constructor with Collections.sort(data). That didn't change between 9329 and 11427. I would say that calls ImageEntry.compareTo(), which compares the EXIF times, type Date. So it should be sorted by GPS time. The patch in #14181 doesn't change the order of the images, but maybe there is some unintended side effect.

Do you have a few images for a test? Low resolution is preferred. What are the file names and what is the order you expect? Is it just the next image after you selected the first by clicking on it in the map or does it happen too if you continue to use the next button in the image viewer? Does the back button select the previously selected image (at an other place) or the one that is next to the current one?

[Don-vip]

I didn't mean I though it was a regression from your patch as I merged it after the release, only that you know the code of this feature probably better than me :)

[holgermappt]

I renamed some images of a sequence, but the order is still right. Is someone else able to reproduce this?

The change in #13668/r11037 might be related, but we need sample images to check.

[holgermappt]

Problem found: r9499/#11685, file src/org/openstreetmap/josm/tools/ExifReader.java line 58:

                    if (tag.getTagType() == ExifIFD0Directory.TAG_DATETIME /* 0x0132 */ ||
                        tag.getTagType() == ExifSubIFDDirectory.TAG_DATETIME_DIGITIZED /* 0x9004 */) {
                        if (dateStr != null) {
                            // prefer TAG_DATETIME_ORIGINAL
                            dateStr = tag.getDescription();
                        }

That doesn't prefer TAG_DATETIME_ORIGINAL as the comment says, it ignores TAG_DATETIME if TAG_DATETIME_ORIGINAL is not set, which is the case for the OsmAnd images (plugin audio/video notes, unselect "system camera app"). See attachment 0MbEfj1S--.1.jpg.

So the fix is obviously this:

                        if (dateStr == null) {

[holgermappt]

Patch to fix the issue.

[holgermappt]

Image taken with OsmAnd audio/video plugin.

[Don-vip]

In 11484/josm:

fix #14209 - prefer TAG_DATETIME_ORIGINAL (patch by holgermappt, regression from r9499) + add non-regression unit test

[Don-vip]

thanks! :)

[progserega@…]

Break date in new version of josm

[progserega@…]

Propertly date in image get by exiftran tool

[progserega@…]

Arhive with photo images, illustrated bad sequince

[anonymous]

In new versin 11503 bug not fixed.

I found, that exif date is bad in josm. This is illustrated by added screenshots:

josminfo.png​ (264.5 KB) - added by progserega@… 12 минут ago.

Break date in new version of josm

exifinfo.png​ (1.2 MB) - added by progserega@… 11 минут ago.

Propertly date in image get by exiftran tool

I add few photo images in arhive for testing bad sequince:
images.tar.gz​ (7.6 MB) - added by progserega@… 7 секунд ago.

Archive with photo images, illustrated bad sequence

[progserega@…]

All images in josm have one date-time timestamp.

[holgermappt]

The images have 0x0132/ModifyDate/DateTime/TAG_DATETIME (Tag ID/Exiftool Name/EXIF spec. name/Java constant) and 0x9004/CreateDate/DateTimeDigitized/TAG_DATETIME_DIGITIZED set. For 7VWFOryj--.1.jpg 0x9004/DATETIME_DIGITIZED comes first and is set to 2002:12:08 12:00:00, 0x0132/DATETIME comes second and is set to 2016:08:13 19:51:13. The ExifReader class takes whatever comes first, which is 2002:12:08 12:00:00. DATETIME_DIGITIZED is the same for all images, DATETIME is different and the real time, I guess. All the programs that I checked (Dolphin, Gwenview, showPhoto, GIMP) show DATETIME, so we should prefer that over DATETIME_DIGITIZED. I can prepare a patch if no one objects.

[Don-vip]

Replying to holgermappt:

we should prefer that over DATETIME_DIGITIZED. I can prepare a patch if no one objects.

Agreed :)

[Don-vip]

In 11514/josm:

fix #14209 - EXIF: prefer DATETIME over DATETIME_DIGITIZED

[holgermappt]

Much smaller image for unit test.

[holgermappt]

I attached an image which is much smaller than the original 7VWFOryj--.1.jpg that is used for the unit test (1.6MB -> 670byte; test/data/regress/14209/7VWFOryj--.1.jpg). The test fails for r11484 but passes with r11514.

The image meta-data of the images in images.tar.gz is wrong in a number of ways. DATETIME_DIGITIZED is set to the wrong value and should be in the ExifIFD directory but is in IFD0. The current implementation covers all that cases.

I'm working on a patch that uses the right SUBSECOND field and refactores the code in ExifReader.java and ImageEntry.java. I will open a new ticket once it is ready.

[Don-vip]

Ok thanks :)

[progserega@…]

Thanks very mach!