digiKam: el sustituto real de Lightroom Library

Hay un patrón que se repite en casi todos los artículos sobre Linux y fotografía: se saltan la parte del catálogo.

Te dicen que uses Darktable o RawTherapee para revelar RAW. Te explican GIMP para retoque. Quizá mencionan Krita. Pero la pregunta crítica — «¿cómo organizo 50.000 fotos de los últimos 10 años?» — se queda sin respuesta.

La respuesta es digiKam. Y es probablemente la pieza más subestimada del software libre fotográfico.

¿Por qué casi nadie lo menciona?

Tres razones:

1. No tiene marketing. Es un proyecto KDE mantenido por gente que prioriza funcionalidad sobre comunicación.
2. Está infrautilizado. Mucha gente lo usa solo como visor de fotos cuando es una bestia de catalogación profesional.
3. Su nombre es feo. «digiKam» suena a 2003. La interfaz también lo parecía hasta hace poco.

Pero abre digiKam con archivo profesional y empezarás a ver lo que ofrece.

Qué hace digiKam que Darktable no

Darktable tiene un módulo «lighttable» que sirve para organizar. No es comparable a digiKam. Es como decir que Notepad sirve para escribir libros.

Conclusión:
Si buscas un sustituto gratuito de Lightroom Classic para gestionar decenas o cientos de miles de fotos, digiKam es claramente superior como catálogo DAM. Por otro lado, Darktable destaca en el revelado RAW, pero sus funciones de catalogación son mucho más limitadas.

DigiKam es el catalogador. Darktable es el revelador. Necesitas ambos.

Mi setup actual con digiKam

Para entender por dónde va este artículo, así tengo configurado mi archivo de 14 años:

• Base de datos: MariaDB (no SQLite) en SSD interno
• Archivos: en NAS Synology vía NFS (/mnt/nas/foto/)
• Tags: jerarquía estructurada por Tipo / Cliente / Lugar / Contenido / Ánimo / Proyecto / Estado
• Reconocimiento facial: activado para más de 200 personas identificadas
• XMP sidecar: activo siempre — los tags viajan con la foto

Lleva 6 meses funcionando sin un solo crash. Tiene unas 180.000 fotos catalogadas. Búsquedas instantáneas.

Instalación correcta

bash

flatpak install -y flathub org.kde.digikam

Por qué Flatpak y no apt: la versión apt de Ubuntu suele estar 1-2 versiones por detrás. Flatpak te da la última estable.

La primera vez que lo abres, te pregunta dónde guardar la base de datos y dónde están las fotos. Esto es crítico. Te lo explico ahora.

Configurar la base de datos correctamente

digiKam tiene tres modos de base de datos. La elección importa.

SQLite (default, NO recomendado para profesional)

• Bien para hasta 10.000 fotos
• Archivo único, fácil de hacer backup
• Lento con catálogos grandes
• No soporta acceso concurrente

MySQL/MariaDB interno (recomendado para profesional)

• Soporta catálogos masivos (cientos de miles de fotos)
• Búsquedas instantáneas
• digiKam levanta el servicio automáticamente

MySQL/MariaDB externo (para casos avanzados)

• Si quieres acceder desde varios equipos
• Más complicado de configurar

Para el 99% de profesionales: MariaDB interno. Configuración:

1. Abre digiKam
2. Te pide elegir BD → MySQL/MariaDB internal
3. Carpeta de datos: ~/.local/share/digikam-mariadb/ (queda en SSD interno, importante)
4. Carpeta de fotos: aquí pones tu archivo (/mnt/nas/foto/ en mi caso)

⚠️ NO pongas la base de datos en el NAS. Es lentísimo y conflictivo. La BD va en SSD interno siempre.

Configuración esencial (pasos críticos)

Antes de empezar a importar, hay 4 ajustes obligatorios. Si te los saltas, te complicas la vida durante años.

1. Activar XMP sidecar

Configuración → Configurar digiKam → Metadatos → pestaña "Comportamiento"

Activa:

• Escribir metadatos a archivos sidecar XMP
• Sidecar separado para cada archivo
• Leer metadatos de archivos sidecar XMP cuando estén disponibles

Por qué: si algún día cambias a Lightroom, Darktable u otro software, los tags están dentro del XMP al lado del RAW. Si no los activas, los tags solo viven en la BD interna y los pierdes.

2. Configurar el cache de miniaturas

Configuración → Configurar digiKam → Sistema

• Tamaño máximo de la cache de miniaturas: 5 GB (o más si tienes espacio)
• Ubicación: en SSD interno, no en NAS
• Tamaño máximo de cache de imágenes: 1 GB

3. Activar reconocimiento facial

Configuración → Configurar digiKam → Reconocimiento Facial

• Activar reconocimiento facial: sí
• Detección: usa el modelo basado en deep learning (más preciso que el clásico)
• Threshold: 0.7 (subir si tienes muchos falsos positivos)

Esto es local. Tus caras no van a ningún servidor. La primera vez tarda mucho indexando, después es rápido.

4. Configurar formatos RAW de tu cámara

Configuración → Configurar digiKam → Formatos

Asegúrate de que tu formato (CR2, NEF, ARW, RAF, etc.) está en la lista de formatos a indexar. Por defecto, los principales están todos.

Estructura de tags: la jerarquía que cambió mi flujo

Aquí viene la parte que más rentabilidad te dará: diseñar bien la taxonomía de tags al principio.

Mi jerarquía actual (después de 6 meses iterando):

Tipo/
├── Concierto
├── Retrato
├── Calle
├── Social
├── Eventos
├── Comercial
├── Personal
└── Experimental

Lugar/                      ← jerárquico
├── Catalunya/
│   ├── Barcelona/
│   │   ├── Razzmatazz
│   │   ├── Sala_Apolo
│   │   ├── Gracia
│   │   └── ...
│   ├── Girona/
│   ├── Tarragona/
│   └── Lleida/
└── Internacional/

Contenido/                  ← lo que SE VE
├── Personas
├── Paisaje
├── Arquitectura
├── Comida
├── Animales
├── Detalles
└── Abstracto

Ánimo_Color/                ← curatoría visual rápida
├── Cálido
├── Frío
├── Alto_contraste
├── Pastel
├── Monocromo
└── Saturado

Proyecto/                   ← multi-canal
├── Substack
├── YouTube
├── lluisridao_portfolio
├── blues_cat
└── ixai_dev

Estado/                     ← workflow
├── A_revisar
├── Editado
├── Publicado
├── Vendido
└── Descartar

Por qué esta estructura funciona

Es ortogonal. Una foto puede ser simultáneamente:

• Tipo/Concierto
• Artista/Blues/Quim_Casas
• Lugar/Catalunya/Barcelona/Razzmatazz
• Contenido/Personas
• Ánimo_Color/Cálido
• Proyecto/blues_cat
• Estado/Publicado