Hi,

ich bin Mitarbeiter einer Firma für Bildverarbeitung.
Derzeit bauen wir(also Ich ^^) unsere Anzeigen von Software auf Hardwarebeschleunigung um.

Wir nutzen Qt und dort gibt es bereits vorgefertigte Fenster mit OpenGl Unterstützung.

Das Problem an der Sache ist, ich habe bisher nix mit OpenGl gemacht.
Daher weiß ich nicht genau, wie ich vorgehen soll, bzw welche Techniken ich verwenden soll.

Wir haben derzeit Kameras bis ca 5mPixel. Diese liefern bis zu 15 Bilder die Sekunde.
Später sind auch größere Kameras mit deutlich mehr Pixeln möglich.
Alles ist nur 2Dimensional. Jedes Bild sollte angezeigt werden.

Natürlich müssen die Bilder stark gezoomt werden.
Die Ergebnisse der Bildverarbeitung sollen in das Bild eingezeichnet werden. Natürlich dürfen etwaige eingezeichnete Linien/Punkte nicht während des Zoomens verschwinden.
Dafür wird derzeit das Bild gezoomt die Ergebnisspunkte ebenfalls und anschließend eingezeichnet.
Geht das mit OpenGl eventuell eleganter, z.B. das Bild durch Entfernung der Kamera zoomen, die Ergebnisse auf ein neues Bild zeichnen und dann ebenfalls zoomen und ev übereinander legen?

Wäre sehr nett wenn mir da jemand den Weg erklären könnte bzw. wie welche OpenGl Techniken dafür am besten geeignet sind.

Natürlich sah ich mir bereits das Tutorial 8 mit den 2D Zeichnen an.

In einige andere guckte ich Interessehalber ebenfalls hinein:).

Lg

Ich fasse mal dein konkretes Problem zusammen und versuche mal ein Beispiel zu konstruieren.

Ihr macht ständig Bilder von Objekten die an einem Fließband vorbeifahren. Die Bilder sind dabei deutlich größer als die Anzeigefläche.
Eure Software erkennt die Objekte und du möchtest, nehmen wir mal was einfaches, eine Bounding-Box drumrum zeichnen.

Ist sowas gemeint?

Allgemein ob OGL geeignet ist.

Ja. Wenn du Hardwareunterstützung haben willst gibt es quasi nur OGL und DirextX, wobei letzteres aufgrund seiner "sprunghaften" Entwicklung in der Industrie nicht so beliebt ist. Dort möchte man lieber Planungssicherheit. Wenn du standard OpenGL nimmst, und keine ausgefallenen Techniken einsetzen willst, dann läuft deine Anwendung auch auf älterer Hardware und auch in 5Jahren wird deine Anwendung noch laufen.

Um in das Thema reinzukommen sind unsere Tutorials natürlich kein schlechter Weg. Auch wenns erstmal nur um 3D geht. Das was du dort lernst, kannst du auch auf 3D übertragen.

OpenGL besitzt weiterhin eine 2D Projektion (glOrtho). Allerdings könntest du auch mit 3D dein Problem angehen. Eine erste Idee von mir dazu: Du mappst dein Photo als Textur auf ein einzelnes Quad und schiebst es soweit nach hinten, dass es bildfüllend ist. Davor zeichnest du deine Bounding Box mit gleicher Skalierung.

Durch diese Methode übernimmt OpenGL das kleinzoomen.

Jetzt die Frage an die anderen DGLer: Ist das auch performant? Oder was denkt ihr?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Die wichtigste frage wäre erst einmal welche OpenGL version vorausgesetzt werden kann. Zwar sind texturen die einzige sinvolle lösung, jedoch muss auch da einiges beachtet werden. Zeichnen von Overlays lässt sich ebenfalls mit texturen lösen.

_________________
Lumina plattform unabhängige GLSL IDE

Hi,

und vielen Dank für die Antworten.
Die OpenGL Version ist erst einmal egal. Wichtig ist, es muss laufen. Je niedriger die benötigte Version ist, desto besser natürlich und umso leichter+konstengünstiger können wir später bei Kunden upgraden.
Wenn ich mir allerdings die Kurzbeschreibungen zu den Versionen anschaue, dann sollte es wohl mind Version 2.0 sein, da unsere Bilder eig nie 2(exp n) Außenmaße haben. Vor allem sollten später keine Probleme auftrene, wenn neuer Kameras mit noch höheren Auflösungen erscheinen. Die größten derzeit liegen im Bereich von 16mPixel.
Ich hoffe, das sprengt nicht den Texturrahmen. Wenn ja, gäbe es zu Texturen alternativen?

Die Bilddaten liegen als unsigned char* vor (C++). Bisher fand ich nur Funktionen wo ich eine Textur als Datei übegeben konnte. Geht es ev auch ohne den Umweg?

@Flash

Genau aus dem Grund der Planungssicherheit sollte es OpenGL sein:). Netterweise liefert unsere Graphische Bibliothek schon fertige OpenGL Fenster mit, wo ich mir den ganzen Initialisierungs und Context-Spattel sparen kann*freu*.

So in etwa würde es ablaufen. Bild aufnehmen, verschiedene Kanten/Winkel/Durchmesser/Konturen etc messen, und dann einzeichnen.

LG

Wenn die Bilder größer werden, dann muss man sich andere Sachen überlegen.
z.B. ist es physikalisch nicht möglich auf einem Bildschirm mit einer vorgegebenen Auflösung die zusätzlichen Informationen größerer Bilder auch darzustellen.
Du hättest quasi zu viele Infos für's Display.
Der Erste Schritt wäre also die Implementierung einer Texturskalierung, da du sonst die überdimensional großen Bilddaten jedesmal an die GraKa übertragen müsstest.
Falls jemand reinzoomt, dann wäre noch eine Mothede sinnvoll, die feststellt, welche Teile der Textur angezeigt werden sollen, und dann den entsprechenden Ausschnitt aus der Textur an die GraKa überträgt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Mit glTexImage2D kann man auch Bilddaten in vielen Formaten auf die Grafikkarte laden. Jede Funktion, die Texturen aus einer Datei lädt wird das früher oder später aufrufen.

16mPixel würde ungefähr einer Textur von 4096x4096 entsprechen. Bei 4 byte pro Pixel sollte das größte Problem sein, dass die Grafikkarte nur 64MB Speicher hat. Denn dann würden die Daten höchstwahrscheinlich im Arbeitsspeicher abgelegt werden, was die ganze Sache dramatisch verlangsamen würde.

Die Funktion schaut schon sehr gut aus:).

Wenn 64MB nicht reichen, muss halt ne Graka mit mehr Speicher rein oder funktioniert das nicht so einfach?

Ich muss mich bissi entschuldigen, ich war beim Zoomen "etwas" ungenau. Ich meinte mit Zoomen eigentlich Skalieren. Bilder werden bei uns meist in Autoskalierung mit der maximalen verfügbaren Fläche angezeigt(Höhen-Breitenverhältnis bleibt erhalten). Je nach Wahl des Nutzers können auch mehr wie ein Bild angezeigt werden, wobei der Skalierungsfaktor dann recht groß wird und nur noch 20-30% vom eig Bild übrig bleiben. Der Faktor hängt natürlich von der Kamera ab.

Wird das Bild nicht in irgendeiner Form skaliert, erfolgt die Bildanzeige mit ScrollBars. Dafür bieten die OpenGL-Fenster gute Unterstützung.

Mir geht es vorallem darum, das es nicht nur mit einer 5MPixel Kamera funktioniert, sondern auch halbwechs zukunftssicher ist.

Reicht es dazu, das Bild per glTextImage2D auf die Graka zu laden, die Ergebnisse der Berechnungen ebenfalls als 2. Textur, die dann per Overlay(wenn ichs richtig so verstanden habe) zu verschmelzen und dann einfach noch ne art Draw aufzurufen? Zusätzlich noch die Kamera für die Skalierung auf die richtige Entfernung setzen.
Wenn ja, klingt es recht einfach, wird bei meinen bisherigen OpenGL Kenntnissen aber garantiert lange dauern und bei euch hoffe nicht die Haare zu Berge stehen lassen:).

LG

Edit: Habe mir die Funktion noch einmal angeschaut. Lese ich das Falsch oder müssen die Texturen 2(exp n) groß sein? Wenn ja würde das Probleme verursachen. Meine aktuellen Kameras haben ca. 2450x2000 und 1400x1050 Pixel.

Hängt wieder von der Karte ab.

Also, das Skalieren würde ich vorher auf der CPU erledigen - du bekommst das Bild ja eventuell nicht vollständig auf die Grafikkarte übertragen. Dann würde ich gleichzeitig auch einen Rahmen (schwarz) um das Bild legen, um es auf power-of-two-Größe zu bekommen. Dann hast du zwar "etwas" mehr Speicher, kannst aber auch ältere Grafikkarten unterstützen.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Da es nur Upgrades für unsere Systeme gibt wäre das mit der Abwärtskombatibilität nicht allzu tragisch. Bei den hohen Maschinenkosten fallen Upgrades auf eine neue Generation von Software von 200-300 Euro für neues Boards+Grakas nicht so arg ins Gewicht. Vornehmlich wird eh für die neuen Maschinen entwickelt.
Man weiß ja, Never Change a running System:).

Zu überlegen wäre es natürlich, die Texturen mit schwarzen Flächen auf volle 2^n aufzuboren und die Kamera anzupassen. Käme drauf an ob es dann schneller ist. Einfach das Schwarz durch den Alphawert abschneiden geht aber nicht, da in den Bilden auch legitime schwarze Bereiche sein können.

EDIT:

Nach 2h tuen sich weiße Flächen auf. Allerdings weiß ich nicht obs an der Graka liegt, unterstützt laut GL_Version auslesen 2.0.1 oder daran das die Textur fehlerhaft gebunden ist.
Leider liefert glTxtImage2D keine wirklich dollen Aussagen über den Erfolg.

Da ich drzeit nur S/W-Kameras habe, hoffe ich, dass ich mit format/internal format mit GL_RGB und der Einstellung unsigend byte richtig liege.
Vor allem weiß ich derzeit nicht, wie ich die Textur aktivieren soll.
In den Beispielen war immer etwas drin wie:

Die Zeile 1 habe ich drin, aber ich bekomme irgendwie keine Bezeichnung für die Textur als GLuint.
Daher ist Zeile 2 bisher nicht möglich.

Wie kann man die Textur mit Schwarzflächen auf einen 2^n erweitern?

Du musst die Textur vorher per glGenTextures() erstellen. Dann bekommst du auch eine ID zurück. Am besten du liest dir mal das Texturen-Tutorial duch, da wird alles erklärt.

Ob GL_RGB das richtige für dich ist, kommt darauf an, wie die Daten im Speicher liegen. Sind es wirklich nur einzelne Graustufenwerte, musst du GL_LUMINANCE nehmen.

Zum erweitern musst du erstmal ausrechnen, was der kleinste passende 2^n Wert für deine Textur ist. bei 1024x768 wäre es dann 1024x1024. Das rechnet man in etwa so aus:


Danach holst du dir newWidth * newHeight * [Pixelgröße] Bytes an Speicher. Die Pixelgröße hängt natürlich von deinem Format ab. Dann füllst du den ganzen Speicher mit EDIT: 0x00, was schwarz bedeuten sollte. Danach kopierst du einfach Zeile für Zeile deine Bilddaten dort rein.

Hi,

das mit dem glGenTextures habe ich grade probiert:). Klappte aber leider nicht. Ich glaube aber es liegt an meiner Graka. Fülle ich alles ohne Textur, und nur mit den schönen Frabüberläufen pro eckpunkt klappt es. Die GL_VERSIOn 2.0.1 ist wohl doch nicht so 100% eingebundn wie gewünscht. Ich probiere das heute abend mal daheim mit meinem Rechner, der hat ne 8800Gts, die sollte da mehr Unterstützung bieten.
Min Testcode sah so aus:



Das erzeugt mir derzeit einen Schwarze Fläche von 1020x770(Bildgröße des Testbildes(also meiner Textur)) mit einer 500x800 weißen Flache links unten.

Was ich noch sah:
http://wiki.delphigl.com/index.php/glTexSubImage2D, wäre das was für mein Problem?. So wie ich das Verstehe, generiere ich damit keine neue Textur, sondern tausche nur den Inhalt aus. Meine Bilder sind ja immer gleich groß. Die Kamera ändert ja nicht plötzlich ihre Auflösung. [/code][/quote]

Du musst die Textur vor glTexImage2D binden, sonst geht das schief. glTexSubImage2D solltest du auch benutzen, weil es eben nur die Daten verändert.

Außerdem musst du glGenTextures() nur einmal am Anfang aufrufen. Du willst ja nicht immer eine neue Textur, sondern nur einen anderen Inhalt.

0xFF = 255 = maximalwert = weiß, zumindest bei allen Farbsystemen, die ich kenne .

Generell gilt, dass glTexImage2D und glGenTextures möglichst außerhalb der Renderschleife liegen sollten (weil "teuer"). Für aktualisierungen sind dann glTexSubImage2D und glCopyTexSubImage2D angebracht.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Oh, natürlich habs schnell editiert.