Bitmapverarbeitung

[Dudadida]

So, will auch mal einen Thread erstellen. Ich arbeite momentan an folgendem: Vielleicht haben manche von euch davon gehört, dass irgendwann mal in der USA ein hingerichteter Mörder in Scheibchen geschnitten und abfotographiert wurde. Das Dataset, das dabei rauskam, kann man in teilweise veränderter Form in JPG Form downloaden. Es besteht aus 1877 JPGs mit Auflösungen bis rauf zu 1728x1000 (also ganz ordentlich groß).
Ich bin jetzt dabei ein Programm zu erstellen, dass aus den Fotos, die ja alle nur in einer Ebene vorliegen, Schnittbilder BELIEBIGER Schnittebenen erstellt. Der Ansatz ist mir auch soweit gut gelungen, ich erhalte auch meine Schnittebenen wie geplant, das Problem ist nur folgendes: die Geschwindigkeit. Es handelt sich wie erwähnt um 1877 JPGs, die entpackt rund 5GB ausmachen (auf DVD passt's nicht), was ich niemandem zumuten will, dem ich das mal gebe (auch nicht mir selbst). Im schlimmsten Fall muss ich also für ein Schnittbild, dass orthogonal auf den Ursprungsbildern steht, alle JPGs verarbeiten. Meine Frage ist nun, hat irgendjemand einen Ansatz oder eine Idee um diese Sache möglichst effizient zu gestalten?
Derzeit erstelle ich ein Vectorarray, dann mappe ich jedes Bitmap in das Array und erstelle ein neues Bitmap. Auf das Vectorarray zu verzichten, würde zwar Arbeitsspeicher sparen, jedoch zu ungusten der Rechenzeit und die ist derzeit immer noch enorm!

 

[Kachelator]

Ich bin jetzt dabei ein Programm zu erstellen, dass aus den Fotos, die ja alle nur in einer Ebene vorliegen, Schnittbilder BELIEBIGER Schnittebenen erstellt.

Meinst du damit Interpolationen oder auch tatsächlich Schnitte, die schräg liegen?

Einen konkreten Lösungsansatz habe ich auch nicht, aber ich selbst würde wahrscheinlich erstmal versuchen, ein 3D-Modell aus den Daten zu erstellen. Wäre das eine Möglichkeit?

 

[Dudadida]

Tatsächliche Schnitte in beliebigen Ebenen (die per Ebenengleichung definiert werden). Mein Ansatz das zu "verräumlichen" ist ja dieses 3D-Vektor-Array. 3D Modelle dürften schwierig werden, wenn man nicht mal 'ne Ebene hinbekommt (3D Modelle aus diesem Datenset zu erstellen ist sogar noch aktives Forschungsgebiet). Das Problem mit dem Array ist, dass original JPG 1mm auseinander liegt, ein Pixel im JPG aber eine Kantenlänge von 0.3mm hat (oder etwas mehr). Das Vektorarray wird dadurch wirklich riesengroß, ist schon 40MB groß, obwohl ich für die Pixelkantenlänge zunächst nur 1mm annehme, und damit ich die JPGs effizient verarbeiten kann, kann ich nur mehrere Vektorarrays erstellen und ein JPG nacheinander "abhaken" (um "gleichzeitig" mehrere Schnittbilder zu erstellen). Allerdings mag das mein Arbeitsspeicher gar nicht, so dass ich das gleichzeitige Verarbeiten wieder einschränken muss und die JPGs wieder mehrfach parsen muss... Nehme derzeit noch float im Array, vielleicht ist da ein Verbesserungsansatz möglich, wenn ich bspw. mit word arbeiten könnte, allerdings würden so mitunter ziemliche Ungenauigkeiten entstehen.

 

[Kachelator]

Wow! Nebenbei: Das wirft auch eine anderes Licht auf deine Äusserungen im Bezug auf Optimierung in anderen Threads.

Eine Lösung kann ich nicht bieten. Ich würde versuchen, die einzelnen Ebenen zu vektorisieren, um daraus später ein 3D-Modell zu erstellen. Eine Bearbeitung auf Bitmap-Ebene halte ich aus den bekannten Gründen (Datenmenge) für abwegig. Aber es müsste doch irgendwie gehen... *neugierig sei*

 

[Dudadida]

Ich bin bisher so vorgegangen:
1. Ebenen vektorisieren: postulieren, dass jede Ebene in der x-z-Ebene liegt, der Normalenvektor also nach oben zeigt und jede ganze Zahl einem Millimeter entspricht. So bekomme ich 1877 Ebenengleichung mit dem Normalenvektor (0;1;0) und d von 0 bis 1876.
2. 2 Vektoren erstellen: 1. Vektor liegt in x-z-Ebene UND in Schnittebene, 2. Vektor liegt orthogonal zum ersten und in der Schnittebene. Die Vektoren noch normalisieren.
3. Da die Vektoren nun normalisiert sind, kann ich über eine einfache Zählschleife nun das 3D-Vektorarray erstellen. Das macht die Sache für die Bildverarbeitung später einfacher, da der y-Wert im Vektorarray immer der Bildnummer entspricht und ich aus den zugehörigen x und z Werten den Wert im zukünftigen Bitmap berechnen kann.

So, das geht auch alles noch ganz schnell, nur die Größe ist halt wirklich problematisch. Der Geschwindigkeitsflaschenhals ist jetzt aber die JPG Verarbeitung. Hab das Vektorarray bereits sortiert um den den Zählaufwand deswegen nahe 0 zu bringen, trotzdem muss ich noch die blöden JPGs öffnen und bisher fällt mir nur die Lösung ein mehrere Ebenen gleichzeitig zu berechnen, dafür fehlt mir aber der Arbeitsspeicher, mit dem Vektorarrayprinzip bisher. Man müsste irgendwie eine 3D Datei erzeugen, die gleichzeitig komprimiert ist aber auch alle Bildinfos beinhaltet und die sich schnell parsen lässt.

 

[Daniel Toplak]

Interessant !

Also eine Lösung kann ich dir da auch nicht bieten, aber vielleicht eine neue Idee.
Wenn du alle Daten schon nicht ständig verarbeiten kannst/wills, dann müsstest du auf eine vorberechnete Datenmenge zurückgreifen. Diese Datenmenge/Struktur sollte in 3-D vorliegen, da du ja die verschiedensten Schnitte machen möchtest.

Mir würde da jetzt spontan eine Voxel-Engine einfallen.
Die Eigenart einer Voxelengine (für diejenigen die das nicht wissen):
Es werden keine Dreiecke (Polygone) gerendert, sondern sog. Volumenpixel (Voxel).
Diese Verfahren wird heutzutage sehr selten eingesetzt (Performance ist sehr schlecht) der größte Einsatzbereich dürfte wohl die Medizin sein (Dudadiada da solltest du dich doch zurchtfinden).

So ich hoffe das es dich evtl. einen Schritt weiter bringt.

Gruß Daniel

P.S.: dürfen denn teile diese Projekts mal eingesehen werden (neugierig bin)? Oder ist das kommerziell und closed Source?

 

[Kachelator]

Diese Verfahren wird heutzutage sehr selten eingesetzt (Performance ist sehr schlecht) der größte Einsatzbereich dürfte wohl die Medizin sein

Die Performance ist nur im Verhältnis schlecht, weil es bisher keine Hardwareunterstützung dafür auf dem Markt gibt. Deshalb haben Polygonmethoden die Nase vorn.

 

[Dudadida]

An Voxel hab ich auch schon gedacht (mehr oder weniger mache ich das ja auch), das Problem ist nur, dass wenn ich eine einzige Datei erzeugen würde, die sämtliche Pixeldaten beinhaltet (in 24bit), dann wäre die Datei 1728x1000x1877x3 Bytes groß, das sind 9,06GB! Naja, ich werde mir da noch ein paar Gedanken machen, trotzdem danke für eure Anregungen.

@Daniel: Wenn das Projekt ein bissel weiter ist, kann den Source Code jeder haben, der sich dafür interessiert, aber momentan ist es noch ein wenig zu früh.

 

[Daniel Toplak]

Datei 1728x1000x1877x3 Bytes groß, das sind 9,06GB! Naja,

Diese Problematik ist mir bekannt, aber daüf gäbe es auch Möglichkeiten:
- Kompression
- unnötige weglassen und beim Einlesen/Verarbeiten wieder interpolieren.

Nur mal so als Idee.

Gruß Homer

 

[Dudadida]

Ja Kompression, das Problem ist dann wieder der Zeitfaktor. Prinzipiell habe ich ja jetzt schon ein komprimiertes Voxelpaket (1877 JPGs halt ). Unnötige weglassen ist da keine gute Idee, weil es keine so wirklich unnötigen gibt, man sieht schon deutliche Unterschiede zwischen den einzelnen Bildern, wobei man vielleicht tatsächlich durch Interpolation annähern könnte, aber ich möchte eigentlich so wenig verfälschen wie möglich.