1° Forum di Astronomia Amatoriale Italiano

L'unica perdita di informazione introdotto dalla divisione è l'arrotondamento. Per ovviare a questo problema i dati vengono analizzati a 32bit. Così facendo, a monte della "stretchatura" l'errore di troncamento è inferiore a 1/256 sulla scala cromatica a 16 bit (da 0 a 255). Stiamo parlando di un errore che in genere è davvero piccolo.

Per fare un esempio, se i nostri dati fossero compresi tutti tra 0 e 1 (con il colore espresso tra 0 e 255) e moltiplicassimo ("stretchassimo") i dati con un coefficiente di 255, l'errore sarebbe inferiore a 1!

Attribuire il rumore a questo errore mi pare azzardato. Per me le fonti di errore sono ben altre.


Sent from my iPhone using Tapatalk

_________________
Vecchio nick: Pj1989

E chi ha attribuito rumore?
Sto dicendo che se usi per esempio light a 8 bit, li sommi arrivando - che so - a riempire 16 bit, e poi dividi il risultato (non float, intendo) e te ne esci di nuovo a 8 bit fai una cavolata. Ma ovviamente nessun programma lo fa...
Era un discorso per assurdo per spiegare come media e somma siano la stessa cosa, a meno di quanto giustamente puntualizzato da Leonardo.

_________________
{andreaconsole.altervista.org}¦ Ballscope 300/1500 DIY "John Holmes"

Giusto. A questo non avevo pensato. Grazie della precisazione.

Però a questo punto mi viene da dire che applicare la rejection a un algoritmo di somma è proprio sbagliato.

Se avessimo due pixel che su 3 foto sono (255 254) (253 254) (251 50) e applicassimo una somma con rejection, scartando il valore "50". Otterremmo (759 508) che mi pare un risultato decisamente "sbagliato"


Sent from my iPhone using Tapatalk

_________________
Vecchio nick: Pj1989

Infatti accanto al sigma clip esiste il sigma median, che sostituisce il bad value con la mediana. Poi c'e' SD mask che ha un algoritmo suo per decidere con cosa sostituirlo, medio o mediano. Di certo lasciare un buco (sommare cioe' un pixel che vale 0) non e' un'idea brillante...
La soluzione forse piu' corretta sarebbe fare, pixel per pixel, sommaCorretta = somma * numeroDiValoriOriginale/numeroDiValoriRimastiDopoLaRejection
Che e' poi quello che (suppongo) fanno quelli di CCDstack quando indicano media...

_________________
{andreaconsole.altervista.org}¦ Ballscope 300/1500 DIY "John Holmes"

Ma quindi per il lucky imaging è meglio la media?

Inviato dal mio Redmi 3S utilizzando Tapatalk

_________________
MN190 Mak-Newton f5,3
Orion atlas eqg moddata con rowan,cuscinetti ar e dec skf, corona gierlinger ,timone polare e vsf lappata, morsetto geoptik
Osc orion starshoot pro v2 e autoguida st4
Polar master

Ah ecco. Quoto Andrea e Pj1989.
Ok, è un dettaglio,
però così mi quadrano le cose.
Condivido.

_________________
Costanzo
"Una cosa ho imparato nella mia lunga vita: che tutta la nostra scienza è primitiva e infantile
eppure è la cosa più preziosa che abbiamo" (A. Einstein).

Tranquillo Ippo puoi condividere benissimo .. avevo già detto di aver sbagliato ma l'intenzione del mio primo intervento era quella di evidenziare che anche la mediana porta a valori che non sono stai letti realmente in caso di numero di campioni dispari e quindi anche con la mediana le tracce di situazioni non in statistica possono permanere per diffusione o per interpolazione. Non è il caso dell'asteroide in oggetto che permane anche con la mediana per via del sommarsi del segnale più basso gaussiano su varie pose che alza la mediana (dipende dalla velocità di spostamento nel FIT).

Per la somma ... il non sommare valori dubbi a seguito di reject aumenta la forbice, in astrofotografia, tra il segnale molto basso (dove maggiori sono le incertezze e lo scarto) ed il segnale degli oggetti andando a mitigare il rumore ed aumentare la dinamica. Per poter prendere coscienza di questo oltre alla teoria occorre anche aver toccato con mano i dati con un bel po' di pratica.

_________________
Cieli sereni.
Astrofotografo per Passione ...

mmm non ho capito cosa vuoi dire

_________________
{andreaconsole.altervista.org}¦ Ballscope 300/1500 DIY "John Holmes"

Provo a spiegarti se non ci riesco chiedo scusa in anticipo.

Premesso che l'SNR è il rapporto segnale su rumore ... nel caso della somma i pixel oggetti di reject non vengono sommati e non viene usata nessuna delle interpolazioni che tu hai supposto ... semplicemente non vengono sommati. Ora dove c'è segnale reale come galassie, nebulose etc la reject avviene al 99% solo per la presenza di oggetti/eventi estranei . Nelle parti deboli invece la reject è più frequente che avvenga (sempre in CCDStack puoi evidenziare in rosso i pixel soggetti a rejection e ti sarà lampante quello che ti dico). Questo significa che le zone con segnale reale accumulano più ADU nella somma in proporzione rispetto alle zone con meno segnale andando ad aumentare il rapporto SNR e di conseguenza la dinamica. I dati cosi ottenuti ovviamente escono dal regime di linearità.

_________________
Cieli sereni.
Astrofotografo per Passione ...

Questo significa che in realta' il rapporto segnale rumore risulta penalizzato dal ridotto numero di campioni proprio dove il segnale e' piu' debole (visto che piu' campioni hai, piu' migliori il SNR), i.e. che si puo' sperare meno di tirare fuori qualcosa stretchando molto. Secondo me c'e' qualcosa che non va. Un algoritmo di rejection ben fatto dovrebbe essere piu' imparziale, visto che presumo che gli outlier debbano essere uniformemente distribuiti. Certo al momento non mi viene in mente nessuna soluzione a questo problema...
Grazie per l'interessante contributo!

_________________
{andreaconsole.altervista.org}¦ Ballscope 300/1500 DIY "John Holmes"