New digikam user - questions/comments

[Rajesh Varadarajan]

On Sun, Jun 15, 2025 at 10:49 AM Rajesh Varadarajan <rajeshvar at gmail.com>
wrote:

>
>
> 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.
>>
>
>

I ended up installing this package and that fixed the issue.

>> sudo dnf install libavcodec-freeworld



> 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.
>
>
The MP4 import from the DJI causes my MP4's to be duplicated as _v1.




>
>
>> >
>> > 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/20250618/0b3440bc/attachment.htm>