Defunct
Aktives Mitglied
Ohne weitere Einleitung:
Aus gegebenem Anlass bin Ich gerade dabei mal zu schauen, welche potentiellen Fehlerquellen bei Mosaiken und bei Drizzel interpolierten Bildern so zu Artefakten wie z.B. "eckigen Pixeln" beitragen koennen.
Wie vielleicht einige von euch wissen und um mal Loriot zu paraphrasieren: "Im mathematischen Sinne heisst ja "Interpolieren" nicht nur "Interpolieren" ...
Interpolation ist in PixInsight (und nicht nur da, das betrifft eigentlich alls Astroprogramme) "Kerngeschaeft", dass fuer eine Vielzahl von darauf aufbauenden Algorithmen wie pixel binning, FastRotation, Resample, Rotation, DynamicCrop, StarAlignment, ImageRegistration, Mosaic_by_Corrdinates, [... und noch vielen mehr ...] verwendet wird.
Vielleicht sollte man sich da erst mal etwas einlesen, siehe z.B. hier:
pixinsight.com
Als soliden Startpunkt und zwecks Vergleichbarkeit habe Ich mir auf die Schnelle ein "einfaches Testbild" mit ein paar Sternen im Zustand des "Undersamplings" in Matlab gezaubert:
Was ihr da oben seht, ist nicht das Originalbild, sondern bereits gezoomt (also - hehehe - auch schon Interpoliert). Aber das mit der primitivsten Methode, naemlich nearest neighbor sampling, die die Form der "Sternenpixel" auch schon wieder veraendert (die werden "rechteckig" und bleiben nicht etwa punktfoermig). Das wirkliche unveraenderte Original hat tatsaechlich nur vier einzelne "Hotpixel", von denen sich zwei in der Diagonale "beruehren").
Und jetzt schauen wir mal wie ein "einfacher" Algorithmus so ein Bild heraufinterpoliert, in diesem Fall mit einer linearen Interpolation mit Matlab:
und so schlecht schaut das gar nicht aus. "Schlecht" heisst hier: Aesthetisch fuer ein Astrobild grob uebergriffig...
Nun werfen wir mal auf dieses Problem eine der eigentlich "besseren" Methoden, eine Interpolation mit Bicubic-Spine-Funktion als Kernel (cubic spline in 2D):
und das sieht mit Verlaub gesagt beschixxen aus. Ohne in eine Vorlesung abzurutschen, aber was das eigentlich macht, dass kann man sich hier anschauen Bicubic interpolation - Wikipedia und solche Interpolationen tun sich mit Daten, die tatsaechlich "Stufen" haben und keine "sanften" Uebergaenge ziemlich schwer. Was die dann produzieren sieht nicht schoen aus.
Aber um auch mal zu zeigen, dass es auch ganz anders geht, werfen wir jetzt den Rolls-Royce der hier zulaessigen Interpolationen an und machen eine Fourier Interpolation mit kreisfoermiger Apodisation (ach was klingt der Buzzword Bullshit immer so toll ...) und wenn schon denn schon dann gleich um einen Faktor fuenf:
*zwinker zwinker* Na?
denn das schaut dann schon mal gar nicht schlecht aus (Mal nebenbei: Dem reflektierten Publikum faellt uebrigens gerade auf, dass es in der Astrofotografie offenbar das beruehmte "Undersampling" nur in den Koepfen derer gibt, die die "Gassenhauer-Kernel" aus der Bildverarbeitung verwenden. Denn die beruhen darauf, dass die digitale Aufloesung hoeher ist, als die optische Aufloesung. Wenn das nicht der Fall ist, na dann nimmt man besser die Sachen, die dafuer geeignet sind. Was da oben lief ist - mal verstaendlich ausgedrueckt - sowas aehnliches wie "digital abblenden" und macht aus einem Bild mit vermeintlich "eckigen Pixeln" ein wunderschoenes Astrobild, Beugungsringe inklusive. Die Vorinformation die man da hinein gesteckt hat ist ganz einfach, dass die tatsaechliche PSF mindestens eine Besselfunktion enthielt, weil der Lichteimer nun mal rund ist und man deshalb nicht mit rechteckigen Kernel und karthesischen Operationen herumfuhrwerken sollte, die dann aus einem "Punkt" das Beugungsbild einer rechteckigen Feldblende zaubern. Man kann das natuerlich auch brutal analog loesen: Teleskop abblenden und die Teleskopaufloesung wieder unter die digitale Aufloesung rammen. Aber wie immer: Ich schweife ab ...)
Kommen wir mal zum eigentlichen Thema zurueck und interpolieren wir mal unser Ursprungsbild etwas in Pixinsight, die Methode(n) sind jeweils im Bild beschriftet.
Dazu sind wohl ein paar Dinge zu sagen:
Die Default Methode im PI Weighted Batch Preprocessing Script ist jedenfalls Lanczos-4 und Ich habe da derzeit ein mulmiges Gefuehl...
Noch einmal klar gesagt: Das funktioniert dann gut, wenn die optische Aufloesung (langsames Oeffnungsverhaeltnis, kleine Kamerapixel) weit unter der Pixelaufloesung liegt. Das ist aber bei schnellen Optiken nicht mehr immer notwendigerweise der Fall. Und fuer Leute, die im sagenumwobenen "Untersampling" arbeiten, ist dass wahrscheinlich Genickbruch mit Ansage. Da versaut man sich genau das, was man mit einer spaeteren Drizzelintegration spaeter eventuell wieder herausholen moechte.
To be continued...
Gruss & CS
Aus gegebenem Anlass bin Ich gerade dabei mal zu schauen, welche potentiellen Fehlerquellen bei Mosaiken und bei Drizzel interpolierten Bildern so zu Artefakten wie z.B. "eckigen Pixeln" beitragen koennen.
Wie vielleicht einige von euch wissen und um mal Loriot zu paraphrasieren: "Im mathematischen Sinne heisst ja "Interpolieren" nicht nur "Interpolieren" ...
Interpolation ist in PixInsight (und nicht nur da, das betrifft eigentlich alls Astroprogramme) "Kerngeschaeft", dass fuer eine Vielzahl von darauf aufbauenden Algorithmen wie pixel binning, FastRotation, Resample, Rotation, DynamicCrop, StarAlignment, ImageRegistration, Mosaic_by_Corrdinates, [... und noch vielen mehr ...] verwendet wird.
Vielleicht sollte man sich da erst mal etwas einlesen, siehe z.B. hier:
PixInsight Reference Documentation | Interpolation Algorithms in PixInsight
A description of the pixel interpolation algorithms currently implemented on the PixInsight platform.
Als soliden Startpunkt und zwecks Vergleichbarkeit habe Ich mir auf die Schnelle ein "einfaches Testbild" mit ein paar Sternen im Zustand des "Undersamplings" in Matlab gezaubert:
Was ihr da oben seht, ist nicht das Originalbild, sondern bereits gezoomt (also - hehehe - auch schon Interpoliert). Aber das mit der primitivsten Methode, naemlich nearest neighbor sampling, die die Form der "Sternenpixel" auch schon wieder veraendert (die werden "rechteckig" und bleiben nicht etwa punktfoermig). Das wirkliche unveraenderte Original hat tatsaechlich nur vier einzelne "Hotpixel", von denen sich zwei in der Diagonale "beruehren").
Und jetzt schauen wir mal wie ein "einfacher" Algorithmus so ein Bild heraufinterpoliert, in diesem Fall mit einer linearen Interpolation mit Matlab:
und so schlecht schaut das gar nicht aus. "Schlecht" heisst hier: Aesthetisch fuer ein Astrobild grob uebergriffig...
Nun werfen wir mal auf dieses Problem eine der eigentlich "besseren" Methoden, eine Interpolation mit Bicubic-Spine-Funktion als Kernel (cubic spline in 2D):
und das sieht mit Verlaub gesagt beschixxen aus. Ohne in eine Vorlesung abzurutschen, aber was das eigentlich macht, dass kann man sich hier anschauen Bicubic interpolation - Wikipedia und solche Interpolationen tun sich mit Daten, die tatsaechlich "Stufen" haben und keine "sanften" Uebergaenge ziemlich schwer. Was die dann produzieren sieht nicht schoen aus.
Aber um auch mal zu zeigen, dass es auch ganz anders geht, werfen wir jetzt den Rolls-Royce der hier zulaessigen Interpolationen an und machen eine Fourier Interpolation mit kreisfoermiger Apodisation (ach was klingt der Buzzword Bullshit immer so toll ...) und wenn schon denn schon dann gleich um einen Faktor fuenf:
*zwinker zwinker* Na?
denn das schaut dann schon mal gar nicht schlecht aus (Mal nebenbei: Dem reflektierten Publikum faellt uebrigens gerade auf, dass es in der Astrofotografie offenbar das beruehmte "Undersampling" nur in den Koepfen derer gibt, die die "Gassenhauer-Kernel" aus der Bildverarbeitung verwenden. Denn die beruhen darauf, dass die digitale Aufloesung hoeher ist, als die optische Aufloesung. Wenn das nicht der Fall ist, na dann nimmt man besser die Sachen, die dafuer geeignet sind. Was da oben lief ist - mal verstaendlich ausgedrueckt - sowas aehnliches wie "digital abblenden" und macht aus einem Bild mit vermeintlich "eckigen Pixeln" ein wunderschoenes Astrobild, Beugungsringe inklusive. Die Vorinformation die man da hinein gesteckt hat ist ganz einfach, dass die tatsaechliche PSF mindestens eine Besselfunktion enthielt, weil der Lichteimer nun mal rund ist und man deshalb nicht mit rechteckigen Kernel und karthesischen Operationen herumfuhrwerken sollte, die dann aus einem "Punkt" das Beugungsbild einer rechteckigen Feldblende zaubern. Man kann das natuerlich auch brutal analog loesen: Teleskop abblenden und die Teleskopaufloesung wieder unter die digitale Aufloesung rammen. Aber wie immer: Ich schweife ab ...)
Kommen wir mal zum eigentlichen Thema zurueck und interpolieren wir mal unser Ursprungsbild etwas in Pixinsight, die Methode(n) sind jeweils im Bild beschriftet.
Dazu sind wohl ein paar Dinge zu sagen:
- Die "schlauen" Methoden wie Sinc-Interpolation, Lanczos-4 [...] beruhen auf Annahmen, die diese "von aussen" in den Bildverarbeitungsprozess hineintragen. Um es kurz zu fassen, naja diese beruhen darauf, dass die digitale Aufloesung deutlich unter der optischen Aufloesung liegt und dass man mit diesem Hintergrundwissen eine PSF abschaetzen kann und damit eine bessere Interpolation hinbekommt. Die Sache hat jedoch einen Haken: Wenn diese Annahmen nicht stimmen, dann gibt's keine bessere Interpolation, sondern Interpolationsartefakte.
- "Auto" sollte laut PI-Anleitung beim Hochsamplen auf eine Lanczos-3 (nicht Lanczos-4) schalten und die sieht mit diesem Testbild noch einlam hochvergroessert so aus und ist vorsichtig gesagt fuer solche Sachen auch nicht gerade die Methode der Wahl.
- Und wenn nicht gerade mein Hamster bohnert, dann funktioniert "Bicubic-Spline" ueberhaupt nicht, oder zumindest nicht so wie's im Lehrbuch steht (man vergleiche das Ergebnis des gleichen Algorithmus mit der Matlab Interpolation). Bissel peinlich, aber wenigstens nicht die Methode die sich hinter "Auto" verbirgt.
- Einfache Algorithmen wie Lineare oder Bilineare Interpolation schlagen sich insgesammt mit solchen Daten einfach besser, weil diese vielleicht nicht so tolldreisst interpolieren, dafuer aber auch nicht von vielen Annahmen abhaengen und deswegen keine zusaetzlichen Artefakte abliefern.
- "Cubic B-Spline mit Filter" ist nicht etwa eine Zigarettenreklame, sondern ein Algorithmus der erstaunlich gut abschneidet. Ich kann mir zwar vom Namen her vorstellen, was der in etwa macht, aber das werde Ich in einer ruhigen Minute noch mal genau nachschlagen.
Die Default Methode im PI Weighted Batch Preprocessing Script ist jedenfalls Lanczos-4 und Ich habe da derzeit ein mulmiges Gefuehl...
Noch einmal klar gesagt: Das funktioniert dann gut, wenn die optische Aufloesung (langsames Oeffnungsverhaeltnis, kleine Kamerapixel) weit unter der Pixelaufloesung liegt. Das ist aber bei schnellen Optiken nicht mehr immer notwendigerweise der Fall. Und fuer Leute, die im sagenumwobenen "Untersampling" arbeiten, ist dass wahrscheinlich Genickbruch mit Ansage. Da versaut man sich genau das, was man mit einer spaeteren Drizzelintegration spaeter eventuell wieder herausholen moechte.
To be continued...
Gruss & CS