Modify

Opened 7 years ago

Closed 7 years ago

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

Change History (27)

by progserega@…, 7 years ago

Attachment: 1_before_press_next.png added

by progserega@…, 7 years ago

Attachment: 2_after_press_next.png added

comment:1 by skyper, 7 years ago

Component: CoreCore image mapping
Version: tested

comment:2 by Don-vip, 7 years ago

Cc: holgermappt added

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

comment:3 by Klumbumbus, 7 years ago

Keywords: regression added

comment:4 by holgermappt, 7 years ago

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 by Don-vip, 7 years ago

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 by holgermappt, 7 years ago

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 by holgermappt, 7 years ago

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

by holgermappt, 7 years ago

Attachment: ticket_14209.patch added

Patch to fix the issue.

by holgermappt, 7 years ago

Attachment: 0MbEfj1S--.1.jpg added

Image taken with OsmAnd audio/video plugin.

comment:8 by Don-vip, 7 years ago

Milestone: 17.01

comment:9 by Don-vip, 7 years ago

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 by Don-vip, 7 years ago

thanks! :)

by progserega@…, 7 years ago

Attachment: josminfo.png added

Break date in new version of josm

by progserega@…, 7 years ago

Attachment: exifinfo.png added

Propertly date in image get by exiftran tool

by progserega@…, 7 years ago

Attachment: images.tar.gz added

Arhive with photo images, illustrated bad sequince

comment:11 by anonymous, 7 years ago

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 7 years ago by stoecker (previous) (diff)

comment:12 by anonymous, 7 years ago

Version: testedlatest

comment:13 by progserega@…, 7 years ago

All images in josm have one date-time timestamp.

comment:14 by holgermappt, 7 years ago

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.

in reply to:  14 comment:15 by Don-vip, 7 years ago

Replying to holgermappt:

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

Agreed :)

comment:16 by Don-vip, 7 years ago

Resolution: fixed
Status: reopenedclosed

In 11514/josm:

fix #14209 - EXIF: prefer DATETIME over DATETIME_DIGITIZED

by holgermappt, 7 years ago

Attachment: 7VWFOryj--.1.jpg added

Much smaller image for unit test.

comment:17 by holgermappt, 7 years ago

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 by Don-vip, 7 years ago

Ok thanks :)

comment:19 by progserega@…, 7 years ago

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. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.