Notizie

Jiyoné (Guillaume Stutin) ha assunto la manutenzione di Ansel da ottobre 2025. L’obiettivo attuale è trasformare Ansel in una cooperativa  in cui gli utenti possano diventare membri e controllare democraticamente gli orientamenti e le priorità del progetto, ma anche garantire una retribuzione equa e un ambiente di lavoro sicuro a chi dedica la propria forza lavoro al progetto. Ho esposto la descrizione del problema e la soluzione proposta nella pagina democrazia.

Tra gennaio 2022 e marzo 2026, Ansel ha registrato 297 commit non di merge riguardanti la griglia del tavolo luminoso, le sue miniature e la loro pipeline di rendering e caching. Ho cercato di arrangiarmi con il trasandato codice del tavolo luminoso di Darktable, solo sgrassato, il più a lungo possibile, ma purtroppo era puro debito tecnico ed era penosamente lento.

In effetti, Darktable «gestisce» la scadente qualità del suo tavolo luminoso riducendone le dimensioni: i pannelli laterali di sinistra e di destra occupano molta superficie di visualizzazione, il che lascia ancora meno area da ridisegnare per il tavolo luminoso. Poiché Ansel ha rimosso il pannello laterale di destra, fondendone il contenuto con quello di sinistra e con il menu globale, c’era più superficie da disegnare, più lavoro per la CPU da svolgere, e il pessimo design del tavolo luminoso è diventato tanto più dannoso.

Da quando ho iniziato a usare Darktable, intorno al 2012, sono sempre rimasto sorpreso dalla poca RAM che utilizzava. La gente pensa che sia una buona cosa che un’applicazione usi la memoria con parsimonia, e questo è senz’altro vero se parliamo del tuo ambiente desktop. Ma parlando di un software di produzione che esegue un pesante rendering dei pixel su immagini da 12 a 54 Mpixel, questo significa che gli stessi calcoli pesanti vengono ripetuti più e più volte invece di essere salvati per essere riutilizzati in seguito. È a questo che serve una cache: evitare calcoli costosi. E dovrebbe usare tutta la RAM disponibile a tale scopo, perché calcolare significa sprecare energia, e questo ha un impatto concreto se stai lavorando a batteria. Inoltre, hai pagato per quella RAM e usarla non ti scarica la batteria. La CPU/GPU d’altro canto…

Memorie di un tizio che ha passato troppo tempo a ripulire la merda degli altri e a pagare per le loro cattive decisioni, episodio #troppi.

Copiare/incollare cronologie e stili sono funzioni fondamentali in Ansel, e quella che gli fa meritare (o meno) il suo titolo di «app per il flusso di lavoro». Ma è anche tra le più difficili da realizzare correttamente a livello interno. Gli utenti vedono un elenco di modifiche, ma sotto il cofano quelle modifiche dipendono dall’ordine della pipeline, dalle istanze dei moduli e dalle maschere. Se due immagini hanno topologie di pipeline diverse, copiare le modifiche in modo ingenuo può produrre incoerenze.

Nel mio articolo fondativo, Darktable: schiantarsi contro il muro al rallentatore, ho presentato il disastro che era il nuovo «Grande turducken MIDI». Lo scopo di questo turducken¹ era riscrivere il sistema di scorciatoie da tastiera per estenderlo ai dispositivi MIDI.

Ancora oggi sono arrabbiato per questa impresa di distruzione di massa, ecco un riepilogo delle ragioni:

1. nel 2021 ha sostituito un sistema di scorciatoie da tastiera che era piuttosto buono, completo di funzioni, ben testato, stabile e scritto in meno di 1500 righe (commenti inclusi),
2. …per aggiungere il supporto ai dispositivi MIDI e ai gamepad PlayStation (!?!)…
3. …ma nel mio sondaggio Darktable del 2022, un anno dopo questa nuova funzione, su oltre 1251 utenti che vi hanno partecipato:
   • l'81% degli utenti non aveva un dispositivo MIDI e non aveva intenzione di procurarsene uno,
   • il 2% non sapeva nemmeno cosa fosse un dispositivo MIDI.
   • l'8% degli utenti aveva un dispositivo MIDI ma non lo usava con Darktable,
   • il 6% stava valutando l’idea di procurarsi forse un dispositivo MIDI in futuro,
   • il 2% degli utenti aveva un dispositivo MIDI che usava davvero in Darktable,
4. il codice era assolutamente terribile, in termini di:
   • qualità del codice: istruzioni if/switch-case illeggibili annidate su 4 livelli, nel bel mezzo di funzioni da 1000 righe (ho pubblicato esempi di frammenti nel mio articolo),
   • volume del codice:
     • 3546 righe di codice per Darktable 4.0,
     • 4397 righe di codice per Darktable 5.0,
     • l’aumento di volume è una conseguenza diretta del tentativo di correggere bug in un’architettura che non può essere corretta perché la sua complessità favorisce ulteriore complessità. Tutto ciò deriva dal design, ma risolvere problemi creati dalla complessità aggiungendo altra complessità non è una soluzione.
   • complessità del codice:
     • complessità ciclomatica :
       • 1088 per Darktable 4.0,
       • 1245 per Darktable 5.0 (dettagli ),
     • complessità cognitiva :
       • 1885 per Darktable 4.0,
       • 2098 per Darktable 5.0 (dettagli ).
     • è di gran lunga la funzione più complessa del software, anche se non opera sulle immagini. Per fare un confronto, la seconda funzione più complessa è la decodifica dei metadati EXIF, che ha una complessità cognitiva di 1348.
5. non decodifica i modificatori dei tasti per progettazione, ma gestisce soltanto le pressioni fisiche dei tasti, il che significa che:
   • l’input «1» dal tastierino numerico viene decodificato come Keypad End,
   • l’input «1» da una tastiera francese AZERTY viene decodificato come Shift+&, o Shift+" su BÉPO,
   • devi quindi duplicare tutte le tue scorciatoie basate sui numeri per ogni modo di inserire un numero, ed essere pronto al fatto che la finestra delle impostazioni delle scorciatoie non contenga alcun numero effettivo nelle combinazioni di tasti.
6. il design lato utente è assolutamente terribile, con troppe azioni ed emulazioni da configurare («effetti»), che dopo 4 anni non sono nemmeno completamente documentate (cos’è «ctrl-toggle»? «right-activate»?), e la configurazione delle scorciatoie usa una strana finestra divisa che non ha alcun senso,
7. anche l’implementazione è terribile: la funzione è a conoscenza di tutta la GUI del software, e la GUI del software è a conoscenza del codice delle scorciatoie. Qui non c’è alcuna modularità, e modificare qualsiasi cosa nel codice delle scorciatoie può avere effetti inaspettati e indesiderati in qualsiasi punto del software.² Basta guardare il grafo delle dipendenze qui sotto,
8. diverse «scorciatoie» (o associazioni MIDI) possono essere collegate alla stessa azione, il che significa che ogni interazione dell’utente deve consultare l’intera lista delle azioni disponibili, comportando una gestione delle scorciatoie molto inefficiente, in alcuni casi rallentamenti della GUI e falsi positivi «combinazione di tasti sconosciuta» in casi particolari.

Dopo aver finalmente collegato l’intero sito web e la documentazione a un flusso di lavoro di traduzione a tenuta stagna (usando po4a sopra Hugo), che per inciso utilizza esattamente lo stesso insieme di strumenti e la stessa logica dell’applicazione Ansel, mi è venuta l’idea di automatizzare le traduzioni vuote, prima a partire dai file di traduzione del software, poi tramite l’API di ChatGPT, che fa un lavoro davvero discreto nel tradurre la sintassi Markdown.

Già nel dicembre 2019, chiesi che qualcuno si occupasse di fornire pacchetti AppImage  per Darktable. Il vantaggio evidente sarebbe stato quello di consentire test anticipati, prima della versione, da parte di persone che non sono in grado di compilare da sole il codice sorgente, così da si spera fornire un riscontro anticipato e aiutare a fare il debug prima di rilasciare. Questo non è mai stato una priorità, il che significa che andava bene avere una corsa a correggere i bug sia prima sia dopo la pubblicazione.

Ansel eredita da Darktable la sua struttura portante di database: le cronologie di modifica non distruttive vengono salvate per ogni immagine in un database SQLite, insieme ai metadati e ad altri dati definiti dall’utente. Rendere il database consapevole di nuove immagini avviene tramite l’«importazione» delle immagini da un disco o da una scheda di memoria. È qui che entra in gioco lo strumento di importazione.

Purtroppo, l’importatore di Darktable è un’altra di quelle cose massacrate intorno al 2020 e trasformate in qualcosa di profondamente sconcertante, essendo un file browser che non somiglia a nessun file browser precedentemente noto, e che riesce a mancare di funzioni basilari (come Ctrl+F o l’anteprima EXIF) pur restando appesantito da funzioni inutili (vedi sotto). È qui che perdiamo molti futuri utenti, ed è solo lo step 0 del flusso di lavoro. Che magnifica vetrina di ciò che una «app per il flusso di lavoro» sa fare!

Ho pensato, per moltissimo tempo, che ci fosse qualche meccanismo di kill-switch sulla pipeline dei pixel. Il caso d’uso è il seguente :

1. stai modificando il parametro di un modulo,
2. le anteprime (quella centrale della camera oscura e la miniatura nel pannello di sinistra, usata anche per l’istogramma e i selettori di colore) ricalcolano la loro pipeline per tenere conto di quella modifica,
3. una delle anteprime finisce il rendering prima dell’altra, e il risultato non è ovviamente ciò che volevi,
4. modifichi di nuovo il parametro del modulo, senza aspettare che il ricalcolo finisca.

In quel caso, vuoi terminare tutte le pipeline attive perché il loro output non verrà usato, e iniziare immediatamente a ricalcolare tutto con i nuovi parametri. Solo che Darktable non fa questo, lascia che la pipeline finisca prima di riavviarla e, guardando i commenti nel codice sorgente, sembra essere una regressione piuttosto recente e non il comportamento originariamente previsto.

Darktable ha una propria libreria di widget per la GUI, per gli slider e le combobox (ovvero i menu a tendina o caselle di selezione), chiamata Bauhaus (nel codice sorgente si trova in src/bauhaus/bauhaus.c). Sebbene usino Gtk come backend, i Bauhaus sono oggetti personalizzati. E come molte cose in Darktable, personalizzato equivale a marcio.

Nel 2022 ho notato ridisegni parassiti e latenze  usandoli, che portavano a un’esperienza utente frustrante: il ridisegno del widget sembrava attendere il completamento dei ricalcoli della pipeline, il che significava che gli utenti non erano davvero sicuri che la loro modifica di valore fosse stata registrata, cosa che poteva indurli a riprovare, avviando un altro ciclo di costoso ricalcolo e di fatto congelando il loro computer per diversi minuti molto frustranti di inutili ricalcoli intermedi della pipeline.

Rawspeed (la libreria che fornisce i decodificatori per i file raw delle fotocamere) ha deprecato il supporto per GCC < 12. Di conseguenza, non posso più compilare l’AppImage su Ubuntu 20.04 (usando i runner di Github), ma devo compilarla su 22.04.

Ciò significa che qualsiasi distribuzione Linux con libc più vecchia della 2.35 non sarà in grado di avviare le nuove AppImage a partire da oggi. Questo non dovrebbe interessare la maggior parte degli utenti che usano distribuzioni aggiornate nel 2021 o più di recente. Ubuntu 20.04 e altre distribuzioni LTS/stabili datate (Debian stable) potrebbero essere interessate.

Se vieni da Darktable, potresti essere abituato a questo nella camera oscura:

mentre Ansel ti offre questo:

Non è un caso, ed è ora di spiegare perché, e perché questo non verrà esteso con opzioni di personalizzazione.

Ho scoperto per caso che lo script di build per Linux usava una build «package», il che significa che le ottimizzazioni della CPU sono limitate a quelle generiche per produrre binari portabili installabili su qualsiasi piattaforma x86-64. Con «usava» intendo che la build package non era esplicitamente disabilitata, quindi era abilitata per impostazione predefinita.

Comunque, ora è disabilitata per impostazione predefinita, dato che i pacchetti veri e propri (.exe e .appimage) non vengono compilati tramite quello script, che è pensato principalmente per aiutare gli utenti finali. Per ripristinare il comportamento precedente, dovresti eseguire:

Il 2022 è stato talmente pessimo in termini di email spazzatura e rumore che ho avviato la Virtual Secretary , un framework Python per scrivere filtri email intelligenti incrociando informazioni provenienti da diverse fonti per indovinare cosa siano le email in arrivo e se siano importanti/urgenti o meno. Quando parlo di email spazzatura, intendo anche le notifiche di Github, i ping su pixls.us (grazie al cielo ho chiuso il mio account su quello stupido forum), YouTube ed email dirette da persone che sperano di ottenere un po’ di aiuto in privato.

Sono passati all’incirca 3 mesi da quando ho ribattezzato «R&Darktable» (che nessuno sembrava capire correttamente) in «Ansel», poi ho acquistato il nome a dominio e creato il sito web da zero con Hugo (non avevo mai programmato in Golang prima, ma si tratta perlopiù di codice di template).

Poi ho impiegato un totale di 70 h per far funzionare le build dei pacchetti nightly per Windows e Linux ai fini della distribuzione continua, qualcosa che Darktable non ha mai fatto bene («puoi compilarlo da solo, non è difficile»), solo per vedere il tracker dei bug esplodere dopo il rilascio (niente di meglio che concatenare lo sprint pre-rilascio con uno post-rilascio per ridurre la propria aspettativa di vita).

Cosa succede quando un gruppo di fotografi amatoriali, trasformatisi in sviluppatori amatoriali, a cui si aggiunge una manciata di sviluppatori back-end che sviluppano librerie per sviluppatori, decide di lavorare senza metodo né struttura su un software professionale destinato agli utenti finali, la cui competenza fondamentale (colorimetria e psicofisica) si colloca da qualche parte tra una laurea triennale in fotografia e una laurea magistrale in scienze applicate, promettendo al contempo di rilasciare 2 versioni all’anno senza gestione di progetto? Il tutto, ovviamente, in un progetto dove i fondatori e la prima generazione di sviluppatori sono passati ad altro e se la sono data a gambe?