¿La conversión colorimétrica relativa de Photoshop es inconsistente?

La conversión colorimétrica relativa de Photoshop parece ser inconsistente.

Estoy convirtiendo de Adobe RGB a sRGB. Los ajustes son los siguientes:

ingrese la descripción de la imagen aquí

Abro el mismo archivo dos veces y ejecuto la misma conversión. Los resultados son diferentes. No lo suficiente como para ser perceptible a simple vista, pero lo suficiente como para tener diferentes valores de píxeles.

Resumen: abro el mismo archivo dos veces, lo convierto con la misma configuración y obtengo dos resultados diferentes. La imagen es un TIFF de 8 bpp sin comprimir, 640x1024 píxeles.

EDITAR: Ocasionalmente parece dar los mismos resultados dos veces, pero nunca dos veces seguidas.

EDITAR: se deshabilitó el tramado en el cuadro de diálogo de configuración según la sugerencia del Sr. Wizard, y ahora los resultados son los mismos cada vez. ¿El tramado no es algorítmico? (¿Es aleatorio?)

También una nota sobre el uso de tramado: si su intención de salida es JPEG u otro formato con pérdida similar, los beneficios de tramado pueden perderse en la compresión, con una pequeña probabilidad de que incluso produzca resultados no deseados.

Respuestas (2)

Dither agrega ruido para suavizar los degradados de color. De Wikipedia con énfasis añadido:

Dither es una forma de ruido aplicada intencionalmente que se usa para aleatorizar el error de cuantización, evitando patrones a gran escala, como bandas de color en las imágenes.

Por lo tanto, el uso de tramado con conversión, por definición, producirá resultados "aleatorios". El algoritmo que utiliza Photoshop aparentemente es tanto

  • lo suficientemente aleatorio como para que se apliquen diferentes tramados a la misma imagen;
  • lo suficientemente optimizado como para que sea muy probable que se utilice un interpolado varias veces al convertir la misma imagen una y otra vez.

Si desea una conversión numéricamente idéntica, desactívela, a expensas de cierta calidad de imagen.

@Unsigned, pruébalo y compruébalo por ti mismo. Si lo desactiva, Ditherlos resultados serán idénticos en píxeles. Si está encendido, no lo están. Por lo tanto, podemos deducir que el ruido dither es aleatorio, con una semilla diferente.
@Unsigned hay diferentes tipos de tramado; El propio Photoshop proporciona Difusión, Patrón y Ruido para la conversión a Color indexado. Usar una distribución aleatoria es probablemente una buena opción, pero podría decirse que podrían usar la misma semilla cada vez. Quizás cambiaron a una biblioteca diferente para la generación de números aleatorios entre CS4 y CS5.
@Unsigned, está basado en ruido, pero más allá de eso, no lo sé, y no conozco ninguna forma de cambiarlo. Para la mayoría de las imágenes no debería suponer una gran diferencia; Le sugiero que simplemente lo apague si el efecto le molesta.
@Unsigned: (1) gracias por aceptar. (2) No creo que todo el espacio de color CMYK encaje dentro de RGB, a menos que sea ProPhoto RGB; Estoy bastante seguro de que los espacios CMYK comunes no encajan en AdobeRGB. (3) Dither no está ahí para la gama (AFAIK), está ahí para la precisión; siempre que su objetivo sea un interpolado de espacio de 8 bits, es útil. Sería mucho menos útil convertir 16 bits a 16 bits, y no es necesario cuando se trabaja con datos flotantes o de 32 bits.
@Unsigned Debe mirar los gráficos de espacio de color 3D para tener una mejor idea de cómo se relacionan. No tengo el complemento VRML instalado en este momento, por lo que no puedo verlos, pero mi memoria es que no es un simple "uno dentro del otro", sino que CMYK alcanza ciertos colores que sRGB pierde, y viceversa. (continuado...)
Sin embargo, eso no es lo más importante aquí: la conversión no puede ser sin pérdidas, incluso si el espacio de color de destino contiene completamente el espacio de origen, porque no hay una precisión infinita para la conversión. Si desea una ilustración de esto, publique una nueva pregunta y la explicaré. (deja un comentario aquí para no tener que recordarlo y/o buscarlo)

Tomando una suposición descabellada, sospecho que te estás encontrando con artefactos de compresión jpeg invisibles a la vista. Incluso en bloques de color aparentemente sólido encontrará inconsistencias, especialmente si los bloques (y su imagen) no son múltiplos exactos de 8x8 píxeles (bloque de construcción de jpeg). Esto es especialmente cierto cuando tiene bordes nítidos y de alto contraste. Sospecho que el problema es independiente de la conversión.

La muestra puntual, a diferencia de 3x3 o 5x5, también puede brindarle resultados inconsistentes, especialmente en imágenes fotográficas, especialmente cerca de límites de alto contraste, y definitivamente si hay ruido en la imagen.

Pruebe este experimento: configure un documento con varios bloques de color sólido sobre un fondo blanco. Cuentagotas alrededor de los bloques de color, especialmente lejos del centro, y anota las lecturas. Ahora guarde el documento como jpeg, cierre y vuelva a abrir. Repita la prueba del cuentagotas.

Repita el experimento, pero esta vez use un documento que tenga exactamente 256 píxeles cuadrados y haga que los bloques de color tengan exactamente 80 píxeles cuadrados, alineados en límites de 8 píxeles. A ver si no obtienes un resultado diferente.

Mike Ninness dio una sesión reveladora (para mí, de todos modos) sobre optimización de imágenes en MAX la semana pasada, y la gran variación producida por la compresión jpeg fue uno de los puntos principales. La sección de "regla de 8" comienza aproximadamente a los 14 minutos y 40 segundos.

[ACTUALIZAR DESPUÉS DE Q ACLARO] Aumente el tamaño de su muestra en el cuentagotas a un valor lo suficientemente grande como para suavizar el ruido en el difuminado. El tramado es necesario cuando se cambian los perfiles para mantener las relaciones visuales entre los diferentes colores sin bandas (esta es también la razón por la que se debe evitar el "colorimétrico absoluto" en el uso normal), pero es (por definición) aleatorio. Si usa una muestra demasiado pequeña, obtendrá variaciones en cualquier lugar donde haya un cambio de color que no se pueda replicar exactamente en el perfil de destino.

Eso no es relevante. Lo relevante es si se trata de un jpeg y si el muestreo se realiza precisamente (hasta el píxel) en el mismo lugar. Si lo primero es cierto y lo segundo no, puede obtener diferentes valores simplemente moviendo el cuentagotas a un punto diferente en un bloque sólido de color, ya sea que cambie de perfil o no. De hecho, intente el experimento, ¿no?
Actualice la pregunta con toda la información para que la situación exacta sea clara: tipo de archivo, imagen o gráfico, ese tipo de cosas. Entonces podemos probar más apropiadamente y responder. No veo este comportamiento cuando trabajo con los bloques de colores sólidos que solía probar.