Development

Between January 2022 and March 2026, Ansel landed 297 non-merge commits regarding the lighttable grid, its thumbnails, and their rendering pipeline and caching. I tried to make do with the scruffy Darktable lighttable code, only degreased, for as long as I could but unfortunately, it was pure technical debt and it was painfully slow.

Indeed, Darktable “manages” the crappiness of its lighttable by reducing its size: the left and right side panels take a lot of display surface, which leaves even less area for the lighttable to repaint. Since Ansel removed the right side panel, merging its content with the left one and the global menu, there was more surface to paint, more CPU work to do, and the terrible design of the lighttable became all the more harmful.

Since I started using Darktable, circa 2012, I have always been surprised by how little RAM it used. People think it is a good thing that an application uses the memory sparingly, and that is surely true if we talk about your desktop environment. But talking of a production software that does heavy pixel rendering on images from 12 to 54 Mpixels, this means the same heavy computations are done again and again instead of being saved to be reused later. That’s what a cache is for : avoiding expensive computations. And it should use all the available RAM for that, because computing is wasting power, and that has a concrete impact if you are working on battery. Also, you paid for that RAM and using it doesn’t empty your battery. The CPU/GPU on the other end…

Memoirs of a guy who spent too much time cleaning other people’s shit and paying for their bad decisions, episode #too many.

Copy/paste history and styles are core features in Ansel, and the one that makes it deserve (or not) its “workflow app” title. But it is also among the hardest to get right internally. Users see a list of edits, but under the hood those edits depend on the pipeline order, module instances, and masks. If two images have different pipeline topologies, naïvely copying edits can produce inconsistencies.

En diciembre de 2019, pedí que alguien se encargara de proporcionar paquetes AppImages  para Darktable. El beneficio obvio habría sido habilitar pruebas tempranas, antes del lanzamiento, de personas que no pueden construir el código fuente por sí mismas, con la esperanza de proporcionar comentarios tempranos y ayudar a depurar antes del lanzamiento. Esto nunca ha sido una prioridad, lo que significa que estaba bien tener una prisa antes y posterior al lanzamiento para corregir errores.

Ansel hereda de Darktable su estructura de base de datos: los historiales de edición no destructiva se guardan por imagen en una base de datos SQLite, junto con metadatos y otros datos definidos por el usuario. Hacer que la base de datos reconozca nuevas imágenes se realiza a través de la “importación” de imágenes desde un disco o tarjeta de memoria. Ahí es donde entra en juego la herramienta de importación.

He pensado, durante mucho tiempo, que había algún mecanismo de interruptor de apagado en la canalización de píxeles. El caso de uso es el siguiente:

1. estás cambiando un parámetro del módulo,
2. las vistas previas (la central del cuarto oscuro y la miniatura en el panel izquierdo, también utilizada para el histograma y selectores de color) recomputan su canalización para tener en cuenta ese cambio,
3. una de las vistas previas termina de renderizar antes que la otra, y el resultado es obviamente no lo que querías,
4. cambias nuevamente el parámetro del módulo, sin esperar a que termine la recomputación.

En ese caso, quieres eliminar todas las canalizaciones activas porque su salida no se utilizará y comenzar a recomputar todo de inmediato con los nuevos parámetros. Excepto que Darktable no hace eso, deja que la canalización termine antes de reiniciarla, y al observar los comentarios en el código fuente, parece ser una regresión bastante reciente y no el comportamiento originalmente previsto.

Darktable tiene su propia biblioteca de widgets de GUI, para sliders y comboboxes (también conocidos como menús desplegables o cuadros de selección), llamada Bauhaus (en el código fuente, está en src/bauhaus/bauhaus.c). Aunque usan Gtk como backend, Bauhaus son objetos personalizados. Y como muchas cosas en Darktable, personalizado equivale a podrido.

En 2022, noté redibujados parásitos y retrasos , al usarlos, lo que lleva a una experiencia de usuario frustrante: el redibujado del widget parecía esperar a que se completaran las recomputaciones del pipeline, lo que significaba que los usuarios no estaban realmente seguros de que su cambio de valor se registrara, lo que podría llevarlos a intentarlo de nuevo, comenzando otro ciclo de recomputación costosa, y congelando efectivamente su computadora durante varios minutos muy frustrantes de recomputaciones de pipeline intermedias inútiles.

Descubrí accidentalmente que el script de compilación de Linux usaba una compilación “package”, lo que significa que las optimizaciones de CPU están limitadas a las genéricas para producir binarios portátiles que se pueden instalar en cualquier plataforma x86-64. Por “usar”, me refiero a que la compilación del paquete no estaba explícitamente deshabilitada, así que estaba habilitada por defecto.

De todos modos, ahora está deshabilitada por defecto, ya que los paquetes reales (.exe y .appimage) no se construyen a través de ese script, que está principalmente destinado a ayudar a los usuarios. Para volver al comportamiento anterior, necesitarías ejecutar:

2022 fue tan malo en términos de correos electrónicos no deseados y ruido que comencé el Secretario Virtual , un marco en Python para escribir filtros de correos electrónicos inteligentes cruzando información entre varias fuentes para adivinar qué son los correos electrónicos entrantes y si son importantes/urgentes o no. Cuando hablo de correos electrónicos no deseados, también me refiero a notificaciones de Github, menciones en pixls.us (gracias a Dios cerré mi cuenta en ese foro estúpido), YouTube y correos electrónicos directos de personas que esperan recibir ayuda en privado.

Han pasado aproximadamente 3 meses desde que rebauticé ‘R&Darktable’ (que nadie parecía entender bien), en ‘Ansel’, luego compré el nombre de dominio y creé el sitio web desde cero con Hugo (nunca había programado en Golang antes, pero es principalmente código de plantilla).

Luego pasé un total de 70 h haciendo que los paquetes de compilaciones nocturnas para Windows y Linux funcionaran para entrega continua, algo que Darktable nunca logró (“puedes construirlo tú mismo, no es difícil”), solo para ver al rastreador de errores explotar después del lanzamiento (nada mejor que encadenar el sprint de pre-lanzamiento con uno post-lanzamiento para reducir tu expectativa de vida).