SUMMARY *** I've a strange behaviour currently: I need to geolocate JPEG images twice to make them persistent. STEPS TO REPRODUCE 1. Select a collection of RAW (NEF) and JPEG files and load them into the geolocation edtor. 2. Assign GPS coordinates to images in the location map e.g. with Google Maps. 3. Apply and save 4. NEF files are saved, JPEG files are not 5. Do the same again for JPEG files, apply and save 6. Now the JPEG files have coordinates, too. OBSERVED RESULT Need two iterations for JPEG files. EXPECTED RESULT This should work without the second round. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.8.1-arch1-1 (64-bit) / 6.0.2 (available in About System) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION
Tested here, no problems, both images have geolocation metadata. Since you're writing in RAW files, I'm guessing you have ExifTool enabled to write or are you using Sidecar files? Maik
I have "write into file and XMP side car files" activated.
I can reproduce it, but it only occurs when the following setting is UNCHECKED: Metadata -> Behaviour -> Write Metadata -> GPS coordinates In this case the NEF files show GPS coordinates i.e. the little globe icon, but the JPEG files not. After a second time, the GPS icon appears also for the JPEG files. However, I cannot find the respective GPS data in the metadata side bar. Maybe it's only written into the DB?
Correct if Metadata -> Behavior -> Write Metadata -> GPS coordinates is not selected, the GPS coordinates are not written to the images, only to the DB. But even then, the coordinates for JPEG files must be displayed (geolocation icon). Unless the metadata is somehow reread. What are your metadata settings exactly? Maik
Git commit b902c89633a806016ff5402819135592d3850fed by Maik Qualmann. Committed on 24/03/2024 at 19:53. Pushed by mqualmann into branch 'master'. do not reread metadata when writing GPS information FIXED-IN: 8.4.0 M +1 -1 NEWS M +3 -16 core/libs/database/utils/ifaces/itemgps.cpp https://invent.kde.org/graphics/digikam/-/commit/b902c89633a806016ff5402819135592d3850fed
This problem also depended on the setting for rereading the metadata when changed and the setting for updating the modification timestamp. Maik
Git commit c73e4c5b560878592ce8966ca3808a96404490bd by Maik Qualmann. Committed on 24/03/2024 at 22:20. Pushed by mqualmann into branch 'master'. Revert "do not reread metadata when writing GPS information" M +1 -1 NEWS M +16 -3 core/libs/database/utils/ifaces/itemgps.cpp https://invent.kde.org/graphics/digikam/-/commit/c73e4c5b560878592ce8966ca3808a96404490bd
The problem is deeper, it is related to a changed behavior of QVariant in Qt6. I'll fix it in the next few days. Maik
Created attachment 167724 [details] Screenshot metadata settings behaviour
Created attachment 167725 [details] Screenshot metadata settings side car files
Created attachment 167726 [details] Screenshot metadata settings Exiftool
i don't know if this is connected, but I've also trouble with the times of JPEG files after activating the settings to write face and GPS data to the file and performing a "write meta data to file". digikam shows them one hour later than they were taken in the album view. I checked the metadata and the following fields are now wrong: Exif tab: all dates Exiftool tab: # Composite SubSecCreateDate SubSecDateTimeOriginal SubSecModifyDate # EXIF CreateDate DateTimeOriginal Dates under XMP and IPTC are correct. I did not adjust any date. For NEF files, digikam displays the dates correctly in the album view, but some metadata fields are also one hour later. Here, only the values for "date and time" under the EXIF tab are wrong while "Date Time Original" is correct.
It's reproducible: It's not even necessary to do anything with the picture, after "writing metadata to file", the dates previously mentioned are changed by one hour. This can be fixed by applying the IPTC change date to all existing time stamps with the "Date & Time Adjust Tool". However, after performing another "write meta data to file", the dates are wrong again. I don't know, if this is a separate bug, though.
Git commit 344e9e69fb0262c03ad0dc6176893f0fa94db291 by Maik Qualmann. Committed on 25/03/2024 at 20:20. Pushed by mqualmann into branch 'master'. fix null QVariant from empty (GPS) string FIXED-IN: 8.4.0 M +1 -1 NEWS M +1 -0 core/libs/metadataengine/dmetadata/dmetadata.h M +25 -5 core/libs/metadataengine/dmetadata/dmetadata_generic.cpp https://invent.kde.org/graphics/digikam/-/commit/344e9e69fb0262c03ad0dc6176893f0fa94db291
digiKam has no significant influence on the Exif date displays; these are “live” data and come directly from the images. This doesn't change when the writing options for faces and GPS are activated. I am sure that digiKam is not making a mistake here. Otherwise, send a sample image and I will check which dates are included and whether digiKam reads the correct ones. Maik