SER - AVI - FireCapture

Status
Es sind keine weiteren Antworten möglich.

Sinus1

Mitglied
Hallo zusammen

Seit 2014 betreibe ich eine Planeten-USB-SW-Kamera von i-Nova (PLA-MX310) mit der beiliegenden Aufnahmesoftware PLX-Capture. Alles klappt prima. Da ich die Kamera mit einem Filterrad betreibe, nehme ich den RGB-Videostream jeweils im SER-Format auf. Toll finde ich dabei, dass der SER-Stream nur 1/3 an Dateigröße einnimmt, gegenüber einem AVI-Stream. Ein Versuch, dieses mit FireCapture aufzunehmen scheiterte, weil FireCapture die i-Nova nicht erkennt. Sehr schade!

Nun habe ich versucht, mehr über das SER-Format in Verbindung mit anderen Kameras zu erfahren. Dabei stellte ich fest, daß andere Programme das SER-Format in gleicher Größe wie AVI aufzeichnen. So auch bei FireCapture. Warum eigentlich ? RGB-Aufnahmen in SER scheint wohl nicht gefragt zu sein ??

Folgendes kleine Experiment sagt doch viel über SER aus: Ich nahm einen alten Mars Farb-Videostream in AVI, addierte diesen in Giotto zum Summenbild.Fits = 4863 Kb. In Fitswork zerlegte ich dieses Summenbild in 3x SW-Bild. Ergebnis: 1 SW-Bild war jeweils nur 1623 Kb. Also nur 1/3 der bisherigen Dateigröße!!
Das zeigt doch, dass bei AVI ganze 2/3 verschenkt werden.
Ob ich am Planeten 20 GB in SER, oder mit AVI 60 GB aufzeichnen muss, ist doch eine andere Größenordnung.

Eigenartig ist nur, warum kann i-Nova dieses realisieren und die anderen Programme bieten diese Möglichkeit bei Mono nicht an. Zumal bei SER nicht komprimiert wird.
Gern werde ich auf die neuere ASI-290 in Mono umsteigen, oder auch auf die angekündigte Astrolumina ALccd-QHY 5III 290, wenn FireCapture das SER-Format auch in 1/3 Dateigröße beherrscht.

Vielleicht bringt auch i-Nova irgendwann eine Kamera mit dem Sony CMos-Chip 290 heraus. Wer weiß??

Frage: Wer kann zu diesem Thema, auch in Verbindung mit FireCapture etwas beitragen. Vielleicht sogar Thorsten Edelmann als Entwickler von FireCapture ?
Sternfreundlicher Gruß,
Ludger
 
Hallo Ludger,

Falls Du in FireCapture die Webcam-Schnittstelle verwendest hast, dann kann es gut sein, dass die volle Dateigröße angelegt wurde.

Außerhalb der Webcam-Schnittstelle (die ab v2.5 eh nicht mehr unterstützt wird) speichert FireCapture aber immer nur in der nötigen Dateigröße ab, d.h. bei Monochrom-Kameras 1 Byte/Pixel im 8bit Modus und 2 Bytes/Pixel bei 16bit (hier wird nur im SER unterstützt). Bei Farbkameras nimmt man üblicherweise immer im RAW-Modus auf, d.h. die Dateigröße ist hier identisch zu Monochrom-Kameras. Nur wenn man Debayering in FireCapture aktiviert wird das AVI/SER 3x so groß, weil dann alle Farbkanäle gespeichert werden. Wie gesagt sollte man das aber nie machen und immer mit AutoStakkert debayern.

Gruß,
Torsten

 
Hallo Torsten,
entschuldige bitte, dass ich erst jetzt antworte. Nachdem meine Anfrage ins Netz gestellt wurde, waren 2 Wochen Familienurlaub angesagt. Herzlichen Dank für Deine schnelle und informative Antwort. 1 Byte pro Pixel als Minimum bei 8 Bit ist ja eine Rechengröße.
Ich habe einmal versucht, dieses auf den SER –Videostream meiner i-Nova Kamera hoch zu rechnen. Toll ist auch bei SER, dass alle Daten wahlweise mit aufgezeichnet werden. So konnte ich nachlesen: Mars Video, 8 Bit SER-Stream Gesamtlänge: 150016 Kb. In Mono mit 2000 Frames. Roi-Aufnahme 320x240 Pix am 04/06/2016, 23:11 Uhr mit 105,12 F/Sec. Bei USB2 Nachgerechnet kam ich auf 153600 Kb. Gesamtlänge.
Jupiter Video, 8 Bit SER-Stream Gesamtlänge: 390011Kb. In Mono mit 1300Frames. Roi-Aufnahme 640x480 Pix am 27/02/2016, 22:53 Uhr mit 56,84 F/Sec. Bei USB2 Nachgerechnet kam ich auf 399360 Kb. Gesamtlänge. Das finde ich eine sehr gute Übereinstimmung mit Deinen Aussagen.
Im März d.J. hatte ich die Gelegenheit eine Astrolumina QHY 5-II Mono zu testen. Mit FireCapture 2.4, sowie 2.5 stürzte das Programm an meinem 3 Jahre alten Toshiba Laptop, 64 Bit und 2,4Gb jedesweils ab. Also keine Aussage möglich. Mit dem beiliegenden EZ-Planetary lief alles. Ein SER-Stream war allerdings gleich groß wie ein AVI. Auch erschien mir das Programm nicht so elegant. Desgleichen mit SharpCap. Im Endeffekt blieb es dann bei meiner i-Nova, welche an meinem USB2-Laptop gut und sparsam im Datenverbrauch funktioniert. Gern würde ich aber die tollen Möglichkeiten von FireCapture nutzen. Ein Sternfreund, der eine neuere SW Mono Kamera von ASI an seinem USB3-Rechner betreibt, machte für mich den SER – AVI - Vergleich mit FireCapture. Seine Aussage „ SER und AVI sind gleich groß. Was sind jetzt die Fakten? 1. Meine i-Nova PLA-x310 wird von FireCapture nicht erkannt. Oder ist da bald etwas geplant? 2. QHY – Kameras werden ab FireCapture 2.5 auch wohl nicht mehr unterstützt? Da war doch etwas mit 64 Bit ? Oder 32Bit? 3. Wurde vielleicht beim oben genannten ASI – Test eine Einstellung nicht beachtet ?? Die Aussage: 1Byte pro Pixel als Minimum bei 8 Bit müsste doch bei SER auch nur 1/3 Dateigröße ermöglichen ! 4. Warum wird SER so wenig benutzt ? Oder ist i-Nova hiermit als Exot anzusehen? I-Nova teilt mit: The SDK is available on request for programming ( Microsoft C# or C++ )
5. Sicherlich muss ich mir zunächst einen Laptop mit USB3 und schneller Festplatte zulegen. Auf dem Wunschzettel steht auch eine Mono Planeten – Kamera mit dem back-illuminatet C-Mos Chip 290 von Sony. Zumal dieser Chip einen ähnlich guten Belichtungsverlauf hat, wie der bisherige oft genannte IXC 618AL. Wenn ich richtig gelesen habe, gibt´s den nur in 16:9 – Ausführung?
Wichtig ist aber die Funktion mit dem tollen Programm: "FireCapture"
Sternfreundlicher Gruß, Ludger
 
Hallo Ludger,
Zu Deine Fragen:

1. Ich hatte vor einiger Zeit mit der i-Nova Anbindung in FireCapture v2.5beta begonnen, musste dieser aber wegen mir unerklärlicher Probleme mir dem SDK auf Halt setzen. Ich habe daraufhin den SDK-Entwickler von i-Nova um Unterstützung gebeten leider ohne Erfolg, auch nach wiederholter Nachfrage. Ob das nochmal was wird, kann ich nicht sagen.

2. QHY-Kameras sollten in der aktuellsten FC v2.5.07 beta (nur 32-bit) wieder unterstützt werden. Dort wird das neue QHY-SDK verwendet, sodass auch neuere QHY Modelle laufen sollten (sofern sie vom SDK unterstützt werden)

3. Bzgl. AVI vs. SER kann ich Dir keine neueren Infos geben als das was ich schon gesagt habe. In FC werden bei Mono/RAW Aufnahme beide Formate gleich groß sein, da mit 1Byte/Pixel gespeichert wird.

4. Ich glaube nicht, dass SER so wenig verwendet wird. Im übrigen kann man das auch nur schwer einschätzen, weil Sternfreunde immer nur die finalen Bilder veröffentlichen, nicht aber ihre Videos. Ich kenne sehr viele FC-Nutzer (mich eingeschlossen) die nur SER verwenden.

5. Wahrscheinlich meinst Du hier den IMX290 von Sony, der z.B. auch in der ASI290 verbaut ist. Das ist zweifelsohne ein sehr guter Sensor, wobei es den (soweit ich weiß) nur in 16:9 gibt. Alternativ müsstest Du mal nach dem ICX291 schauen, der vom Substrat her identisch ist, aber mit 1300x729 ein anderes Format hat.

Gruß, Torsten
 
Hallo Torsten,
Du hast Dir wieder viel Mühe gemacht mit der Beantwortung meiner Fragen. Ganz herzlichen Dank dafür.
Ja, bei i-Nova hatte ich auch schon erlebt, dass Service bei der Firma wohl nicht vorgesehen ist. Die Sternfreunde werden dieses wohl zur Kenntnis nehmen.
Ich war erfreut zu hören, dass Du auch von SER überzeugt bist. Dann hatte ich hier doch auf das richtige Format gesetzt.
Gern würde ich noch wissen, ob ein 64 Bit Rechner auch abwärts kompatibel ein 32 Bit Programm verarbeiten kann. ( Siehe Dein Hinweis auf die Beta Version 2.5.07 nur 32-bit, sowie die Kamera QHY 5-III290 )


Ich wurde ja jetzt diesem Themenbereich zugeordnet. Die über 400“Klicks“ lassen vermuten, dass doch ein gewisses Interesse zu den bisherigen Fragen besteht. Darum habe ich einmal 2 Fragen an die größere Astro- Kollegen Runde:

1. Die ASI 290, sowie die QHY5-III290 sind beides neuere Modelle mit dem Chip IMX-290 von Sony. Hier kommt der Rolling Shutter zum Einsatz, dem man nachsagt, dass er bei „Seeing“ zu leichten Verwischungen neigt. Ein Global_Shutter hat dieses Problem nicht, da er immer komplett ausgelesen wird.

Hat jemand Erfahrung, ob sich das wirklich störend bemerkbar macht? Sollte man auf dieses System besser verzichten?
2. Ein Vorteil von kleineren Pixeln wäre doch der Wegfall einer Barlow-Linse. In beiden Fällen wird das Bild dunkler. Allein mechanisch hat dieses doch Vorteile. Oder ist das falsch gedacht?
Gern höre ich hier eure Erfahrungen.

Sternfreundlicher Gruß,
Ludger
 
Hallo Torsten,

toll, dass ich bisher von Dir so gute Antworten bekommen habe. Inzwischen ist mir Vieles klarer geworden. Zwischenzeitlich habe ich auch via you-Tube Dein Astro-Seminar über die Planetenfotografie besucht. Sehr interessant gemacht. Dabei wurde mir auch bewusst, wie doch durch die Technik auch die Zeit gerast ist.
Nicht mehr in der Selbstständigkeit, kann ich jetzt meine technischen Möglichkeiten in der Astronomie einsetzten. Auch steht mir an unserer Sternwarte in Borken bei Bedarf ein 16“ – 4 m Spiegelteleskop zur Verfügung, welches ich hauptsächlich für Planeten einsetze.
Da diese schon wieder weit entrückt sind, kann ich jetzt in Ruhe die neuen Techniken auswählen. Deine kompetenten Antworten haben mir dabei sehr geholfen.

Neben der anfangs erwähnten i-Nova für Planeten, kommt für Deep Sky hauptsächlich eine Watec 120+ am F5 Foto-Newton erfolgreich zum Einsatz. Also wenig Auge, dafür hauptsächlich Kamera.
Interessant ist aber auch, dass Erfahrungen anderer Sternfreunde hier bisher nicht eingeflossen sind.

Wenn ich bei auftauchenden Problemen gelegentlich noch einmal anklopfen darf, wäre mir das sehr angenehm. Ansonsten verbleibe ich:

Mit sternfreundlichem Gruß,

Ludger
 
SER – AVI – Fire Capture
Runde Nr.2 (April 2017)

Hallo liebe Astrofreunde - Vielleicht auch Torsten Edelmann ?

Hier nun mal mein Erfahrungsbericht mit neuer Technik:

Es ist schon ½ Jahr her als ich obiges Thema angeschnitten habe. Das hat allerdings Torsten Edelmann in dankenswerter Weise im Alleingang bestritten.

Zum Jahresende 2016 hatte ich mir zunächst einen schnelleren Laptop zugelegt:
Acer mit USB3, Prozessor i7-7500, 2,7 Ghz Takt, 64 Bit, Windows 10-Home,
Festplatten: SSD-250 GB, HDD-1000 GB, RAM 8 GB,
Grafik: N-Vidia Ge Force 940 Mx.
Damit , so glaube ich, müsste man wohl arbeiten können.


Nach langem Suchen und dann Abwarten, hielt ich dann Anfang März auch die neue Astrokamera in den Händen:
ALCCD QHY5-III 290 in Mono mit dem gewünschten back-illuminatet Sony C-Mos Sensor IMX-290 mit 2,9 um Pixelbreite.

Noch gerade rechtzeitig zu der beginnenden Jupiter-Opposition im April,
konnte der erste Test am Teleskop unserer Sternwarte beginnen.
Bange Frage: Hält FireCapture durch, oder stürzt es ab, wie ½ Jahr zuvor.

Versuch 1
Mit dem beiliegenden Programm SharpCap :
Bei voller Auflösung mit 1920 x 1080 Pixel dauerte es nicht lange, bis das erste Stocken im Life Bild auftrat. Ein reduzieren des Traffic brachte etwas Besserung.
Erst die Einstellung 1280 x 1024 Pixel ließ das Life Bild dauerhaft stehen.

Versuch 2
Mit FireCapture v. 2.5.11 32 Bit
Das Programm startet mit der vollen Auflösung 1920 x 1080 Pixel.
Nach ca. 10-20 Sek. War das Life Bild schon eingefroren!
Na toll, ….. war es das schon??
Eine Reduzierung auf 1280 x 1024 Pixel hielt etwas länger durch.
Die Einstellung 1024 x 768 Pixel und die Reduzierung des Traffic Richtung „ 0“,
ließ das Bild schon mal ca.3 Minuten stehen.
Die Kamera bricht dann ab. Anzeige in Rot: ( Aufnahmefehler )
Dann hatte ich aber irgendwo etwas von einer RAM – Erweiterung gelesen.

In den Grundeinstellungen fand ich die Möglichkeit den RAM – Buffer
auf 750 MB zu erweitern.
Nach einigen Versuchen mit verschiedenen Größen das Ergebnis:
Die Einstellungen :
Aufnahme in SER/ 8 Bit, Auflösung 640 x 480 Pixel.
Belichtung ca. 5 mSek., Gain ca. 20-25 RAM-Buffer auf max. 750 MB.
Der notwendige Test sagt, dass bei der Auflösung Platz für 2560 Bilder erzeugt sind.
Die gestartete Aufnahme in SER hielt jetzt ca. 2-3 Minuten durch.
SER meldet ca. einen Durchfluss von ca. 250 F/Sek. Nicht schlecht!!!

Versuch 3:
Mit FireCapture Vers. 2.5.11 64 Bit
Die Einstellungen:
Auflösung 640 x 480 Pixel in SER mit 8Bit
RAM Buffer max. 1700 MB. Es wird dann mit obiger Auflösung
Platz für 5802 Bilder erzeugt.
Belichtung ca. 3-4 mSek., Traffic „0“, Gain mit 18.
Jetzt hielt das Liefe Bild schon 5 Minuten durch.
Am Blasen des Ventilators im Laptop konnte man entnehmen, dass der Prozessor
gut beschäftigt war.
Die Aufnahme lief mit ca. 270 F/Sek. recht gut ab. Die Bildserie war jeweils 5000 Bilder.
Auch hier brach die Aufnahme immer wieder meist nach 5 Minuten ab.

Wenn ich einmal Aufnahmen am Mond machen möchte, macht dieses nur Sinn
mit 1920 – 1080 Pixeln. Das führt wahrscheinlich wieder zu mehr Abstürzen.
Auf jeden Fall kann ich sagen, dass diese Kamera mit nur 2,9 um Pixelbreite bessere
Ergebnisse liefert, als meine bisherige Kamera mit 5,6 um Pixel und 2-fach Barlowlinse.

Nun die Frage an alle:
Kennt jemand bessere Einstellungen, um das Problem der Abstürze zu verringern?
Die wichtigste Änderung erscheint mir, den RAM-Buffer wahlweise zu vergrößern,
z.B. in Richtung 2500 MB. ( Bisher 1700 MB )
Aber das könnte wahrscheinlich nur Torsten Edelmann beantworten.

Mit Sternfreundlichen Grüßen,
Ludger
















 
Hallo Ludger,

Ich bin mir nicht sicher aber zumindest früher hat die "Taffic" Einstellung bei QHY genau andersherum funktioniert wie bei den ASI-Kameras, d.h. bei Traffic = 0 hat Du die höchste USB-Bandbreite und damit auch die höchste Wahrscheinlichkeit von Übertragungsproblemen falls die Bandbreite nicht ausreicht. Überprüfe diese Vermutung bitte mal und schau ob die Framerate nach unten geht, wenn Du den Traffic-Regler aufs Maximum ganz nach rechts regelst. Wenn dem so ist, dann darfst Du nicht mit Traffic=0 arbeiten, sondern musst den Traffic erhöhen, sobald "Aufnahmefehler" in der Vorschau erscheint.

Gruß, Torsten
 
Hallo Torsten,
herzlichen Dank für Deine Antwort und der klaren Darstellung des USB-Traffic.
Bei QHY-Kameras reagiert der Traffic tatsächlich anders herum, als bei ASI-Kameras.
Meine neue, oben genannte QHY-Kamera macht in der Einstellung
ROI 640 x 480 Pix in SER mit 8 Bit folgendes Ergebnis:

Traffic 50 = 60 F/PS
Traffic 10 = 160 F/PS
Traffic 0 = 280 – 300 F/PS

Da ich die unruhige Luft am Jupiter neulich austrixen wollte, habe ich einen Traffic
bei „0“ gewählt. Dabei habe ich die immer wieder auftretenden Abstürze halt
in Kauf genommen.
Die günstigsten Einstellungen, neben einem niedrigen ROI,
ist auch der größtmögliche Wert im RAM – Buffer. ( z.Z. 1700 Mb in der 64-Bit-Version)

Darum meine Frage:
Kann dieser Wert eventuell noch ca. 1 BG erhöht werden, oder bringt das wieder
andere Probleme mit sich?
Für eine Antwort wäre ich Dir dankbar.

Mit sternfreundlichen Grüßen,
Ludger



 
Hallo Ludger,
Die Größe des max verfügbaren RAM-Puffers hängt von der Heapsize ab, mit der Du FC startest. Ich würde als max Heapsize nicht mehr als 50% Deines verfügbaren RAMs verwenden. Also bei 8GB RAM solltest Du FC mit 4GB Heapsize starten können. Bei 4GB Heapsize kannst Du dann den RAM-Puffer auch entspr. vergrößern.
Gruß, Torsten
 
SER – AVI – Fire Capture
Runde Nr.3 (November 2017)

Hallo Torsten
Vor ein paar Tagen versuchte ich mit meiner weiter oben beschriebenen Kamera
AstroLumina_ALCCD QHY5-III 290 in Mono und dem 4m Spiegelteleskop unserer
Sternwarte den Uranus einzufangen. Leider war es sehr windig. Der Planet tanzte auf dem
Bildschirm hin und her. (Laptop Acer, wie zuvor weiter oben beschrieben)
Die tolle Funktion des Planeten-Tracking in FireCapture 2.5, und 2.6-Beta
erbrachte die „scheinbare“ Ruhe auf dem Bildschirm.
Aufzeichnung mit USB3 in SER, ca.10 ms Belichtung und ca. 100 Fram/Sek.

Weil meine Kamera ( auch mit neuerem Treiber) in Verbindung mit FC leider häufiger
abstürzt, nahm ich auch mit dem Programm SharpCap, sonst aber gleichen Einstellungen auf.
Hier gibt es jedoch kein beruhigendes Planeten-Tracking. ( Also zappelnder Planet )
Die L-RGB Aufnahmen in SER, von jeweils 3000 Bildern wurden später mit
AutoStakkert3 ( auch mit Stakkert2) addiert.

Und jetzt ein interessantes Ergebnis:
Die in FC gemachten L-RGB-Aufnahmen hatten im Summenbild weitgehend alle
in der Vertikalen eine leicht eirige, also längliche Ausrichtung! Im Extremfall sogar
wie 2x aufeinander gedrückte Bälle. Eigenartigerweise beim Rotkanal am stärksten!
Die unter gleichen Bedingungen gemachten Aufnahmen mit SharpCap hatten auf dem
Bildschirm auch stark gezappelt. Das Summenbild, wieder mit AutoStakkert addiert,
war aber normal rund und konnte in Fitswork zum guten L-RGB, ( etwas besser G-RGB )
Uranusbild gebracht werden. Damit hatte ich nicht gerechnet!!

Die SER Wiedergabe von FC zeigt einen beruhigt stehenden Uranus.
Die SER Wiedergabe von SharpCap zeigt einen zappelnden Uranus.

Meine Frage:
Hat die beruhigende Rechenarbeit auf das Planetenscheibchen ungünstigen Einfluss
für die Aufzeichnung auf die Festplatte??
Oder gibt es eine andere Erklärung für dieses so ungleiche eirige Endbild mit FireCapture?
Eine weitere Kontrolle ließ das bisherige Wetter leider nicht zu.
Über einen Kommentar würde ich mich freuen.


Mit Sternfreundlichen Grüßen,
Ludger
















 
Zuletzt von einem Moderator bearbeitet:
Hallo Ludger,
Die Bildstabilisierungsfunktion in FC sollte keinen Einfluß auf das Endbild haben, denn sie macht nichts weiter, als zu Beginn oder Ende jedes Bildes schwarze Pixel hinzuzufügen, bis das Planetenscheibchen zentriert in der Bildmitte steht.
Du kannst mir aber gerne mal ein paar Beispielbilder schicken, damit ich mir das mal anschauen kann.
Gruß, Torsten
 
Betreff: Langgestrecktes Planetenscheibchen

Hallo Torsten,
zunächst meinen herzlichen Dank für Deine Bereitschaft das zuvor beschriebene Problem
und die zugehörigen Bilder anzuschauen.
Leider hatte ich schon alle Dateien gelöscht, aber vorige Tage war für ein 3 Stunden klarer
Himmel mit wenig Wind angesagt. Der Aufnahmeort und die schon zuvor beschriebene
Technik, sowie auch Einstellungen, ermöglichten mir den Uranus erneut einzufangen.

Vorab:
Die zuvor genannte Störung besonders bei den Rot-Aufnahmen, stellten sich als nicht
richtig heraus. ( Ist ja auch logisch )
Aus der nachfolgend beschriebenen SER- Aufnahmeserie, wählte ich als Beispiel
den Grün-Kanal aus. Alles wurde in Autostakkert3 addiert. Ich konnte sogar den zuvor
beschrieben Fehler erneut rekonstruieren.

Mein Eindruck:
Der Fehler tritt immer dann auf, wenn ich den SER-Stream mit eingeschalteter
Bild-Stabilisierung aufzeichne. Ist die Stabilisierung ausgeschaltet, tanzt zwar der Planet
auf dem Bildschirm, das Endresultat von AutoStakkert ist aber ziemlich gut.


Versuch 1:
Besonders krass zeigt sich der Fehler, wenn ich in AutoStakkert bei dem
strukturlosen Uranus mehrere Ausrichtungspunkte setze ( Siehe Bild 1=9xAP).
Setze ich nur 1xAP=Quadrat, ist das Resultat sogar ziemlich gut. ( Bild 2=1xAP )

Nachfolgend der Link zu den Bildern 1-4, sowie 2x Text-Dateien (Bilddaten)
https://c.web.de/@519489883824200337/1Ghi9qisSHezDVJ2QIWnCw

(Wenn z.B. in Fitswork mittels Historamm der Gammawert höher gezogen wird, kann man
bei den etwas besseren Bildern auch noch einen Ansatz von Verwischung erkennen.)

Versuch 2:
Wenn ich aber ohne Bildstabilisator aufzeichne, ist das Planetenscheibchen als ziemlich
rund anzusehen. Ob in AutoStakkert nur 1, oder mehrere Ausricht.-Punkte gesetzt werden,
ist nicht mehr so entscheidend. ( Bild 3= 9xAP, und Bild 4= 1x AP ).
Auf jeden Fall ist das Häkchen bei der Bildstabilisierung eine tolle Hilfe bei der
Schärfeeinstellung.

Lieber Torsten, wenn diese Darstellungen etwas hilfreich für eine eventuelle Bearbeitung
wären, würde mich das sehr freuen.
Vielleicht habe ich ja auch irgendwo einen Fehler gemacht!!
Nochmals vielen Dank für Deinen unermüdlichen Einsatz.

Mit Sternfreundlichen Grüßen,
Ludger














 
Betreff: Langgestrecktes Planetenscheibchen, anbei Ausgangs_ SER-Stream.Zip

Hallo Torsten,
nachfolgend der Link zu Web.de, wo der SER-Stream zu den oben beschriebenen
Bildern 1-4 abgelegt ist. Wie schon zuvor genannt, habe ich aus der RGB- Folge
nur den Grün-Kanal ausgewählt und im Zip- Format hochgeladen.
Achtung: Der SER-Stream ist trotz gezippter Version doch noch ca. 100MB groß!

Nr. 2 https://c.web.de/@519489883824200337/K2fd46RqSPW8cJz-hdYb-w
ist die Aufnahme mit Stabilisierung, aus denen die weiter oben genannten Bilder
1 + 2 entstanden sind.

Nr.4 https://c.web.de/@519489883824200337/mBYjtl6sRCW0JRrj2v9wiA
ist die Aufnahme ohne Stabilisierung, aus denen die Bilder 3 + 4 entstanden sind.

Der Uranus ist ja nicht gerade das Paradestück zum Vorzeigen, das war aber auch nicht
der Zweck der Übung.
Ich hoffe, dass hiermit eine gute Analyse der im vorigen Beitrag beschriebenen
Probleme möglich sind. Die Spannung steigt, aber auch die Freude über eine eventuelle
Lösung durch Deinen geschulten Blick für alles, was so im Hintergrund abläuft.

Mit sternfreundlichen Grüßen
Ludger




 
Hallo Ludger,

Danke für die SER-Dateien. Ich hab Nr. 4 (ohne Stabilisierung) mal mit AutoStakkert/Fitswork bearbeitet ("Original"). Dann hab ich SER Nr.4 mittels Drag&Drop in FC (DummyCam) geladen, die Stabilisierung aktiviert und ein neues SER aufgenommen (= gleiche Daten). Dieses neue SER hab ich absolut identisch bearbeitet ("Zentriert"). Im animierten GIF (siehe Dateianhang) kann ich absolut keinen Unterschied zwischen "Original" und "Zentriert" erkennen, d.h. die Stabilisierungsfunktion in FC macht da nichts "kaputt", sondern die Unterschiede kommen wahrscheinlich von den unterschiedlichen Daten oder von untersch. gesetzten MA-Points in AutoStakkert.

Gruß,
Torsten
 

Anhänge

  • output_Z1vMzl.gif
    output_Z1vMzl.gif
    4,6 KB · Aufrufe: 374
Vorab: Allen alles Gute zum neuen Jahr 2018

Betreff: Langgestrecktes Planetenscheibchen, Nachlese Januar 2018

Hallo Torsten,
zunächst erst einmal meinen herzlichen Dank und Anerkennung für Deine Arbeit
mit der Analyse der Uranus SER- Aufnahme, den ich im Onlinespeicher von Web.de
abgelegt hatte.
Als Erstes habe ich meine Datei Uranus Nr. 4 (ohne Stabilisierung) nach Deiner
Gebrauchsanweisung in den DummyCam-Modus hineingezogen.
(Übrigens eine tolle Funktion, die ich noch nicht kannte.)
Hierbei kam ich zu dem gleichen Ergebnis wie zuvor von Dir beschrieben.
Form, Position und Größe beider Uranusbildchen sind deckungsgleich. Anschließend
habe ich in Fitswork noch die beiden Bildchen im Blink-Modus laufen lassen. Ohne
jegliche Korrektur lagen die Planetenscheibchen deckungsgleich übereinander.
Soweit also volle Übereinstimmung!!!

Nun habe ich nochmals meinen mit Stabilisierung aufgezeichneten SER-Stream
von Uranus Nr.2, mit dem Programm „ SER-Player“ abgespielt. Man kann hier
beim nun ziemlich ruhig stehenden Uranus, am unteren Rand deutlich einen
nach oben zappelnden grauen Streifen sehen!
Genau dieser graue Streifen scheint es auch zu sein, der in AutoStakkert beim Summenbild
unten wieder erscheint und das Planetenscheibchen nach oben verschiebt. ( dezentriert)
( Durchlauf in AutoStakkert mit nur 1x Ausrichtungs-Quadrat und 10% Auslese).
Das Summenbild zeigt (beim Gammawert von 2.20 in Fitswork) deutlich den Fehler.
Der Uranus ist nicht mehr ganz rund, sondern leicht länglich nach oben verzogen.
Sichtbar die grauen Streifen am unteren Rand mit dem oberhalb stehenden Uranus.
Dies hatte ich im Vor-Bericht vom 5.12.2017 bereits beschrieben und auch abgebildet.


Eigenartig ist doch, dass beide SER-Streams unter gleichen Bedingungen, mit nur
ca. 8 Minuten Zeit-Differenz aufgezeichnet wurden. ( Auch noch ein paar weitere
Aufnahmen danach mit gleichem Ergebnis ).
Gern würde ich erkennen, dass ich etwas falsch gemacht habe, aber wo…..?

Lieber Torsten, es ist mir schon fast peinlich, aber dürfte ich Dich bitten, den mit
Stabilisierung aufgezeichneten SER-Stream von Uranus Nr.2 doch noch einmal
vorzunehmen? Ist als Ergebnis der Uranus dann rund und zentriert, oder länglich,
dezentriert und unten mit der grauen Störzone versehen?

Wenn demnächst in 2018 wieder Planeten angesagt sind, wäre das schon ( nicht nur für
mich allein ) eine interessante Erkenntnis, um zu guten Bildern zu gelangen.
Ganz herzlichen Dank sage ich schon vorab für Deine Mühe, die vielleicht zu
einem positiven Ergebnis führt.

Mit sternfreundlichen Grüßen
Ludger




 
Ludger,

Interessant wäre für mich zu wissen, wie der graue Bereich bei der Bildstabi entstanden ist. Wenn ich Dein unstabilisiertes SER in FC lade und stabilisiere, dann erhalte ich keinen grauen Bereich. FC berechnet und füllt bei der Stabilisierung mit Durchschnittswerten des Hintergrundes. Deshalb wundert es mich, wie dieser graue Bereich entstanden ist.

Wenn Du in AutoStakkert den Schwellwert erhöhst (siehe Anhang), dann sollte auch das stabiliserte Bild mit dem grauen Bereich normal bearbeitet werden.

Gruß, Torsten
 

Anhänge

  • 2018-01-08_12h42_34.png
    2018-01-08_12h42_34.png
    84,2 KB · Aufrufe: 237
Betreff: Störstreifen im SER-Stream bei Aufnahmen in FireCapture mit Stabilisierung

Hallo Torsten,
herzlichen Dank, dass Du den im letzten Bericht genannten SER-Stream von Uranus 2
noch einmal auf die grauen Störstreifen untersucht hast.
Deiner Empfehlung folgend, habe ich in AutoStakkert zunächst den „Thershold“ Schwellwert
auf 40 eingestellt und den Uranus 2 - SER-Stream ( mit Stabilisierung) erneut
addieren lassen. Und siehe da, -------- genau wie Du es oben gesagt hast, das Summenbild
war diesmal ohne die zuvor genannten Störstreifen.
Auch stand Uranus mittig zentriert, ohne nennenswerte Verzerrung !!
Der höhere Schwellwert in AutoStakkert wirkte also positiv auf das Endergebnis.
Das war schon mal ein Teilerfolg, aber noch nicht die eigentliche Lösung des Problems.

Erst am 14.1. war wieder eine erneute Aufnahmeserie möglich. ( Gleicher Ort und Technik
wie zuvor schon einmal beschrieben)

Diesmal aber ein sehr interessantes Ergebnis:
Nachdem ich bei den Aufnahme-Einstellungen „ mit Stabilisierung“ aktiviert hatte,
konnte ich diesmal auf meinem Laptop direkt den grauen Störstreifen zappeln sehen !!!
Die Einstellungen:
ROI: 300x300, Belichtung: 11 ms, Gain: 50
Die Primär-Brennweite: 4 Meter. Verlängert mit Barlow: 1,5–fach, Pixelbreite : 2,9 um.

Die Dicke des Störstreifens ist abhängig von der Lage des Planetenscheibchens!
Driftet Uranus nach oben, so kommt der Streifen auch von oben und wird dabei dicker.
Driftet Uranus nach unten, so kommt der Streifen von unten und wird dicker, je tiefer
das Planeten - Scheibchen sinkt.
Ich konnte den Störstreifen also beeinflussen.
Stabilisierung ausschalten,…. und schon ist alles wieder in Ordnung !
So habe ich dann noch eine ganze Serie ohne Stabi aufgenommen. Alles in Ordnung.

Ob dieses Problem nur mit meiner kleinen Kamera: Astrolumina QHY5 III-290 mono
auftritt, vermag ich nicht zu beurteilen, zumal ich immer noch sehr häufig einen
Programm-Absturz nach ca. 2- 4 Minuten in Verbindung mit FC habe.
( siehe Berichte weiter oben, vom 16.4. und 20. 5. 2017 )
Die Kamera läuft aber wesentlich stabiler in Verbindung mit Sharp Cap, aber auch längst
nicht so elegant wie mit Deinem FireCapture.

Lieber Torsten, man kann die Planeten-Aufnahmen wirklich gut ohne Stabilisierung
aufzeichnen. Für die Fokussierung ist diese Funktion aber eine tolle Hilfe.
Viel nerviger sind meine Programm-Abstürze, für die ich noch keine Lösung habe.
Vielleicht konnte der obige Test auch etwas zur Klärung beitragen.

Ganz herzlichen Dank aber für Deine unendliche Geduld und Mühe, die Du
uns Sternfreunden immer wieder entgegen bringst.

Mit sternfreundlichen Grüßen
Ludger




 
SER – AVI – Fire Capture
Runde Nr.4 (Juli 2018)

Hallo Torsten,
bei der FC-Version 2.6.06 waren wie berichtet Probleme mit der Belichtungseinstellung
aufgetreten. Wie Du mitteiltest, war das ein Bug bei den QHY-Kamera-Modellen.
Inzwischen habe ich die neue Version 2.6.08 herunter geladen und getestet.
Herzlichen Dank für Deine Bemühungen mit dieser neuen Version.
Es scheint alles gut zu laufen. Auch stand inzwischen ein neues Update für meine schon
oben erwähnte Astrolumina QHY5III-290 mono bereit.

Vor ein paar Tagen habe ich mir von der Fa. Bresser-Rhede deren kleine
Okular- Einschub-Kamera zugelegt. Dieses Modell:
„Bresser Full HD Deep Sky Color“ GPCMOS 02000 KPA Color”
wird mit der Software: Touptek Sky 3.7 ausgeliefert.

Besagtes Modell ist 100%ig identisch mit dem AstroShop-Modell:
ToupTek Kamera GPCMOS 02000 KPA Deep Sky Color.
Es ist mit dem tollen rückwärts belichteten Sony Chip IMX 290 Color
mit 2,9 my Pixelbreite bestückt.
( Genau dieser Chip in „Mono“, sitzt auch in meiner weiter oben beschriebenen
AstroLumina QHY5III-290 mono-Kamera)

Diese Bresser / Astro Shop-Kamera hat zwar nur USB 2.0, ist aber preislich interessant
und für Deep Sky- Aufnahmen auch mit USB 2.0 sehr gut geeignet.

Beim Test, ob Fire Capture die Kamera erkennt, konnte ich feststellen, dass hier die
„ Altair GP CAM 130 C“ erkannt wird.
Es kamen allerdings nur SW-Streifen-Muster zustande.

Nun meine höfliche Frage:
Ist es mit vertretbarem Aufwand möglich, diese ToupTek Kamera in FireCapture
einzubinden?
FireCapture ist bei unseren Sternfreunden einfach das beliebtere Astro-Programm.
Es dürften sich noch wohl viele Sternfreunde für dieses Modell interessieren.

In der Hoffnung, dass ich nicht zu forsch gefragt habe verbleibe ich
mit sternfreundlichen Grüßen,
Ludger
















 
Status
Es sind keine weiteren Antworten möglich.
Oben