https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #28 from caulier.gil...@gmail.com ---
@Daniel,
This problem still reproducible with the new digiKam 8.2.0 pre-release Windows
installer available at usual place:
https://files.kde.org/digikam/
This new bundle is based on last Qt framework
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #27 from caulier.gil...@gmail.com ---
Hi all,
digiKam 8.0.0 is out. This entry still valid with this release ?
Best regards
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=407049
caulier.gil...@gmail.com changed:
What|Removed |Added
Version|6.1.0 |7.0.0
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #26 from Daniel ---
Still happens to me on 7.0.0. When importing the same picture from a different
hardware medium than originally imported (a file copy, from hdd instead of
SDcard, etc), it doesn't mark as already imported.
--
You are rec
https://bugs.kde.org/show_bug.cgi?id=407049
caulier.gil...@gmail.com changed:
What|Removed |Added
CC||caulier.gil...@gmail.com
--- Comment
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #24 from Maik Qualmann ---
All fine, yes that's the only way to avoid duplicate image at the moment.
DigiKam has grown over the years, the import tool should only prevent that
imported images from the camera's memory card are not re-importe
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #23 from Martynas Brijunas ---
@Maik - thank you for clarifying. Perhaps I fundamentally misunderstood how
digiKam works (I am mostly used to Picasa). From what you are saying I am
getting the impression that there is no way for digiKam to a
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #22 from Maik Qualmann ---
The import tool does not look in the "Images" table, but in the
"DownloadHistory" table. A file that was not imported with the import tool will
not be recognized. A possible 1 hour difference is calculated in the
"
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #21 from Martynas Brijunas ---
I think I have found one important detail. I looked at the DB to see how
digiKam sees the files it chooses to import despite them already present in one
of the albums. It turns out that the existing file and th
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #20 from Maik Qualmann ---
Everything is fine, it's just an explanation that "Download New" in the import
tool has nothing to do with the similarity search at the moment. If you add new
images you have to do this first. Then update the finge
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #19 from Martynas Brijunas ---
@Maik - without trying to add gas to the fire - I am merely reporting an issue
from a user perspective, without fully knowing what goes under the hood. It is
a genuine problem when trying to reconcile several d
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #18 from Maik Qualmann ---
Again, the digiKam import tool does not use the fingerprint signatures. There
are several reasons for this. Depending on the device used, we may not have the
complete image data available when importing. And some d
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #17 from Martynas Brijunas ---
My test is based on the knowledge (manually checking) that the photos already
exist and have been found by digiKam. By "found" I mean digiKam has run "Scan
for new items" and generated hashes. I have also run "
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #16 from Maik Qualmann ---
If you add new images, you have to update the fingerprints. Did you do this?
And yes, it is a signature of the image data, not the metadata.
Maik
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #15 from Martynas Brijunas ---
Unfortunately, 7.0.0-RC seems to still have the same problem. The steps that I
described on 2019-04-29 for version 6.1.0 still result in an incorrect
behaviour. Photos are recognised as existing only if I allow
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #14 from Martynas Brijunas ---
(In reply to Maik Qualmann from comment #13)
> Use the digiKam-7.0.0-RC version. The release will be in July, over 700 bugs
> have been fixed and we need fresh feedback.
>
> https://files.kde.org/digikam/
>
>
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #13 from Maik Qualmann ---
Use the digiKam-7.0.0-RC version. The release will be in July, over 700 bugs
have been fixed and we need fresh feedback.
https://files.kde.org/digikam/
Maik
--
You are receiving this mail because:
You are watch
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #12 from klaus ---
Maik, I can agree, right now it does appear to be working with 100% Similarity
among albums/folders I'm working with now. Strange how my initial test case
was clearly not working. Hopefully I can find something more repr
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #11 from Maik Qualmann ---
I can not confirm. Identical images can be found with 100% setting in different
albums.
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #10 from klaus ---
One more comment - There still seems to be some room for improvement with this
Similarity/Duplicates Search. Even with a range of 99/100 the system couldn't
find a file that is a straight duplicate in 2 separate folders.
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #9 from klaus ---
Eureka! I just found out that my Similarity min/max range of 100/100 was too
strict.
When I change the similarity range to 99/100, the search found all my
duplicates!
Hopefully this helps!
--
You are receiving this ma
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #8 from klaus ---
Created attachment 129334
--> https://bugs.kde.org/attachment.cgi?id=129334&action=edit
Success case where image search found all 3 duplicates.
Here you can see in the Image search tab, the digiKam was able to find all 3
https://bugs.kde.org/show_bug.cgi?id=407049
klaus changed:
What|Removed |Added
CC||kmon...@gmail.com
--- Comment #7 from klaus ---
Create
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #6 from daniel-other+kde...@dadosch.de ---
Also, importing via MTP doesn't work properly (not a digikam issue), but I copy
the files using adb instead. However, duplicate photos aren't detected when
importing. Maybe it would be possible to us
https://bugs.kde.org/show_bug.cgi?id=407049
daniel-other+kde...@dadosch.de changed:
What|Removed |Added
CC||daniel-other+kdebug@dadosch
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #4 from Martynas Brijunas ---
(In reply to Maik Qualmann from comment #3)
> I do not know if you're starting with digiKam. But you do not need to import
> images. As an example the images are under Windows in the pictures
> directory. Then y
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #3 from Maik Qualmann ---
I do not know if you're starting with digiKam. But you do not need to import
images. As an example the images are under Windows in the pictures directory.
Then you select this folder as a lokal collection. DigiKam a
https://bugs.kde.org/show_bug.cgi?id=407049
--- Comment #2 from Martynas Brijunas ---
It sounds as if it might be the best practice to start with an empty album and
"import" the entire old directory structure to "familiarize" digiKam with its
content.
--
You are receiving this mail because:
You
https://bugs.kde.org/show_bug.cgi?id=407049
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #1 from Maik
29 matches
Mail list logo
