Re: New digikam user - questions/comments
Rajesh Varadarajan <[email protected]>
| Newsgroups | gmane.comp.kde.digikam.user |
|---|---|
| Message-ID | <CAGcysa30txqNOaT1RnDTdWOHJwFavH+YJr2oY-Qs_xvjO+a2nA@mail.gmail.com> |
On Sun, Jun 15, 2025 at 1:23 AM Gilles Caulier <[email protected]> wrote: > Le dim. 15 juin 2025 à 06:30, Rajesh Varadarajan <[email protected]> a > écrit : > > > > I've started using digikam 8.6.0 on linux (fedora 42) over the last 2 > weeks, really impressed with how mature it is. > > Thanks... > > >I experienced a couple of issues/and have a couple of questions, but I > could not find a specific answer in the archives (at least in >2025). > > > > 1) Once an import is complete, is there a way for me to look at a log > file to see what happened in the last import. Better still, a running log > show the import process will also be useful. > > There is a small log view in the import tool. Look at the option > View/Show History > > > https://docs.digikam.org/en/menu_descriptions/menu_importtool.html#the-view-menu > > Thanks Gilles for the quick response. I will check this out in my next import. > > > > 2) I have a Canon EOS R6 camera and I imported the photos/videos using > the USBC connection from the R6 to the linux fedora laptop. The SD card > filesystem is formatted as an ex fat -- some video files are > 4G, > however, fedora 42 uses the gphoto2 PTP interface and all files > 4G > (typically large video files) show as size 0. digikam did not give any > notifications or popup information about the import warning me of size 0 > file imports, it will be nice for digikam to give this notice in BOLD -- so > that less attentive users don't nuke their photos/videos thinking that > their import was successful. > > > > My understanding is that this limitation is to do with the 32 bit limit > size field in the PTP protocol, is there a way to get around this and > continue to use the PTP. The alternative is to pull the SD card out and use > an SD card reader and as long as it is mounted as ex FAT, the file size > seems appropriate and the import went ok. > > Yes, it's probably a limitation (and mostly a bug) in the gphoto2 > driver. Uses a USB SD card reader instead of the camera/Gphoto2. > > Note : it's not a limitation of exFat which supports files of >4Gb. > > https://github.com/gphoto/gphoto2/issues/526 > > > Thanks for the pointer -- yeah this is quite a dangerous issue as such. > > > > 3) I also have some DJI footage and the video's from here are not > playing (4k HEV?) -- what packages do I need in linux to make this work? > > ffmpeg + libde265 support. as HEV format is patented, this codec is > not included in standard ffmpeg. > > You can use the AppImage bundle that we provided, this one is included. > Ah ok -- let me look into that -- I will try to compile libde265 from source if possible. Do you in general recommend the AppImage -- are there other advantages of using the appImage vs what comes stock in fedora 42 when I install the digikam package? > > > > 4) As I am a bit paranoid about losing photos/videos, I'd like to have a > script that runs a hash function like md5 on the photo/video on my SD card > and verify that the image with the appropriate hash exists in the sqlite3 > db of digikam. However, I don't see the specific hash function being > documented. The hash value in the Images sqlite3 table does not seem to be > md5. What algorithm is being used and can a user run this hash algorithm on > an image outside of the UI? This would improve the fidelity of the import > at least in my mind. I'm sure other advanced users would appreciate this. > > The digiKam database, for performance reasons, does not compute an MD5 > sum over the whole files, but only on the Exif bytearray, to identify > the changed files on the media. Typically the metadata for a speedup > reading are mostly written on the first chuck of the files and when a > file is changed, the metadata is also updated. > > > https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/dimg/dimg_metadata.cpp?ref_type=heads#L22 > > thanks! For MP4 files, the duplicate import detection did not work for some reason -- I ended up running a md5sum check against my files and removed the files that were identified as duplicates by md5sum. > > > > 5) In step 2 above, when I first imported using PTP (and > 4G files were > missing) and then later switched to importing using the SD card, all the > photos/videos were duplicated with _v1 suffixed to the duplicates. So, what > is the method that digikam uses to determine if a photo is new or not. I > selected the Download new in the 2nd import using the SD card. > > It uses the same algorithm as point 4/ to identify the file already > registered in the database. > > thanks! > Best > > Gilles Caulier >