darktable page lede image
darktable page lede image

Capítulo 10. Temas especiales

Este capítulo trata varios temas técnicos que pueden ayudarlo a ejecutar darktable en un hardware específico u optimizar su rendimiento. También se incluye una gran cantidad de información técnica adicional y muchos consejos y trucos en una extensa sección de blogs que puede encontrar en nuestra página principal.

10.1. darktable y la memoria

darktable's memory requirements are high. A simple calculation makes this clear. If you have a 20MPix image, darktable for precision reasons will store this internally as a 4 x 32-bit floating point cell for each pixel. Each full image of this size will need about 300MB of memory. As we want to process the image, we will at least need two buffers for each module  – one for input and one for output. If we have a more complex module, its algorithm might additionally require several intermediate buffers of the same size. Without further optimization, anything between 600MB and 3GB would be needed only to store and process image data. On top we have darktable's code segment, the code and data of all dynamically linked system libraries, and not to forget further buffers where darktable stores intermediate images for quick access during interactive work (mip map cache). All in all, darktable would like to see a minimum of about 4GB to run happily.

10.1.1. Memoria total del sistema

De lo dicho anteriormente, es evidente que su computador necesita un ajuste sensato de memoria para correr darktable apropiadamente. Le sugerimos que tenga al menos 4GB de memoria RAM física además de 4 u 8GB de espacio swap adicional instalado. Lo último es requerido para que su sistema pueda intercambiar temporalmente los datos innecesarios al disco para liberar espacio de la RAM física.

Teóricamente, también puede correr darktable con menores cantidades de RAM física y balancearlo con suficiente espacio swap. Sin embargo, debe estar preparado para que su sistema reciba una fuerte paliza, ya que leerá y escribirá páginas de datos hacia y desde su disco duro. Tenemos reportes positivos de que esto funciona bien para varios usuarios, pero quizás sea extremadamente lento para otros...

10.1.2. Espacio disponible

Ademas de la cantidad total de memoria en el sistema hay otro factor limitante: el espacio disponible de la arquitectura de su hardware. Cuando memoria puede ser usada por un proceso dependerá del número de bits que su CPU ofrece. Para un CPU con 32-bit registrados, esto es 2^32 bytes, lo cual da un total de 4GB. Esto es el límite superior absoluto de memoria que puede ser utilizado por un proceso y constituye una situación apretada para darktable, como vimos anteriormente.

La ruta de escape de darktable se llama bandas. En vez de procesar una imagen en un gran pedazo, dividimos la imagen en pequeñas partes para cada paso de procesado (módulo). Aún así, esto requerirá un buffer completo de entrada y uno de salida, pero los buffers intermedios pueden ser lo suficientemente pequeños para que todo se ajuste a los limites del hardware.

10.1.3. Fragmentación de memoria

Lamentablemente, esta no es todavía la historia completa. Existe un efecto llamado fragmentación de memoria, que puede y afectará al software que necesita realizar una gestión de memoria extensa. Si un programa de este tipo asigna 300 MB por vez y lo libera nuevamente 5 veces, esa memoria normalmente debería estar disponible después para una asignación grande de 1.5 GB. Sin embargo, no suele ser el caso. El asignador de memoria del sistema ya no puede ver esta área como un bloque contiguo de 1.5 GB sino como una hilera de áreas de 300 MB. Si no hay otra área libre de 1.5GB disponible, la asignación fallará. Durante la ejecución de un programa, este mecanismo eliminará cada vez más los bloques de memoria más grandes en lugar de los más pequeños. La memoria temporal de los mapas MIP en darktable 2.0 asigna varios bloques de memoria pequeños por cada miniatura, por lo que este problema es aún mayor. Por esta razón, a partir de la versión 2.0 de darktable, el soporte para 32 bits está en desuso.

10.1.4. Limitaciones adicionales

Y por si esto no fuese lo suficientemente difícil, hay mas cosas que pueden limitar su acceso a la memoria. En algunas tarjetas antiguas necesita activas la opción remapeo de memoria en su BIOS para tener instalada toda la memoria física. Adicionalmente, si está en un SO de 32-bit, probablemente necesitará una versión de kernel que tenga activada la Extensión de Dirección Física (PAE). Este es usualmente, pero no siempre, el caso para Linux. Muchas distribuciones ofrecen diferentes kernels, algunos con o sin la PAE activada; necesita escoger el correcto. Para verificar que su sistema este configurado correctamente, utilice el comando free en una terminal y examine la salida. Si la salida reporta menos RAM de la que tiene instalada, entonces tiene un problema que necesita ser corregido; por ejemplo, si tiene 4GB en su tarjeta, pero su kernel solo ve 3GB o menos. Necesita consultar su BIOS manualmente y la información sobre su variante de Linux para mas ayuda.

10.1.5. Configurando darktable en sistemas de 32 bits

Como se pudo ver, los sistemas de 32 bits son entornos difíciles para darktable. Aún así, muchos usuarios los ejecutan exitosamente darktable en ellos, si los requerimientos básicos en términos de memoria total del sistema y los temas mencionados en el párrafo anterior son abordados correctamente.

There are several adjustment parameters to get it running. If you install fresh, darktable will detect your system and set conservative values by default. However, if you upgrade darktable from an older version (e.g. coming from 0.9.3 and going to 1.0), chances are you have unfavorable settings in your preferences. The consequences might be darktable aborting due to allocation failures or – very typically – darktable not being able to properly import a new film roll. As a frequent symptom you get skulls displayed instead of thumbs for many of your pictures.

If this is the case, take a minute to optimize the preference settings in this case. You will find them under cpu / gpu / memory (Sección 8.8, “Cpu / gpu / memory”) in darktable's preference dialog. You should also find these parameters as configuration variables in $HOME/.config/darktable/darktablerc and edit them there.

Aquí tiene una corta explicación de los parámetros relevantes y sus ajustes propuestos:

número de hilos en segundo plano

Este parámetro define el número máximo de subprocesos que se permiten en paralelo al importar rollos de película o hacer otras cosas de fondo. Por razones obvias en los sistemas de 32 bits, solo puede tenerse un subproceso que consume recursos a la vez. Así que solo se puede establecer este parámetro en 1; cualquier valor superior lo matará.

límite de memoria (en MB) para el proceso por bandas

Este parámetro le indica a darktable cuanta memoria (en MB) deberá asumir como disponible para almacenar los buffers de la imagen durante las operaciones de los módulos. Si una imagen no puede ser procesada dentro de estos límites en un solo pedazo, las bandas se ocuparán y procesarán la imagen en varias partes. Ajuste esto a lo mas bajo posible tomando 500 como punto de partida. Quizás experimente luego si puede incrementarlo un poco para reducir las bandas.

mínima cantidad de memoria (en MB) para un buffer de proceso en bandas

Este es un segundo parámetro que controla las bandas. Está ajustado a un límite bajo para el tamaño de buffers intermedios de la imagen en megabytes. El parámetro es necesario para evitar las bandas excesivas en ciertos casos (para algunos módulos). Ajuste este parámetro a un valor inferior a 8. Quizás luego quiera incrementarlo a 16.

memoria en megabytes para usar en la cache de las miniaturas

Esto controla la cantidad de miniaturas (o mapas mip) que se pueden almacenar en la memoria a la vez. Como punto de partida, establézcalo en algo así como 256 MB. Desde darktable 2.0, la memoria caché asigna algunos búferes pequeños para cada miniatura en la memoria caché, lo que provoca una fragmentación significativa de la memoria. Como se explicó anteriormente, esto plantea un problema para los sistemas de 32 bits. Por esta razón, a partir de la versión 2.0 de darktable, el soporte de 32 bits está en desuso.

10.1.6. darktable en sistemas de 64 bits

No hay mucho mas que decir. Claro que los sistemas 64-bit también requieren de una cantidad suficiente de memoria principal, así que la recomendación de los 4GB más la swap se mantiene verdadera. Por otra parte, las arquitecturas 64-bit no sufren de las limitaciones especificas de los 32-bit como el pequeño espacio de asignación y la locura de fragmentación.

La mayoría de los CPUs modernos Intel o AMD 64-bit tendrán un espacio de asignación disponible en el rango de varios Terabytes. La palabra moderno es relativa a este contexto: todos los CPUs AMD e Intel introducidos entre el 2003 y el 2004, respectivamente, ofrecen un modo 64-bit. Linux para 64-bit ha estado disponible por muchos años.

Todas las distribuciones relevante de Linux le dan la opción de instalar una versión 32-bit o 64-bit sin costos adicionales. Incluso puede correr binarios obsoletos de 32-bit en Linux 64-bit. Lo único que necesita hacer: invierta algo de tiempo en la migración. Al final, le recomendamos enérgicamente moverse a una versión 64-bit de Linux. Realmente no hay razón por la cual no actualizar a un 64-bit.

En un sistema 64-bit puede dejar de forma segura los parámetros de configuración para las bandas relacionadas como vienen por defecto: límite de memoria (en MB) para el proceso de bandas debería tener un valor de 1500 y el mínima cantidad de memoria (en MB) para un buffer único de proceso en bandas debería estar en 16. En caso de que migre de un sistema 32-bit a uno de 64-bit necesitará activar estos parámetros y cambiarlos manualmente en el diálogo de preferencias de darktable.

Typically there is no need to restrict oneself in the number of background threads on a 64-bit system. On a multi-processor system a number of two to eight threads can speed up thumbnail generation considerably versus only one thread. The reason is not so much taking maximum advantage of all your CPU cores – darktable's pixelpipe anyhow uses all of them in parallel – but hiding I/O latency.

Hay una excepción que vale la pena mencionar. Si utiliza darktable para procesar panoramas combinados, e.g. TIFFs generados por Hugin, estas imágenes pueden alcanzar tamaños considerables. Cada hilo en segundo plano necesita asignar suficiente memoria para mantener una imagen completa mas sus intermediarios y la salida en el buffer. Esto no funcionará incluso en sistemas de 64-bit bien equipados que se quedaron sin memoria. En ese caso, baje el número de hilos en segundo plano a solo uno.