Oggi è 28 mar 2024, 18:10
   
Text Size
Login

Astroart 7!

Discutiamo qui dell'hardware e dei software astronomici per l'elaborazione grafica, planetari, interfacce per strumenti e altro.

Messaggioda Paolo » 19 set 2018, 10:53

Ciao a tutti, segnalo il rilascio della nuova versione di Astroart:

http://www.msb-astroart.com/

Le novita' sono davvero tante, da una potentissima versione nativa del software a 64 bit (ideale per processare piu' velocemente frame di grandi dimensioni, es. RAW DSLR) a nuove interessanti funzioni del pretrattamento. L'atlante e' rinnovato e capace di accedere al nuovissimo database stellare Gaia DR2 (via WEB). E' stato introdotto un comodo sequencer per la fase di acquisizione. Altre nuove funzionalita' riguardano la rimozione dei gradienti, i filtri per l'analisi di immagini cometarie e un filtraggio multiscala utile per le immagini hi-res (simile a quello di Registax per intenderci).

Non e' tutto, vedi elenco sotto (comprende l'accesso al db Gaia che ho gia' menzionato):

-------------- Astroart 7.0 minor new features --------------

* Profiles can be changed in realtime.
* Blink windows save animated GIFs.
* Blink windows with zoom and panning.
* Bigger preview for image and header in the Open Dialog.
* Compress stars with adaptive option.
* Crop as macro command.
* Automatic coregister for images from different sources.
* Improved autoalignment for trichromy.
* Immediate plate solve without dialog window.
* Palettes can be applied to color images.
* Smart file selection for sequences in Apply Macro and Preprocessing.
* Interpolation for photometry plots.
* Copy to spreadsheets for photometry plots.
* Telescope with calculated altazimuth coordinates.
* Telescope commands for tracking on and off.
* Script new functions for camera and telescope control.
* Script template from sequencer.
* Script template from file list.
* Connection with Aladin web site.
* Star atlas supports the GAIA DR2 catalog.
* Star atlas shows CCD frame for calibrated images.
* Optimize JPEG with comparison to original image.
* Selection of images is easier thanks to a colored frame.
* Optimized 2/3 visualization zoom (66%).
* Option for automatic zoom when opening images.
* Rectangle selection with preview (CTRL+R).
* Rectangle and line selections can be moved in realtime (CTRL+arrows/mouse).
* Improved Configuration, with aperture photometry preview and more.
* Visualization cursors can be moved slowly clicking the right mouse button.
* Numeric fields can be changed quickly with CTRL+mouse wheel.
* Option to remember the last used folder.
* Option for big fonts in status bars.
* Option for desktop brightness.
* Several minor bug fixes.


Paolo
Avatar utente
Paolo
Quasar Guru
 
Messaggi: 7747
Iscritto il: 16 gen 2006, 22:49
Località: L'Aquila

Messaggioda Pering » 19 set 2018, 11:47

al di là delle novità accennate e sempre positive, segnalo che astroart 6 lavora con file a 16 bit mentre pixinsight con file a 32 bit. Non so se questo divario è stato colmato con la nuova versione.
Pering
Quasar Guru
 
Messaggi: 4061
Iscritto il: 22 nov 2010, 14:58

Messaggioda Paolo » 19 set 2018, 15:55

Ciao Edo, io impiego prevalentemente immagini mono a 16 bit e ho avuto modo di fare solo qualche trattamento di RAW colore della EOS-500D (14 bit per canale, file da 42 bit).

Puoi condividere un esempio di cosa non riesci a caricare/trattare? Astroart e' in grado di gestire immagini a 96 bit (tre piani colore da 32 bit a virgola mobile ciascuno), non riesco a capire come puoi avere problemi con un file a 32 bit. Forse un problema di formato, non di profondita' di bit?

Paolo
Avatar utente
Paolo
Quasar Guru
 
Messaggi: 7747
Iscritto il: 16 gen 2006, 22:49
Località: L'Aquila

Messaggioda Pering » 19 set 2018, 17:13

Scusate non mi sono spiegato bene.
Faccio un esempio: se carico file a 16 bit e uso la funzione preprocessing in astroart il risultato sarà un file in 16 bit, mentre se uso pixinsight ottengo un file a 32 bit.
Pering
Quasar Guru
 
Messaggi: 4061
Iscritto il: 22 nov 2010, 14:58

Messaggioda Paolo » 19 set 2018, 17:38

Nessun problema Edo! In Astroart i bit di profondita' vengono decisi in fase di salvataggio in base alle intensita' dei pixel presenti nell'immagine. Se ad esempio i valori sono compresi tra 0 e 255, AA salva un FITS ad 8 bit. Sopra 255, se non superano 65535 ADU, AA salva un 16 bit FITS. Se si superano i 65535 ADU (anche in un solo pixel) oppure se il valore di un pixel e' espresso in virgola mobile, AA salva in 32 bit.

Detto questo, capisci che ad esempio la media o la somma dello stacking possono dare origine a FITS a 16 o 32 bit rispettivamente.

Penso che Pixinsight, per salvare un file a 32 bit a valle di uno stacking di immagini a 16 bit, abbia prodotto una immagine con valori dei pixel che superano i 64K ADU, altrimenti sta sprecando spazio!

Puoi verificare con le funzioni di statistica in entrambi i sw.

Paolo
Avatar utente
Paolo
Quasar Guru
 
Messaggi: 7747
Iscritto il: 16 gen 2006, 22:49
Località: L'Aquila

Messaggioda Pering » 19 set 2018, 21:38

Io la vedo in maniera più semplice, dimmi se sbaglio, faccio un esempio per essere chiaro.
Il pixel x,y del primo frame vale 1003, il pixel x,y del secondo frame vale 1004, faccio la somma esce che il pixel x,y della somma vale 2007, faccio la media esce che il pixel x,y vale 1003,5, ora se ho a disposizione 16 bit dovrò decidere di attribuire al pixel x,y somma o media il valore 1003 o il valore 1004 certo no posso dargli 1003,5. Avendo a disposizione 32 bit gli darò 4014. È chiaro che se in una media ho il valore 1003,1 be allora non basta neanche 32 bit per definire quel numero dovrò andare almeno a 64 bit per avvicinarmici.
Circa la virgola mobile ne riparleremo.
Pering
Quasar Guru
 
Messaggi: 4061
Iscritto il: 22 nov 2010, 14:58

Messaggioda Paolo » 19 set 2018, 23:53

Ciao Edo, teniamo un attimo conto del sistema binario:

- il totale dei numeri interi rappresentabili con 8 bit 0/1 e' pari a 256 (da 0 a 255). 256 sono le combinazioni possibili che vanno da 00000000 a 11111111. Si arriva direttamente al dato con la formula: "combinazioni possibili = 2^bit"

- il totale dei numeri interi rappresentabili con 16 bit e' pari a: 2^16 = 65536

- il totale dei numeri interi rappresentabili con 32 bit e' pari a: 2^32 = 4294967296

Spero che sei d'accordo. Detto questo torniamo a quello che scrivi.

Il pixel x,y del primo frame vale 1003, il pixel x,y del secondo frame vale 1004, faccio la somma esce che il pixel x,y della somma vale 2007, faccio la media esce che il pixel x,y vale 1003,5, ora se ho a disposizione 16 bit dovrò decidere di attribuire al pixel x,y somma o media il valore 1003 o il valore 1004

Perfetto. Il sw fa la dovuta approssimazione al numero intero.

certo no posso dargli 1003,5

In Astroart puoi, basta impostare il formato dell'immagine in virgola mobile (io ho il menu di AA in inglese: EDIT -> DATA FORMAT -> Floating point). Ma lasciamo stare adesso questo caso "complicato"...

Avendo a disposizione 32 bit gli darò 4014

Da quale somma esce 4014? Stai sommando 4 frame? In ogni caso 32 bit sono sprecati per memorizzare il valore 4014. Ne bastano 12 (con 12 bit si arriva a 4095). Se il valore max dei pixel non supera 4095 e' uno spreco salvare a 32 bit (il file e' inutilmente piu' grande).

È chiaro che se in una media ho il valore 1003,1 be allora non basta neanche 32 bit per definire quel numero dovrò andare almeno a 64 bit per avvicinarmici.

Perche' no? Bastano 32 bit in vigola mobile (come detto sopra).

AA_float.jpg

Questo pero' e' un caso meno semplice, e' meglio lasciarlo da parte.



Ricapitolando, il pixel piu' luminoso nella tua immagine da memorizzare ha valore 240 ADU? La profondita' piu' conveniente e' 8 bit. Se salvi questa immagine in un FITS a 32 bit e' come se riponi una goccia di vino in una botte vuota da 100 litri! Perde tutto l'aroma! ;)

Altro esempio. Le stelle, si sa, saturano facilmente e nei nostri frame di luminose ce ne sono sempre. La tua camera SBIG mono (per fare un esempio) ti restituira' sempre singoli frame a 16 bit (piu' di 64K ADU non puo' andare il convertitore A/D a 16 bit).

Se fai la media di due frame, il risultato puo' tranquillamente essere memorizzato in un FITS a 16 bit. La media del pixel piu' luminoso (esempio della stella satura) infatti resta al massimo 64K ADU. A cosa serve piazzare il risultato in un file a 32 bit per pixel? Non ci sarebbe alcun guadagno a livello qualitativo.

Se invece fai la somma, il pixel saturo puo' raggiungere 128K ADU. Questo valore oltrepassa la soglia massima dei numeri rappresentabili con 16 bit e ti serve un "contenitore" piu' grande. I sw come AA sono impostati per salvare ad 8, 16 e 32 bit (senza intermedi) per cui, dopo i 16 bit, e' necessario passare a 32 bit se vuoi preservare i dati. Ovvio che pixel a 64K ADU nei frame nativi sono totalmente inutili a livello pratico, hanno infatti oltrepassato (di molto) il campo di linearita', il mio e' solo un esempio numerico. In ogni caso, quanto detto vale per qualunque pixel che supera nel singolo frame 32K ADU (che diventa maggiore di 64K nella somma di due frame).

Fammi sapere se non ti quadra...

Paolo
Avatar utente
Paolo
Quasar Guru
 
Messaggi: 7747
Iscritto il: 16 gen 2006, 22:49
Località: L'Aquila

Messaggioda Pering » 20 set 2018, 10:25

Grazie Paolo per la spiegazione, ogni tanto un pò di teoria ci vuole per rinfrescare la mente e puntualizzare certe cose che poi sono importanti anche al fine della elaborazione delle immagini.
La tua spiegazione mi ha fatto capire che ho commesso un errore grossolano, (dopo pranzo il sangue non affluisce bene al cervello), 16 bit 65k ok, poi 17 bit il doppio, poi 18 il doppio di 17 e così via. questo lo sapevo ma come ho fatto a asserire che 32bit era il quadruplo di 16 bit, ora che il sangue è tornato a circolare al cervello, non me ne capacito.
Ora se a te sta bene ricomincerei da capo per fissare certi valori che astroart visualizza per poi riprendere eventualmente il discorso sui bit.
1)Innanzitutto i valori sulla barra quando si clicca una stella
nel caso di una stella della immagine #7 astroart restituisce ADU 13156 e valore 5069, cosa sono questi valori? e perchè "ADU" non è uguale a "valore"?
2)il fatto di selezionare o meno virgola mobile influisce sulle operazioni o è solo la visualizzazione dei valori?
3)l'immagine #8 è la rotazione di .5 gradi dell'immagine #7 si nota come si sia "rovinata" apparendo sfuocata e con tracce del trascinamento dovuto alla rotazione. La domanda è quando si fa l'allineamento nella funzione preprocessing succede la stessa cosa?
Allegati
Astroart.jpg
Pering
Quasar Guru
 
Messaggi: 4061
Iscritto il: 22 nov 2010, 14:58

Prossimo

Torna a Hardware & software

Chi c’è in linea

Visitano il forum: Nessuno e 2 ospiti

cron

Chi c’è in linea

In totale ci sono 2 utenti connessi :: 0 iscritti, 0 nascosti e 2 ospiti (basato sugli utenti attivi negli ultimi 5 minuti)
Record di utenti connessi: 595 registrato il 22 dic 2022, 1:59

Visitano il forum: Nessuno e 2 ospiti

Login Form