Las dos mitades de esa foto son el mismo archivo. La misma boda, el mismo encuadre, la misma edición. Lo único que cambia es cómo se procesó el color al prepararla para la web — y la de la derecha perdió un 20 % de saturación por un descuido de una línea.

Si alguna vez subiste una foto y sentiste que en Lightroom se veía mejor, probablemente no era tu pantalla ni tu imaginación. Era esto.

Qué pasa, en una frase

Tu cámara y tu Lightroom probablemente trabajan en Adobe RGB, que es un espacio de color más amplio que sRGB — puede representar más verdes y más cianes. La web, en cambio, asume sRGB cuando no se le dice otra cosa.

Los valores de un píxel son solo tres números. Esos números no significan nada por sí solos: significan un color dentro de un espacio. Si la foto se guardó en Adobe RGB y en algún punto se pierde esa etiqueta, el navegador lee los mismos números como si fueran sRGB. Y como sRGB es más estrecho, cada número describe un color menos saturado del que debía. Resultado: todo se ve un poco lavado, sobre todo los rojos y los verdes.

Los navegadores modernos sí gestionan color

Y esto conviene decirlo, porque circula mucha información vieja. Chrome, Safari y Firefox sí leen el perfil incrustado y muestran bien una imagen en Adobe RGB si el perfil viene con ella.

El problema no es Adobe RGB. El problema es que el perfil se pierde por el camino con muchísima facilidad: lo quitan los optimizadores de imágenes, lo quitan algunos gestores de contenido, lo quitan varias redes sociales al recomprimir, y lo quita cualquier script que procese la foto sin saber lo que hace. Y cuando se pierde, el archivo queda sin manera de decir en qué espacio está.

Por eso convertir a sRGB antes de publicar no es una superstición: es quitarle al archivo la posibilidad de que lo malinterpreten.

El error de código que me costó encontrar

Cuando automaticé el procesado de las fotos del sitio, la primera versión hacía esto:

imagen = imagen.convert('RGB')

Parece una conversión. No lo es. .convert('RGB') cambia el modo del archivo — de CMYK a RGB, de escala de grises a RGB — pero no toca el espacio de color. Los números se quedan exactamente como estaban y salen del proceso sin perfil, así que a partir de ahí todo el mundo los lee como sRGB.

Es un error especialmente traicionero porque no falla. No lanza un error, no rompe nada, y el archivo se ve bien si no tienes el original al lado. Solo se ve apagado.

Cuánto se pierde, medido

Tomé una de mis fotos de boda —montaje de mesa, mucha flor, mucho color— y la procesé de las dos formas para medir la diferencia en lugar de suponerla. Es la imagen que abre este artículo.

La saturación media pasa de 66.7 a 53.1: un 20.5 % menos. La diferencia máxima en un canal llega a 46 niveles sobre 255. No es un cambio brutal, y ahí está lo peligroso: no se ve mal, se ve apagado. Nadie se va a quejar. Simplemente tus fotos tienen menos fuerza de la que tienen en tu pantalla.

Qué hacer

Si exportas desde Lightroom: elige sRGB en el espacio de color de la exportación para todo lo que vaya a la web, y deja Adobe RGB o ProPhoto para lo que vaya a imprenta. Es un desplegable y se te olvida una vez.

Si procesas con un script: no uses .convert('RGB') a secas. Hace falta una conversión de perfil a perfil, leyendo el perfil incrustado del original y transformando a sRGB de verdad. En Python, con Pillow, eso es ImageCms.profileToProfile, y después hay que incrustar el perfil sRGB en el archivo de salida.

Y comprueba el resultado, no confíes. Abre el archivo final y mira qué perfil declara. Si dice «sRGB IEC61966-2.1», está bien. Si no declara ninguno, ya empezaste a perder color.

Cuándo sí quieres Adobe RGB

Para imprenta. Un laboratorio o una imprenta buena aprovecha ese espacio más amplio, sobre todo en verdes y cianes, y ahí sí notarías la diferencia al revés. Por eso el consejo no es «usa siempre sRGB», sino sRGB para pantalla, Adobe RGB para papel, y nunca dejar que el archivo viaje sin decir cuál es.