Cross-platform Bildverarbeitungs-GUI

Status
Es sind keine weiteren Antworten möglich.

Lorchi

Aktives Mitglied
Hallo zusammen,

seit langer Zeit hege ich einen Traum - ich würde gerne ein Projekt aufsetzen, das Hobby-Astrofotografen eine halbwegs einfach bedienbare, aber erstklassige astronomische Bildverarbeitung ermöglicht.
Das übliche Problem: die Zeit.

Der Hintergrund: ich entwickle beruflich mathematische Bildverarbeitungs-Algorithmen. D.h. ich weiß, was unter der Haube nötig ist, um es nicht perfekt aber sehr gut zu machen. Selbst Programme wie Fitswork stellen mich nicht zufrieden, weil ich leider durch den beruflichen Hintergund sehe, woran es hapert.

Weiterer Hintergrund: das meiste, was nötig ist, gibt es schon irgendwo auf der Welt, ob beim ESO als Teile der Instrumenten-Pipelines, oder bei anderen großen Observatorien. Nur wenige spezialisierte Module müsste ich selber stricken, z.B. unter Umständen die sich um korrekte Behandlung der Daten von Farb-Digikam-Sensoren kümmern, damit jeder Farbkanal ohne Interpolation eine eigene Astrometrie erhält, oder ähnliches.

Eigentlich ist es also ein Patchwork-Projekt, das verschiedenste Sachen miteinander verwursteln würde. Um damit aber wenigstens irgendwo mal starten zu können, und ab und zu mal dran weiterzubasteln zu können, brauche ich erstmal einen Startpunkt für das Framework bzw. die Gui.

Bei allem, was nicht mit GUI zu tun hat, fühle ich mich wohl. Algorithmen schreiben ist ok. Also brauche ich am besten ein Bildverarbeitungs-Programm, das ich als GUI mißbrauchen kann, und das folgende Features anbietet:
- Unterstützung für Plugins, einfache Erlernbarkeit der Schnittstelle
- Wünschenswert cross-platform, aktives Projekt mit vielen Benutzern (also kein absoluter Exot)
- Skripting-fähig
- Unterstützung von Bildern in floating-point
- Wünschenswert: Grafikfähigkeit von Plugins (also so dass man kleine Fensterchen erhält zum Einstellen von Parametern)
- Sehr wünschenswert: Benutzerinteraktion aus Plugin heraus (z.B. sowas wie "bitte klicke auf einen Stern", Rückmeldung der Koordinaten bzw. Zeichnen einer Box oder sowas)

Jemand hat mir von ImageJ erzählt, das das meiste der Kriterien erfüllt.
Kennt jemand vielleicht noch andere ähnliche Tools, oder hat einen Vergleich?
Oder gibt es irgendwelche anderen Tipps?

Bitte erwartet kein Hexenwerk, ich weiß nicht wie es zeitlich hinhaut. Aber ich würde gerne mal damit anfangen, vielleicht hat es ja eine Chance.

Viele Grüße,
Henning
 
Hallo Klaus,
danke für den Hinweis, leider scheidet es aufgrund der 8-bit-Beschränkung absolut aus.
Grüße, Henning
 
Hallo Henning,

ich verwende schon seit Jahren ImageJ (bzw. den Vorgänger NIH-Image) oder den Spin-Off "Image SXM". Bis auf ein vernünftiges GUI hat dieses Programm alles, was du willst. :-)
Die Plugin-Programmierung in Java ist recht einfach, die Pascal-ähnliche Skriptsprache ebenfalls, so dass sogar ich es hinbekam, eine Auswerteroutine für tausende von Bildern zu schreiben.

Viele Grüße
Bernd
 
Also noch eine Stimme für ImageJ. Na dann werde ich mich da mal langsam einlesen!
Dankeschön :)

Viele Grüße, Henning
 
Hallo Henning,

Zitat von Lorchi:
Hallo Klaus,
danke für den Hinweis, leider scheidet es aufgrund der 8-bit-Beschränkung absolut aus.
Grüße, Henning
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

von Gimp gibt es einen Fork, den Cinepaint. Da
ist 16-Bit implementiert. Ich verwende das, um
16-bit Tiffs, die aus HDR-Tools rauskommen, weiter
zu verarbeiten. Seltsamerweise habe ich die Windows-
Version bei mir nicht ans Laufen gebracht, aber
unter Linux kein Problem :D
 
Hmmm hmmm,

das klingt auch nicht so schlecht. Obwohl ich eigentlich vor hatte, per default mit float zu rechnen.
Die Versionsnummer, die noch weit von 1 entfernt ist, irritiert mich etwas. Das muss aber nichts heißen.

Ich habe den Eindruck, dass ImageJ grundsätzlich flexibler ist (durch die Java-Plugin-Schnittstelle kann man da fast alles implementieren). Zusätzlich scheint es in der Wissenschaftswelt gebräuchlich zu sein. Ich kann zwar noch kein Java, aber das lässt sich bestimmt leicht ändern. Da mache ich mir mehr Sorgen um die Tools, die ich im Hintergrund aufrufen will.

Grüße, Henning
 
Hallo, Henning.

Wie ich sehe, bist du auch noch nicht weiter gekommen :(

Wir haben vor ca. drei Jahren schon mal per E-Mail darüber diskutiert,
was alles in so eine Software 'rein gehört und womit man die
Oberfläche programmieren will. Nach der Feststellung, dass wir beide
einen ziemlich ähnlichen beruflichen Background haben, kam aber auch
gleich die Erkenntnis, dass wir beide mit nur 24h/Tag nicht hinkommen,
um alle Ideen, die man so in Bezug auf seine Hobbys hat, umzusetzen :)
Ich habe damals wxWindows und QT untersucht um damit ein GUI für eine
Astro-EBV zu erstellen und bin dann auch angefangen ein kleines
Framework in QT zu erstellen. Aus Zeitgründen ist das Projekt aber
schon im Sommer 2005 wieder versandet.

Mittlerweile würde ich tendenziell eher mit C# und Windows Forms
arbeiten (mit Mono ist man dann auch gleichzeitig in der Linux Welt
(selber an einigen Beispiele getestet)).

Im Grunde genommen, geht es mir aber wohl wie dir: Am liebsten wäre
mir ein vorhandenes Open Source GUI/Framework, auf dem man aufsetzen
kann.

Ich habe mir die letzten Monate Sachen wie MIDAS, IRAF/PyRAF, DS9,
Skycat, gcx, Sextractor, Skycat, ImageJ, AIPS, wcstools, Astrobuffer, ImageMagick (und das waren jetzt nur
die, die mir spontan wieder einfielen)) installiert und
angesehen. Aber es bleibt dabei, dass ich eigentlich was eigenes
brauche :-) Solange bin ich (als Kommandozeilen-Fan) weiterhin bei
Christian Buils Iris und für das finale End-Tuning und die
Beschriftung der Bilder bei Gimp. Wenn man den technischen Background
hat, wie EBV auf Bit-Ebene funktioniert, ist Iris unschlagbar. Leider
ist aber auch hier die GUI grausam und auch die Skriptfähigkeit nur
sehr sehr eingeschränkt nutzbar.


ImageJ ist sehr mächtig, es gibt aber bisher scheinbar nichts was in
Richtung Astronomie/Astrometrie/Photometrie geht und die GUI ist auch
nicht gerade State-Of-The-Art. Leider gibt es hier wohl auch kein
Ebenen-Konzept. Ich habe zwar einiges an Java-Erfahrungen, bin aber
nicht so der Java-Fan ... Aber mit der jetzigen GUI ist ImageJ bei mir
eh schon im Aus.

2004 habe ich von einer Kommandozeilen-Konsole mit Iris-Kommandos für
GIMP geträumt. Der Traum platze aber schnell mit der Erkenntnis, daß
Gimp nur eine maximale Bit-Tiefe von 8 Bit pro Kanal unterstützt. Das
hat sich ja auch mit Gimp 2.4 leider nicht geändert. Aber vielleicht
kommt es, dadurch dass es mittlerweile nicht nur
Astronomie-Bildverarbeiter sind, die dieses bemängeln, sondern auch
die HDR-Digital-Knipser, mal zu etwas mehr Beachtung bezüglich dieses
Gimp-Problems. Cinepaint habe ich übrigens auch getestet: Stabil,
aber bezüglich Features und Oberfläche weit hinter dem aktuellen Gimp
zurück ...

Krita macht in meinen Augen
einen guten Eindruck. Skript-Bar, das Plugin-Interface scheint auch
durchdacht zu sein, Ebenen, modernes GUI, Bittiefen > 8-Bit,
QT/KDE-Basiert (C++) ... allerdings weiß ich im Augenblick nicht, wie
weit es mit der Portierung in Richtung WIN32 vorangegangen ist.

Gruß Frank
 
Hallo Frank!!!

Nee, ich bin gar nicht weitergekommen. Zumindest mit nichts in der Hand außer ein paar Ideen.

Meine Intention hat sich mittlerweile etwas verschoben: einfach nur ne korrekte Hotpixelkorrektur reicht nicht.

Ich arbeite momentan für ein bekanntes europäisches Observatorium, und um mich herum wird "richtige" Bildverarbeitung gemacht. Da steigen natürlich die Ansprüche, und andererseits sehe ich, wieviel es im Grunde schon gibt. Es wird nur eine Kunst werden, das unter einen Hut zu bekommen. Manche Schwierigkeiten treten hier gar nicht auf, mit denen Amateure zu kämpfen haben, wie z.B. Bayer-Grids von Digikams. Dafür wird hier soweit möglich alles mathematisch zerpflückt, um wirklich beste Ergebnisse zu erzielen.

Habe aber zufällig heute Nachmittag mit dem Entwickler von Stellarium gesprochen, und der hat ein Projekt im Auge, das perfekt in eine professionelle Bildverarbeitung reinpassen würde. Er will an einem Hintergrund-Framework arbeiten, das die Klassifikation von Bilddaten erlaubt. Darunter kann man sich ein generisches Speichermodell vorstellen, um Astrometrie (also die mathematische Modellierung der Zuordnung von Pixelpositionen zu Himmelspositionen), Photometrie (also die eigentlichen Pixelwerte mit Rauschen etc.), Modellierung von PSFs, Modellierung der opt. Bandbreiten pro Kanal etc. etc. zu erfassen.

Die Traumvorstellung wäre, dass er das hinkriegt, und ich es hinkriege, vorhandene (sog. Pipeline-) Module, andere Software und eigene Erweiterungen z.B. für Digikams, damit zu verbinden.

Eine GUI dafür zu stricken, ist erstmal zweitrangig, und kann kommen wenn etwas von diesem Grundframework läuft.

Das würde dann z.B. so aussehen:

1.) Kalibration (soweit möglich automatisch, grob skizziert)
---------------
a) Import eines Bildes, hoffentlich als reine Rohdaten (Farbbilder pfui)
b) Zuordnung des Equipments (evt. manuell)
c) wenn von Farbkamera, Aufsplitten in die 4 verschiedenen Bayer-Arrays (z.B. Kanal genannt oder wie auch immer), ab jetzt alles getrennt für die verschiedenen Kanäle
d) Zuordnung des optischen Bandes (vergleichbar mit Farbzuordnung)
e) Durchführung der Astrometrie (subpixelgenau, optische Verzerrungen werden modelliert, Fehlerabschätzung ist selbstverständlich)
f) Offsetkorrektur, Darkframekorrektur, Flatfieldkorrektur (automatische Auswahl der entsprechenden Bilder, Masterdarks und Masterflats wurden vorher automatisch erstellt durch gewichtete Kombination und noch mehr Parametern wie Modelle von Hot/Coldpixeln, Linearität, Temperatur ohne die Temperatur zu kennen), andere Equipment-bezogene Maßnahmen wie z.B. die Elimination von Ripple-Noise, Interferenzen...
g) Bestimmung des Rauschens (evt. verschiedene Rauschmodelle)

So, dann wüsste man schonmal wo jeder Pixel in Raum, Zeit, opt. Band (und jeweilige Unsicherheiten) hingehört. Durch die kanalseparate Astrometrie gehört u.a. atmosphärische Refraktion der Vergangenheit an.

Die Himmelsabdeckung könnte man sich z.B. in Stellarium anzeigen lassen. Ein Benutzer könnte dann eine Region herauspicken, und sich davon ein Bild generieren lassen. Ob das dann im klassischen Sinne mehr ein Mosaik oder ein Stack seiner Bilder ist, braucht ihn nicht mehr zu kümmern, weil alle Daten gemäß ihrer Verfügbarkeit und Exaktheit (Auflösung, Rauschen etc.) verwendet werden. D.h. es würden tatsächlich alle Bilder verwendet, die er je von dieser Region gemacht hat, und jedes noch so schlechte verbessert nur das Ergebnis, weil es nur entsprechend der Fehlerwerte gewichtet wird.

Das ist der Traum. Der Traum geht noch weiter. Denn unter Verwendung der entsprechenden Kalibrationsmethoden lässt sich dasselbe Schema z.B. auch auf Spektrometrie anwenden. Usw. Aber die Frage ist nun, ob es realistisch ist, von diesem Framework einen Prototypen hinzukriegen, der dann schrittweise erweitert werden kann.

Tja nun schaumamal. Um mich darum zu kümmern, bräuchte der Tag 48h...

Ich vergesse also erstmal die GUI, und schau mal, ob sich der Grundaufbau irgendwie definieren lässt.

Zwangsweise sage ich daher mal "bis auf weiteres..."

Viele Grüße,
und danke trotzdem für Deine Anregungen,
Henning
 
Hallo Steffen,

das sieht wirklich gut aus! Nein, nicht nur gut, sondern fast perfekt!

Allerdings nur fast - am liebsten wäre mir schon Freeware gewesen...

Gruß, Henning
 
Hi Henning,

vielleicht hilft dir unsere pipeline weiter:

ftp://ftp.ing.iac.es/mischa/THELI/

THELI ist hauptsaechlich auf C/C++ aufgesetzt und unter GPL lizenziert. Es handelt sich um ein weitgehend automatisiertes Paket fuer professionelle Daten, ich verwende es aber auch fuer meine ST10. Gegenwaertig sind etwa 35 verschiedene (prof) Instrumente unterstuetzt, das reicht von optischen und nah-infraroten multichip-Kameras (WFI, SuprimeCam, HAWK-I) bis zu mid-infrared Systemen wie VISIR. Weitere Instrumente lassen sich leicht hinzufuegen.

Der Funktionsumfang deckt das komplette pre-processing ab, also debiasing, flatfielding, superflatting, defringing, modellierung des himmelshintergrundes etc. Des weiteren findet ein automatischer Abgleich mit astrometrischen Referenzkatalogen statt. Ueber individuelle Distortionskorrektur wird eine Genauigeit von 1/5-1/10 pixel erreicht, die Koadditionsroutine erstellt automatisch auch ein Mosaik.

Das ganze laeuft unter Linux/Unix und auch Mac, und ist sehr modular aufgebaut. Ein Teil ist selbst geschrieben, andere Pakete stammen von Terapix (terapix.iap.fr). Alle Funktionen sind ueber ein recht intuitives GUI zugaenglich.

Darauf aufbauen wirst du fuer deine Zwecke wohl nicht koennen, aber du kannst dir eventuell bestimmte Routinen rauspicken und diese weiterverwenden.

mischa

 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben