main
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Alby96andClaude Opus 5
|
15735a7b11 |
I comandi entrano nella scheda e la scheda prende tutta la finestra
I pulsanti contestuali stavano sulla riga del marchio, fuori dal riquadro della scheda a cui appartenevano: per trovare il comando che riguardava una tabella bisognava risalire fino al bordo della finestra. Ora stanno dentro la sezione, sopra il contenuto su cui agiscono, e ciascuno spiega a comparsa cosa fa. Il marchio scende nella barra delle sezioni, che diventa alta quanto la finestra e si riduce ai soli simboli; a destra non resta altro che la scheda, dall'alto al basso. Lo spazio liberato in cima ospita l'avanzamento delle operazioni di massa — una barra sola, perche' la scheda Esportazione ne aveva una seconda che diceva la stessa cosa piu' in basso — che passa anche sull'icona nella barra delle applicazioni tramite ITaskbarList3 dichiarata a mano. Durante un'operazione di massa i controlli che la disturberebbero sono spenti: il progetto viene letto da un altro thread a ogni fotogramma, e cambiare risoluzione o ritaglio a meta' significa cambiare le regole a partita iniziata. L'anteprima guadagna due letture. La maschera del ritaglio mostra il fotogramma intero scurendo cio' che il formato d'uscita taglia via, perche' il rapporto d'immagine si sceglie guardando cosa si perde; e lo schermo intero apre il fotogramma in una finestra a parte alla risoluzione nativa, con i dati di scatto in un pannello che si chiude, perche' decidere se una stella e' puntiforme si fa al cento per cento. La scheda Esportazione si apre su una preimpostazione. I parametri di codifica non sono indipendenti — il bitrate abbondante a 1080p lascia gradini sul cielo a 4K — e sceglierli bene significa muoverli insieme; restano tutti modificabili, e toccarne uno riporta la voce a «Personalizzata». Sull'annullamento: non sono riuscito a riprodurre un crollo sull'albero di partenza in dodici scenari automatici, ma ho chiuso quattro strade per cui poteva passare. Cancel() veniva chiamato nudo dentro il gestore del clic, dove un'eccezione di una registrazione avrebbe ucciso la finestra. FrameWindow non tollerava ObjectDisposedException quando il file di parcheggio veniva chiuso sotto le decodifiche in volo, non impediva l'avvio di nuove decodifiche dopo la chiusura, e lasciava non osservate le eccezioni dei compiti falliti. Soprattutto, la coda di un'esportazione annullata tocca i controlli dopo che la finestra puo' essere gia' stata chiusa — ed e' proprio la cosa piu' naturale da fare dopo aver annullato: quel percorso ora si ferma prima. Resta una rete: le eccezioni non gestite finiscono in Documenti\Titano\errori.txt invece di portarsi via il lavoro. I dati dell'applicazione si spostano da AppData a Documenti, perche' sono file fatti per essere aperti; le preferenze nella vecchia collocazione vengono migrate. Tre nuove verifiche coprono l'annullamento con il parcheggio su disco attivo: 63 su 63 passano, provate anche sulle sequenze reali in K:\Time Lapse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
db21a31e56 |
Scheda Archivio, ottimizzazione per sezione e spiegazioni a comparsa
Aggiunge l'importazione da scheda di memoria e riordina l'interfaccia attorno a quello che ciascuna sezione serve a fare. L'importazione riconosce i supporti collegati, cerca nelle sottocartelle e prima di toccare il disco mostra il piano: quali cartelle nasceranno e che nome avranno i primi file. Un'importazione sbagliata su mille file non si annulla, e guardare prima costa un istante. Fa poi tre cose che a mano si sbagliano sempre: separa le sessioni sulla pausa fra due scatti, invece di lasciare piu' riprese mescolate in una cartella sola; costruisce i nomi da modelli con segnaposto, perche' un archivio si consulta anni dopo e il nome e' l'unica cosa leggibile senza aprire nulla; e rilegge quello che ha scritto confrontandone l'impronta, perche' una scheda che si scollega a meta' copia produce file della dimensione giusta e del contenuto troncato, e il danno si scopre mesi dopo. Sulla conversione in DNG va detto con precisione cosa si puo' e non si puo' fare. Un DNG vero contiene i valori del sensore prima dell'interpolazione cromatica; ottenerlo da un formato proprietario richiede la libreria del produttore, che il vincolo sulle dipendenze esclude. Quello che si ottiene in-house e' un DNG lineare - la specifica lo prevede, i pixel sono gia' interpolati, il file e' valido e apribile ovunque ma non restituisce la liberta' del grezzo. La copia resta quindi la scelta predefinita, e l'interfaccia lo dice invece di lasciarlo intuire. Il contenitore TIFF/DNG e' scritto a mano come il multiplexer MP4, e la verifica lo rilegge con il parser di questo stesso programma: due implementazioni indipendenti dello stesso formato, e al primo confronto e' saltato fuori un errore di dodici byte per voce nel calcolo degli scostamenti - la directory Exif finiva oltre il puntatore che la indicava. Le spiegazioni passano dalle note stampate ai suggerimenti a comparsa. Una nota sotto un cursore occupa spazio a chi la conosce gia', quindi deve restare corta; un suggerimento che appare solo quando serve non ha quel vincolo e puo' dire l'unica cosa che conta - perche' quel parametro esiste e cosa succede a spostarlo nel verso sbagliato. Ogni sezione guadagna un comando Ottimizza che rileva le impostazioni migliori per quella sola parte e riferisce cosa ha cambiato e perche'. Si distingue dal pilota automatico, che lavora di continuo sui parametri deducibili senza ambiguita': l'ottimizzazione si chiede a mano perche' accende e spegne interi moduli, e sostituire quelle scelte in silenzio sarebbe peggio che lasciarle sbagliate. Dove il dato manca non tira a indovinare: lo dice. L'uscita guadagna rapporto e ritaglio. Cambiare rapporto non deforma piu' l'immagine: il ritaglio viene preso con il nuovo rapporto dentro il fotogramma, il che ha anche corretto un difetto latente dello stadio geometrico, che con rapporti diversi fra sorgente e uscita stirava invece di tagliare. La zona da tenere si sceglie trascinandola. I comandi seguono la sezione: importazione e analisi compaiono solo dove servono. Un pulsante che non ha senso dove ci si trova non va disabilitato ma tolto, perche' disabilitato resta un ingombro che chiede perche' non funziona. Le preferenze dell'applicazione non mostrano piu' anteprima, riepilogo della sequenza ne' riga di stato che ne parli: non riguardano la sequenza caricata, e tenerle accanto confondeva due piani diversi. Via anche le descrizioni inutili: la finestra si chiama Titano e basta. Due difetti trovati durante la verifica a video. La barra di navigazione nasceva sulla prima voce, che ora e' Archivio, quindi il selettore usciva subito perche' l'indice coincideva e la sezione non veniva mai mostrata: barra su una voce, contenuto su un'altra. E il posizionamento dei pulsanti leggeva Visible, che in WinForms resta falso finche' la finestra non e' stata mostrata perche' riporta la visibilita' dell'intera catena: alla costruzione nessun pulsante veniva collocato e restavano tutti impilati sull'angolo. Verifica: da 54 a 60 controlli. I nuovi coprono i modelli di percorso, la sostituzione dei caratteri illegali, il rifiuto dei segnaposto inventati, il riconoscimento delle sessioni e la rilettura del DNG scritto - sia dal parser interno sia dal decodificatore di sistema. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
2e5a441938 |
Navigazione verticale e strumenti di misura nell'interfaccia
Rifa' l'impaginazione attorno a una barra verticale sul fianco sinistro che governa insieme il contenuto principale e la colonna delle impostazioni: una sezione, una vista, i suoi comandi. Prima c'erano due gerarchie di schede da tenere allineate a mano; adesso ce n'e' una sola, in verticale ci sta il nome per esteso, e la sezione scelta resta leggibile mentre si lavora - cosa che in una fila di schede in cima si perde appena l'occhio scende sul contenuto. Accanto a ogni voce compare il numero di avvisi che la riguardano. L'anteprima non e' piu' il contenuto di una scheda fra le altre: resta in alto sempre, perche' in un programma che tratta immagini l'immagine si guarda mentre si regola qualunque cosa. Guadagna le quattro cose che la rendono utile per giudicare e non solo per guardare. Zoom e trascinamento, perche' una stabilizzazione sotto il pixel non si vede su un'immagine rimpicciolita per stare in un riquadro, e da scala uno a uno in su i pixel si mostrano come sono invece di essere interpolati. Confronto a tendina fra originale e corretto, perche' l'unico modo di capire cosa una correzione stia facendo e' vedere accanto ciо' che c'era prima. Campo vettoriale sovrapposto, che il motore calcola comunque e che spiega perche' la sfocatura viene come viene, soprattutto quando e' sbagliata. Confine delle regioni, campionato attraverso la stessa mappatura del ritaglio cosi' resta al suo posto anche sotto una panoramica virtuale. Ogni sezione porta lo strumento di misura che le riguarda: striscia di provini e pannello degli avvisi sulla sequenza, istogramma e forma d'onda sull'esposizione, percorso ricostruito della stabilizzazione sul movimento, piano temporale sul tempo. Sono tutte grandezze che il motore gia' calcolava e che finivano in due numeri in fondo a una riga di stato, cioe' invisibili. Il pilota automatico. I parametri deducibili dalle misure non si chiedono piu': un cursore con l'indicatore auto mostra il valore scelto e il motivo, toccarlo passa il comando all'utente, l'indicatore lo restituisce. E' lo stesso modello che il menu dell'orientamento usava da solo, esteso a larghezza di analisi, finestra del deflicker, lunghezza della transizione, finestra della stabilizzazione e tetto di memoria. Non sono valori di comodo: la finestra del deflicker viene da quattro periodi dello sfarfallio misurati sull'autocorrelazione, quella della stabilizzazione e' la piu' corta che rende liscio il percorso, la transizione e' meta' della distanza tipica fra i cambi. Dove il valore giusto non si puo' misurare il direttore non inventa: restituisce meno decisioni e lascia il cursore dov'e'. Il riquadro sponsor sta soltanto nella scheda Esportazione, perche' quello e' l'unico momento in cui non c'e' niente da fare e uno spazio pubblicitario non toglie niente a nessuno; accanto a un cursore che si sta regolando sarebbe un ostacolo. Gli annunci si leggono da una cartella locale con un listino in formato testo, ed e' importante dire cosa NON fa: nessuna rete, nessun identificativo, nessun clic registrato. Non e' prudenza eccessiva - un circuito pubblicitario vero richiederebbe il suo SDK, che il vincolo sulle dipendenze esclude, e comunque significherebbe far uscire dati dalla macchina di chi sta montando un time-lapse. Le campagne si aggiornano copiando file; a listino vuoto compaiono note interne; il riquadro si spegne dalle preferenze. Aggiunge anche le preferenze dell'applicazione, distinte da quelle del progetto, con persistenza in un file di testo scritto a mano nello stesso spirito del resto: una riga per voce, correggibile con un editor. Il progetto descrive come trattare questi fotogrammi, le preferenze come si comporta il programma. Piu' due cose piccole che pesavano: immissione numerica sui cursori, perche' trascinare fino a 0,35 e' un esercizio di mira e non una regolazione, e anteprima dei fotogrammi mentre vengono codificati, che non migliora il risultato di un pixel ma cambia molto un'attesa di mezz'ora. Verifica: 54 controlli invariati, Debug e Release puliti, tutte e sei le sezioni ispezionate a video sulla scena di prova. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
790637bc0d |
Correzioni emerse provando i moduli avanzati sui DNG reali
I sei moduli passavano cinquantuno controlli su scene sintetiche. Le scene sintetiche pero' sono costruite perche' la risposta sia nota, e per questo non possono sorprendere. Provati su quattro sequenze vere - da 554 a 1005 scatti, riprese notturne di comete e aurore con una GoPro - hanno mostrato cinque difetti, nessuno dei quali visibile prima. Uno sta nel nucleo del deflicker e c'era da molto. La curva obiettivo poteva essere piu' a scatti del segnale che lisciava. La robustezza di Tukey presuppone anomalie sparse; dove invece un tratto contiguo si discosta - il crollo di luce del crepuscolo - azzera l'intera finestra, e la stima commutava fra l'usare i soli sopravvissuti e l'usare tutto. Nel punto di commutazione si apriva uno scalino di 2,3 stop, piu' grande di qualunque salto presente nel segnale che doveva lisciare. Il rimedio non e' scegliere meglio fra le due stime ma non scegliere affatto: ora si mescolano con continuita' secondo quanta finestra e' sopravvissuta, e dove sopravvive per intero il risultato resta identico a prima. Sulla ripresa di sedici ore la riduzione dello sfarfallio passa dal 17% al 67% e il salto massimo da 1,73 a 0,21 stop. La correlazione di fase inseguiva spostamenti inventati. Una ripresa attraversa il giorno con pose da trenta secondi, quindi esce bruciata: su un riquadro uniforme la normalizzazione al modulo unitario amplifica il solo rumore numerico e l'antitrasformata da' un picco qualunque. Con un controllo di tessitura il tremolio misurato scende da 9,8 a 0,07 px e il ritaglio richiesto dal 15% allo 0,1%. La ricerca dell'orizzonte presupponeva un cielo chiaro e sgombro sopra la testa. Sotto un pergolato agganciava il bordo del tetto e chiamava cielo le travi. Ora la linea e' il gradino piu' marcato del profilo di luminanza per riga, che del verso non si cura: cielo dal 29% al 91% dell'inquadratura, con 1,9 EV di separazione dove prima erano zero, e sfarfallio trasmesso al paesaggio ridotto del 79% invece che del 57%. I gradini dichiarati nei metadati non sempre si vedono. Se il fotogramma e' gia' saturo dimezzare la sensibilita' non lo scurisce, e se l'esposizione automatica insegue l'alba il salto e' compensato dalla scena. In entrambi i casi sottrarlo introduceva il gradino invece di toglierlo. Ora ogni cambio viene ridotto alla quota che la luminanza ha davvero recepito. La temperatura di colore inventava numeri. Su un cielo stellato il colore medio non somiglia a nessun corpo nero, McCamy diverge, e uscivano decine di migliaia di kelvin troncate a un estremo. Ora fuori dall'intorno del luogo di Planck la misura si dichiara inapplicabile - e il controllo che lo verifica ha trovato subito un buco nel primo filtro, perche' un riquadro sulle coordinate cromatiche sa dire in quale zona si e' ma non quanto si e' vicini a una curva. La diagnostica impara a fare queste domande: --diagnose accetta ora parole chiave che accendono i moduli e riporta cosa ciascuno ha trovato sul materiale vero. Le scie stellari si verificano sull'uscita con la proprieta' che le definisce - la luminanza non puo' calare, perche' ogni pixel trattiene il valore piu' alto incontrato - e su 150 fotogrammi risulta non decrescente sul 99,3% dei passi. Verifica: da 51 a 54 controlli. I tre nuovi coprono proprio cio' che era sfuggito, a partire dalla garanzia che una curva lisciata non sia mai piu' a scatti dell'originale. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96
|
3d51e98ca3 | Rimozione del progetto TimeLapseTransfer e dei file di configurazione associati | ||
|
Alby96andClaude Opus 5
|
a815a91006 |
Sei moduli avanzati per la produzione cinematografica
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> |
||
|
Alby96andClaude Opus 5
|
332f02d17d |
Orientamento regolabile, profilo di qualita' e icona dell'applicazione
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> |
||
|
Alby96andClaude Opus 5
|
e476ebb648 |
Correzione dei difetti emersi sui DNG GoPro reali
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> |
||
|
Alby96andClaude Opus 5
|
5d8798f1f7 |
Avvio in debug da VS Code e correzione dell'output a riga di comando
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> |
||
|
Alby96andClaude Opus 5
|
cc1d040ac0 |
Titano: motore e interfaccia per time-lapse, senza dipendenze di terze parti
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> |
||
|
Alby96
|
165eff627b |
Aggiunta applicazione Windows Forms "TimeLapseTransfer"
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
|
fe85c7b569 | Initial commit |