SUMMARY Right now the app does not read or display any look vector from the file or writes it into the EXIF data.* * at leastI couldn't find it THE GOAL (aka 'What I want to achieve') Having the position saved to your file is nice, the view direction would be even better. So the goal is to be able to display and save the view direction alongside the GPS location. SUGGESTION Rendering: The idea for rendering would be "just like in the OpenStreetMap editor iD" OK, but how does that look: A point on the GPS location and a ~45° part of a circle pointing in the view direction with it's tip in the GPS location. There could also be multiple styles like an arrow that can be added maybe even with simple svg files. Editing: The idea would either be to have a popup window where you can enter the number of th destination or maybe have a drop down menu for general directions or maybe even some sort of spider web where you can click onto to manipulate an arrow and set the direction. I have some ideas for a mokup and I want to add them soon. EXIF DATA I think the EXIF tags would be "GPS Img Direction Ref" and "GPS Img Direction". I would guess from EXIF data extraction that the value for "GPS Img Direction" would be a float value, but it could also be a string. See also: https://dicom.innolitics.com/ciods/vl-photographic-image/vl-photographic-geolocation/00160080 There also is "GPS Dest Bearing Ref" and "GPS Dest Bearing". On the test shots I saw they always were the same, but I have no idea how they would differ. On https://exiftool.org/forum/index.php?topic=9694.0 it was asked if "GPSDestBearing is the direction of movement, while GPSImgDirection the camera is facing". I have no idea, but I can take some test shots and check that. I If there is a need for this, I can supply test images.
Hi BOF, thanks for the request! Sounds essentially like a good idea. I'll have to investigate this closer. But: You can't derive the view direction from a GPX track though, so this would have to be done by hand, for each and every picture taken, no? If there's a standardized Exif header for that, this could be doable. The problem to implement this is that KGeoTag doesn't mess with the Exif headers directly (which is, as you might have already thought, not so easy ;-), but uses KExiv2 to do the "dirty work". So, as long as KExiv2 doesn't support setting such information, the only thing we could do is to implement our own Exif header writer (and I'm pretty sure I don't want to do that :-P). So I think you should ask the KExiv2 guys to add the respective functionality first (or implement it yourself and create a MR of course!). As soon as KExiv2 support this, we can think about how to use it in KGeoTag. Cheers, Tobias
No, you would not be able to get the view direction directly from a GPS track. However, as far as I know about this feature from a different application it positions images along the track based on their time. So it's to add GPS info to files that were taken with a device that does not have a build in GPS receiver (like an old DSLR camera) or was not turned on at the time (like in the settings of your smartphone) I'm not sure if it's what you mean by 'header', but there already is a standard entry for the view direction in the EXIF data. The company smartphone I got saved the view direction alongside the image in already mentioned 'GPS Img Direction' tag. I guess KExiv2 sound like a fork of Exiv2. So everything that Exiv2 can do should be able possible for KExiv2 as well (as long as the latest changes are transfered to the fork). I tried to test around with exiv2 today (on Windows) and it told me that "ligcc_s_seh-1.dll" was missing. After I got that one an error box told me that the application can not run with bug code "0xc00000007b". I remember this tool to be rather simple to use (just /path/to/file/application.exe "path/to/file/filename.jpg" and the application will display the contained EXIF data. So it will may take some time to check f Exiv2 can do that.
KExiv2 is not a fork, it's a Qt/KDE wrapper using exiv2 that makes your life much easier when developing a Qt/KDE app, and, as said, it's the library that KGeoTag uses to do the Exif tagging. If exif2 can write the respective Exif header, KExiv2 would be able to also do so – if somebody adds the respective functionality (but this is not the case by now).