[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 Philipp Reichmuth changed: What|Removed |Added CC||philipp.reichm...@gmail.com --- Comment #1 from Philipp Reichmuth --- 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. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 John Clark changed: What|Removed |Added Assignee|gwenview-bugs-n...@kde.org |john.cl...@cantab.net CC||john.cl...@cantab.net --- Comment #2 from John Clark --- Created attachment 143703 --> https://bugs.kde.org/attachment.cgi?id=143703&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 John Clark changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|NEEDSINFO --- Comment #3 from John Clark --- Marking as NEEDSINFO until we can get an example where this doesn't work. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 linadmin changed: What|Removed |Added CC||linad...@quickline.ch --- Comment #4 from linadmin --- Created attachment 144069 --> https://bugs.kde.org/attachment.cgi?id=144069&action=edit Screenshot of erroneous display -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #5 from linadmin --- Created attachment 144070 --> https://bugs.kde.org/attachment.cgi?id=144070&action=edit jpg with embedded GPS erroneously displayed -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #6 from linadmin --- Please find enclosed jpg-image with embedded GPS info which is erroneously displayed as shown in enclosed screenshot gwenview-erroneous-display.png -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #7 from linadmin --- (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" -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #8 from linadmin --- (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? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #9 from Philipp Reichmuth --- (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 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #10 from Philipp Reichmuth --- Created attachment 144076 --> https://bugs.kde.org/attachment.cgi?id=144076&action=edit 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? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 linadmin changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Ever confirmed|0 |1 Resolution|WORKSFORME |--- --- Comment #11 from linadmin --- (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". :-( -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #12 from Philipp Reichmuth --- (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.GPSTagLong1 15800 Exif.GPSInfo.GPSVersionIDByte4 2.3.0.0 Exif.GPSInfo.GPSLatitudeRef Ascii 2 Norden Exif.GPSInfo.GPSLatitude Rational3 53deg 32' 51" Exif.GPSInfo.GPSLongitudeRef Ascii 2 Osten Exif.GPSInfo.GPSLongitudeRational3 13deg 15' 13" Exif.GPSInfo.GPSTimeStampRational3 16:09:34 Exif.GPSInfo.GPSStatus Ascii 2 Messung wird durchgeführt Exif.GPSInfo.GPSMeasureMode Ascii 2 Zweidimensionale Messung Exif.GPSInfo.GPSDOP Rational1 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.GPSDateStampAscii 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. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #13 from linadmin --- (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? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #14 from Philipp Reichmuth --- (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. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 --- Comment #15 from linadmin --- (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. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 Philipp Reichmuth changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |UPSTREAM --- Comment #16 from Philipp Reichmuth --- (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. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 418635] Display of GPS Area Information does not respect EXIF specification
https://bugs.kde.org/show_bug.cgi?id=418635 Philipp Reichmuth changed: What|Removed |Added CC|philipp.reichm...@gmail.com | -- You are receiving this mail because: You are watching all bug changes.
