Bitmapverarbeitung

Also sorry, aber irgend wie reißt mich das Projekt mit und lässt mich nicht mehr los.
Eine weitere Frage:
warum musst du 24Bit Farben Speichern, reichen dir 256 nicht? denn dann könntest du schon mal Platz um Faktor 3 einsparen (8Bit pro Pixel).

Gruß Homer
 
Wenn er die erstellten Schnitte tatsächlich medizinisch nutzen will, kann er es sich vermutlich nicht leisten, allzuviel Farbinformationen zu verlieren. Und mit farbindizierten Grafiken kann man sowas ohnehin nicht machen. Aber vielleicht wäre ja ein Kompromiss denkbar, Highcolor oder ein eigenes Format.
 
Hm ja, die Kontraste sind halt nicht überwältigend, also nicht dass die Farben nicht stimmen würden, aber es sind halt alles rot, weiß und braun Töne, die sich nur unwesentlich unterscheiden, aber die die Struktur ausmachen. Wenn ich da mit 256 Farben arbeite, könnte es ziemlich schwammig werden. Vermutlich werde ich die Rechenzeit und den Speicherbedarf zunächst in Kauf nehmen müssen, bis mir was besseres einfällt. Heute fange ich jedenfalls erstmal damit an, eine richtige Struktur in das Projekt zu bringen (schön modular in Klassen), weil ich gewisser Maßen ziemlich drauf los programmiert habe, weil ich anfangs kaum eine Ahnung hatte, wie ich ansetzen soll. Hab halt noch einiges anderes zu tun und komme deshalb nur recht langsam voran.
 
Zitat: "[...]Diese Daten werden nun während der Show von einer Onyx 350 mit zwölf Prozessoren und drei InfiniteReality Graphik-Subsystemen, sechs GByte RAM und einem TeraByte Diskspace gerendert[...]

Jo, echt interessant. Leider stehen mir die Mittel nicht ganz zur Verfügung :rolleyes: ... Vor allem die 6GB Ram wären cool, damit könnte ich den ganzen Datensatz unkomprimiert in den Speicher laden.
Allerdings würde mich der Algorithmus von diesem OpenGL Voluminizer mal interessieren. Dem werde ich mal auf die Spur gehen.
 
So, ich wollte meinen Thread mal wiederbeleben, weil es was neues gibt.
Habe wieder Zeit gefunden um daran zu arbeiten und die ersten Ergebnisse sind da. Ich habe mittlerweile eine Konsequenz gezogen und berechne jetzt nicht mehr "beliebige" Ebenen (zugunsten der Geschwindigkeit, des Speicherbedarfs und vor allem des Schwierigkeitsgrad wegen :rolleyes: ). Stattdessen soll der Algorithmus die Ebenen jeweils orthogonal zur Ursprungsebene berechnen, mit der Möglichkeit die entsprechende Schnittebene in beliebigen Winkeln auf die Ursprungsebene zu klappen. Bisher ist es soweit mit der Frontalebene gelungen. Habe ein JPG angehängt, mit den bisherigen Ergebnissen. Die Ebene schneidet von hinten im 12° Winkel durch den Körper (trifft erst kurz nach den Knien auf den Körper). Wer ein bisschen Fantasie (bzw. besser anatomisches Basiswissen) hat, dürfte auch was erkennen. Es haut vor allem hin!

(P.S.: Es sind noch diverse Verschiebungen zu verzeichnen, weshalb nur bestimmte zusammenhängende Bereiche tatsächlich 100%ig zusammenpassen. Dabei macht der Algorithmus keine Fehler, vielmehr liegt es daran, dass die Ursprungsbilder unterschiedliche Größen haben und ich deswegen "annehme", dass die Mittelpunkte der Bilder übereinander liegen, was jedoch nicht vollkommen stimmt. Muss demnächst mal noch einen Korrekturwert für jedes der 1877 Bilder bestimmen *stöhn*...)
 

Anhänge

  • frontalebene position 0. - winke
    128 KB · Aufrufe: 43
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück