ubit
Aktives Mitglied
Hallo zusammen,
seit ein paar Wochen schlage ich mich mit einer Idee herum...
Bei der Registrierung der Rohbilder vor dem Stacking werden die Bilder ja quasi "verschoben" und ggf. gedreht um mit einem Referenzframe deckungsgleich zu sein. Das funktioniert allerdings nur "bedingt". Nun kann man ein Pixelbild nicht einfach so um Werte verschieben (oder gar drehen) die nicht einem ganzzahligen Vielfachen eines Pixels entsprechen. Daher wird an dieser Stelle interpoliert. Ein Pixel eines Frames landet ggf. auf mehreren Pixeln im registrierten Bild. Das klappt auch ganz ordentlich, da normalerweise ja z.B. Sterne größer als ein Pixel abgebildet werden. Trotzdem ist eine solche Verschiebung ja nicht wirklich optimal in Sachen "Qualität". Dafür gibt es dann das Drizzle. Hier wird das registrierte Bild mit höherer Auflösung berechnet. Das wird dann zwar "besser" - aber ideal ist es natürlich auch nicht.
Je nach Software und Bearbeitungs-Workflow werden die Rohbilder einer OSC vor oder nach der Registrierung debayered. Auch das Debayern ist nicht wirklich "perfekt". Im Prinzip werden ja die Werte der fehlenden Pixel mit verschiedenen Verfahren von der Software "erraten". Auch hier wieder: Interpolation.
Also: Die Registrierung der Bilder interpoliert, das Debayering interpoliert. Zwei mal Interpolation = zwei mal "Schätzung". So richtig überzeugend ist das nicht, oder?
Nun zu meiner Idee:
Man könnte die Registrierung ja auf z.B. dem Grünkanal durchführen (ist ja durchaus üblich) und sich nur die Werte für Verschiebung und Drehung "merken". Das Rawframe bleibt erstmal unangetastet. Die Registrierungsinformationen werden erst beim Stacking genutzt. Das Pixel-Koordinatensystem wird entsprechend den Registrierungsdaten verdreht und verschoben - Pixel bleiben 1:1 erhalten. Nun kann man für jedes Pixel jeder Farbe berechnen wo im fertigen Bild dieses Pixel landet. Auch hier wird man "interpolieren" müssen, da nur sehr selten ein Pixel des gedrehten/verschobenen Rawframes genau auf einem Pixel des Zielbildes landen wird. Auch hier kann man problemlos Drizzlen - einfach indem man das Zielbild entsprechend in höherer Auflösung in das Verfahren einbaut. Im Prinzip kann man sogar mit beliebigen Faktoren Drizzlen - nicht nur mit den normalerweise verwendeten 2x2 oder 3x3.
Aber: Man müsste GAR NICHT debayern wenn man genügend Rohframes verwendet. Durch kleine Verschiebungen und Dithering landen statistisch wohl auf jedem Pixel des Zielbildes alle drei Farben. Hat man zu wenig Frames um das zu erreichen bleiben halt "Löcher" im fertigen Bild. Diese Lücken könnte man dann relativ einfach durch Interpolation auffüllen - aber bei hinreichend vielen Einzelframes wird das kaum nötig sein. Im Prinzip wird also jedes Pixel des Rawframes als Quadrat betrachtet und dieses Quadrat wird mit Hilfe der Registrierungsdaten über die quadratischen Pixel des Zielbildes gelegt. Das Stacking berechnet nun bei allen Pixeln im Zielbild wie viel Anteil das Pixel des Rawframes an dieser Stelle hat. Das Verfahren ist ähnlich zu einer normalen Bildverschiebung/-drehung von Pixelbildern - nur halt mit der zusätzlichen "statistischen" Komponente des Stackings.
Ich bin nicht sicher ob ich das jetzt verständlich beschrieben habe. Ich weiß auch nicht ob dieses Verfahren in der Praxis tatsächlich Vorteile hätte. Auf jeden Fall würde man die klassischen Debayer-Algorithmen vermeiden - das ist ja immer eine Balance zwischen möglichst geringem Auflösungsverlust und ggf. auftauchenden Artefakten.
In Sachen Rechenzeit würde man bei der Registrierung etwas Zeit einsparen da die Bilder ja nicht wirklich transformiert werden. Debayern entfällt auch. Auch der Speicherplatzbedarf wäre deutlich reduziert, da man ja keine registrierten Bilder zwischenspeichern muss sondern nur die Transformationsparameter (Verschiebung/Drehung). Dafür wird das Stacking halt komplizierter. Andererseits würden ja z.B. nur die tatsächlich vorhandenen Pixel gestackt. Also 25% der Auflösung rote Pixel, 25% blaue Pixel und 50% grüne Pixel (bei üblicher RGGB Bayer-Matrix). Beim üblichen Stacking von debayerten Frames werden ja auch die "geschätzten" Pixel im Stacking mitberechnet, also 4 mal so viele - das wäre bei "meinem" Verfahren anders. Bei einer 8 MPixel OSC Kamera werden "klassische" 3 x 8 MPixel gestackt - bei mir nur 2 MPixel rot, 2 MPixel blau und 4 MPixel grün = 1 x 8 MPixel. Das könnte sogar schneller sein....
Frage: Was haltet Ihr davon?
Gibt es vielleicht sogar schon Software die so arbeitet? Oder ist die ganze Idee Unsinn? Wenn ja: Warum?
Ciao, Udo
seit ein paar Wochen schlage ich mich mit einer Idee herum...
Bei der Registrierung der Rohbilder vor dem Stacking werden die Bilder ja quasi "verschoben" und ggf. gedreht um mit einem Referenzframe deckungsgleich zu sein. Das funktioniert allerdings nur "bedingt". Nun kann man ein Pixelbild nicht einfach so um Werte verschieben (oder gar drehen) die nicht einem ganzzahligen Vielfachen eines Pixels entsprechen. Daher wird an dieser Stelle interpoliert. Ein Pixel eines Frames landet ggf. auf mehreren Pixeln im registrierten Bild. Das klappt auch ganz ordentlich, da normalerweise ja z.B. Sterne größer als ein Pixel abgebildet werden. Trotzdem ist eine solche Verschiebung ja nicht wirklich optimal in Sachen "Qualität". Dafür gibt es dann das Drizzle. Hier wird das registrierte Bild mit höherer Auflösung berechnet. Das wird dann zwar "besser" - aber ideal ist es natürlich auch nicht.
Je nach Software und Bearbeitungs-Workflow werden die Rohbilder einer OSC vor oder nach der Registrierung debayered. Auch das Debayern ist nicht wirklich "perfekt". Im Prinzip werden ja die Werte der fehlenden Pixel mit verschiedenen Verfahren von der Software "erraten". Auch hier wieder: Interpolation.
Also: Die Registrierung der Bilder interpoliert, das Debayering interpoliert. Zwei mal Interpolation = zwei mal "Schätzung". So richtig überzeugend ist das nicht, oder?
Nun zu meiner Idee:
Man könnte die Registrierung ja auf z.B. dem Grünkanal durchführen (ist ja durchaus üblich) und sich nur die Werte für Verschiebung und Drehung "merken". Das Rawframe bleibt erstmal unangetastet. Die Registrierungsinformationen werden erst beim Stacking genutzt. Das Pixel-Koordinatensystem wird entsprechend den Registrierungsdaten verdreht und verschoben - Pixel bleiben 1:1 erhalten. Nun kann man für jedes Pixel jeder Farbe berechnen wo im fertigen Bild dieses Pixel landet. Auch hier wird man "interpolieren" müssen, da nur sehr selten ein Pixel des gedrehten/verschobenen Rawframes genau auf einem Pixel des Zielbildes landen wird. Auch hier kann man problemlos Drizzlen - einfach indem man das Zielbild entsprechend in höherer Auflösung in das Verfahren einbaut. Im Prinzip kann man sogar mit beliebigen Faktoren Drizzlen - nicht nur mit den normalerweise verwendeten 2x2 oder 3x3.
Aber: Man müsste GAR NICHT debayern wenn man genügend Rohframes verwendet. Durch kleine Verschiebungen und Dithering landen statistisch wohl auf jedem Pixel des Zielbildes alle drei Farben. Hat man zu wenig Frames um das zu erreichen bleiben halt "Löcher" im fertigen Bild. Diese Lücken könnte man dann relativ einfach durch Interpolation auffüllen - aber bei hinreichend vielen Einzelframes wird das kaum nötig sein. Im Prinzip wird also jedes Pixel des Rawframes als Quadrat betrachtet und dieses Quadrat wird mit Hilfe der Registrierungsdaten über die quadratischen Pixel des Zielbildes gelegt. Das Stacking berechnet nun bei allen Pixeln im Zielbild wie viel Anteil das Pixel des Rawframes an dieser Stelle hat. Das Verfahren ist ähnlich zu einer normalen Bildverschiebung/-drehung von Pixelbildern - nur halt mit der zusätzlichen "statistischen" Komponente des Stackings.
Ich bin nicht sicher ob ich das jetzt verständlich beschrieben habe. Ich weiß auch nicht ob dieses Verfahren in der Praxis tatsächlich Vorteile hätte. Auf jeden Fall würde man die klassischen Debayer-Algorithmen vermeiden - das ist ja immer eine Balance zwischen möglichst geringem Auflösungsverlust und ggf. auftauchenden Artefakten.
In Sachen Rechenzeit würde man bei der Registrierung etwas Zeit einsparen da die Bilder ja nicht wirklich transformiert werden. Debayern entfällt auch. Auch der Speicherplatzbedarf wäre deutlich reduziert, da man ja keine registrierten Bilder zwischenspeichern muss sondern nur die Transformationsparameter (Verschiebung/Drehung). Dafür wird das Stacking halt komplizierter. Andererseits würden ja z.B. nur die tatsächlich vorhandenen Pixel gestackt. Also 25% der Auflösung rote Pixel, 25% blaue Pixel und 50% grüne Pixel (bei üblicher RGGB Bayer-Matrix). Beim üblichen Stacking von debayerten Frames werden ja auch die "geschätzten" Pixel im Stacking mitberechnet, also 4 mal so viele - das wäre bei "meinem" Verfahren anders. Bei einer 8 MPixel OSC Kamera werden "klassische" 3 x 8 MPixel gestackt - bei mir nur 2 MPixel rot, 2 MPixel blau und 4 MPixel grün = 1 x 8 MPixel. Das könnte sogar schneller sein....
Frage: Was haltet Ihr davon?
Gibt es vielleicht sogar schon Software die so arbeitet? Oder ist die ganze Idee Unsinn? Wenn ja: Warum?
Ciao, Udo