[digikam] [Bug 487920] Adjust DateTime is unnecesarily slow - it re-reads all the images all the time
https://bugs.kde.org/show_bug.cgi?id=487920 --- Comment #1 from fotograaf --- To add insult to unjury... when you adjust the amount of time to add/substract... It read all the images again. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 487920] New: Adjust DateTime is unnecesarily slow - it re-reads all the images all the time
https://bugs.kde.org/show_bug.cgi?id=487920 Bug ID: 487920 Summary: Adjust DateTime is unnecesarily slow - it re-reads all the images all the time Classification: Applications Product: digikam Version: 8.4.0 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Plugin-Generic-TimeAdjust Assignee: digikam-bugs-n...@kde.org Reporter: fotogr...@mail.farside.nl Target Milestone: --- Adjust dateTime for a number of images is slow, slower than necessary. 1. It reads all the images, entirely. If you are working with Raws on a network drive, this takes a long time. 2. When you change the radiobutton 'timestamp used', it re-reads them again. Problems: 1) reading all of this is not needed. All the info is already in the database! It was already read on importing the images. There is no need to re-read it from the original image. 2) reading the entire 38 megabytes of a rawfile just to read the date? That is too much. Just read what is actually needed. 3) re-reading all the information when you click a different radio-button? Not needed because the data was already read and available. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 487915] New: Unclear from screen AND documentation: What does "Sync XMP Creation Date" do?
https://bugs.kde.org/show_bug.cgi?id=487915 Bug ID: 487915 Summary: Unclear from screen AND documentation: What does "Sync XMP Creation Date" do? Classification: Applications Product: digikam Version: 8.4.0 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Usability-Ergonomy Assignee: digikam-bugs-n...@kde.org Reporter: fotogr...@mail.farside.nl Target Milestone: --- Relevant manual page is here: https://docs.digikam.org/en/post_processing/metadata_editor.html#date-and-time On Edit Metadata -> Time, there are checkboxes "sync XMP Creation Date" and "Sync IPTC Creation Date". It is unclear what is synced towards what. Even the documentation does not explain this. 2 questions: 1) If I check the box, is the Exif-date synced TOWARDS the XMP-date or FROM it? 2) If the corresponding box is checked in the XMP tab and the dates are different, what happens? Who wins? The first can be solved by one single word: "Sync Creation date TO XMP" or "Sync Creation date FROM XMP". When boxes are checked on multiple tabs, I do not know a quick solution. I could imagine that checking the box on one tab unchecks the boxes on other tabs but that is unfriendly - the user does not see this happening. Perhaps a warning? "You have checked the same box on the other tab, choose only one" ? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 487683] New: Import should import to the currently active album.
https://bugs.kde.org/show_bug.cgi?id=487683 Bug ID: 487683 Summary: Import should import to the currently active album. Classification: Applications Product: digikam Version: 8.4.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Import-Albums Assignee: digikam-bugs-n...@kde.org Reporter: fotogr...@mail.farside.nl Target Milestone: --- *** *** SUMMARY Digikam should (1) remember the last album on startup and (2) remember which album you just created. Whenever I import, the location points to a random album. Never the last one. Never the album I just created. Never the actually active album. Just a random one. STEPS TO REPRODUCE 1. Create a new album 2. Click import 3. Experience disappointment when you notice that Digicam suggests to import to a random album, and not to the one you just created. 4. Experience additional disappointment when you realize 'Import' does not point to your currently active album. It's always a random album. OBSERVED RESULT 'Import' never starts at your currently active album or the most recently created one. It's always a random album. EXPECTED RESULT Import works on the active album. If I create an album, it's instantly active - and empty. When I click 'import' I want to import in to that album. SOFTWARE/OS VERSIONS Linux/KDE Plasma: -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374655] Working with raw processors
https://bugs.kde.org/show_bug.cgi?id=374655 fotograaf changed: What|Removed |Added CC||fotogr...@mail.farside.nl --- Comment #1 from fotograaf --- I 'd like this too. The thumbnail for a raw file can be produced by Darktable. If you open the file in Digikam it could be processed by Darktable as a full size image. As I can do exstensive editnig the resulting image can look very different from the embedded JPG. I would welcome closer collaboration between the two programs. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 362638] Reading Darktable metadata
https://bugs.kde.org/show_bug.cgi?id=362638 fotograaf changed: What|Removed |Added CC||fotogr...@mail.farside.nl --- Comment #2 from fotograaf --- Some of this is possible. See here: https://userbase.kde.org/Digikam/Tutorials/Setup_of_digiKam_for_Windows_compatibility#Step_2_-_Fix_which_metadata_is_written_into_files It is possible to exchange tags and star-rating between Darktable and Digikam, so that tags set in one program are recognized by the other. If you set it up right, it works in both directions. Preferred solution: Ideally there would be a "set data exchange for Darktable" setting which would configure all the metadata to work with Darktable. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 467276] New: FR: Better (native) integration with Darktable sidecars
https://bugs.kde.org/show_bug.cgi?id=467276 Bug ID: 467276 Summary: FR: Better (native) integration with Darktable sidecars Classification: Applications Product: digikam Version: 7.9.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Metadata-Sidecar Assignee: digikam-bugs-n...@kde.org Reporter: fotogr...@mail.farside.nl Target Milestone: --- SUMMARY *** I found settings on how to better integrate Digikam and Darktable, reading and writing each others sidecar files. It would be nice if those could be native to Digikam, in some sort of profile or a checkbox. *** To better integrate Digikam and Darktable, 3 settings must be done and it takes a *lot* of time and searching to find these. Most users will never find out that this is even possible. I'll list these with the notice that this is applicable to working with these two programs. It is not a universal 'make everything better' setting. I would prefer if there was some setting or button that would make all these changes at once (and for good measure, perhaps a checklist with which other programs you want to integrate Digikam :) ) 1. digikam should prioritize XMP files over its database Ncessary because Darktable can update the XMP files, so the XMP must be leading, always. 2. digikam must read and write tags in the sections and format where Darktable has them. Here is a very good explanation: https://userbase.kde.org/Digikam/Tutorials/Setup_of_digiKam_for_Windows_compatibility#Step_2_-_Fix_which_metadata_is_written_into_files However, it is still missing the "xmp.lr.hierarchicalSubject' - it should be added. 3. digikam must no longer read/write tags in other sections of the XMP Otherwise, when Darktable updates something, Digikam will happily read the old data back from another section of the XMP file. Example: There is a tag 'elephant' which exists in "Mediapro:catalogsets". The user removes this tag in Darktable. When you start Digikam, it will still read the tag because it finds it in a section of the XMP that Darktable did not update. Found this out the hard way and needed to fix all my XMP files with awk. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 465635] Geolocate is too slow: it reads way too much data
https://bugs.kde.org/show_bug.cgi?id=465635 --- Comment #2 from fotograaf --- I am using the Linux appimage, not snap. I see what you mean however, when adding tags this does not seem to work this way. They can be added with far less diskreads And at the end of the day, geolocation data is also just a tag. They seem to work different, tags and geolocation. It's like the tagging says 'ok, I know this file, add this tag and its XMP data, just write it in the XMP'. And when Geolocation is started, it's like it's a completely new program which has not seen these files ever before - and therefore has to read them from scratch. Again, in the main window when you tag a file, it's not completely re-read. So there the necessary information to perform tagging is present. Only the Geolocation module acts like it does not get this info. Extra info: It's much faster when files already have a geolocation. It doesn't read the entire file first. Debug: This is for a single file. Is it me or does it read the metadata (which the tagging module already has) 3 times?? ^[[34mDigikam::DMetadata::load^[[0m: Loading metadata with "Exiv2" backend from "/media/erin_only/home/Photos/Mobile/PhoneCamera/Camera/IMG_20140717_093012.jpg" ^[[34mDigikam::DMetadata::load^[[0m: Loading metadata with "Exiv2" backend from "/media/erin_only/home/Photos/Mobile/PhoneCamera/Camera/IMG_20140717_093012.jpg" ^[[34mDigikam::DMetadata::load^[[0m: Loading metadata with "Exiv2" backend from "/media/erin_only/home/Photos/Mobile/PhoneCamera/Camera/IMG_20140717_093012.jpg" ^[[34mDigikam::MetaEngine::save^[[0m: MetaEngine::metadataWritingMode 1 ^[[34mDigikam::MetaEngine::save^[[0m: Will write XMP sidecar for file "IMG_20140717_093012.jpg" ^[[34mDigikam::ItemLister::listSearch^[[0m: Search result: 33973 ^[[34mDigikam::MetaEngine::Private::saveOperations^[[0m: wroteComment: false ^[[34mDigikam::MetaEngine::Private::saveOperations^[[0m: wroteEXIF: true ^[[34mDigikam::MetaEngine::Private::saveOperations^[[0m: wroteIPTC: true ^[[34mDigikam::MetaEngine::Private::saveOperations^[[0m: wroteXMP: true ^[[34mDigikam::MetaEngine::save^[[0m: Metadata for file "IMG_20140717_093012.jpg" written to XMP sidecar. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 465635] New: Geolocate is too slow: it reads way too much data
https://bugs.kde.org/show_bug.cgi?id=465635 Bug ID: 465635 Summary: Geolocate is too slow: it reads way too much data Classification: Applications Product: digikam Version: 7.9.0 Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Geolocation-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: fotogr...@mail.farside.nl Target Milestone: --- SUMMARY *** My pictures are on a networked drive over a gigabit network. When I geolocate hundreds of images at once, it takes an extremely long time. System usage monitor reveals that geolocate is reading many, many gigabytes of data - presumably the pictures. This takes a LNG time. And it's unneccesary; all the data is already available. On applying the data, same story: It only needs to write the XMP files. Instead it reads many many gigabytes of data - again. *** STEPS TO REPRODUCE 1. Have 500+ pictures on a network drive 2. Geolocate them 3. be surprised at the very long time it takes to read all the data that is already available 4. be surprised at the very long time it takes to apply the geolocation which should only be a small XMP-write. OBSERVED RESULT System monitor reports digikam is reading gigs of data, as if it is importing these pictures for the very first time. EXPECTED RESULT To be much faster since all the data is already available. SOFTWARE/OS VERSIONS Linux Kubuntu, all versions ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 407672] printer changes not saved when clicking "Apply"
https://bugs.kde.org/show_bug.cgi?id=407672 fotograaf changed: What|Removed |Added CC||ger...@mail.farside.nl --- Comment #7 from fotograaf --- Confirmation of this bug (it's reported over and over and over). I get it when I use driverless printing. Hope that helps when replicating it. Happens on a Canon G500 driverless and Brother laserprinter driverless. -- You are receiving this mail because: You are watching all bug changes.
