Hallo Stefan,
"Zur Berechnung aber müsste man da dann das RGB-Pixel hernehmen- also die doppelte Größe des Einzelpixels"
das ist falsch.
Die Anzahl der (bunten) Pixel nach dem Debayern entspricht genau der realen Anzahl der Pixel eines RGB-Chips. Beim Debayern errechnet errechnet sich statt einem einfarbigen (R, G oder B) Informationswert für jedes Pixel dann stattdessen ein farbiger Wert an genau derselben Stelle.
Gruss
Günter
Hallo Andreas,
irgendwas muss bei der Eingabe in Astrometry falsch gelaufen sein.
Wenn ich den angezeigten pixel_scale ps = 3,4"/px und deine Pixelgrösse nehme pg = 5.2µm nehme,
komme ich auch auf f = 5.2µm / tan(3.4") = 315mm.
Vergiss doch Astrometry, und mach es direkt aus deinem Bild raus.
Dazu misst du den Pixelabstand PA = Wurzel(delta_x² + delta_y²) zweier Sterne.
Dann schaust du z.B. bei CdC nach, welchen Winkelabstand WA diese Sterne haben.
Dann rechnest du (wie oben): f = pg * PA / tan(WA)
Gruss
Günter
Hallo Andreas,
beide gleichzeitig wird nicht gehen. Die 400D hat bei 750mm etwa 101x67 Bogenminuten.
Das wäre eine Bilddiagonale von ziemlich genau 2 Grad.
Die Belichtungszeit hängt auch von deiner Nachführung ab (guidest du?).
Im Einzelbild wirst du die Bewegung von Catilina bei moderaten Belichtungszeiten kaum sehen. Erst beim Stack vieler Bilder wird das auffällig.
Gruss
Günter
Gruss
Günter
Hallo Stefan,
nochmal zum Mitschreiben. Mein erster Einwand bezog sich auf deine falschen Behauptungen zum Addieren in Gegensatz zum Mitteln (z. B. 'Ausbrennen'). Deshalb habe ich folgendes behauptet:
Addieren bringt exakt dasselbe Ergebnis wie Mitteln.
Der einzige Unterschied ist der konstante Faktor (=Anzahl der Bilder), um den jedes Pixel des addierten Stacks grösser ist als das entsprechende Pixel des gemittelten Stacks.
Diese Aussage ist übrigens trivial, siehe Definition der Mittelwertbildung.
Deshalb ist es mir unverständlich, dass du jedesmal widersprichst.
Was sagst du dazu ?
ps:
bei diesen grundsätzlichen Fragen gilt übrigens Matthaeus 5 Vers 37
Gruss
Günter
Hallo Stefan,
Luc's Aussage
"but in this case the wrong values will have an influence on the result"
ist falsch.
Gruss
Günter
Hallo Alex,
"Vielleicht ist es ja so . Wenn man deiner Logik folgt und statt 4 übertrieben gesagt 1000 Amplituden addiert, wird auch bei 32 bit mal schluss sein."
Nimm mal bei Fitswork ein beliebiges Bild und multipliziere es mit 1 Million
(->Bearbeiten->Pixelmathematik->Wert multiplizieren).
Das Ergebnis sieht genauso aus wie das Original, auch das Histogramm ist identisch
(nur mit neuen Grenzen).
Wenn du zur Kontrolle das neue Bild wieder durch 1 Million dividierst (->Bearbeiten->Pixelmathematik->Wert dividieren) und das Ergebnis dann durch das Usprungsbild dividierst, bekommst du ein absolut ebenes Bild, wo sich der Min- und Maxwert erst in der letzten Stelle unterscheiden (->Rechtsklick->Bildstatistik zeigen).
Du könntest also ohne Überlaufprobleme 1 Million Bilder stacken.
ps:
bei 1 Milliarde geht's nicht mehr (bei einem Rohbild mit max=15000).
Man sieht's übrigens besser, wenn das zurückdividierte Bild wie ein Dunkelbild vom Original abgezogen wird
(->Bilder kombinieren->Dunkelbildsubtraktion->normal).
Gruss
Günter
Hall Stefan,
das stimmt nicht. Rschne mal statt mit der lächerlichen Integer-Arithmetik das Ganze mit 32 Bit-Fliesskomma durch, so wie jedes Bildbarbeitungsprogramm. Dann siehst du, dass ich recht habe.
Gruss
Günter
Hallo Andreas,
der Denkfehler in deiner Darstellung ist, dass du Nutzsignal und Rauschen als 2 gleichwertige Signale betrachtest.
In Wirklichkeit gibt es je Pixel und Aufnahme aber immer nur einen Pixelwert, der sich aus (vereinfacht, wie in deinem Beispiel) 2 Komponenten zusammensetzt. Da ist das konstante Nutzsignal s und das von Bild zu Bild variable statistische Rauschen n (mal grösser, mal kleiner, mal positiv, mal negativ).
Wenn du jetzt x Bilder addierst, addiert sich das konstante Nutzsignal zu x*n, aber das Rauschen ist ja in jedem Bild anders, der Pixelwert jeder Aufnahme ist ja mal grösser, mal kleiner als der Nutzsigalwert.
Mathematisch heisst das, dass das Rauschen des addierten Bildes nicht linear mit x anwächst, sondern nur mit Wurzel(x).
Beispiel:
s=20, n=2, x=16
->s/n jedes Einzelbilds ist also 20/2 = 10
Stack_s = 16*20 = 320
Stack_n = Wurzel(16) * 2 = 8
->s/n des addierten Stacks ist also Stack_s/n = 320/8 = 40
und jetzt ein allerletztes Mal:
ob du nach dem Stacken jeden einzelnen Pixelwert des addierten Stacks noch durch x dividierst (also mittelst), ändert überhaupt nichts an dem s/n des Stacks, das kann man also machen, muss es aber nicht.
Gruss
Günter
Hallo Andreas,
du machst hier eine ganz andere Baustelle auf.
Natürlich reduziert sich das Rauschen beim Stacken.
Das hat absolut nichts damit zu tun, was ich Stefan zu erklären versuchte:
dass es beim Stack-ERGEBNIS vollkommen egal ist, ob gemittelt oder summiert wurde.
Gruss
Günter
Hallo Stefan,
ob ein DSS-Stack nun mit dem Mittelwert oder der Summe weiterarbeitet ist mir vollkommen egal.
Es geht mir um die grundsätzliche Informationsgleichheit zwischen beiden Methoden.
"Das mag für den Anteil Rauschen passen, aber wo wird was multipliziert?"
Genau diese Multiplikation aller Pixelwerte des Stacks mit der Anzahl der gestackten Bilder ist doch der einzige Unterschied zwischen der Summe und dem Mittelwert.
Ich kann nicht verstehen, warum du das nicht kapierst. Aber egal, ich geb's auf.
Gruss
Günter
Hallo Andreas,
ich spreche von den zwei gestackten Bildern derselben Lights, nur einmal gemittelt und einmal addiert.
Da sind alle Informationen identisch, auch das Rauschen.
Und die 'Formeln' gelten auch nur dafür.
ps:
wir sind ja ganz schön vom Thema abgekommen, sorry.
Aber den immer wieder falsch dargestellten Unterschied zwischen Mitteln und Addieren muss man jedesmal wieder richtigstellen.
Dazu verpflichtet uns schon unsere Präambel.
Gruss
Günter
Hallo Andreas,
Wenn du jeden Pixelwert eines Bildes mit demselben Faktor multiplizierst, änderst du nichts an der Bildinformation.
Das Signal-Rauschverhältis S/N beider Bilder ist beispielsweise identisch, weil deine Manipulation Signal und Rauschen gleichermassen betrifft und sich der Faktor k rauskürzt.
Hier also eine Formel für dich: S/N = (S*k)/(N*k).
ps:
ebenso ist beispielsweise das Verhältnis jedes Pixelwerts Px zum hellsten Pixel Ph beider Bilder identisch (und damit auch die Bildinformation).
Formel: Px/Ph = (Px*k)/Ph*k)
Gruss
Günter
Hallo Stefan,
das stimmt nicht. Addieren und Mitteln einer Bilderserie enthält EXAKT dieselbe Information.
Der einzige Unterschied ist der konstante Faktor, nämlich die Anzahl der Bilder.
Wenn du den Schwarz- und Weisspunkt des Bildes des gemittelten Stacks notierst, und beim Bild des addierten Stacks diese beiden Werte multipliziert mit der Anzahl der Bilder verwendest, sieht das angezeigte Bild EXAKT gleich.
Gruss
Günter
Hallo Thomas,
das Knurren machen die Schrittmotoren beim Durchfahren der Start- und Stoprampen.
Zieh' mal deren Zahnräder ab, so dass sich nur noch die Motoren drehen.
Es wird immer noch knurren. Also nichts Dramatisches.
Gruss
Günter
Hallo BsBolide,
keine schlechte Entscheidung.
Stefans Einwand (ohne jede praktische Erfahrung) kann ich nicht verstehen.
Meine AS hat den besten PE aller meiner bisherigen Montierungen, bis 200mm gehen wirklich problemlos (wenn du Einnorden kannst).
Mein IOPTRON Skytracker ist nicht leichter, hat keinen brauchbaren Polsucher (der der SA ist dagegen wirklich brauchbar) und dessen PE ist etwa 3x schlechter. Er braucht eine externe Stromversorgung, der Stromverbrauch ist auch deutlich grösser. Also unterm Strich um Klassen schlechter.
Meine weiteren Erfahrungen:
Der PE der EQ5, der Astro5, der EQ3, der NP oder der GP-DX sind alle 2- bis 3-mal schlechter.
Ausserdem ist die faustgrosse Nachführung (einschliesslich Stromversorung) sehr mobil,
für Einsätze mit DSLR und Objektiv ideal (was du ja vorhast).
Ich hab' (nur interessehalber) auch mal einen ED80 (mit selbstgebauer zusätzlicher DE-Nachfühung, Arduino-basiert)draufgeschnallt. Ging auch noch, war aber grenzwertig.
Sowas widerspricht auch dem eigentlichen Sinn des SA, für 2-achsige Nachführungen mit höheren Brennweiten gibt es andere Lösungen.
Gruss
Günter
Hallo Martin,
natürlich sind alle Kapazitätsangaben geschönt, das ist mir klar. Aber kannst du deine Aussage belegen, dass sich die mAh auf den internen Akku beziehen (mit dessen Spannung)? Das glaube ich nämlich nicht.
Ich melde mich in ein paar Tagen mit den Ergebnissen meines Langzeittests mit dem (leider schon betagten) Logilink 2200mAh-Akku am Star Adventurer.
Gerade habe ich die Messung gestartet (nach dem Vollladen des Akku, Startwerte U=5,12V I=49mA).
Für die Verlaufsmessung verwende ich allerdings nicht den 'CHARGER Doctor' (habe auch so ein Ding wie Reiner, sehr praktisch). Aber der verbraucht selbst schon fast halb so viel der Star Adventurer (22,5mA).
Deshalb habe ich 2 Multimeter fix angeschlossen, die ich zur Messung nur kurz einschalten muss.
edit: Pleonasmus entfernt
Gruss
Günter
Hallo Reiner, Christopher,
der AS zieht knapp 50mA. Da gehen mit meiner daumendicken 2200mAh-Powerbank mehr als 40h.
Ich bevorzuge allerdings 4 Ni-MH-Akkus (2500mAh) im AS-Batteriefach. Die halten ebenfalls über 40h. So hat man kein Kabel und keinen Akku rumhängen, was einfacher und auch sicherer ist.
Gruss
Günter
Hallo Joachim,
Deine "Asteroiden" müssten sich mit retrograden 15°/Stunde bewegen, um bei stillstehender Kamera (fast) Punktbilder zu liefern.
Den Sonnenorbit, der das kann, gibt es nicht.
Das können also nur erdgebundene Objekte (Satelliten) sein.
Gruss
Günter
Hallo Karl,
die Sauberkeit der Frontscheibe deiner 314 (oder der Lodestar) kannst du ganz einfach bei Tag oder abends im Wohnzimmer testen.
Steck' die Kamera an einen kleinen Refraktor (oder Sucher) und mach vorne eine nur einige Millimeter grosse Blende dran.
Wenn du dann Bilder einer weissen Wand machst (muss nicht im Fokus sein), siehst du jeden kleinsten Makel auf der Scheibe und auch dem Chipfenster selbst (unterschiedlich gross).
Meine 314 hat übrigens einige winzige Staubkörner direkt auf dem Chip. Sie äussern sich durch sehr kleine, aber scharf begrenzte Donuts, ganz anders als deine oben gezeigten. Sie traten nach einem unfreiwilligen Sturz der Kamera auf den Boden auf. Die Innenseite des Glases ist glücklicherweise noch sauber, und aussen kann man ja putzen (und einfach kontrollieren).
Falls du es wagen solltest, die 314 zu öffnen, dann berichte bitte davon.
Falls es wirklich ganz einfach ist, könnte ich das vielleicht auch machen. Ich tendiere jedoch dazu, es zu lassen, denn erfahrungsgemäss wird es nur schlechter (Reinraumausrüstung steht mir nicht zur Verfügung).
ps:
die etwa 250 Pixel grossen Donuts deiner ersten Aufnahme entstanden durch Staubkorner, die etwa (900/200) * 250 * 6,54µm = 9mm vor der Chipebene waren, also auf der Frontscheibe der Kamera.
Der kleine Donut oben links wird übrigens von Staub direkt auf dem Chipfenster kommen (wie ich einige habe).
Gruss
Günter
Hallo Karl,
Ein Flat ohne die Aufnahmeoptik macht keinen Sinn.
Das Flat soll ja gerade alle Anschattungen des Light rausrechnen, und dazu muss es natürlich in derselben Kameraposition und mit derselben Optik wie das Light gemacht werden.
Die Donuts sich Schatten der Staubkörner auf eigentlich transparenten Flächen. Je grösser die Teleskopöffnung und je weiter das Staubkorn entfernt sind, desto grösser (und unauffälliger) werden diese Schatten.
Wenn du jetzt ein "Flat" ohne Aufnahmeoptik machst, kommt das diffuse Licht aus allen Richtungen und es gibt praktisch keinen erkennbaren Schatten mehr (höchstens bei Staubkörnern direkt auf dem Chip).
Gruss
Günter
Hallo Jo,
haben die Encodereingänge Pullups, siehe https://www.arduino.cc/en/Tutorial/DigitalPins ?
Ist einfach zu prüfen: der Eingang muss 5V haben, wenn kein Encoder angeschlossen ist.
Gruss
Günter
Hallo Karl,
auf die Idee mit der Lodestar bin ich auch schon gekommen, allerdings habe ich ein billiges 16mm C-Mount Objektiv verwendet.
Das hat ganz gut geklappt. Bei der EQ6 brauche ich das zwar nicht, da sie fix montiert ist, aber bei dem Star Adventurer ist es ganz praktisch, ohne Verrenkungen die richtige Position schnell und einfach zu finden.
Die Klemmung am Polsucher der EQ6 und auch des Star Adventurer geht übrigens ganz einfach mit zwei 1 1/4"-Okularadaptern:
Ein 2"-Reduzieradapter mit T2-Gewinde wird mit dessen Okularklemmschraube am Polsucher geklemmt und ein draufgeschraubter T2-Okularadapter klemmt die Lodestar.
Hier mal zwei (mangels Bildern vom praktischen Einsatz gerade hier im Wohnzimmer) gemachte Bilder:
Gruss
Günter
Hallo Jürgen,
eine unwichtige Bemerkung off topic: ein Projektor projiziert (so wie auch ein Injektor injiziert).
Sorry, aber mich stört das falsche Verb einfach.
Mein Latein war zwar auch traumatisch (>=5), aber das blieb doch hängen (jicere, icio, jeci, jectum = werfen).
Gruss
Günter
Hallo Karl,
die Bildfelddrehung beim gegebenem Konusfehler ist abhängig vom DEC-Wert der Bildmitte. Bei DEC=0° (Himmelsäquator) ist sie =0, bei DEC=90° (Polarsternregion) ist sie maximal (Bildfelddrehung = 2 * Konusfehler * sin(DEC) ).
Zum Scheinern:
Die Funktion 'Drift Align' bei PHD2 ist übrigens recht hilfreich zum Einscheinern. Es werden quantitative Polabweichungen angezeigt und die nötigen Korrekturen können im FOV der Guidecam kontrolliert/vorgenommen werden.
nachbarschaftliche Grüsse
Günter
Hallo Karl,
Zenitsicht wirst du doch haben. Da kannst du doch auch den Azimutfehler rausscheinern (oder leicht südlich davon, dann siehst du die Drift schneller).
Westlich oder östlich vom Zenit kannst dann den Altitudefehler korrigieren.
Auch ein Konusfehler führt zu einer Bildfelddrehung beim Meridianflip und anschliessendem Rezentrieren (falls DEC in Bildmitte ungleich 0).
Hast du das schon geprüft?
Gruss
Günter
