N.I.N.A. 3.3 nightly: FWHM ed eccentricità native, nuovi driver e due cambi di comportamento
La build di sviluppo #57 affianca all’HFR due nuove metriche stellari calcolate nativamente, allarga l’elenco dei dispositivi gestiti senza passare da ASCOM e modifica il comportamento di sparcheggio della montatura e delle logiche di sicurezza. La versione stabile resta la 3.2: le nightly vanno tenute fuori dalle sessioni operative.
Le stelle non si misurano più solo in HFR
La parte più interessante del ramo di sviluppo, per chi guarda alla qualità ottica delle proprie pose, riguarda il motore di misura stellare. Il changelog ufficiale del ramo develop indica che lo star detector nativo ricava ora l’HFR da una curva di crescita costruita su un centroide raffinato, al posto della precedente approssimazione basata sui momenti primi. Cambia anche la stima del fondo cielo locale attorno a ciascuna stella, che passa a una mediana robusta con sigma-clipping per ridurre la contaminazione dovuta a stelle vicine e a valori anomali.
Su questa base poggiano le due novità vere: FWHM ed eccentricità sono ora calcolate ed esposte nativamente accanto all’HFR. La FWHM deriva da profili radiali con fondo sottratto, l’eccentricità da momenti secondi pesati sul flusso. Entrambe diventano metriche selezionabili nel pannello image history, mentre i pannelli di statistica e cronologia possono mostrare FWHM, HFR e deviazione dell’HFR indifferentemente in pixel o in arcosecondi, usando la dimensione del pixel della camera e la focale del telescopio impostate nel profilo attivo.
Alla stessa area appartiene una correzione dalle ricadute concrete sull’autofocus: lo star detector nativo scarta ora le stelle il cui centroide raffinato cade su un bordo del rettangolo di rilevamento, evitando che stelle troncate falsino le misure. Chi lavora con crop ratio stretti o con inseguimento imperfetto si trovava esattamente in quella condizione.
Driver nativi: ToupTek, Oasis, Moravian e Alpaca senza discovery
Il secondo blocco di novità riguarda la gestione dei dispositivi. Le ruote portafiltri e i focheggiatori basati su piattaforma ToupTek diventano disponibili come driver nativi, insieme alla correzione del difetto che li faceva comparire erroneamente nell’elenco del connettore camera. Arrivano inoltre driver nativi per il focheggiatore e per la ruota portafiltri Oasis, e per le camere Moravian Instruments con le relative ruote integrate.
Per chi usa ASCOM Alpaca, ogni tipo di dispositivo guadagna una voce statica in cui specificare direttamente l’indirizzo a cui connettersi: serve nei casi in cui il dispositivo abbia un IP fisso oppure non offra la discovery Alpaca. Sempre lato Alpaca e ASCOM, i driver camera che implementano le proprietà LastExposureStartTime e LastExposureDuration vengono ora interrogati per popolare i metadati di data e durata dell’esposizione nelle immagini.
Due dettagli minori ma pratici: le ruote portafiltri effettuano ora un polling in background della propria posizione, così che N.I.N.A. resti allineata anche se la ruota viene mossa da un altro client, e la ruota PlayerOne attende il completamento dell’homing prima di proseguire in fase di connessione. Sul fronte reflex, la conversione dei RAW passa a LibRaw al posto dei vecchi convertitori DCRaw e FreeImage, e i driver nativi Nikon e Canon possono essere configurati per salvare nel formato selezionato in applicazione, FITS o XISF, invece del RAW proprietario della camera.
Due cambi di comportamento da leggere prima di aggiornare
Il changelog elenca esplicitamente due modifiche che non sono correzioni ma cambi di comportamento, ed è su queste che conviene fermarsi. La prima: lo sparcheggio della montatura non avvia più automaticamente l’inseguimento siderale. L’inseguimento partirà durante lo slew verso il target, come di consueto. La modifica riguarda solo i driver che avviavano il tracking subito dopo l’unpark, e la motivazione dichiarata è evitare movimenti inattesi della montatura e ridurre il rischio di collisioni con il treppiede o di altri spostamenti non voluti.
La seconda riguarda la sicurezza: l’istruzione Wait Until Safe non richiede più che un safety monitor sia connesso, perché un monitor disconnesso viene ora trattato come condizione non sicura, potendo la disconnessione derivare da un guasto di comunicazione. In parallelo, quando un safety monitor connesso segnala condizioni non sicure i trigger di imaging non scattano più; se in quella situazione dovesse maturare il meridian flip, l’applicazione interrompe l’inseguimento della montatura invece di eseguirlo, lasciando alla logica di sicurezza della sequenza il compito di riprendere il tracking quando le condizioni tornano favorevoli.
Resta il punto di metodo su quale canale installare. La pagina di download ufficiale indica la 3.2 come ultima versione stabile rilasciata, testata e adatta alle sessioni di ripresa, mentre le nightly sono descritte come versioni di anteprima contenenti lavoro di sviluppo attivo, potenzialmente instabili e soggette a cambiamenti frequenti, con destinatari principali sviluppatori, autori di plugin e tester volontari. Il changelog stesso raccomanda di salvare una copia dei profili in %localappdata%\NINA prima di passare a una nightly, così da poter tornare alla stabile senza danni.
Le novità descritte qui confluiranno nella prossima versione rilasciata, ma nulla garantisce che arrivino nella forma attuale: i numeri delle nightly avanzano rapidamente e il progetto sconsiglia esplicitamente di restare su build datate. Per chi voglia provarle, l’approccio sensato è una notte dedicata al collaudo, con profili salvati a parte e senza obiettivi di acquisizione da portare a casa.
Fonti
Nighttime Imaging ‘N’ Astronomy – pagina di download ufficiale
N.I.N.A. – changelog ufficiale, ramo develop (RELEASE_NOTES.md)
Nighttime Imaging ‘N’ Astronomy – annuncio della versione 3.2
