New digikam user - questions/comments

[Rajesh Varadarajan]

On Sun, Jun 15, 2025 at 1:23 AM Gilles Caulier <caulier.gilles at gmail.com>
wrote:

> Le dim. 15 juin 2025 à 06:30, Rajesh Varadarajan <rajeshvar at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20250615/ad9545ae/attachment.htm>