Bug 418635 - Display of GPS Area Information does not respect EXIF specification
Summary: Display of GPS Area Information does not respect EXIF specification
Status: RESOLVED UPSTREAM
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: 18.04.0
Platform: Debian stable Linux
: NOR major with 20 votes (vote)
Target Milestone: ---
Assignee: John Clark
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-08 18:19 UTC by linadmin
Modified: 2021-12-01 19:03 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Gwenview GPS Area Information (10.60 KB, image/png)
2021-11-18 18:50 UTC, John Clark
Details
Screenshot of erroneous display (1.51 MB, image/png)
2021-11-29 17:33 UTC, linadmin
Details
jpg with embedded GPS erroneously displayed (354.65 KB, image/jpeg)
2021-11-29 17:36 UTC, linadmin
Details
Screenshot of the GPSAreaInformation tag in Gwenview 21.08.3 (109.89 KB, image/jpeg)
2021-11-30 04:44 UTC, phrxmd
Details

Note You need to log in before you can comment on or make changes to this bug.
Description linadmin 2020-03-08 18:19:26 UTC
SUMMARY
I appreciate very much all efforts taken by the KDE team and use Gwenview almost every day.

The left panel with meta data correctly displays all Information I do need like GPS Longitude & Latidude. However the field  "GPS Area Information" is displayed as a huge block of integer numbers 0-255 instead of the significant text.

It's a shame that the detailed documentation at https://www.exiv2.org/ has not been consulted. It says that this field is coded as XMPtext and the libraries in their github have conversion routines from/to ISO and ASCII text.
 
STEPS TO REPRODUCE

1. Start gwenview with loading a jpg-photo that contains GPS coordinate data and   "GPS Area Information"

2. Enable left panel for Meta Information. If "GPS Area Information" is not displayed, click on "More" and enable the box for "GPS Area Information" 

OBSERVED RESULT
"GPS Area Information" is displayed but as a bunch of integers.

EXPECTED RESULT
"GPS Area Information" is displayed as text string.


SOFTWARE/OS VERSIONS
Debian Buster
gwenview 18.04.0
KDE Frameworks 5.54.0
Qt 5.11.3 (kompiliert gegen 5.11.3)
Das xcb Fenstersystem
Comment 1 phrxmd 2021-11-15 20:01:10 UTC
Can you provide a sample file? I wanted to see if I can reproduce this and went through a bunch of my own photos, as well as sample JPEGs from places like https://github.com/ianare/exif-samples/tree/master/jpg/gps, and didn't find any that have this particular tag.
Comment 2 John Clark 2021-11-18 18:50:18 UTC
Created attachment 143703 [details]
Gwenview GPS Area Information

I have just attempted this with an image of my own. I did not have any images with this data so I applied my own tags using exiv2:

exiv2 -M"set Exif.GPSInfo.GPSAreaInformation Somewhere cool in space" ./test.jpg

and then opened in in Gwenview 21.08.3 and the tag shows correctly.
Comment 3 John Clark 2021-11-18 18:51:27 UTC
Marking as NEEDSINFO until we can get an example where this doesn't work.
Comment 4 linadmin 2021-11-29 17:33:04 UTC
Created attachment 144069 [details]
Screenshot of erroneous display
Comment 5 linadmin 2021-11-29 17:36:19 UTC
Created attachment 144070 [details]
jpg with embedded GPS erroneously displayed
Comment 6 linadmin 2021-11-29 17:38:20 UTC
Please find enclosed jpg-image with embedded GPS info which is erroneously displayed as shown in enclosed screenshot gwenview-erroneous-display.png
Comment 7 linadmin 2021-11-29 22:38:08 UTC
(In reply to Philipp Reichmuth from comment #1)
> Can you provide a sample file? I wanted to see if I can reproduce this and
> went through a bunch of my own photos, as well as sample JPEGs from places
> like https://github.com/ianare/exif-samples/tree/master/jpg/gps, and didn't
> find any that have this particular tag.

None of the fotos in above link do have embedded "GPS Area Information"
Comment 8 linadmin 2021-11-29 22:44:06 UTC
(In reply to John Clark from comment #2)
> Created attachment 143703 [details]
> Gwenview GPS Area Information
> 
> exiv2 -M"set Exif.GPSInfo.GPSAreaInformation Somewhere cool in space" ./test.jpg
> 
> and then opened in in Gwenview 21.08.3 and the tag shows correctly.

For me that exiv2 command does not work at all?
Maybe that with correct parameters it does set the text in a different was?
Comment 9 phrxmd 2021-11-30 04:41:07 UTC
(In reply to linadmin from comment #6)
> Please find enclosed jpg-image with embedded GPS info which is erroneously
> displayed as shown in enclosed screenshot gwenview-erroneous-display.png

For me Gwenview displays the GPS Area Information in that file just fine. I can post a screenshot if you want. 
This is with Gwenview 21.08.3 on OpenSUSE Tumbleweed.

(In reply to linadmin from comment #8)
> (In reply to John Clark from comment #2)
> > Created attachment 143703 [details]
> > Gwenview GPS Area Information
> > exiv2 -M"set Exif.GPSInfo.GPSAreaInformation Somewhere cool in space" ./test.jpg
> > 
> > and then opened in in Gwenview 21.08.3 and the tag shows correctly.
> 
> For me that exiv2 command does not work at all?
> Maybe that with correct parameters it does set the text in a different was?

It looks like it. Check out the length of the GPSAreaInformation field (266 vs. 46, 27 without the charset tag). 

# exiv2 -g GPSAreaInformation P1020755A.JPG
Exif.GPSInfo.GPSAreaInformation              Undefined 266  charset=Unicode Dampferanlegestelle
# cp P1020755A.JPG exif-gps-area-information-test.jpg
# exiv2 -M"set Exif.GPSInfo.GPSAreaInformation charset=Unicode Dampferanlegestelle" ./exif-gps-area-information-test.jpg
# exiv2 -g GPSAreaInformation ./exif-gps-area-information-test.jpg
Exif.GPSInfo.GPSAreaInformation              Undefined  46 charset=Unicode Dampferanlegestelle
Comment 10 phrxmd 2021-11-30 04:44:40 UTC
Created attachment 144076 [details]
Screenshot of the GPSAreaInformation tag in Gwenview 21.08.3

Here's how Gwenview displays the tag on my system, it looks OK.
Maybe the issue is with a particular combination of libraries and tags?
Comment 11 linadmin 2021-11-30 09:30:39 UTC
(In reply to Philipp Reichmuth from comment #10)
> Created attachment 144076 [details]
> Screenshot of the GPSAreaInformation tag in Gwenview 21.08.3
> 
> Here's how Gwenview displays the tag on my system, it looks OK.
> Maybe the issue is with a particular combination of libraries and tags?

Thousand thanks for your efforts. Indeed your version does display it in a different way from my slightly older version.
I therefore installed Debian Bullseye which has Gwenview 20.12.3 and the display indeed looks as you showed it.

However, I do not see why it should display the additional information that the  GPSAreaInformation is in such and such character coding. It does not show that on City and City2 which also can be Unicode and which have already worked as expected in older versions.

I conclude that the Gwenview project management it too lousy to believe: They _somehow_ worked at the bug without looking how it has been done on other fields.

Therefore I revise my initial bug report, saying that "it now does show unnecesary character coding". :-(
Comment 12 phrxmd 2021-11-30 10:32:17 UTC
(In reply to linadmin from comment #11)
> (In reply to Philipp Reichmuth from comment #10)
> > Created attachment 144076 [details]
> > Screenshot of the GPSAreaInformation tag in Gwenview 21.08.3
> > 
> > Here's how Gwenview displays the tag on my system, it looks OK.
> > Maybe the issue is with a particular combination of libraries and tags?
> 
> Thousand thanks for your efforts. Indeed your version does display it in a
> different way from my slightly older version.
> I therefore installed Debian Bullseye which has Gwenview 20.12.3 and the
> display indeed looks as you showed it.
> 
> However, I do not see why it should display the additional information that
> the  GPSAreaInformation is in such and such character coding. It does not
> show that on City and City2 which also can be Unicode and which have already
> worked as expected in older versions.

It shows exactly what you have in your file, as reported by libexiv2:

# exiv2 -g City P1020755A.JPG
Exif.Panasonic.City                          Undefined  72  Mecklenburgische Seenplatte
Exif.Panasonic.City2                         Undefined  72  Neubrandenburg
# exiv2 -g GPS P1020755A.JPG
Exif.Image.GPSTag                            Long        1  15800
Exif.GPSInfo.GPSVersionID                    Byte        4  2.3.0.0
Exif.GPSInfo.GPSLatitudeRef                  Ascii       2  Norden
Exif.GPSInfo.GPSLatitude                     Rational    3  53deg 32' 51"
Exif.GPSInfo.GPSLongitudeRef                 Ascii       2  Osten
Exif.GPSInfo.GPSLongitude                    Rational    3  13deg 15' 13"
Exif.GPSInfo.GPSTimeStamp                    Rational    3  16:09:34
Exif.GPSInfo.GPSStatus                       Ascii       2  Messung wird durchgeführt
Exif.GPSInfo.GPSMeasureMode                  Ascii       2  Zweidimensionale Messung
Exif.GPSInfo.GPSDOP                          Rational    1  9/10
Exif.GPSInfo.GPSMapDatum                     Ascii      10  WGS-84   
Exif.GPSInfo.GPSProcessingMethod             Undefined  14  charset=Ascii GPS
Exif.GPSInfo.GPSAreaInformation              Undefined 266  charset=Unicode Dampferanlegestelle
Exif.GPSInfo.GPSDateStamp                    Ascii      11  2019:07:14

> I conclude that the Gwenview project management it too lousy to believe:
> They _somehow_ worked at the bug without looking how it has been done on
> other fields.

I think bashing developers is counterproductive. I think it's more probable that they didn't have test cases that were generated by whatever process you use to put GPS tags in your files. Where do those tags come from? I notice that the lengths of several fields are off. 

Maybe that process has something to do with the behaviour we're seeing here. For example, there are digital cameras that zero-pad the EXIF strings to a fixed length, but I'm not sure whether Panasonic is one of them.
Comment 13 linadmin 2021-11-30 18:03:26 UTC
(In reply to Philipp Reichmuth from comment #12)
> I think bashing developers is counterproductive. I think it's more probable
> that they didn't have test cases that were generated by whatever process you
> use to put GPS tags in your files. Where do those tags come from? I notice
> that the lengths of several fields are off. 

I do know that bashing may be counterproductive, but my many years of waiting without success proved that positive feedback does not help either.

Getting many test cases is the first step any good developer will do even before starting to code!
There is the EXIF standards documentation and Gwenview must first of all adhere to this paper.

Then there may be camera models of well known brands that do not correctly apply the standard and then there is a difficult problem to decide: Adhere to the standard only or add some quirk to display useful data for these cameras too?
Comment 14 phrxmd 2021-11-30 21:18:27 UTC
(In reply to linadmin from comment #13)
> (In reply to Philipp Reichmuth from comment #12)
> > I think bashing developers is counterproductive. I think it's more probable
> > that they didn't have test cases that were generated by whatever process you
> > use to put GPS tags in your files. Where do those tags come from? I notice
> > that the lengths of several fields are off. 
> 
> I do know that bashing may be counterproductive, but my many years of
> waiting without success proved that positive feedback does not help either.

A bug tracker is not a good place for venting and deliberately bashing developers is destructive, no matter how unhappy we are. 

I think this was probably an upstream issue that was fixed upstream unnoticed while you were waiting. If you still have access to your old system, and you want to be sure whether the bug was fixed in Gwenview or exiv2, you can verify this: go back to the old version where you see the Gwenview behaviour in the original bug report, check the exiv2 version installed there, and read out the broken 266-byte GPSAreaInformation tag on the command line.

(In reply to linadmin from comment #11)
> However, I do not see why it should display the additional information that
> the  GPSAreaInformation is in such and such character coding. It does not
> show that on City and City2 which also can be Unicode and which have already
> worked as expected in older versions. I conclude that the Gwenview project 
> management it too lousy to believe: They _somehow_ worked at the bug 
> without looking how it has been done on other fields.
(In reply to linadmin from comment #13)
> There is the EXIF standards documentation and Gwenview must first of all
> adhere to this paper. [...]

As fas as I can see Gwenview uses exiv2 for handling metadata. On my system the metadata is displayed exactly as exiv2 also shows it.  So you might be holding the developers accountable for something with which they have nothing to do.

According to the exiv2 manpage, the character specification applies to the tags Exif.Photo.UserComment, Exif.GPSInfo.GPSProcessingMethod and  Exif.GPSInfo.GPSAreaInformation. It does not mention that this applies to tags from the manufacturer MakerNote such as Exif.Panasonic.City and I wouldn't expect it to, as they are not part of the standard. 

Either way I think we are talking about an upstream issue.
Comment 15 linadmin 2021-12-01 10:21:20 UTC
(In reply to Philipp Reichmuth from comment #14)
> As fas as I can see Gwenview uses exiv2 for handling metadata. On my system
> the metadata is displayed exactly as exiv2 also shows it.  So you might be
> holding the developers accountable for something with which they have
> nothing to do.
> 
> According to the exiv2 manpage, the character specification applies to the
> tags Exif.Photo.UserComment, Exif.GPSInfo.GPSProcessingMethod and 
> Exif.GPSInfo.GPSAreaInformation. It does not mention that this applies to
> tags from the manufacturer MakerNote such as Exif.Panasonic.City and I
> wouldn't expect it to, as they are not part of the standard. 
> 
> Either way I think we are talking about an upstream issue.

Thanks for making clear that Gwenview does use exiv2 libraries. The changes in that code result in changing display of the exiv data.

However, I disagree that this is an upstream issue. When the developer of Gwenview decides to use some unstable library with version numbers 0.xx he holds the obligation to check from time to time that his application still works as expected and eventually adapt his own code in order to maintain the expected functionality.

This has not happened for Gewenview and therefore my bug entry still is valid. The maintainer should adapt his code to the latest version or better use some workaround so that his codes can cooperate with older or newer versions of exiv.
Comment 16 phrxmd 2021-12-01 19:03:32 UTC
(In reply to linadmin from comment #15)
> However, I disagree that this is an upstream issue. When the developer of
> Gwenview decides to use some unstable library with version numbers 0.xx he
> holds the obligation to check from time to time [...]

Plenty of software is at 0.x without being unstable, or at >= 1.x without being stable. Exiv2 is 13 years old and pretty stable. All of KDE uses exiv2. There has been talk of making it a KDE project.  Of course it has bugs. The best way to get them fixed is to report them in the right place.

The bug reports states that a particular field is displayed as a bunch of integers. This is not happening any more, so the bug as reported has been resolved upstream and is gone. 
If there is some other undesirable behaviour now, this should IMHO be reported separately.