Bild in einem Bild suchen
-
so hab mich mal grob drüber informiert, aber das ganze ist ja ziemlich umständlich.
sobald die bmp anders komprimiert ist, kann ich nix mehr mit den daten anfangen
und anders auslesen wenn ich das so weit richtig verstanden habe...da ist es doch mit winapi einfacher denke ich - oder?
achja^^... nein das ist kein aprilscherz :PP
-
Wenn was anderes ist als wirklich einfache datenformate ist es vermutlich einfacher irgendeine bibliothek zuhilfe zu nehmen. Letztlich kann man theoretisch aber auch alles in reinem ISO-C++ machen. Es ist halt dann entsprechend aufwendig.
-
das hab ich mir schon gedacht aber welche bibliothek kannst du mir denn
empfehlen um mit grafiken zu arbeiten?
-
Die WinAPI stellt vermutlich ein paar einfache Funktionen zur Verfügung. Nahezu jede GUI-Framework bietet Klassen um Bilder zu laden und auf die Pixel zuzugreifen. Außerdem gibt's natürlich noch speziellere Bibliotheken, beispielsweise OpenCV. Die können allerdings noch viel mehr als nur Bilder laden. In OpenCV ist ne Kreuzkorrelation ziemlich sicher schon implementiert. Je nach Deinem Erfahrungsstand mußt Du aber auch Zeit einrechnen bis sone Library dann läuft und Du Dir die richtigen Funktionen rausgesucht hast.
Wenn Du also nicht vor hast die Bildverarbeitungsfunktionen von OpenCV zu benutzen würde ich eher zur WinAPI oder ähnlichem raten.
-
hm... kann mir leider das erste bild nicht ansehen "link has been blocked" erscheint da nur, was auf dem zweiten bild ist, kann ich auch nicht erkennen (kaputte kokosnuss?
:p ) , aber so etwas:Phenex schrieb:
1,1 in bild1 == pixel 1,1 in bild2
wird definitiv nicht funktionieren, wenn die beiden bilder in getrennten dateien vorliegen und irgendwie nicht-verlustfrei komprimiert wurden (zb in JPEG = das sieht zwar für den menschen ähnlich aus, die farbwerte werden jedoch alle irgendwie geringfügig verändert).
Ausserdem wird es mehr oder weniger ewig dauern, wenn die bilder größer werden, da lohnt es sich evtl, das ganze zunächst mal in gröbere "verwischte" rechtecke zu zerlegen...
-
Andrey schrieb:
kaputte kokosnuss?
hehe, jep. zum trinken
hatte grad kein anderes bild da.
aber das ist eben ein ausschnitt aus dem ersten bild.Andrey schrieb:
[...] wird definitiv nicht funktionieren, wenn die beiden bilder in getrennten dateien vorliegen und irgendwie nicht-verlustfrei komprimiert wurden
ja das ist ja einer der gründe wieso ich ne toleranz einbauen will.
muss eben das irgendwie voneinander abziehen und den rest dann bis zu einem
bestimmten wert tolerieren...Andrey schrieb:
Ausserdem wird es mehr oder weniger ewig dauern, wenn die bilder größer werden, da lohnt es sich evtl, das ganze zunächst mal in gröbere "verwischte" rechtecke zu zerlegen...
hm was meinst du mit gröberen rechtecken
das ganze soll schon mehr oder weniger genau sein.
-
Du kannst ja versuchen erstmal kleinere Bildauschnitte zu lokalisieren und nur dort wo die passen auch versuchen das ganze Bild unterzubringen.
-
naja aber das kommt ja auf das selbe raus denn wenn die ersten pixel nicht
passen hört er ja eh auf zu vergleichen.
-
Ja okay, aber was ist wenn's nur ähnlich ist und ausgerechnet die ersten Pixel nicht passen?
-
hm ja... aber das ganze bild vergleichen und dann in einer art *prozentzahl* die ähnlichkeit ausgeben ist doch ziemlich rechenintensiv hum?
wenn ich das für jedes möglich rechteck mache - omg
-
Das würde ich als erste mal implementieren. Und anschließend kannste ja noch optimieren indem Du erstmal Bildausschnitte suchst.
-
was meinte ich mit den "verwischten" rechtecken...
hm..Zuerst würde ich gerne folgendes loswerden: ich habe von dem thema absolut keine ahnung, wahrscheinlich ist alles, was ich hier vorschlage schon längst erfunden, mein problem: ich weis nicht, wie das "bereits erfundene rad" heisst...
was ich jetzt gemeint habe: evtl wird das alles um einiges effizienter, wenn man zu den beiden bildern so etwas wie "MIP-maps" erzeugt, also bilder in mehreren qualitätsstufen, wo nach und nach details weggelassen werden
=> du bekommst eine reihe von bildern mit immer kleineren auflösung = mit immer weniger pixel, die zu vergleichen sind.Dann fängst du den vergleich mit der gröbsten stufe an. Für die bereiche, wo es einigermaßen übereinstimmt, nimmst du dann das genauere bild, und fängst wieder an, pixel für pixel zu vergleichen, wenn es immer noch ganz gut übereinstimmt, nimmst du die nächste stufe, und so weiter und so fort...
Das hat einfach den vorteil, dass man mit den groben bildern sehr schnell evtl. ziemlich große bildbereiche wegschmeissen kann, wo es definitiv nicht zur übereinstimmung kommen kann, beispiel:
"Ein kleiner roter apfel (200x200 px) auf einem größtenteils grünen hintergrund (so um die 1600x1000 px)"Da ist es natürlich nicht besonders schnell, jeden dieser 1,6 Megapixel zu überprüfen, stattdessen vereinfacht man besser zunächst das bild, und schaut nach, in welchen bereichen es überhaupt irgendetwas rotes gibt (der ganze apfel wird dann zB von 40000 pixel auf 4, dann auf 16, ... auf 400 usw pixel vereinfacht).
ich weis nicht genau, wie man das am besten umsetzt, glaube jedoch, dass es evtl eine überlegung wert wäre... :p
-
hört sich ja gut an aber ich glaube nicht das ich imstande bin sowas umzusetzen
an alle: danke schonmal soweit - ihr habt mir echt interessante anregungen gegeben. muss jetzt aber wieder los - bin am fr wieder da. melde mich dann mal falls mir nochwas einfällt mfg phen
-
Phenex schrieb:
aber ich glaube nicht das ich imstande bin sowas umzusetzen
damned, ich muss leider zugeben, dass ich im moment auch nicht im stande bin, sowas umzusetzen^^
hab im moment irgendwie keinen kopf für sowas...mal eine richtig interessante frage:
wie vergleiche ich denn beliebig gedrehte fingerabdrücke?