Posible pérdida de información al guardar archivos

[David Serrano]

Tenemos una imagen abierta en la cual hay varias horas de trabajo y, además del .psm, también queremos guardarla por ahí por si acaso. Guardar como TIFF, 32 bits, compresión zip. Todo correcto.

Ahora seguimos trabajando con ella un rato y la volvemos a guardar, yendo a File -> Save. El programa no nos pregunta de nuevo la profundidad ni la compresión ni todo eso, y guarda sin más. Entonces en la Processing console aparece:

"Writing TIFF: 16-bit integers, 3 channel(s), 3899x2562 pixels, chunky: 100%"

Nótese el "16-bit integers". Si más tarde el ordenador se muere y decidimos continuar desde esta versión, habremos perdido la mitad (!) de la información que había en la imagen.

Digo "posible" en el título porque quizá resulta que la imagen es de 16 bits y por tanto es correcto guardarla así. Sin embargo no creo que este sea el caso porque ajustando las Readout Options para que muestre números de 32 bits, compruebo que el valor para determinado canal y determinado pixel es de 4294508536, el cual no es divisible por 16 y por tanto el quinto bit menos significativo debe estar a 1. Si la imagen fuera de 16, supongo que los 16 bits menos significativos deberían estar a 0. Hmm... sin embargo veo que la representación binaria de ese número es nada menos que 11111111 11111000 11111111 11111000... es decir, dos grupos iguales de 16 bits... Help!

[Juan Conejero]

Bueno, vamos a ver cómo explico ésto  

Se trata de una manifestación "sutil" de la orientación a objetos que rige toda la arquitectura de PI, tanto interna como externamente.

Tú abres una imagen en 16 bits, la procesas, y después la guardas en una archivo de 32 bits. Muy bien, pero no esperes que PI transforme la imagen que tienes en el espacio de trabajo (el objeto imagen) a 32 bits automáticamente, porque nunca lo hará

Al trabajar en PI, acostúmbrate a pensar disociando datos y procesos. Es así como PI funciona siempre, y lo hace de forma tan radical que lo sacrificará todo para preservar ese principio de diseño. Esto es lo que hay

Al guardar una imagen en disco, se genera una instancia de un formato de archivo (que reside en un módulo), se establece una comunicación con esa instancia que quizá conduzca a la generación de datos en un archivo de disco (o quizá no, el sistema es muy flexible), e inmediatamente se asesina (literalmente) a esa instancia sin piedad. No existe forma alguna de que la instancia de formato altere a los datos de imagen que maneja porque la comunicación es unidirecccional; en el sentido instancia->imagen existe un muro infranqueable que aísla completamente a ambas partes. Por eso la imagen (el objeto real que reside en el espacio de trabajo de PI) no cambiará nunca cuando la guardes en disco. Sólo cambiará la trayectoria de archivo que se mantiene asociada a la imagen, y otros datos auxiliares asociados con el formato empleado, pero todo eso es información de control asociada que no forma parte de la imagen en sí.

La forma correcta de proceder es:

1. Abrir la imagen de 16 bits
2. Tal vez procesar... procesar... en 16 bits
3. Eventualmente, transformar la imagen a 32 bits (aplicando SampleFormatConversion)
4. Tal vez procesar... procesar... ahora quizá en 32 bits
5. Guardar la imagen como ... con un formato cualquiera - la imagen no cambia.
6. Tal vez procesar... procesar...
7. Guardar la imagen (ojo que no hay "como") - se guardará en 32 bits porque es el formato que tiene, pero de nuevo la imagen no cambia.

Ésa es la idea

[Juan Conejero]

ajustando las Readout Options para que muestre números de 32 bits, compruebo que el valor para determinado canal y determinado pixel es de 4294508536, el cual no es divisible por 16

Ten en cuenta que la información de readout no corresponde necesariamente a valores existentes en la imagen, sino que es totalmente virtual (digamos que se hace el paso del rango [0,1] que usa PI internamente al rango que se solicita), a no ser que escojas un formato de representación de readout que coincida con el formato de la imagen, en cuyo caso dará la casualidad de que los valores presentados y los existentes coincidirán (salvo errores por redondeo, que no deberían producirse nunca).

[David Serrano]

Tú abres una imagen en 16 bits, la procesas, y después la guardas en una archivo de 32 bits. Muy bien, pero no esperes que PI transforme la imagen que tienes en el espacio de trabajo (el objeto imagen) a 32 bits automáticamente, porque nunca lo hará

Una vez leí que Pixi trabajaba siempre a 32 bits (o incluso a 64 en algunos casos). Por tanto, supuse que, por mucho que mi imagen fuera de 16, la simple aplicación de un proceso haría que pasara a ser de 32.

Entonces, ¿podemos asumir que, para averiguar la profundidad de color de una imagen, un posible método es simplemente guardarla a disco y ver lo que aparece en la consola?

Haré alguna prueba empírica con una imagen con profundidad de 3 bits, a ver lo que pasa ;^).

Por eso la imagen (el objeto real que reside en el espacio de trabajo de PI) no cambiará nunca cuando la guardes en disco.

Mi preocupación venía en caso de que cerremos la imagen (que lógicamente no ha cambiado al guardarla) y abramos la que hemos guardado. Según pensaba, teníamos en memoria una imagen de 32 y ahora obtendríamos una de 16.

2. Tal vez procesar... procesar... en 16 bits

Vale, ahora queda todo claro.

Este me parecía un "bug" muy gordo como para existir realmente, y sin embargo acabó en el subforo de bugs simplemente por carrerilla . Trataré de ser más cuidadoso la próxima vez. Imagino el susto: "Pérdida de información??? Qué dice este tío???" xD.