Grüße,
habe nach drei Jahren mal wieder hier reingeschaut und die neuste Version getestet - mit großer Freude sehe ich, dass das Programm immer noch aktiv weiterentwickelt wird. Top!
Weshalb ich eigentlich die neue Version testen wollte, war, um zu schauen, ob die Bildähnlichkeitssuche schneller wurde - ist sie leider nicht. Könnte man das nicht multiprozessmäßig auslagern, da aktuell nur ein Kern auf Anschlag läuft ohne relevantes IO auf der Platte.
Der eigentliche Grund meines Beitrages ist aber ein anderer: Die Suchergebnisse unterscheiden sich signifikant von 4.1.4 (die Version benutzte ich bis vorhin) und sind leider schlechter. Beides nutzt dHash, 70%, 16x16. Ob "Vergleiche nur Bilder mit den gleichen Eigenschaften: Bildausrichtung & Seitenverhältnis" aktiviert sind, macht keinen Unterschied.
Anbei ein Bild mit den unterschiedlichen Ergebnissen. Die der aktuellen Version sind praktisch unbrauchbar. Bei den Bildern gibt es immer genau zwei, die ähnlich sind (leicht andere Farben etc), so wie 4.1.4 es für die meisten korrekt ermittelt hat.
Bildähnlichkeitssuche anders als in 4.1.4
-
- Site Admin
- Posts: 4047
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Bildähnlichkeitssuche anders als in 4.1.4
Das ist leider nicht möglich.
Wir haben die Suche nach ähnlichen Bildern mit der alten Version 4.1.4 und der aktuellen Version verglichen und konnten hierbei noch ein paar Optimierungen durchführen, damit das Suchergebnis in der aktuellen Version weniger falsch-positive Duplikate anzeigt und bei bestimmten Dateitypen noch mehr Duplikate findet.
Danke noch für den Hinweis!
-
- Site Admin
- Posts: 4047
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Bildähnlichkeitssuche anders als in 4.1.4
Neues Update mit den Optimierungen für die Suche nach ähnlichen Bildern ist online. Bitte testen und berichten.
Re: Bildähnlichkeitssuche anders als in 4.1.4
Hallo,
gerade mal getestet an dem Beispiel aus dem OP. dHash, 70%, 16x16.
Generell sind die Ergebnisse wesentlich sinnvoller und es gibt nun wieder auch mehr Gruppen, so wie es bei 4.1.4 der Fall war.
Gefundene Duplikate haben eine etwa zehn Prozentpunkte höhere Übereinstimmung bei jedem Bild als Version 4.1.4 - sowohl richtige als auch falsche.
Bei Bild "88_094.jpg" beispielsweise sind zwei falsche Duplikate nach oben auf die eingestellte 70% Schwelle gerutscht und somit sind es vier Duplikate statt zwei wie bei 4.1.4.
Bei Bild "88_095.jpg" ist wohl Gegenteiliges passiert, denn hier ging es von vier erkannten Duplikaten in 4.1.4 auf nur noch zwei zurück was korrekt ist - die zwei falschen Duplikate von 4.1.4 hatten 70% und 82% Übereinstimmung.
Insgesamt funktioniert es nun wieder so wie es sollte, Danke.
Darf man fragen, warum das Aufteilen auf mehrere Prozesse nicht möglich ist? Die Hashes werden ja komplett unabhängig voneinander berechnet und erst im Anschluss verglichen?
Eine weitere Sache, die mir auffiel: Bei jedem Start, auch wenn die Option für die Datenbank nicht aktiviert ist, wird die Datenbank initialisiert etc. was Zeit benötigt. Aber neben dem Zeitaspekt gibt es ein signifikanteres Problem: Öffnet man eine zweite AllDup Instanz, beschwert diese sich, dass sie nicht auf die DB zugreifen darf und man muss erst eine Fehlermeldung wegklicken. Idee: Wenn "Datenbank bei den folgenden Suchmethoden verwenden" deaktiviert ist, versucht AllDup erst gar nicht auf die DB zuzugreifen.
Danke & Grüße
gerade mal getestet an dem Beispiel aus dem OP. dHash, 70%, 16x16.
Generell sind die Ergebnisse wesentlich sinnvoller und es gibt nun wieder auch mehr Gruppen, so wie es bei 4.1.4 der Fall war.
Gefundene Duplikate haben eine etwa zehn Prozentpunkte höhere Übereinstimmung bei jedem Bild als Version 4.1.4 - sowohl richtige als auch falsche.
Bei Bild "88_094.jpg" beispielsweise sind zwei falsche Duplikate nach oben auf die eingestellte 70% Schwelle gerutscht und somit sind es vier Duplikate statt zwei wie bei 4.1.4.
Bei Bild "88_095.jpg" ist wohl Gegenteiliges passiert, denn hier ging es von vier erkannten Duplikaten in 4.1.4 auf nur noch zwei zurück was korrekt ist - die zwei falschen Duplikate von 4.1.4 hatten 70% und 82% Übereinstimmung.
Insgesamt funktioniert es nun wieder so wie es sollte, Danke.
Darf man fragen, warum das Aufteilen auf mehrere Prozesse nicht möglich ist? Die Hashes werden ja komplett unabhängig voneinander berechnet und erst im Anschluss verglichen?
Eine weitere Sache, die mir auffiel: Bei jedem Start, auch wenn die Option für die Datenbank nicht aktiviert ist, wird die Datenbank initialisiert etc. was Zeit benötigt. Aber neben dem Zeitaspekt gibt es ein signifikanteres Problem: Öffnet man eine zweite AllDup Instanz, beschwert diese sich, dass sie nicht auf die DB zugreifen darf und man muss erst eine Fehlermeldung wegklicken. Idee: Wenn "Datenbank bei den folgenden Suchmethoden verwenden" deaktiviert ist, versucht AllDup erst gar nicht auf die DB zuzugreifen.
Danke & Grüße
-
- Site Admin
- Posts: 4047
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Bildähnlichkeitssuche anders als in 4.1.4
Es ist generell schon möglich. Allerdings müsste dafür der komplette Suchalgorithmus umgeschrieben werden. Dies ist nicht so trivial.Darf man fragen, warum das Aufteilen auf mehrere Prozesse nicht möglich ist?
Die Datenbank wird unabhängig von dieser Option initialisiert, damit die Datenbank-Tools und die Datenbank-Info funktionieren.Wenn "Datenbank bei den folgenden Suchmethoden verwenden" deaktiviert ist, versucht AllDup erst gar nicht auf die DB zuzugreifen.
Re: Bildähnlichkeitssuche anders als in 4.1.4
Auch wenn die Datenbank hier jetzt eher ausgeschlossen war:
Die Datenbank als solche stellt ja auch ein Mittel zur Beschleunigung dar. Wenn nun eine parallele Ermittlung der Hashes im Rahmen eines Suchlaufes nicht "trivial" zu implementieren ist, wäre vlt. ein reiner Scan-Lauf eine Option. Hier könnten dann die Verzeichnisse mit der Datenbank abgeglichen werden und alle nicht bekannten Dateien an parallel laufende Hashing-Prozesse gegeben werden ...
Steht man nun vor einem großen Berg an Vergleichen inkl. der Hash-Berechnungen, könnte man für bestimme Verzeichnisse im ersten die Schritt Hashes in die Datenbank bringen und anschließend die (beschleunigte) Dublettensuche starten.
Viele Grüße,
JoBeCo
Die Datenbank als solche stellt ja auch ein Mittel zur Beschleunigung dar. Wenn nun eine parallele Ermittlung der Hashes im Rahmen eines Suchlaufes nicht "trivial" zu implementieren ist, wäre vlt. ein reiner Scan-Lauf eine Option. Hier könnten dann die Verzeichnisse mit der Datenbank abgeglichen werden und alle nicht bekannten Dateien an parallel laufende Hashing-Prozesse gegeben werden ...
Steht man nun vor einem großen Berg an Vergleichen inkl. der Hash-Berechnungen, könnte man für bestimme Verzeichnisse im ersten die Schritt Hashes in die Datenbank bringen und anschließend die (beschleunigte) Dublettensuche starten.
Viele Grüße,
JoBeCo