Modify

Opened 11 months ago

Closed 10 months ago

Last modified 9 months ago

#14209 closed defect (fixed)

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

Reported by: progserega@… Owned by: team
Priority: normal Milestone: 17.01
Component: Core image mapping Version: latest
Keywords: image geo regression Cc: holgermappt

Description

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.

Attachments (8)

1_before_press_next.png (274.1 KB) - added by progserega@… 11 months ago.
2_after_press_next.png (265.7 KB) - added by progserega@… 11 months ago.
ticket_14209.patch (744 bytes) - added by holgermappt 10 months ago.
Patch to fix the issue.
0MbEfj1S--.1.jpg (35.3 KB) - added by holgermappt 10 months ago.
Image taken with OsmAnd audio/video plugin.
josminfo.png (264.5 KB) - added by progserega@… 10 months ago.
Break date in new version of josm
exifinfo.png (1.2 MB) - added by progserega@… 10 months ago.
Propertly date in image get by exiftran tool
images.tar.gz (7.6 MB) - added by progserega@… 10 months ago.
Arhive with photo images, illustrated bad sequince
7VWFOryj--.1.jpg (670 bytes) - added by holgermappt 10 months ago.
Much smaller image for unit test.

Change History (27)

Changed 11 months ago by progserega@…

Attachment: 1_before_press_next.png added

Changed 11 months ago by progserega@…

Attachment: 2_after_press_next.png added

comment:1 Changed 11 months ago by skyper

Component: CoreCore image mapping
Version: tested

comment:2 Changed 11 months ago by Don-vip

Cc: holgermappt added

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

comment:3 Changed 11 months ago by Klumbumbus

Keywords: regression added

comment:4 Changed 11 months ago by 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?

comment:5 Changed 11 months ago by 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 :)

comment:6 Changed 10 months ago by holgermappt

Owner: changed from team to progserega@…
Status: newneedinfo

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.

comment:7 Changed 10 months ago by holgermappt

Owner: changed from progserega@… to team
Status: needinfonew
Summary: in new version (11427) of josm images with geo-tags sort by names, but not by time in exif[PATCH] in new version (11427) of josm images with geo-tags sort by names, but not by time in exif

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) {

Changed 10 months ago by holgermappt

Attachment: ticket_14209.patch added

Patch to fix the issue.

Changed 10 months ago by holgermappt

Attachment: 0MbEfj1S--.1.jpg added

Image taken with OsmAnd audio/video plugin.

comment:8 Changed 10 months ago by Don-vip

Milestone: 17.01

comment:9 Changed 10 months ago by Don-vip

Resolution: fixed
Status: newclosed

In 11484/josm:

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

comment:10 Changed 10 months ago by Don-vip

thanks! :)

Changed 10 months ago by progserega@…

Attachment: josminfo.png added

Break date in new version of josm

Changed 10 months ago by progserega@…

Attachment: exifinfo.png added

Propertly date in image get by exiftran tool

Changed 10 months ago by progserega@…

Attachment: images.tar.gz added

Arhive with photo images, illustrated bad sequince

comment:11 Changed 10 months ago by anonymous

Resolution: fixed
Status: closedreopened

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

Break date in new version of josm Propertly date in image get by exiftran tool

Last edited 10 months ago by stoecker (previous) (diff)

comment:12 Changed 10 months ago by anonymous

Version: testedlatest

comment:13 Changed 10 months ago by progserega@…

All images in josm have one date-time timestamp.

comment:14 Changed 10 months ago by 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.

comment:15 in reply to:  14 Changed 10 months ago by Don-vip

Replying to holgermappt:

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

Agreed :)

comment:16 Changed 10 months ago by Don-vip

Resolution: fixed
Status: reopenedclosed

In 11514/josm:

fix #14209 - EXIF: prefer DATETIME over DATETIME_DIGITIZED

Changed 10 months ago by holgermappt

Attachment: 7VWFOryj--.1.jpg added

Much smaller image for unit test.

comment:17 Changed 10 months ago by 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.

comment:18 Changed 10 months ago by Don-vip

Ok thanks :)

comment:19 Changed 9 months ago by progserega@…

Thanks very mach!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.