Dear digiKam fans and users, following the long stage of integrating a lots of work from students during the Summer of Code we are proud to announce the first beta of digiKam 6.0.0.
Improvements and Fixes The next major version 6.0.0 looks promising, and will introduce new features as:
Full support of video files management working as photos. An integration of all import/export web-service tools in LightTable, Image editor and Showfoto.
This is a companion discussion topic for the original entry at https://www.digikam.org/news/2018-08-19-6.0.0-beta1_release_announcement/
4 Likes
Looking forward to the 6.0 stable release! This sounds like some awesome new features!
For photos I have darktable, but video support is awesome! Was waiting for a video dam for too long already. Great news, congratulations to the devs for this tremendous progress (I mean the whole thing, not just the videos) 
.
3 Likes
Sounds great. Sadly the beta crashes without further notice after the second dot in the startup window (Windows 10 X64). Setup assistant worked as usual.
I think Gilles fixed that issue last night. You can try to download again and re-install.
Hmm. The build in the repository still has a datestamp from the 19th. So I’ll wait a few days and look again.
This build works. Thanks!
Awesome!
I’ve really come to like using digikam as a DAM.
1 Like
What I don’t like with digiKam is the mix of icons - especially on the tools page. Anything I can do about it (Windows)?
Video improvements is great. Videos could have even more tools available. Such as rotate?
Other than much VideoLAN (VLC) will soon bring forth open source video editor/creator: VLMC, open source video editor - VideoLAN
That VideoLAN project has been there aty least a year and a half with little progress, so I don’t know about “soon”.
I think you can right click on a video to rotate.
Just now digiKam 5.9 on Gentoo quit with a segmentation fault when it encountered an XCF file it didn’t like (i seemed fine with several other XCF files in the same folder).
So I downloaded the digikam 6 beta 1 appimage from here:
https://download.kde.org/unstable/digikam/
which upon attempting to start dies with this message:
$ ./digikam6b1.appimage
-- digiKam AppImage Bundle
-- Use 'help' as CLI argument to know all available options for digiKam application
digikam: error while loading shared libraries: libgssapi_krb5.so.2: cannot open shared object file: No such file or directory
Looking “error while loading shared libraries: libgssapi_krb5.so.2: cannot open shared object file” up on the internet brings up similar problems with various other applications on various Linux distributions, including this one regarding Gentoo:
https://github.com/Subsurface-divelog/subsurface/issues/917
Returning to the segmentation fault when trying to use digiKam 5.9 to browse through the image files in the folder with the problem XCF file, here’s the error message when digiKam 5.9 encountered the XCF file that it didn’t like:
digikam.metaengine: Cannot load metadata from file (Error # 11 : /home/elle/Digikam/Digikam-collections/paintings/brush-and-paper-size-testing/3000x3000-digikam-segfault.xcf: The file contains data of an unknown image type
digikam.dimg: "/home/elle/Digikam/Digikam-collections/paintings/brush-and-paper-size-testing/3000x3000-digikam-segfault.xcf" : QIMAGE file identified
Segmentation fault
I’ve reported bugs and problems with digiKam segfautling when encountering specific XCF files several times over the last years, as have a few other people.
In case it might be useful, here’s the XCF file:
3000x3000-digikam-segfault.xcf (261.9 KB)
Edit: I’d be very happy if digiKam would just skip past the files it doesn’t want to read. The problem is that instead of skipping these files, digiKam crashes.
digiKam needs a more graceful way to handle files that it can’t read.
To ignore this kind of image type, go to setup/Views/Mime-Types and add “-xcf” in image text field.
Hmm, yes, well, I don’t want to ignore XCF files. I want to use digiKam to keep track of XCF files.
I solved the immediate problem by using the solution I came up with before, which is to build kimageformats modified to remove support for XCF files, and then reinstall digiKam to use this modified version of kimageformats.
This way, when I use digiKam, digiKam doesn’t try to read XCF files, and so doesn’t seg-fault. But then in digiKam I add XCF files as a file type to include. This way at least I can see when there really are XCF files to go with the raw files, tiffs, and etc, and I can tag the XCF file, even though it doesn’t have any thumbnail.
I had somehow inadvertently built digiKam to use the default kimageformats installed by Portage, which is why digiKam started segfaulting again.
Nonetheless, my “solution” is only half a solution, and no solution at all for people who can’t or don’t want to modify and build software from source.
Please see this bug report for GIMP:
And this bug report for KDE/digiKam:
https://bugs.kde.org/show_bug.cgi?id=360821
As noted by Boudewijn (comment 22 in the kde bug report), making digiKam or kimageformats read all of the XCF file and generate a thumbnail isn’t a good option. Instead, I’m guessing the better option is to embed a thumbnail in GIMP that kimageformats can actually read. But this probably requires some feedback from KDE folks as to what kimageformats looks for - I’m guessing, I don’t know.
What I do know is I have a lot of XCF files and I’d very much like to use digiKam to keep track of them 
Again: I needed to reinstall Win OS therefor DK B1 as well. But the beta isn’6t yet again starting up… After quick setup (launch setup) and pointing it to previous DB location.
Looking forward for B2!
What version(s) of Mac OS are supported in 6.0 moving forward? I get an error when launching and a message about the OS version. Thanks.
Just FYI in case anyone else runs into this; I was able to install and run Beta 2 without issue, so I’m not sure what happened with Beta 1. I’m on OS X 10.11.6 still.