[digikam] [Bug 443863] New: DK crash on rating image
https://bugs.kde.org/show_bug.cgi?id=443863 Bug ID: 443863 Summary: DK crash on rating image Product: digikam Version: 7.3.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tags-Rating Assignee: digikam-bugs-n...@kde.org Reporter: f...@kdmurray.id.au Target Milestone: --- SUMMARY Digikam 7.3.0 appimage crashes when rating an image (Ctrl-1 etc) with the following on the terminal unknown: ASSERT failure in QList::at: "index out of range", file ././/include/QtCore/qlist.h, line 571 I'm running debian sid, with SwayWM (wayland), and running the digikam appimage with the following wrapper script: export QT_QPA_PLATFORM=xcb /path/to/digikam/digiKam-7.3.0-x86-64.appimage STEPS TO REPRODUCE 1. Open digikam, browse to image in thumbnail/preview mode. 2. Rate image with keyboard shortcut or captions side bar + apply button OBSERVED RESULT Digikam crashes. It appears the rating in the digikam DB is updated, but the XMP sidecar is not (I have write to XMP sidecars enabled). It also seems that this only happens when changing the rating to non-zero (ctrl-0 or setting rating to zero stars is unaffected). It seems to happen on both CR3 raws and JPEGs. Updating pick labels and tag metadata works as per normal. EXPECTED RESULT No crash, metadata happily written to image file or sidecar as appropriate. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: Using debian sid with appimage bundle and Sway WM on wayland (But digikam via Xwayland and XCB-based QT rendering, see above). ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 443863] DK crash on rating image
https://bugs.kde.org/show_bug.cgi?id=443863 K D Murray changed: What|Removed |Added Platform|Other |Debian unstable --- Comment #1 from K D Murray --- I just came across the development snapshot appimages, and I can confirm that the same bug/behaviour appears in digiKam-7.4.0-20210905T231405-x86-64-debug.appimage I'd be happy to test an appimage of current main branch too if one is available. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426597] New: stack underflow crash in Digikam::DImg::load()
https://bugs.kde.org/show_bug.cgi?id=426597 Bug ID: 426597 Summary: stack underflow crash in Digikam::DImg::load() Product: digikam Version: 7.2.0 Platform: Debian unstable OS: Linux Status: REPORTED Severity: grave Priority: NOR Component: general Assignee: digikam-bugs-n...@kde.org Reporter: f...@kdmurray.id.au Target Milestone: --- SUMMARY A stack underflow crash occurs with both 7.1.0 and the current master branch from git when compiled on debain sid. Traceback below, with asan. Appears to be in QString::QString() as part of the DRawInfo() ctor, while doing Digikam::DImg::load() STEPS TO REPRODUCE 1. Run digikam, and trigger loading any RAW file (in my case CR2) NB: i've re-compiled this with -fsanitize=address to hopefully help debugging, but the error initially occured without this flag. OBSERVED RESULT ``` digikam.general: Using 16 CPU core to run threads digikam.general: Action Thread run 1 new jobs digikam.general: Cancel Main Thread digikam.general: One job is done digikam.general: Cancel Main Thread digikam.database: Starting scan! digikam.general: Stacked View Mode : 1 digikam.metaengine: index : 0 digikam.metaengine: properties: 3 digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.metaengine: index : 0 digikam.metaengine: properties: 3 digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.general: Stacked View Mode : 1 digikam.metaengine: index : 0 digikam.metaengine: properties: 3 digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.metaengine: index : 0 digikam.metaengine: properties: 3 digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.general: Stacked View Mode : 1 digikam.metaengine: index : 0 digikam.metaengine: properties: 3 digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.metaengine: index : 0 digikam.metaengine: properties: 3 digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile. digikam.general: Shortcut value: 1 digikam.general: Detected change, triggering rescan of "/home/kevin/photos/library/2020/2020-09-99_around-home/todo/" digikam.general: Writing tags digikam.metaengine: MetaEngine::metadataWritingMode 3 digikam.metaengine: Will write Metadata to file "/home/kevin/photos/library/2020/2020-09-99_around-home/todo/029A0172.CR2" digikam.metaengine: "029A0172.CR2" is a TIFF based RAW file, writing to such a file is disabled by current settings. digikam.metaengine: Will write XMP sidecar for file "029A0172.CR2" digikam.general: Detected change, triggering rescan of "/home/kevin/photos/library/2020/2020-09-99_around-home/todo/" digikam.metaengine: wroteComment: false digikam.metaengine: wroteEXIF: true digikam.metaengine: wroteIPTC: true digikam.metaengine: wroteXMP: true digikam.metaengine: Metadata for file "029A0172.CR2" written to XMP sidecar. digikam.dimg: "/home/kevin/photos/library/2020/2020-09-99_around-home/todo/029A0172.CR2" : "RAW" file identified =
[digikam] [Bug 426597] stack underflow crash in Digikam::DImg::load()
https://bugs.kde.org/show_bug.cgi?id=426597 K D Murray changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #2 from K D Murray --- Hi Maik $ ulimit -s 8192 It would seem that $ ulimit -s 65535 $ digikam makes it not crash. I'll update/reopen this bug report if it starts crashing again. It would be great if digikam could increase the stack size, e.g. using setrlimit on linux if needing a larger stack size is a known issue. I'm happy to provide a patch if this is something you'd like included. Cheers, Kevin -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426597] stack underflow crash in Digikam::DImg::load()
https://bugs.kde.org/show_bug.cgi?id=426597 --- Comment #14 from K D Murray --- Gilles, Many thanks for the patches. It does seem to have fixed the immediate cause of my crash. However, now with ASAN on, I'm getting a buffer overflow in LibRaw. Crash below, not sure why the line numbers aren't showing, i'm using CMAKE_BUILD_TYPE=Debug. Cheers, Kevin ==948374==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffa8693892 at pc 0x72353fbf bp 0x7fffa86937d0 sp 0x7fffa86937c8 READ of size 1 at 0x7fffa8693892 thread T55 (Thread (pooled)) #0 0x72353fbe in LibRaw::tiff_set(tiff_hdr*, unsigned short*, unsigned short, unsigned short, int, int) [clone .constprop.0] (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x15bffbe) #1 0x72355857 in LibRaw::tiff_head(tiff_hdr*, int) (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x15c1857) #2 0x7231acc3 in LibRaw::dcraw_make_mem_thumb(int*) (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x1586cc3) #3 0x7237f9dd in Digikam::DRawDecoder::Private::loadEmbeddedPreview(QByteArray&, LibRaw*) (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x15eb9dd) #4 0x7236feb4 in Digikam::DRawDecoder::loadEmbeddedPreview(QByteArray&, QString const&) (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x15dbeb4) #5 0x7236f3f0 in Digikam::DRawDecoder::loadEmbeddedPreview(QImage&, QString const&) (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x15db3f0) #6 0x7212325f in Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo const&, QRect const&) const (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x138f25f) #7 0x72117760 in Digikam::ThumbnailCreator::load(Digikam::ThumbnailIdentifier const&, QRect const&, bool) const (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x1383760) #8 0x7211646c in Digikam::ThumbnailCreator::load(Digikam::ThumbnailIdentifier const&) const (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x138246c) #9 0x7213906f in Digikam::ThumbnailLoadingTask::execute() (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x13a506f) #10 0x7213bee2 in Digikam::LoadSaveThread::run() (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x13a7ee2) #11 0x7219e15a in Digikam::DynamicThread::Private::run() (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x140a15a) #12 0x7fffefa64691 (/lib/x86_64-linux-gnu/libQt5Core.so.5+0xcc691) #13 0x7fffefa60a00 (/lib/x86_64-linux-gnu/libQt5Core.so.5+0xc8a00) #14 0x7fffef5caea6 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8ea6) #15 0x7fffef6e7eae in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfdeae) Address 0x7fffa8693892 is located in stack of thread T55 (Thread (pooled)) at offset 50 in frame #0 0x7235487f in LibRaw::tiff_head(tiff_hdr*, int) (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x15c087f) This frame has 2 object(s): [48, 50) 'latref' (line 123) <== Memory access at offset 50 overflows this variable [64, 66) 'lonref' (line 124) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) Thread T55 (Thread (pooled)) created by T0 here: #0 0x776202a2 in __interceptor_pthread_create (/lib/x86_64-linux-gnu/libasan.so.6+0x552a2) #1 0x7fffefa604da in QThread::start(QThread::Priority) (/lib/x86_64-linux-gnu/libQt5Core.so.5+0xc84da) SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/kevin/.homedir/opt/digikam/lib/x86_64-linux-gnu/libdigikamcore.so.7.2.0+0x15bffbe) in LibRaw::tiff_set(tiff_hdr*, unsigned short*, unsigned short, unsigned short, int, int) [clone .constprop.0] Shadow bytes around the buggy address: 0x1000750ca6c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000750ca6d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000750ca6e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000750ca6f0: 00 00 00 00
[digikam] [Bug 426597] stack underflow crash in Digikam::DImg::load()
https://bugs.kde.org/show_bug.cgi?id=426597 --- Comment #16 from K D Murray --- OK, thanks Gilles, will do. Any hints you have to easily try step 1? > 1/ try to identify which Raw image introduce this memory leak, Cheers, Kevin -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426597] stack underflow crash in Digikam::DImg::load()
https://bugs.kde.org/show_bug.cgi?id=426597 --- Comment #19 from K D Murray --- OK, so now I get a possibly related issue: Clicking on any CR2 leads to "Failed to load image" message in GUI, and this in console with debug logging on: ``` digikam.general: Try to get preview from "/home/kevin/photos/library/2020/2020-09-15_tidbinbilla/2020-09-15_12-44-37_029A0472.CR2" digikam.general: Preview quality: 2 digikam.dimg: "/home/kevin/photos/library/2020/2020-09-15_tidbinbilla/2020-09-15_12-44-37_029A0472.CR2" : Unknown image format !!! digikam.general: Cannot extract preview for "/home/kevin/photos/library/2020/2020-09-15_tidbinbilla/2020-09-15_12-44-37_029A0472.CR2" digikam.general: Stacked View Mode : 1 ``` Also seems as though it's failing to open or even create thumbnails of any JPEG. Cheers, K -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426597] stack underflow crash in Digikam::DImg::load()
https://bugs.kde.org/show_bug.cgi?id=426597 --- Comment #23 from K D Murray --- Hi Gilles, Do you mind sharing the OS/library versions/etc you use in your screenshots? Maybe my issue is triggered by some broken dependency from debian I can work around. Or are there nightly appimage bundles that would include these fixes? And regarding the asan issue: yes it appears fixed after the patch from upstream. Thanks to you/them for that :) Cheers, Kevin -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426923] New: EOS R5 CR3 Missing exif data with current master branch code
https://bugs.kde.org/show_bug.cgi?id=426923 Bug ID: 426923 Summary: EOS R5 CR3 Missing exif data with current master branch code Product: digikam Version: 7.2.0 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Metadata-Raw Assignee: digikam-bugs-n...@kde.org Reporter: f...@kdmurray.id.au Target Milestone: --- SUMMARY CR3 images from the EOS R5 don't seem to display metadata from exif etc. Possible duplicate of https://bugs.kde.org/show_bug.cgi?id=424860, but I think that the fixes in this issue are included in the current master branch and therefore in theory are included in the version I'm running. I can confirm the same behaviour with the released 7.1.0. STEPS TO REPRODUCE 1. With digikam from current master branch 2. ./bootstrap.local && cd build && make install && ./finish_install.sh 3. Navigate to a directory containing CR3s 4. click metadata from RHS menu 5. Chose "no filter" from drop down menu, and "select all" under settings to enable display of all metadata fields. OBSERVED RESULT No metadata in exif/makernotes/iptc panels of metadata tab, even with it set to display all metadata. EXPECTED RESULT If I understand correctly, at least some basic EXIF metadata (e.g. exposure settings, capture date, GPS) should be present in this view in digikam version 7.1.0+ thanks to bug 424860's Exiv2 workaround. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian sid KDE Frameworks 5.70.0 Qt 5.14.2 (built against 5.14.2) The xcb windowing system ADDITIONAL INFORMATION My digikam database (sqlite) and config file (~/.config/digikamrc) were first created with DK v 6.4-ish. I have confirmed that the behaviour I describe above happens also when i back up digikamrc etc and start from scratch with 7.2.0-beta (from current master branch). While no QT wizard, I'm more than happy to contribute code or whatever to better support CR3s in digikam. I have some experience in C++, and a modest background in image processing. I would need supervision, but if someone from digikam knows approximately how to fix these issues but doesn't have time, I'm happy to contribute code for this. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426923] EOS R5 CR3 Missing exif data with current master branch code
https://bugs.kde.org/show_bug.cgi?id=426923 --- Comment #2 from K D Murray --- Sure! See https://cloudstor.aarnet.edu.au/plus/s/sVDMnJLFmdWPvJG password is DigikamBug#426923 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426923] EOS R5 CR3 Missing exif data with current master branch code
https://bugs.kde.org/show_bug.cgi?id=426923 --- Comment #5 from K D Murray --- OK, so i can confirm the nightly appimage build does read the metadata. I assume it's an issue with a dependency from debian. Is there any easy way to make digikam build use mostly vendored libaries a la the appimage? For now i'm just saving metadata to sidecars with exiftool so I can see it in DK, so I have a workaround -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426923] EOS R5 CR3 Missing exif data with current master branch code
https://bugs.kde.org/show_bug.cgi?id=426923 --- Comment #7 from K D Murray --- > did you put something special in type mime settings in digiKam setup panel ? Not that I can find. I've checked: Configure Digkam -> Views -> Mime Types: no text in any "extra image/video/audio files" text boxes, and cr2 and cr3 are in the currently supported image list Configure Digkam -> Metadata -> Sidecars: both read and write to/from xmp files are enabled, writing to xmp is for read-only item only. Is there anywhere else I should look? > There is a difference about CR3 files which have XMP sidecar or not? Unless I make an XMP sidecar with exiftool which contains the full metadata from the CR3, there is no difference between CR3 files with or without XMP files. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426923] EOS R5 CR3 Missing exif data with current master branch code
https://bugs.kde.org/show_bug.cgi?id=426923 --- Comment #8 from K D Murray --- Oh, i forgot to say that there are also no notes about metadata when the qt debugging logs are enabled, so no hints from that either. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426923] EOS R5 CR3 Missing exif data with current master branch code
https://bugs.kde.org/show_bug.cgi?id=426923 --- Comment #11 from K D Murray --- Looks like broken CR3 from EOS R5/R6 is a known issue for libraw, with fixes in the pipeline. It appears the author of the new CR3 decoder is keeping it private for now, but will be in the next released version of libraw (I hope). https://github.com/LibRaw/LibRaw/issues/317#issuecomment-671383514 https://github.com/LibRaw/LibRaw/issues/317#issuecomment-674831840 Cheers, Kevin -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 436953] New: Feature request: keyboard shortcut for "assign pick label then advance image" as one action
https://bugs.kde.org/show_bug.cgi?id=436953 Bug ID: 436953 Summary: Feature request: keyboard shortcut for "assign pick label then advance image" as one action Product: digikam Version: 7.2.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability-Keyboard Assignee: digikam-bugs-n...@kde.org Reporter: f...@kdmurray.id.au Target Milestone: --- SUMMARY To facilitate rating large numbers of images, I have the three pick label states mapped to my numeric keypad: 1 -> rejected, 2 -> pending, 3-> accepted. I also have the + and - of my numeric keypad mapped to next/previous image. This way, I can press 1 then + to reject an image, 2 then + to mark images for further consideration. This is a workable system, however other tools I've used allow mapping "rate then move on" as a single keypress (in the above example, pressing 1 would assign rejected label and move to the next image). Would this be difficult to support in Digikam? My QT is a bit rusty, but is there a way to trigger multiple slots (slotAssignPickLabel() and then slotNextItem()) from one key combination? STEPS TO REPRODUCE n/a OBSERVED RESULT n/a EXPECTED RESULT n/a SOFTWARE/OS VERSIONS Linux 7.2.0-rc AppImage ADDITIONAL INFORMATION n/a -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 436953] Feature request: keyboard shortcut for "assign pick label then advance image" as one action
https://bugs.kde.org/show_bug.cgi?id=436953 --- Comment #2 from K D Murray --- With current settings, pressing 1 would assign rejected to all selected images, and + would deselect the selection and select the image after the last selected image. I assume the same would happen with the hypothetical feature I describe below? That's certainly what I'd assume should happen. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 436953] Feature request: keyboard shortcut for "assign pick label then advance image" as one action
https://bugs.kde.org/show_bug.cgi?id=436953 --- Comment #4 from K D Murray --- @Maik: agreed, a generalised macro system for digikam would be fantastic. A perhaps more easily achieved goal would be generalising this to all metadata assignments: picks, ratings, colours, etc. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 415949] Can't write sidecar file if image file is a symlink to readonly directory [patch]
https://bugs.kde.org/show_bug.cgi?id=415949 K D Murray changed: What|Removed |Added CC||f...@kdmurray.id.au --- Comment #4 from K D Murray --- Hello all, I've hit the exact same issue as David, as I am now also using git-annex. Could I please ask that his patch be applied (or a similar solution found). Using git annex to manage photo libraries is fantastic, and having to `git annex unlock` a whole directory before editing metadata is very frustrating. A "git annex mode" check box in settings could be used to selectively enable this behaviour if you are concerned with backwards compatibility. I'll have a brief attempt at implementing this in the next hour or so, and if successful I'll make a PR on gitlab/invent. To recap: git annex stores raw files as symlinks to an immutable directory (good, my RAWs won't change), with *.xmp stored as normal files (tracked by ye olde git). Digikam *should* be able to write to e.g. library/IMG0002.CR2.xmp, but refuses to as library/IMG0002.CR2 is an immutable symlink. Digikam correctly *reads* metadata in this case, and will write to it if one does `git annex unlock library/IMG0002.CR2` (which replaces the symlink with a copy of the immutable content, i.e. makes the situation "normal"). Best, kevin -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 404749] New: Feature request/proposed patch: Separate items by pick rating
https://bugs.kde.org/show_bug.cgi?id=404749 Bug ID: 404749 Summary: Feature request/proposed patch: Separate items by pick rating Product: digikam Version: 6.1.0 Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-MainView Assignee: digikam-bugs-n...@kde.org Reporter: f...@kdmurray.id.au Target Milestone: --- SUMMARY The main album view can be separated into categories through View -> Separate Items -> thing to separate on. Currently, one can separate by Album or Image format. I'd love it if I could separate by pick rating, such that accepted images are grouped together. I have experience in C++ programming, including some with Qt, but not the KDE frameworks or digikam. If someone could guide me on where this feature would need to be implemented, I'm happy to provide a patch. -- You are receiving this mail because: You are watching all bug changes.
