Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect below sea level altitude #688

Open
Self-Perfection opened this issue Jul 5, 2019 · 4 comments
Open

Incorrect below sea level altitude #688

Self-Perfection opened this issue Jul 5, 2019 · 4 comments
Labels

Comments

@Self-Perfection
Copy link

ISSUE TYPE

  • Bug Report

GEEQIE VERSION

Geeqie 93e6dd0d
     Config results:
    -=-=-=-=-=-=-=-=-

Package:
  Name:          geeqie
  Version:       93e6dd0d

Architecture:
  UNIX:          yes
  Win32:         no (native: no)

Flags:
  Geeqie:        
  DEFS:          -DHAVE_CONFIG_H
  CPPFLAGS:      
  CFLAGS:        -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Werror -Wno-error=deprecated-declarations -Wno-error=sign-compare -Wno-error=return-type
  CXXFLAGS:      -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
  Gtk:           -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/libffi-3.2.1/include -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/libdrm -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -pthread 
  Glib:          -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
  Thread:        -pthread -lgthread-2.0 -lglib-2.0 
  Others:        -ljpeg -ltiff -llcms2  -lexiv2      

Localization:
  NLS support:   yes
  LINGUAS:        ar be bg ca cs da de el en_GB eo es et eu fi fr hu id it ja ko nb nl pl pt_BR ro ru sk sl sr@latin sr sv th tlh tr uk vi zh_CN zh_TW

Settings:
  Developer:     no
  Debug flags:   no
  Debug log:     no
  Deprecated:    no

Support:
  LCMS:          yes
  Exiv2:         yes
  Lirc:          no
  Clutter:       no
  Libchamplain:         disabled
  Libchamplain-gtk:     disabled
  Lua:           disabled
  FFmpegthumbnailer:    yes
  Pdf:           yes
  Heif:          yes

Documentation:
  Doxygen:       
  doc-tool:      /usr/bin/gnome-doc-tool

OS / DISTRIBUTION

Arch linux

SUMMARY

Geeqie shows altitude for all photos taken with Xioami Mi A1 as "below sea level". Digikam, Gwenview and exiftool correctly indicate it as above sea level.

STEPS TO REPRODUCE

Here is sample image:
IMG_20190604_101103_25%
This is how Geeqie parses metadata:
Screenshot_20190705_170912

@caclark
Copy link
Collaborator

caclark commented Jul 5, 2019

If you open View/Exif window you will see that there are two values for Exif.GPSInfo.AltitudeRef.
The spec. defines this field as a byte: 0 = above sea level, 1 = below sea level, other values = reserved. Therefore the second item is the correct one.

Geeqie makes only one call for each parameter, and in this case tests the received value for value == 0 (thus it sees 200/100 as below sea level).
I guess the test could be changed to value == 1, but I am not sure that is the right way to go.
If I have time I will try to find how the other programs handle this.

@mowgli mowgli added the bug label Aug 1, 2019
@gdt
Copy link
Contributor

gdt commented Nov 22, 2022

Two separate ideas:

  1. Given a spec defining 0 and 1 and everything else reserved, how about processing by checking first if the altituderef field is a byte, and then if so looking for 0 and 1 and handling those as is, and other values printing "invalid reference" for altitude ref? And printing invalid if the field is not a byte?

  2. exiftool -n -e prints GPS Altitude Ref : 0. But indeed geeqie's browser shows a field of type rational with 220/100 and a field of type byte with 0. So while this image has invalid exif, I wonder if it is reasonable to just ignore values of type rational. Alternatively, a simple "is there only one value" could be added, leading to "invalid reference".

I think the big question is how much workaround code should be added for invalid input.

@caclark
Copy link
Collaborator

caclark commented Nov 22, 2022

In #1034 @kha84 suggested using exiftool instead of exiv2. That would solve the problem - but unfortunately there is not a simple one-to-one correspondence between the two libraries.

@gdt
Copy link
Contributor

gdt commented Nov 23, 2022

And exiftool is in perl, which really doesn't seem ok to add.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants