Pixinsight WBPP - bei OSC rote Bilder statt grün

[eddy74]

Hallo,

bisher habe ich immer den DeepSkyStacker (RGGB AHD) für die Datenreduktion meiner OSC-Aufnahmen verwendet (ASI 2600 MC).
Nun wollte ich mal mit dem WBPP-Skript in Pixinsight arbeiten. Die Datenreduktion dauert länger und verbraucht ordentlich Speicher, aber wenn die Qualität steigt - warum nicht.
Bei der Integration der Light-Frames habe ich dann CFA mit RGGB-Pattern und VNG ausgewählt. Das Ergebnis ist ein rotes Bild - statt dem üblichen grün! Schon die debayerten Bilder haben diesen Rot-Stich. Wenn ich nun allerdings den Debayer-Prozess auf die Rohbilder anwende, erhalte ich das erwartete grün-stichige Bild.
Ich habe dann im WBPP-Skript alle anderen Bayer-Pattern durchprobiert, meist mit den zu erwarteten verschiedenen Farbstichen. Nur das GRGB-Pattern liefert einern Grünstich, zeigt aber immer noch eine Rasterung.
Ich habe jetzt keine Idee, welche Einstellung im WBPP-Skript falsch sein könnte - aber hoffe, ihr könnt mir hier weiterhelfen.

Bis denne
Etienne

 

[eddy74]

Hallo,

mein Fehler war, das ich bei den Flat-Frames das Häkchen für CFA gesetzt hatte. Jetzt ist alles wieder schön grün.

Bis denne
Etienne

 

[astrozausel]

Moin,
DSS macht seine Sache sehr gut, und obendrein geht der Stack schnell. Das Rohbild ist sehr gut. Letztendlich kommt das Rohbild eh in der Bearbeitung. Sterne und sonstiges wird eh angepasst. Bleib bei DSS da unkompliziert und schnell. Nur meine Meinung.
Gruß Dieter
Habe übrigens auch Pixinsight.

 

[steffens]

mein Fehler war, das ich bei den Flat-Frames das Häkchen für CFA gesetzt hatte

Ich kenne mich mit PI und WBPP nicht aus, aber sind denn die Flat-Frames etwa keine CFA Bilder?
Du schreibst doch von einer OSC Kamera, also sollten doch alle Kalibrations-Bilder auch CFA sein?

Grüße,
Steffen

 

[eddy74]

Hallo Steffen,
die Flats sind auch CFA-Bilder, deswegen hatte ich intuitiv das Häkchen gesetzt. Ich denke, weil die Flats zur Kalibration gehören, wird hier noch kein CFA angewandt.

Bis denne
Etienne

 

[Tom0104]

Ich denke ja auch das "RGGB" eigentlich richtig ist, aber hast Du es mal mit "Auto" probiert?

 

[DerOndre]

Moin,
also irgendwie klingt das komisch. Bei mir lässt das WBPP Skript überhaupt keine Kalibration mit den Flats zu, wenn diese nicht ebenfalls den Haken bei CFA gesetzt haben:

Das würde ja auch gar keinen Sinn ergeben.

Bist Du sicher, dass PI die Lights wirklich mit den Flats verarbeitet hat?

Ich vermute bei der Farbverschiebung eher ein Problem mit den Flats selber. Vielleicht sind die in einem Kanal gesättigt? Kannst Du mal eins einer Flats bei Wetransfer oder so hochladen und hier zur Verfügung stellen?

Übrigens, wenn Dir der Prozess in PI zu lange dauert, überlege gut, ob Du die Local Normalization wirklich anwenden musst. In vielen Fällen ist das meiner Meinung nach gar nicht notwendig und das dauert dann einfach nur unglaublich lange und braucht auch sehr viel Arbeitsspeicher.

Gruß
André

 

[eddy74]

Ich denke ja auch das "RGGB" eigentlich richtig ist, aber hast Du es mal mit "Auto" probiert?

RGGB schaut am 'normalsten' - ohne Rasterung un mit erwarteten Grünstich.

 

[eddy74]

Ich denke ja auch das "RGGB" eigentlich richtig ist, aber hast Du es mal mit "Auto" probiert?

'Auto' funktioniert bei mir nicht, da MaximDL das schlüsselwort nicht setzt.

 

[eddy74]

Bist Du sicher, dass PI die Lights wirklich mit den Flats verarbeitet hat?

Ich schaue mir mal das Fluss-Diagramm an.

Ich vermute bei der Farbverschiebung eher ein Problem mit den Flats selber.

Die Flats mache ich in der Dämmerung - sind also blau-lastig.
Das analoge Vorgehen hat im DeepSkyStacker keine Probleme gemacht.

Ich schaue auch mal, ob ich die 'Local Normalization' angewählt habe.