Iso, Stacks,Rauschzahl,gesamtbelichtung=Verwirrung

  • Hallo


    die Stacking Programme verwenden immer 32 bit Fleißkomma, die angezeigten Werte Sind nur auf gewünschten Wertebereich skaliert, das geht bei Fredi auch in 0-1 rein. wie man zu der höheren Bittiefe kommt ist einfach, belegt ein Stern 2x den Wert1 und 1x den Wert 0 wird das zu 0,666 oder auf einer Scala von 0-3 die 2 oder einfacher 2/3


    Aber beim addieren und mittelnder Bilder habt ihr einen Bock geschossen,
    12 + 18+14+16 ist zwar im Durchschnitt 15 aber da es Rauschen ist muß es noch durch Wurzel Anzahl Bilder dividiert werden also durch Wurzel 4
    ergibt mit gemitteltem Nutzsignal einen s/n von 22/7,5 was tatsächlich gegenüber Einzelbild mit 22/15 das halbe Rauschen ist.
    Geht auch beim addieren, dann 88/30
    sind nun Brüche, man könnte den Nenner auch gleich setzen um zu vergleichen, ist in beiden Fällen 2,9333/1 das Signal ca. 3x Stärker als das Rauschen, im Einzelbild war es nur 1,5x Stärker als das Rauschen.


    Gruß Frank

  • Hallo Alex,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"> Ich hab kurz vor deinem Beitrag auch schon mal angesprochen. Wie man von einem 8 Bit System auf ein höheres kommt, also 255 mal 4 , ist wirklich für mich die entscheidende Frage<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Nun, gerechnet wird vermutlich sogar mit 64bit[:D], das gespeicherte Bild hat 32Bit Farbtiefe. Da passen nun mal deutlich mehr als 4x8Bit Bilder rein.


    Anders gefragt? Was würde es für einen Sinn geben das gestackte Bild auf 8bit zu reduzieren? Egal ob gemittelt oder addiert.
    Mittle doch mal (15+18+13)/3 = 15.333333 rundest du dann auf 15 ab und schmeisst die Nachkommastellen einfach weg?


    Gruss Jürg

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: gscholz</i>
    <br />


    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.


    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hallo und Danke für Deine Erklärung.


    Hatte aber diesen Punkt ja bereits als "Richtig" erkannt?? Das war ein lediglich ein verbales Mißverständnis. Mathematisch ist ein Mittelwert nicht eine Summe, sonst bräuchte man diesen nicht. Das man bei teilen eines Zählers denn Nenner um den gleichen Wert teilen muß, um auf das gleiche Ergebnis zu kommen, ist korrekt!


    s/x geteilt durch n/x = s / n!


    Mit der Darstellung war dann ja auch Alles klar (siehe auch meine Tabelle, wo ich das mit aufgenommen habe, um Diskussionen vorzubeugen). Nötig war es nicht


    Liebe Grüße und Danke Dir


    in sofern hätte es


    "ich erkläre es aber nun ein allerletztes Mal" nicht unbedingt bedurft.


    Andreas[:)]

  • Hi, <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"> Rschne mal statt mit der lächerlichen Integer-Arithmetik das Ganze mit 32 Bit-Fliesskomma durch, so wie jedes Bildbarbeitungsprogramm<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote"> <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">die Stacking Programme verwenden immer 32 bit Fleißkomma...<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Komisch- zu lesen in der Deepskystacker-FAQ- <b>Photoshop kann die von DeepSkyStacker erstellten 32 Bit (Ganzzahl-Typ) TIFF-Dateien nicht öffnen. </b>


    Hi Jürg, <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Mittle doch mal (15+18+13)/3 = 15.333333 rundest du dann auf 15 ab und schmeisst die Nachkommastellen einfach weg?
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Das macht ja der Chip bzw. die Ausleserei doch auch schon- ein Pixel hat z.B. entweder den Wert 25 oder 26- und wenn auf 25 noch 3 Photonen dazukamen, den Wert aber nicht auf 26 erhöhen konnten werden diese 3 Photonen unter den Tisch fallen. Rechenfehler treten bei Intergerzahlen ebenso auf wie bei Fließkommaberechnungen.


    Gruß
    Stefan

  • Hallo jürg,


    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. Was passiert denn, wenn du in deinem Beispiel die grauwerte mit 1000 multiplizierst. Das Verhältnis bliebe gleich aber du hättest einen Bereich von 255000 graustufen.


    Viele grüße

  • Hallo Stefan,


    das ist ein weit verbreitere Irrtum. Wenn das Signal zwischen 25 und 26 liegt, also sagen wir 25,5, dann kommt es eben bei 100 Aufnahmen etwa 50 mal auf die 25 und 50 mal auf die 26.
    Es geht durch die A/D Wandlung nix verloren, es sei denn der gain ist viel zu niedrig.


    Anbei ein schönes Gegenbeispiel: Eine 8bit DMK Aufnahme, links oben das Einzelbild. Im Histogramm und im Bild nur Ausleserauschen, alle Werte des Einzelbildes zwischen 1 und 7 ADU.
    (es handelt sich nur um ein abfotografiertes Bild)
    Dann habe ich bis zu 1000 mal gestackt. Es muss also schon ein Teil der Info im Einzelbild drin sein, sonst könnte es ja nicht funktionieren (und die lucky Imaging Sachen auch nicht)


    Zu guter letzt habe ich auch noch ein Dark mit 1000 Bildern abgezogen, man sieht sehr schön, dass man damit wieder den Noise erhöht. Man müste somit ein nochmehr gemitteltes masterdark hernehmen.



  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: der alex</i>
    <br />Hallo jürg,


    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. Was passiert denn, wenn du in deinem Beispiel die grauwerte mit 1000 multiplizierst. Das Verhältnis bliebe gleich aber du hättest einen Bereich von 255000 graustufen.


    Viele grüße
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hallo Alex,


    Wie schon telefonisch mit Dir auch schon diskutiert ein Beispiel. Die Frage ist doch, was für ein Signal erwarte ich?


    Vor mir stehen zwei Menschenschlangen. Ich kann diese nach unterschiedlichen Gesichtspunkten auswerten. Zum Rauschen oder Signal dürfte nicht die Anzahl der Personen korrelieren sondern die durchschnittliche Größe der Menschen.


    Der erste in der linken Schlange ist ein kleinwüchsiger Mensch, der in der zweiten Schlange neben ihn steht, riesig. Der Infogehalt zur Aufgabenstellung ist nahe Null. Erst wenn ich alle in den zwei Schlangen stehenden Menschen ausgewertet habe und dann zwei nebeneinander stelle, welche dem Durchschnitt entsprechen habe ich links und rechts einen Menschen stehen, welcher annhähernd gleichgroß ist. Das ist der Mittelwert und der Median einer Gaußverteilung, welcher sich durch die Anzahl der Menschen heraus kristallisiert. Alle Andere sind Informationen, welche durch Ihr Delta ein rauschen hervorrufen, welches um das Signal schwanken.


    Und ja, eine völlig andere Information ist die Anzahl der Menschen, welche ich im Zweifelsfall auf 6Milliarden aufsummieren kann. Damit treffe ich eine Aussage zur statistischen Sicherheit aber nicht zu dem erwarteten Signal!


    Für das S/N Verhältnis (um gleich wieder vorzubeugen ist es Wurst). Aber durch Masse an Informationen (Addition) hebe ich das Signal (Median) erst hervor. Der Median ist aber nun einmal der Mittelwert und nicht die Anzahl an Infos.


    Und das mit den Kommastellen. Ich könnte, wie erwähnt, z.B.: keine Länge mit einem digitalen Meßschieber messen. Das würde nicht funktionieren, wenn Kommastellen ein Problem sind.


    Liebe Grüße in die Heimat


    vom Andreas

  • 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
    (-&gt;Bearbeiten-&gt;Pixelmathematik-&gt;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 (-&gt;Bearbeiten-&gt;Pixelmathematik-&gt;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 (-&gt;Rechtsklick-&gt;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
    (-&gt;Bilder kombinieren-&gt;Dunkelbildsubtraktion-&gt;normal).


    Gruss
    Günter

  • Hi Norbert, <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Wenn das Signal zwischen 25 und 26 liegt, also sagen wir 25,5, dann kommt es eben bei 100 Aufnahmen etwa 50 mal auf die 25 und 50 mal auf die 26. <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Also stimmt meine Aussage- ich bezog mich auf das Auslesen eines <b>einzelnen </b> Bildes- und entsprechend deinem Beispiel würde als 50 Bildern zu wenig, bei den anderen 50 Bilder zuviel ausgelesen.


    Würde der Pixelwert nicht bei 25,5 sondern bei 25,4 liegen dürften 100 Bilder mit 25 ausgelesen werden. Also wird 100x der Wert 0,4 unterschlagen. Nichts anderes hab ich gesagt, bereits die Kamera macht Rundungsfehler. [:)]


    Es ging dabei nicht darum ob Info im Einzelbild drin ist oder nicht, lediglich um den Vorgang Auslesen eines Pixels.


    Gruß
    Stefan

  • Hallo Günther!


    Und der dargestellte Wert ist dann die physische Signalgrösse?
    Die Bilder werden doch gleich aussehen! Vermute ich. Da sollte das Pixel schwarz doch auch schwarz bleiben!


    Ist die Information nicht immer in der Abszisse des Histogramms versteckt und ändert sich diese? In der Ordinate versteckt sich doch die Anzahl der pro Klasse aufgetretenen Ereignisse! Wenn das Programm die Ordinate hochzieht, dann ist es doch das Hochziehen der absoluten Häufigkeit eine Signals welches aber in der Ordinate liegt. Kann mich täuschen aber wenn das Programm hier mit relativen Häufigkeiten arbeiten würde, dann wäre wieder Alles in Ordnung. Am Besten wäre es auf eine Standardnormalverteilung zu bringen.


    Ich kenne das Programm allerdings nicht. Um Verwirrungen vorzubeugen ... ich kann das nur vermuten besser das ist so in anderem Zusammenhang in meinem Beruf so.



    Lg


    andreas


    Nachtrag, wobei die Bitanzahl = Histogrammklassen sind. Die kann ich füllen bis unendlich aber die Info ist, ob der beobachtete Wert sich in entsprechender Klasse befindet oder nicht. Ich kann durchaus Meßgrößen in Klassen einteilen ohne und mit Komma, wenn die Klasse ein natürliche Ober und Untergrenze hat.

  • Hallo Alex,


    nun wie schon einmal angedeutet hat ein 12bit Bild 1Mio. mal Platz in einem 32Bit Bild.


    Wenn du das gestackte Bild also auf 16 oder 8Bit skalierst und in dem Formart speicherst, verlierst du Informationen und zwar genau gleich viel ob addiert oder gemittelt.


    Der Wert einer Gleitkommazahl wird in die Mantisse und Exponet dargestellt.


    Eine Zahl hat dann z.B. eine 8-Stellen Genauigkeit. Die Kommastelle wird durch den Exponent bestimmt.
    54248125
    5424.8125
    5.4248125


    Hat man nun ein Format was nur 4-Stellen speichern kann, ist dass nun logischerweise weniger genau. z.B.
    5.424 es geht Information verloren egal ob Mittelwert oder sonst Addition es gehen die Gleichen Werte flöten.


    Gruss
    Jürg

  • Hallo, Günter,


    Das bestätigt ja meinen Einwand. Bloß mal theoretisch. Ein stapelprogramm würde mit 8 Bit (255)arbeiten und Ich hätte einzelbilder mit einem Umfang von 2 (4) Bit. Dann stößt doch die summierung an Grenzen. Multiplizieren ich diesen Umfang(4) mit 100 hätte ich einen von 400. Beim Signal und rauschen mache ich dasselbe. Wie schon geschrieben, das Verhältnis stimmt. Was sagt jetzt aber mein Programm dazu.Es kann 255 aber 400? Hochrechnen geht ja , geht auch runterrechnen? Wenn es ein auffüllen wäre , würde ja das Verhältnis nicht mehr stimmen.
    Da wäre es doch sinnvoll erst alles zusammenzurechnen , den Mittelwert bilden und dann auf das 32 oder 64 Bit System hochzurechenen.
    Wie gesagt wenn ich ein 255 stufenbild habe , addiere und Mittle ,kann das Ergebnis nicht grösser als 255 sein. 10 Prozent wären ca. 25 und bleiben nach dem Hochrechnen auf 32 oder 64 bit auch 10 Prozent . Wenn 10 Prozent rot sind , dann sind sie nach dem Hochrechnen eine feinere Abstufung von rot.
    Das sind so meine Gedankengänge zur Frage , nicht ob addieren oder Mitteln das gleiche Verhältnis bringen, sondern was am Ende gemacht wird, damit es funktioniert.


    Viele grüsse

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Würde der Pixelwert nicht bei 25,5 sondern bei 25,4 liegen dürften 100 Bilder mit 25 ausgelesen werden. Also wird 100x der Wert 0,4 unterschlagen. Nichts anderes hab ich gesagt, bereits die Kamera macht Rundungsfehler.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Das ist übrigens ein schönes Beispiel, bei dem das Noise sogar hilft:
    Wenn das Pixel nun rauschbehaftet ist, so wird es auch manchmal über 25.5 ansteigen. Beim Mitteln entsteht dann ein Wert, welcher idealerweise recht gut 25.4 wiedergibt.
    Dies wird in der Technik gelegentlich ausgenützt: Einem Nutzsignal künstliches Rauschen addieren; um solche Quantisierungsfehler zu reduzieren.


    Beim Stacken hängt die Genauigkeit des Endergebnisses davon ab, wie der interne Zahlenraum dargestellt ist. Wenn man mit 1e6 multiplizieren und anschl. dividiere kann, scheint das Programm ganz gut zu sein.
    Übrigens, die Darstellung am Bildschirm ist dann wieder 8Bit pro Farbe, also hier klar begrenzend.


    Gruß: Richard

  • Hallo Stefan

    Code
    Würde der Pixelwert nicht bei 25,5 sondern bei 25,4 liegen dürften 100 Bilder mit 25 ausgelesen werden. Also wird 100x der Wert 0,4 unterschlagen. Nichts anderes hab ich gesagt, bereits die Kamera macht Rundungsfehler.


    Macht sie im konkreten Fall nicht, weil dein readnoise in der Praxis so hoch ist, dass sich Verteilung nicht nur auf die zwei benachbarten Werte, sondern einige darüber hinaus erstreckt. Bei einer DSLR hast Du zum Beispiel je nach ISO eine typische Kombinatonen von 1 e-/ADU und 6 e- readnoise, teilweise mit recht ungenauem ADC.
    Natürlich wird irgendwo ein Rest abgeschnitten, aber im gleichen Bild kommt dafür der Wert genauso oft zum nächsthöhergelegenen bit.
    (Im Mittel natürlich) Die Photonen, die du an einem Pixel scheinbar verlierst, gewinnst Du an anderer Stelle. Du kannst es eben nicht auflösen, aber die Digitalisierung bewirkt netto keinen Signalverlust.


    Um bei deinem Beispiel zu bleiben: die 15 käme trotzdem noch vor, nur nicht so oft.


    Wenn der Gain jetzt bei 50 Elektronen pro ADU läge, und der Read Noise des Chips vor der A/D Wandlung bei bei 4 Elektronen läge, dann hättest Du recht, da müsste in jedem Bild erst mal die 50 übersprungen werden. Das ist aber ein rein akademisches Beispiel.
    (okay, da müßte ich mich dann auch zurückhalten)


    Bei DSLRs und Astro CCDs ist das Histogramm in den Rohdaten immer über ausreichend ADU Stufen gespreizt, bei niedrigen durchs Ausleserauschen, bei hohen durch den Shotnoise sowieso. Durch diese Verbreiterung sieht auch ein Kamera- 8bit Bild immer noch natürlich aus, während man bei Grafiken oder Trickfilmen, die sozusagen unnatürlich "glatte" Flächen mit beliebig feinen Intensitätsstufen haben, bei 8bit/Kanal Grafikauflösung flächige Artefakte zeigen können. Ebenso liefert eine 16bit Kamera bei Tageslicht auch selten bessere Bilder, als eine vergleichbare 12bit Kamera.





    Gruß
    Norbert

  • Hi,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Da wäre es doch sinnvoll erst alles zusammenzurechnen , den Mittelwert bilden und dann auf das 32 oder 64 Bit System hochzurechenen<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Wenn schon andersherum wird ein Schuh daraus.
    Wie willst du den vorher alles Zusammenrechnen, wenn du die 400 in deinem Gedankenexperiment gar nicht abbilden kannst?

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Juerg_B</i>
    <br />Hi,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Da wäre es doch sinnvoll erst alles zusammenzurechnen , den Mittelwert bilden und dann auf das 32 oder 64 Bit System hochzurechenen<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Wenn schon andersherum wird ein Schuh daraus.
    Wie willst du den vorher alles Zusammenrechnen, wenn du die 400 in deinem Gedankenexperiment gar nicht abbilden kannst?
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    ... wenn die 400 die einzigste Information in jedem Pixel der Mittelwertbildung ist, lässt die sich die aber auch mit einem Bit darstellen. 400 = 1--&gt; nicht 400 =0!

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: 19Dreas70</i>
    <br /><blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Juerg_B</i>
    <br />Hi,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Da wäre es doch sinnvoll erst alles zusammenzurechnen , den Mittelwert bilden und dann auf das 32 oder 64 Bit System hochzurechenen<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Wenn schon andersherum wird ein Schuh daraus.
    Wie willst du den vorher alles Zusammenrechnen, wenn du die 400 in deinem Gedankenexperiment gar nicht abbilden kannst?
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    ... wenn die 400 die einzigste Information in jedem Pixel der Mittelwertbildung ist, lässt die sich die aber auch mit einem Bit darstellen. 400 = 1--&gt; nicht 400 =0!
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Richtig, ist jetzt aber schon sehr weit aus dem Zusammenhang gerissen.


    Ein Letzter Versuch.
    Es sind 10 3dl Gläser unterschiedlich mit Wasser gefüllt. Wenn du alles in ein Gefäss schüttest, muss dieses min. ein Fassungsvermögen von 3L haben sonst läuft's über. Deshalb nimmt man gleich einen Swimmingpool. Da hat es genug Platz[:D]


    Gruss
    Jürg

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Juerg_B</i>
    <br /><blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: 19Dreas70</i>
    <br /><blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Juerg_B</i>
    <br />Hi,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Da wäre es doch sinnvoll erst alles zusammenzurechnen , den Mittelwert bilden und dann auf das 32 oder 64 Bit System hochzurechenen<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Wenn schon andersherum wird ein Schuh daraus.
    Wie willst du den vorher alles Zusammenrechnen, wenn du die 400 in deinem Gedankenexperiment gar nicht abbilden kannst?
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    ... wenn die 400 die einzigste Information in jedem Pixel der Mittelwertbildung ist, lässt die sich die aber auch mit einem Bit darstellen. 400 = 1--&gt; nicht 400 =0!
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Richtig, ist jetzt aber schon sehr weit aus dem Zusammenhang gerissen.


    Ein Letzter Versuch.
    Es sind 10 3dl Gläser unterschiedlich mit Wasser gefüllt. Wenn du alles in ein Gefäss schüttest, muss dieses min. ein Fassungsvermögen von 3L haben sonst läuft's über. Deshalb nimmt man gleich einen Swimmingpool. Da hat es genug Platz[:D]


    Gruss
    Jürg
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Da hast Du Recht. Der Pool ist aber die Summe aller Informationen nicht die Information selbst!


    Die wäre z.B. wie viele Gläser waren voll =2, halbvoll = 1, leer = 0.


    Wenn der Pool statistisch gesehen zu klein ist um dieses Rätsel im niedrigen Bit Bereich zu lösen, kann man auch auf ein Freibad ausweichen. Die Bitzahl lässt sich ausdehnen (Befüllungsgrad). Egal ob ganze Weltmeere (Bildanzahl) benötigt werden, dass Pixel bekommt wahrscheinlich nicht den Atlantik beaufschlagt sondern unter Umständen ein mageres 1 Signal! Irgendwann lohnt das stapeln nix mehr, denn ab 125 Bildern ist statistisch sicher der Mittelwert ermittelt, welcher im Beispiel 1 ist.


    Gruß


    Andreas


    [:)]

  • Hallo, Alex,


    wenn Du noch etwas zu den sinnvollsten ISO-Werten (betrifft aber nur die Kamera-Teleskop-Kombination! mehr nicht) lesen möchtest, schau mal auf die Beiträge des Kollegen Tino, "tbstein", weiter unten auf der Seite. Der Wert hängt auch von der Einzelbelichtungszeit ab. Für längere Belichtungen: ISO 200!


    http://www.astrotreff.de/topic…PIC_ID=190052&whichpage=2


    viele Grüße und cs
    Andreas

  • Hallo andreas,


    Danke für den Tip . Ich schau gleich mal rein.


    Dir nen schönen abend


    Ps: das mit den Sternen , also blau und gelb m38 , hast du zuletzt doch gut hinbekommen !



    Viele grüsse

  • Hi zusammen,


    um Klarheit zu schaffen- wird nun addiert oder gemittelt- hab ich einfach mal den Autor von Deepskystacker per Mail angefragt.


    Meine Fragestellung war-


    wird bei DSS und den anderen ihm bekannten SW-Tools addiert oder gemittelt?


    Warum wird das so gemacht?


    Rechnen die Programme Integer oder Fließkomma.


    Er gab mir auch recht schnell eine nette Antwort und auch die Erlaubnis, diese hier einzustellen.


    <i>Hi Stefan,


    The goal of reducing noise is to keep meaningful data and remove stray data.


    On any given image, some pixels are right and others are wrong (noise). The assumption is that for any given pixel in a set of images, most of them will be right or close to right.
    The idea is to remove the stray pixels and keep the right ones. You can do it by averaging (that’s the same as summation), but in this case the wrong values will have an influence on the result.
    By using the mean, you will remove all the lower and higher values and keep a mean value. That is working assuming that the noise is evenly spread (Gaussian noise is).


    As for SW implementation they all use floating point value to retain the best possible precision.


    I hope it is making sense to you ;)


    Clear skies,
    Luc</i>


    Damit ist also klar- es werden Fließkommawerte gemittelt.


    Gruß
    Stefan

  • Hallo Stefan,


    Danke Dir. Der Satz zu gleichmäßigen Verteilung nach Gauß ist dann das erwähnte Histogramm (pro Pixel und Stapel) und dabei ist jede "Bitstufe" durch eine Unter- und Obergrenze gekennzeichnet.


    Nachdem ich diese "Bitsäule" gefüllt habe, ist aber nicht mehr erkennbar, ob das eingeordnete Signal mal eher an der Bitunter- oder Obergrenze lag. Deshalb verliert man wahrscheinlich Infos beim Skalieren, denn nach dieser Aktion gibt es nur noch den Bitwert selbst.


    Ich kann nur sagen "Das ursprüngliche Signal lag zwischen der Untergrenze x und der Obergrenze y". Das ist aber Vermutung! Auch Kommazahlen sind durch ein Bit darstellbar. Die Zahl 0,23456 lässt sich in ein Bit packen, in welchen alle Daten reingepackt werden, welche zwischen 0 und 1 liegen. Wenn das Ergebnis besser sein soll, muß ich aus dieser Säule 2 Klassen machen. Theoretisch ist der gestackte Himmel mit einem Bit dasrtellbar. Das Ergebnis wäre, mein gestacktes Bild hat nur zwei Anteile: schlohweiß oder tiefschwarz. Aber auch das ist eine Mittelwertbildung.


    Danke nochmals und einen schönen Tag!


    Andreas

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: 19Dreas70</i>
    <br />Hallo Stefan,


    Danke Dir. Der Satz zu gleichmäßigen Verteilung nach Gauß ist dann das erwähnte Histogramm (pro Pixel und Stapel)


    Danke nochmals und einen schönen Tag!


    Andreas
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!