Wie mit Threads Daten von Webcam holen?

[kuhlmaehn]

Hallo,
ich will über eine DLL Daten von einer Webcam holen und verarbeiten. Für die Verarbeitung sind viele Threads verantwortlich, die alle auf die Bild-Daten zugreifen müssen.
Dafür fallen mir jetzt zwei Varianten ein.
1. Es gibt einen zusätzlichen Thread bzw. ein zusätzliches Objekt mit einem Thread, welches nur die Daten von der Kamera holt und alle anderen Threads holen die Daten dann von diesem.
2. Alle Threads holen sich selber über die DLL die Daten der Kamera.

Jetzt bin ich mir nicht sicher, was da besser ist?
Bei 1. könnte es ja sein, dass vor lauter Threads der Kamera-Thread nicht oft genug rankommt und daher die Daten nicht immer auf dem neuest möglichen Stand sind.
Bei 2. könnte es (vielleicht) sein, dass die DLL bzw. Kamera mit den ganzen Anfragen nicht klar kommt. Oder meint ihr es ist normal, dass die DLL von alleine die Daten zwischenpuffert und nicht jedes Mal neu holt?
Wie würdet ihr das machen?
Danke!

[sheel]

Hi

Ich würde Variante 1 nehmen.

Prinzipiell glaub ich erst einmal nicht, dass mir eine DLL eine Arbeit abnimmt, die nicht explizit irgendwo in der Beschreibung steht.
Wenn in der Doku nichts steht, das gebuffert wird, nicht drauf verlassen.

Nur...was meinst du bei 1 genau mit dem "nicht oft genug drankommen"?
Dass der Computer allgemein zu langsam sein könnte? Das wird durch 2 auch nicht besser.
Und alles andere kann man über den Code mehr oder weniger ausgleichen.

[kuhlmaehn]

Naja z.B. auf einem Ein-Kern-Prozessor und mit 50 Threads neben dem "Datenhol"-Thread kann es ja sein, dass der "Datenhol"-Thread die Daten immer nur alle 51 Zeiteinheiten (= wie lange jeder Thread rechnen darf) einmal holen kann. Vielleicht wäre die Webcam aber im Stande, ein Bild alle 20 Zeiteinheiten auszuliefern. Dann würde man ja ganz schön an Genauigkeit verlieren oder nicht?

[sheel]

Was passiert eigentlich in den anderen Threads? Sind die auch zeitkritisch?

[kuhlmaehn]

Die holen sich das Kamera-Bild und durchsuchen ihren Bereich im Bild nach Rot.
Ist also nicht wirklich Zeitkritisch, es wäre allerdings schön, wenn das Bild möglichst aktuell ist.

[sheel]

Willst du die Rotanteile eigentlich speichern/weiterverarbeiten oder nur "in Echtzeit" anzeigen?

[kuhlmaehn]

Ist das wichtig?
Weiß ich noch nicht genau, warscheinlich beides. Erstmal will ich nur etwas in der Konsole ausgeben...

[sheel]

Naja...wenn du nur in einer Gui ein Diagramm oder so anzeigst wäre es ja kein Problem, bei Bedarf einfach ein paar Frame-verarbeitungen auszulassen.
Die Threadpriorität vom Auslesethread raufstellen und das wärs.

So aber musst du dich wohl einfach darauf verlassen, dass der Compute genug Leistung übrig hat.
Der Scheduler teilt schon gerecht auf, das ist nicht das Problem.

[kuhlmaehn]

Ah ok
Ich programmiere in C#, meinst du da ist der Scheduler so schlau? Merkt der, dass wenn Threads Daten aus einem anderen Thread beziehen, dass dieser dann wohl wichtiger ist und daher öfter darf? Das wäre natürlich sehr gut.
Mit der Priorität hatte ich auch überlegt aber in C# gibt es irgendwie nur so absolute Werte, dass dann der Bild-Thread immer zuerst an der Reihe wäre (http://msdn.microsoft.com/en-us/libr...=vs.71%29.aspx).
Aber ich denk, ich verlass mich dann wohl auf den Scheduler. Danke dir

[sheel]

Ich programmiere in C#, meinst du da ist der Scheduler so schlau?

.NET verwendet auch nur den internen vom Windowskernel.

Merkt der, dass wenn Threads Daten aus einem anderen Thread beziehen, dass dieser dann wohl wichtiger ist und daher öfter darf?

Mit den eingebauten Threadsafemöglichkeiten (zB. Keyword lock in c#) kann man das ziemlich gut seinen eigenen Vorstellungen anpassen. Alles eine Frage des Codes.

Mit der Priorität hatte ich auch überlegt aber in C# gibt es irgendwie nur so absolute Werte

Hmm..machen relative Werte einen Sinn? A muss 97.59% von B haben?
Bei deinem Link sind 5 Stufen angegeben. Mit den nativen C-Funktionen hat man Zugriff auf 6.
Und das wars dann auch schon wieder. Die Beschränkung hängt ja auch nicht wirklich von der Programmiersprache ab, sondern wieder mal vom Kernel.

Gruß

[MCoder]

Hallo,

wie ist denn das Thema 'Threadsynchronisation' gedacht? Wenn die vielen Threads jeweils einen Bildbereich verarbeiten sollen, wäre es sicher sinnvoll, dass das mit denselben Bilddaten für alle Threads passiert. Mit Variante 2 kannst du das nicht sicherstellen. Jeder Thread bekommt das Bild, das zuletzt aufgenommen wurde und das kann sich im Verlaufe der vielen Abfragen schon mal ändern.

Es wäre wahrscheinlich sinnvoll, so eine Art Bildmanager zwischen Bildaufnahme (DLL) und Weiterverarbeitung zu schalten, der möglicherweise die Bilder erst mal in eine Queue stellt und für eine geordnete Verteilung bzw. Bereitstellung sorgt.

Gruß
MCoder

[kuhlmaehn]

Hi,
die roten Punkte tauchen zufällig auf aber bewegen sich nicht daher ist es (meines erachtens) nicht wichtig, dass alle Threads das gleiche Bild untersuchen (ein Punkt genau auf einer Grenze mal ausgenommen). Wichtig ist mir halt nur, dass die Punkte so früh wie möglich erkannt werden. So gesehen ist ja Variante 2 eigentlich die richtige, wenn das die Kamera nicht überlastet oder? Das würde ich aber halt gerne irgendwie sauberer umsetzen.

@sheel
Ich hatte eher sowas gedacht wie bei 50 Threads, jeder Thread bekommt 1% und der Bildholer bekommt 50%. Dann wäre er ja quasi immer nach jedem Thread einmal dran aber da könnte man dann ja noch dran rumschrauben