Estende il motore con stabilizzazione sub-pixel, deflicker per regioni,
transizioni giorno-notte, movimento di macchina virtuale, rimappatura non
lineare del tempo e accumulo temporale. Tutto in-house, nessuna dipendenza
aggiunta: il progetto continua a non contenere un solo PackageReference.
Perche' questa forma. Il rendering non percorre piu' la sequenza sorgente ma
un piano di fotogrammi d'uscita, ognuno con posizione anche frazionaria e
durata propria. Le quattro modalita' temporali producono tutte quella stessa
forma, quindi il ciclo di rendering e' uno solo e non ha un ramo per ciascun
caso; da li' discende anche la sfocatura, perche' un fotogramma che copre v
scatti ha angolo di otturatore diviso v.
Gli spostamenti si misurano con la correlazione di fase, che ignora per
costruzione le differenze di luminosita' fra scatti - in un time-lapse ci sono
sempre - e reagisce alla sola geometria. Il picco intero non basta: la
superficie di correlazione viene ricostruita a passo fine valutando la somma
di Fourier sulle posizioni intermedie invece di interpolare con una parabola
tre campioni di una cresta che parabola non e'. L'errore misurato scende da
0,14 a 0,08 px.
I gradini di esposizione non sono rumore da mediare: l'ampiezza si legge
esatta nei metadati e viene ridistribuita su una transizione a derivata nulla
agli estremi. Il deflicker lavora poi su una serie gia' priva di gradini,
invece di trasformare lo scalino in una rampa con due spigoli.
La maschera delle regioni nasce dalla mediana temporale di un campione di
fotogrammi, che toglie di mezzo proprio le nuvole di passaggio, e la linea
d'orizzonte viene agganciata al massimo del gradiente verticale. Sulla scena
di prova il terreno passa da 0,062 a 0,026 stop di oscillazione.
Ritaglio virtuale e correzione di stabilizzazione sono entrambi affini e
vengono composti in una sola trasformazione: due ricampionamenti in fila
costerebbero il doppio di nitidezza senza dare nulla in cambio.
Sulla memoria: i moduli avanzati hanno rotto l'assunto che bastassero due
fotogrammi vivi alla volta, quindi il disco entra ora in gioco - come annotato
nel commit precedente, e' questa la porta che si apriva. La finestra attiva
resta sempre in memoria perche' la mediana ha bisogno di tutti i suoi
fotogrammi insieme; solo la lettura in anticipo viene parcheggiata su disco
oltre il tetto, e ripresa una volta sola. Non esiste un caso in cui lo stesso
fotogramma vada e torni piu' volte. Il file di parcheggio si cancella da se'.
Verifica: da 26 a 51 controlli. Nessuna soglia scelta a posteriori - il
tremolio ha un percorso noto, il gradino un'ampiezza dichiarata nei metadati e
visibile nei pixel, la nuvola attraversa il solo cielo. Il controllo
conclusivo rende una sequenza con tutti i moduli attivi insieme e tetto di
memoria volutamente stretto, poi la rilegge con il lettore di sistema.
Verificato anche sui DNG GoPro reali: 580 file, render di prova conforme.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ORIENTAMENTO
Il tag Exif dice come raddrizzare l'immagine, ma non basta leggerlo: alcuni
decodificatori di sistema lo applicano gia' per conto proprio e altri no, e la
stessa installazione di Windows si comporta diversamente a seconda del formato.
Applicare la trasformazione due volte ribalta il fotogramma, non applicarla mai
lo lascia coricato.
In modalita' automatica Titano confronta ora le dimensioni che il decodificatore
restituisce con quelle che il file dichiara di contenere: se la trasformazione
scambia gli assi ed e' gia' stata applicata, non la riapplica. La sezione
Generale mostra cosa ha dedotto e con quale motivo, e permette di imporre una
delle sei trasformazioni Exif quando i metadati sono sbagliati. L'anteprima
mostra subito l'effetto della scelta.
Sui DNG GoPro il rilevamento riporta "specchiata orizzontalmente (dal tag Exif
del file)": e' quanto dichiara il file e quanto applicano i lettori conformi
alla specifica DNG. Se all'occhio risulta sbagliato, ora si cambia dal menu.
QUALITA' PRIMA DELLA VELOCITA'
Nuovo profilo di elaborazione con tre livelli, predefinito su Massima. Governa
la finezza della griglia del campo vettoriale, i livelli della piramide, le
iterazioni per livello, i campioni per pixel della scia e la risoluzione della
passata fotometrica. Costa circa tre volte il tempo del profilo Standard e si
vede nei bordi dei soggetti in movimento.
Non e' stato introdotto alcun uso del disco come memoria d'appoggio: nessuna
fase della pipeline supera cio' che la RAM regge, e i file temporanei sono
esclusi per scelta architetturale. Se in futuro servira' tenere in vita molti
fotogrammi a piena risoluzione, quella e' la porta da cui entrare.
ICONA
Scie stellari attorno al polo celeste: l'immagine in cui il tempo diventa
visibile, e che dice insieme time-lapse e cielo notturno senza ricorrere a
orologi o otturatori. Disegnata in-house con GDI+, contenitore ICO scritto a
mano con sette livelli. Sotto i venti pixel il disegno si semplifica a due archi
piu' spessi: alla dimensione della barra delle applicazioni sette scie sottili
diventerebbero una macchia.
La verifica del motore sale a 25 controlli: si aggiunge che lo specchiamento
richiesto sposti davvero i pixel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Provato il programma sulle quattro sequenze in K:\2024 (oltre 3000 scatti DNG
convertiti da GPR con le applicazioni Adobe). Ne sono usciti quattro difetti,
tutti latenti perché la verifica sintetica usa JPEG piccoli.
1. Risoluzione letta dalla miniatura. Nei DNG la IFD0 descrive un'anteprima
256x192 marcata NewSubfileType=1 e l'immagine vera vive in una SubIFD:
leggendo ImageWidth dalla prima directory il programma credeva di lavorare
su 256x192 e avrebbe esportato un video di quelle dimensioni. Ora si sceglie
la directory dell'immagine principale, preferendo quelle non marcate come
versione ridotta.
2. Lettura dei metadati lentissima. Si leggevano 4 MiB per file a prescindere:
179 s per una cartella da 1005 scatti. La finestra sul file ora si estende
solo quando un offset punta oltre quanto gia' caricato, e di un DNG da 15 MiB
ne bastano 128 KiB. Stessa cartella: 7,4 s.
3. Decodifica corrotta quando interveniva il ridimensionamento. Il convertitore
a 48bppRGB precedeva lo scaler; con i codec RAW quell'ordine restituisce
righe disallineate, immagini a strisce e luminanza sbagliata di due stop,
senza segnalare alcun errore. Lo scaler ora precede il convertitore, come
indica Microsoft. I 16 bit per canale restano.
4. Multiplexer che corrompeva il primo fotogramma chiave. Il buffer di
conversione Annex-B veniva riallocato senza copiare il contenuto: le NAL gia'
scritte per quel campione diventavano zeri e il campione usciva con un
prefisso di lunghezza nullo in testa. Il file restava formalmente valido ma
il lettore di sistema si fermava dopo sedici fotogrammi su quaranta. Con i
JPEG del test il campione non superava mai la capacita' iniziale, per questo
non era mai emerso; ora il buffer parte piccolo, cosi' il percorso di crescita
viene esercitato da qualunque sequenza.
Aggiunto inoltre il vincolo di conformita' dei codec. Una sorgente 4:3 da
4000x3000 supera il Livello 5.2 di H.264: l'encoder hardware la accetta e
dichiara il Livello 6.0, ma i decodificatori comuni non aprono il file. La
risoluzione viene ora ricondotta al massimo riproducibile conservando le
proporzioni, e la riduzione e' dichiarata nella barra di stato invece di
avvenire in silenzio. Le sorgenti 16:9 fino al 4K UHD non sono toccate.
Il campo di movimento non viene piu' calcolato quando non serve: con pose da
30 s su intervalli da 34 s lo shutter angle e' gia' 317 gradi e non c'e'
sfocatura da sintetizzare. Il render della sequenza aurora passa da 1,3 a
8,5 fotogrammi al secondo.
La verifica del motore sale a 24 controlli: si aggiungono l'invarianza della
luminanza alla scala di decodifica e l'allineamento delle NAL dentro ogni
campione, i due invarianti che avrebbero intercettato i difetti 3 e 4. Nuovo
comando --diagnose per esaminare una cartella reale.
Verificato sui file dell'utente: 40 fotogrammi a risoluzione nativa, H.264 e
HEVC, entrambi riletti per intero dal lettore di sistema.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aggiunta la configurazione .vscode allineata a quella di Mimante ed Encelado:
F5 apre la finestra di Titano, una seconda configurazione entra con i breakpoint
nella verifica del motore (--selftest), che è un punto d'ingresso separato e non
raggiungibile dall'interfaccia. Nei task: build, verifica, cattura interfaccia
e pulisci.
La verifica usciva con codice 0 ma senza stampare nulla quando lanciata con
"dotnet run" o con l'output su file. La causa è AttachConsole: l'eseguibile è
un'applicazione a finestre e senza aggancio non si farebbe leggere da un
terminale, ma se lo standard output è già dirottato l'aggancio lo sostituisce e
i messaggi finiscono nella console invece che nella pipe. Ora l'aggancio avviene
solo quando l'output non è già dirottato. Verificato nei tre casi: eseguibile
diretto, dotnet run e redirezione su file, 55 righe in tutti e tre.
Svuotato Modifiche.txt: il file è dell'utente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Applicazione desktop completa per creazione e ottimizzazione di time-lapse.
Il vincolo che ne definisce l'architettura è l'assenza totale di componenti
di terze parti: il progetto non ha alcun PackageReference e non invoca processi
esterni. Oltre alla libreria standard di .NET si usano solo API native di
Windows (WIC, Media Foundation, GDI+, DWM) richiamate via P/Invoke scritto a mano.
Sono in-house tutte le parti che di norma si delegherebbero a una libreria:
il parser binario EXIF/XMP, la misura di luminanza e la curva di deflicker,
il calcolo del campo vettoriale di movimento con il motion blur sintetico,
il multiplexer MP4 e ogni controllo dell'interfaccia.
Scelte algoritmiche che meritano una nota:
- il deflicker usa una regressione lineare locale pesata con seconda passata
robusta, così le rampe reali di luce (alba, tramonto) sopravvivono mentre
lo sfarfallio del diaframma viene rimosso; una media mobile semplice le
appiattirebbe entrambe;
- la sfocatura mancante si compone in quadratura con quella già incisa nello
scatto, perché sommarla linearmente renderebbe l'immagine troppo morbida;
- la luminanza si misura come media logaritmica troncata, invariante alla
scala e insensibile a cieli bruciati e ombre chiuse.
L'elaborazione non produce file temporanei e mantiene un'occupazione di memoria
stazionaria: buffer poolati e canale a capacità limitata rendono i fotogrammi
vivi indipendenti dalla lunghezza della sequenza.
Verificato con "Titano.exe --selftest": 23 controlli su una sequenza sintetica
dalle proprietà note, incluse la struttura del contenitore prodotto e la sua
ri-decodifica con il lettore di sistema. Tutti superati.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sono stati aggiunti i file di progetto e configurazione per un'applicazione Windows Forms chiamata "TimeLapseTransfer". È stato creato un file di soluzione (`TimeLapseTransfer.sln`) e un file di configurazione (`App.config`) per specificare la versione del runtime supportato.
È stata implementata la classe principale dell'applicazione (`Main.cs`) con l'interfaccia utente, inclusi controlli per selezionare i percorsi di origine e destinazione, un pulsante per avviare il trasferimento dei file e una barra di progresso.
Inoltre, sono stati creati file di designer (`Main.Designer.cs`), file di risorse (`Main.resx`), e la classe `Program.cs` come punto di ingresso. È stato creato anche il file di progetto (`TimeLapseTransfer.csproj`) e file di informazioni sull'assembly (`AssemblyInfo.cs`). Infine, sono stati aggiunti file di risorse e impostazioni per gestire le risorse e le configurazioni dell'applicazione.
Alby96
