<div dir="ltr">Thank you Maik for the quick response.<div><br></div><div>> Otherwise, the unique digiKam file hash may already have changed after the import due to metadata operations during the import, e.g. document name was written or automatic image rotation.</div><div>This is not the case, since my script computes the hash in the same way as Digikam does (i.e. uniqueHashV2) and I can clearly find all the images.</div><div><br></div><div>> Since we already started redesigning the import process in digiKam-8.0.0-Beta,</div>> it would be possible to check for the unique digiKam file hash after importing<br>> the file. However, this would require that all import options that would modify<br>> the file are disabled and that the original file in the digiKam Album has never<br>> been modified<div>That's actually my use case. I'm using Digikam mainly as an image database and don't modify images nor metadata.</div><div><div><br></div></div><div>> This is not really user friendly. A solution with our duplicates search is more conceivable.</div><div>My problems with duplicate search are:</div><div>1. It's quite slow to generate the fingerprints</div><div>2. It's quite cumbersome to remove the duplicates one by one.</div><div>I have a lot of duplicates in my Database and I need to have some automated way of doing this. Maybe I can re-write my script to be based on fingerprints instead of unique hash.</div><div><br></div><div>Cheers,</div><div>Nino</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am So., 5. Feb. 2023 um 12:24 Uhr schrieb Maik Qualmann <<a href="mailto:metzpinguin@gmail.com">metzpinguin@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We already have bug reports and wishes for this import problem. When importing <br>
items from camera devices or USB media, we use a mix of device, file name, file <br>
size, file date to recognize files that have already been imported. The unique <br>
digiKam file hash is not suitable for this as we do not have access to the file <br>
on GPhoto2 devices. Otherwise, the unique digiKam file hash may already have <br>
changed after the import due to metadata operations during the import, e.g. <br>
document name was written or automatic image rotation.<br>
<br>
Since we already started redesigning the import process in digiKam-8.0.0-Beta, <br>
it would be possible to check for the unique digiKam file hash after importing <br>
the file. However, this would require that all import options that would modify <br>
the file are disabled and that the original file in the digiKam Album has never <br>
been modified. This is not really user friendly. A solution with our duplicates <br>
search is more conceivable.<br>
<br>
Maik<br>
<br>
Am Sonntag, 5. Februar 2023, 11:30:20 CET schrieb Nino:<br>
> Hi folks,<br>
> <br>
> I was writing a small script that moves all duplicate images of my<br>
> Digikam database<br>
> to another folder:<br>
> <a href="https://github.com/ninok/digikam-utils/blob/main/move_duplicates.py" rel="noreferrer" target="_blank">https://github.com/ninok/digikam-utils/blob/main/move_duplicates.py</a><br>
> <br>
> To double check that the script did the right thing, I was trying to<br>
> re-import the duplicates.<br>
> I was expecting that the import will mark none of the images as new, but<br>
> instead all of the images are marked as new.<br>
> <br>
> I wrote another script that checks if there is a copy of each duplicate and<br>
> it works as expected:<br>
> <a href="https://github.com/ninok/digikam-utils/blob/main/safe_remove_duplicates.py" rel="noreferrer" target="_blank">https://github.com/ninok/digikam-utils/blob/main/safe_remove_duplicates.py</a><br>
> <br>
> Am I doing sth. wrong? How can I prevent import to import images that are<br>
> already in the database?<br>
> <br>
> Best regards,<br>
> Nino<br>
<br>
<br>
<br>
<br>
</blockquote></div>