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.
Alby96andClaude Opus 5