Setting the direction of a panned 360 photo causes a counterintuitive result

[bartosomail@…]

What steps will reproduce the problem?

1. Load a 360 photo in a geotagged image layer
2. in the Geotagged image window, right click and drag the image to the left, until the direction of the image pointer on the map has turned 90° clockwise

3. Hold the control key down and click on the map o a point aligned with the current direction of the image

What is the expected result?

The direction of the pointer doesn't change

What happens instead?

The direction of the pointer turns 90° clockwise

Please provide any additional information below. Attach a screenshot if possible.

This happens because the direction change to the clicked point is always calculated relative to the centered direction of the 360 image, not to the currently displayed direction.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-11-04 00:56:52 +0100 (Thu, 04 Nov 2021)
Revision:18309
Build-Date:2021-11-04 02:31:03
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18309 en_GB) Windows 10 64-Bit
OS Build number: Windows 10 Home 2009 (19043)
Memory Usage: 3076 MB / 4068 MB (1962 MB allocated, but free)
Java version: 17.0.1+12-LTS-39, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 3840×2160 (scaling 2.50×2.50)
Maximum Screen Size: 3840×2160
Best cursor sizes: 16×16→64×64, 32×32→64×64
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: en_GB
Numbers with default locale: 1234567890 -> 1234567890

Plugins:
+ Mapillary (2.0.0-alpha.40.a)
+ QuickLabel (23)
+ SimplifyArea (35640)
+ apache-commons (35524)
+ apache-http (35589)
+ editgpx (35562)
+ ejml (35458)
+ geotools (35458)
+ jna (35662)
+ jts (35458)
+ measurement (35640)
+ merge-overlap (35640)
+ photo_geotagging (35783)
+ photoadjust (35770)
+ reltoolbox (35829)
+ reverter (35732)
+ rex (53)
+ undelete (35640)

Tagging presets:
+ D:\OSM\JOSM\presets\cai_josm_preset-master\cai.xml
+ https://josm.openstreetmap.de/josmfile?page=Presets/Mountains&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Presets/ParkingLanes&zip=1
+ https://raw.githubusercontent.com/yopaseopor/traffic_signs_preset_JOSM/master/CH.zip
+ https://raw.githubusercontent.com/yopaseopor/traffic_signs_preset_JOSM/master/IT.zip

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/DestinationSignRelation&zip=1
+ https://raw.githubusercontent.com/species/josm-preset-traffic_sign_direction/master/direction.mapcss
- https://josm.openstreetmap.de/josmfile?page=Styles/Osmc&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/MaxspeedIcons&zip=1
+ https://raw.githubusercontent.com/yopaseopor/traffic_signs_style_JOSM/master/Styles_Traffic_signs_EUR.zip
+ https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes&zip=1

Last errors/warnings:
- 00247.029 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 00247.038 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 00247.046 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 00247.054 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 00247.062 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 00247.072 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 00247.080 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 00247.089 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 00247.098 E: Error reading EXIF from file: com.drew.metadata.MetadataException: Tag 'GPS Latitude' has not been set -- check using containsTag() first
- 23083.242 W: java.net.SocketTimeoutException: Read timed out. Cause: java.net.SocketTimeoutException: Read timed out

[gillux]

Patch to fix the issue

[gillux]

Hello, I was also affected by this issue and I wrote a simple patch to address it. Please have a look.

The arrow direction does not display the exif direction angle, instead it displays exif angle + image viewer angle. So when the plugin sets the exif angle from the arrow direction, it needs to substract the image viewer angle from it.

[GerdP]

I've no acces to 360 photos but I wonder if the patched code may result in negative direction values. There is code to add 360 if direction is below 0, but what if the values is below -360 when viewerAngle is near 360?

[gillux]

I see. I will double check that.

You can find and download 360 photos from ​https://panoramax.fr/

[gillux]

what if the values is below -360

It turns out the value is never negative.

double direction = photoLL.bearing(mouseLL) * 360.0 / 2.0 / Math.PI - viewerAngle

In that line, photoLL is of type ILatLon, and ILatLon.bearing() always returns a positive value, ever since its first implementation. Which means direction will always be higher than -360.

It looks like the existing check

        if (direction < 0.0) {
            direction += 360.0;

was never triggered, and my patch made it useful.

If you’d like, for safety I can make the boundary check work with any value, with something like:

direction %= 360.0;
if (direction < 0) {
    direction += 360.0;
}

[GerdP]

Thanks for checking. I find quite a few places in JOSM core or plugins where this problem is solved in various slightly different ways.
In plugins\photoadjust\PhotoPropertyEditor.java I see e.g.

                Double imgDir = getDoubleValue(direction);
                if (imgDir != null) {
                    if (imgDir < 0.0) {
                        imgDir %= 360.0; // >-360.0...-0.0
                        imgDir += 360.0; // >0.0...360.0
                    }
                    if (imgDir >= 360.0) {
                        imgDir %= 360.0;
                    }
                }

Maybe it would be good to implement a really robust (and possibly simpler) solution in class Utils?

[gillux]

Maybe it would be good to implement a really robust (and possibly simpler) solution in class Utils?

Yes, certainly. This could actually be a one-liner like direction = (direction + 360.0) % 360.0. But I believe this kind of maintenance work is outside of the scope of this ticket. Also, wouldn’t it break compatibility with old versions of JOSM?

I suggest you apply my patch first, and later factorize the boundary check code everywhere it’s relevant.

[GerdP]

OK, will do the commit+release today.

[GerdP]

Sorry, I can't do the release because the build seems to require perl (I am on Windows). I know I can install perl on Windows but I don't want it.
Hope Dirk can help.

[stoecker]

Hmm. Can you be a bit more specific what exactly? Builds should not need perl. Perl scripts are only to make life easier for us lazy guys.

[GerdP]

The build runs plugins\photoadjust\i18n\build-i18n.xml which executes perl.

[stoecker]

It shouldn't... Again a non-standard build... Aaah. Can you get rid of that and switch to defaults like most plugins?

[GerdP]

remove some targets

[GerdP]

I can build when I apply this patch. No idea if the result is usable.

[stoecker]

Patch looks good to me. Output size is nearly the same as last. Files are similar. Everything fine I'd say.

[GerdP]

OK. Should I commit both patches?

[stoecker]

Sure.

[GerdP]

In 36463/osm:

fix #21523: Setting the direction of a panned 360 photo causes a counterintuitive result

• apply photoadjust_21523_fix_direction_360.patch by gillux: "The arrow direction does not display the exif direction angle, instead it displays exif angle + image viewer angle. So when the plugin sets the exif angle from the arrow direction, it needs to substract the image viewer angle from it."
• remove targets from build.xml which invoke perl or overwrite the code to build javadoc

[GerdP]

In 36464/osm:

fix #21523: Setting the direction of a panned 360 photo causes a counterintuitive result
release