¿Acaso no son todas las imágenes digitales valores de píxeles entre 0 y 255?

Tengo algunas preguntas increíblemente básicas (¿estúpidas?) Sobre imágenes; específicamente, formatos de imagen y valores de píxeles.

Perdóname, no soy fotógrafo. Solo soy alguien que trabaja con imágenes, y para mí, son solo filas y columnas de números.

Mis preguntas son:

Si en el núcleo, las fotos son solo 3 canales de valores de píxeles [0, 255] X RBG, entonces, ¿cómo podría haber alguna diferencia entre dos formatos de imágenes? Quiero decir, ¿qué hace que un RAW sea diferente de un TIFF? ¿No están todos estos limitados a valores entre 0 y 255? Un número es un número, ¿no debería haber solo un formato establecido? O, ¿no deberían bloquearse dos imágenes con la misma altura y ancho para tener el mismo tamaño de archivo?

Además, desde un punto de vista numérico, ¿qué hace que algo como las imágenes de 16 bits sea diferente de las imágenes de 32 bits? Una vez más, una imagen es solo una matriz con valores enteros entre 0 y 255.

Continuando con esta perspectiva de que una imagen en el sistema de archivos de una computadora es solo una matriz de enteros de 3 canales entre 0 y 255, ¿cuál es el punto de comprimir una imagen en un formato con pérdida como, por ejemplo, JPG? Digamos que el algo de compresión cambia algunos valores de píxeles de 254 a 255 o lo que sea. ¿Entonces? ¿Cómo proporciona eso algún ahorro en el tamaño del archivo o tiene algún impacto en la calidad visual?

Sé que hay muchas maneras diferentes de almacenar datos de imágenes. Pero no estoy preguntando nada más que una imagen RBC básica de 3 canales. Todo lo que sé es que si alguien me entrega uno de estos, ahora tengo una serie de números. No tengo ninguna razón para saber por qué una matriz de números podría ser diferente de otra matriz de números del 0 al 255. Espero que esto tenga sentido. ¡Esta pregunta no se limita al formato RAW! Más bien, se trata de cualquier conjunto de valores de píxeles

Lo sentimos, pero su premisa básica es incorrecta: una imagen puede codificarse como una matriz de píxeles RBG con 8 bits por valor, pero hay muchas otras formas:

• un canal con un bit / canal (blanco y negro puro),
• un canal con x bit / canal (formatos en escala de grises, x generalmente será 8 o 16, dando 256 o 65536 valores),
• Varios formatos basados ​​en paletas (cf.GIF)
• a todo color con (al menos en teoría) tantos canales como desee con cualquier profundidad de bits requerida.

Y eso es para la imagen almacenada en la RAM de la computadora durante la edición / visualización. Estoy ignorando los diversos formatos de imagen RAW que existen (aquí y en el resto de esta publicación).

Para la fotografía , los más comunes son 3 canales con 8, 16 o 32 bits / canal (generalmente enteros, pero al menos algunos programas funcionan internamente con números de coma flotante de 32 bits). A menudo hay un cuarto canal (alfa), especialmente cuando el programa permite el uso de capas. Y en algún lugar, las dimensiones de la matriz de imágenes deben almacenarse.

Hay varias razones para estos diferentes formatos. Para el formato en memoria, una consideración importante solía ser el tamaño de los datos y la velocidad (mucho más rápido para manipular un canal de 8 bits que 4 canales de 32 bits). Esos son menos importantes hoy en día, pero obtuvimos una gestión completa del color con varios espacios de color. Algunos de ellos (por ejemplo, prophoto RGB) necesitan al menos 16 bits / canal para mantener las diferencias entre colores vecinos lo suficientemente pequeñas como para evitar bandas visibles. Y a medida que los tratamientos se vuelven más complicados, existen ventajas al usar números de coma flotante de 32 bits (donde los colores se codifican con valores entre 0.0 y 1.0, y el tratamiento permite valores intermedios fuera de este rango).

Si desea poder almacenar la imagen en un archivo y volver a cargarla en los mismos datos en memoria, deberá usar al menos tantos bits por canal como el formato de memoria im, y debe almacenar información sobre dimensiones de imagen, profundidad de bits y espacio de color.

A los usuarios de esas imágenes también les gusta almacenar información adicional sobre la imagen (título, título, quién tomó la imagen, etc.). Nuevamente, varias formas de almacenar esta información.

Luego hay diferentes formas de comprimir los datos de la imagen para el almacenamiento de archivos. Uno de los más simples es RLE (Run Length Encoding), donde almacena un recuento y un valor de píxel cada vez que encuentra un valor de píxel repetido. Otros, como jpeg, son mucho más complicados, pero también dan mucha más compresión. Por ejemplo, jpeg usa una transformación de coseno y arroja la información de alta frecuencia (menos visible), dando altas tasas de compresión a costa de la pérdida de información (hay más, pero esto se está alargando demasiado).

Esto ya ofrece muchas formas de almacenar la información en el disco, pero de cualquier forma que elija, el formato debe estar bien especificado para permitir una interpretación correcta al cargar la imagen.

Luego hay un desarrollo constante, por ejemplo, en técnicas de compresión sin pérdida, que los formatos existentes no siempre pueden manejar.

Así que terminamos con una variedad de formatos de archivo, con varias compensaciones entre la fidelidad de la información almacenada, el espacio en disco ocupado y la velocidad de lectura, escritura y transmisión (compare el tamaño de un TIFF no comprimido y un jpg de calidad decente) .

Si se maneja una imagen en memoria, tendrá la forma de una o más matrices. En ese punto, el formato de archivo original ya no debería jugar un papel . Asumiré que manejaste tus datos con 8 bits / canal.

Pero tendrá que saber si tiene una imagen procesada o una imagen sin procesar, ya que hay dos diferencias importantes entre ellas:

• las imágenes en bruto generalmente tienen 1 color por píxel , y los píxeles generalmente se organizan en una matriz Bayer con 2 píxeles verdes, 1 rojo y 1 azul por cuadrado de 4 píxeles. Los valores son proporcionales a la intensidad de la escena (excepto valores muy bajos y muy altos).
• Las imágenes procesadas se pueden organizar como una matriz 2D de registros que contienen 3 valores numéricos, o como planos de color (3 matrices 2D, una para cada uno de R, G, B). Además, los valores generalmente no son proporcionales a las intensidades de la escena . Peor aún, la relación exacta entre los valores de píxeles y las intensidades de la escena depende del procesamiento que haya tenido la imagen. Y el equilibrio entre los colores se ha ajustado para corresponder a la respuesta del ojo humano (el balance de blancos, rojo y azul se amplifican en relación con el verde).

Entonces, si obtiene una imagen en bruto con 3 valores de color por píxel, esa imagen en bruto ya ha recibido algún tratamiento (al menos ya sea un demoaicing o un binning simple de 4 píxeles en bruto a 1 píxel de imagen). Si eso es aceptable, dependerá de su aplicación.

Si en el núcleo, las fotos son solo 3 canales de valores de píxeles [0, 255] X RBG,

Pero las fotos no son "solo 3 canales de valores de píxeles", incluso "en el núcleo". Las pantallas de computadora generalmente están formadas por una matriz de píxeles RGB, por lo que si desea mostrar una imagen en la pantalla de una computadora, en algún momento debe asignar cualquier dato de imagen que tenga en una matriz de píxeles RGB, pero esos datos son solo una representación particular de los datos de la imagen. Es posible que los datos de la imagen no consistan en una secuencia de valores de píxeles. Para obtener valores de píxeles de una imagen, debe saber cómo se formatean los datos.

entonces, ¿cómo podría haber alguna diferencia entre dos formatos de imágenes? Quiero decir, ¿qué hace que un RAW sea diferente de un TIFF? ¿No están todos estos limitados a valores entre 0 y 255?

Esos son dos buenos ejemplos, porque ninguno de esos formatos contiene necesariamente una matriz rectangular de valores RGB.

RAW no es un formato único en absoluto: es una especie de nombre general para archivos que contienen datos grabados directamente desde un sensor de imagen. Por lo tanto, un archivo RAW puede contener una secuencia de valores que representan los voltajes leídos de los distintos sitios de sensores. Esos sitios son como píxeles de la imagen, pero son no píxeles RGB. Para obtener píxeles RGB de un archivo RAW, debe interpretar esos datos en el contexto de la información sobre el sensor, la configuración de la cámara en ese momento, etc. En otras palabras, puede abrir un archivo RAW en un editor hexadecimal y mira todo lo que quieras, pero no encontrarás un solo valor RGB.

TIFF significa formato de archivo de imagen etiquetado , y es un formato muy interesante porque puede contener muchas representaciones diferentes de una imagen. Un solo archivo TIFF podría contener la "misma" imagen en varios tamaños, como una imagen en miniatura, resolución de pantalla e imagen de resolución de impresión, y también podría tener versiones en color y en escala de grises. ¿Sabía que las máquinas de fax suelen enviar sus datos como archivos TIFF? Para obtener píxeles RGB de un archivo TIFF, debe comprender no solo el formato TIFF, sino también el formato de la representación de imagen particular dentro de ese archivo.

Un número es un número, ¿no debería haber solo un formato establecido?

No. Hay muchos formatos de imagen diferentes porque cada persona sirve a un conjunto diferente de necesidades. La compresión con pérdida de JPEG es excelente para obtener archivos de imagen muy pequeños, pero no es bueno para las imágenes que tendrán que editarse varias veces. Algunos formatos usan entrelazado , lo que hace que sea muy rápido leer la imagen en varias resoluciones diferentes. Y así sucesivamente ... cada formato ofrece su propia combinación de ventajas y compromisos.

O, ¿no deberían bloquearse dos imágenes con la misma altura y ancho para tener el mismo tamaño de archivo?

No, eso sería terrible. Si el tamaño de cada archivo de imagen tuviera que ser esencialmente width * height * 3(asumiendo un color de 24 bits), entonces desperdiciaría mucho espacio de almacenamiento. La mayoría de las fotos contienen mucha redundancia, es decir, regiones donde el mismo color se repite muchas veces. Para ahorrar espacio de almacenamiento, a menudo tiene sentido eliminar esa información redundante. Una forma de hacerlo, por ejemplo, es la codificación de longitud de ejecucióno RLE. Por ejemplo, si tiene una región de 4195 píxeles consecutivos que son todos blancos, es mucho más eficiente codificar eso como "los siguientes 4195 píxeles son todos {255, 255, 255}" en lugar de simplemente almacenar esa cantidad de píxeles blancos en el archivo. RLE se usa en algunos formatos de imagen, pero muchos formatos tienen esquemas mucho más sofisticados que ahorran mucho más espacio, y eso significa que puede almacenar muchas más imágenes en un disco duro o tarjeta de memoria. También hace que sea mucho más rápido enviar la imagen a otra persona.

Continuando con esta perspectiva de que una imagen en el sistema de archivos de una computadora es solo una matriz de enteros de 3 canales entre 0 y 255, ¿cuál es el punto de comprimir una imagen en un formato con pérdida como, por ejemplo, JPG?

El punto es que hace que el archivo sea mucho más pequeño. La compresión JPEG con frecuencia reduce el tamaño de un archivo en un factor de 10 o más. Eso significa que puede colocar más imágenes en un dispositivo de almacenamiento determinado, puede copiarlas más rápido, abrirlas más rápido y cargarlas y descargarlas más rápido. El almacenamiento de la misma imagen (o casi) en un espacio mucho más pequeño utiliza los recursos de manera más eficiente y, por lo tanto, reduce los costos. Piense en eso a gran escala: es probable que un porcentaje muy grande de la información disponible en Internet consista en imágenes y películas, y sin compresión necesitaríamos centros de datos más o más grandes y consumiríamos mucha más energía.

Digamos que el algo de compresión cambia algunos valores de píxeles de 254 a 255 o lo que sea. ¿Entonces? ¿Cómo proporciona eso algún ahorro en el tamaño del archivo o tiene algún impacto en la calidad visual?

Considere mi ejemplo RLE anterior. Digamos que tiene una foto que incluye una gran pared en blanco, por lo que grandes áreas de su foto son todas del mismo color, excepto que hay una dispersión de píxeles ligeramente más oscuros, apenas perceptibles en la imagen. Esos píxeles reducen la efectividad de la compresión. En lugar de poder decir "los siguientes 500,000 píxeles son todos {243, 251, 227}", debe ejecutar la longitud de codificación de muchos más fragmentos más pequeños, porque cada cierto tiempo se encuentra con uno de esos píxeles ligeramente diferentes. Si permite que el algoritmo de compresión realice pequeños cambios, tal vez solo cambiando cualquier píxel en no más del 1% o 2%, entonces puede obtener una relación de compresión mucho mayor sin cambiar perceptiblemente la imagen. Es una compensación: usted ' renunciar a una pequeña cantidad de información en la imagen original a cambio de una gran reducción en el tamaño del archivo. Exactamente dónde desea dibujar esa línea puede cambiar, por lo que los formatos con pérdida como JPEG le permiten al usuario elegir qué nivel de compresión desea.

Además de la fantástica respuesta de @ remco , quiero agregar por qué hay diferentes códecs para (aproximadamente) el mismo propósito.

Los códecs están diseñados para:

• Se sin pérdida vs. con pérdida
• Codifique rápido versus reduzca el tamaño del archivo
• Asimétrica vs simétrica en- / decodificación
• Ser compatible con el software
• Percepcionalmente casi sin pérdidas en diferentes niveles / situaciones de compresión
• Tiene características que otros códecs no ofrecen, incluyendo:
  • ser libre de regalías
  • soporte para capas
  • soporte para canal alfa (por ejemplo, RGBA) / transparencia
  • ofrecer una vista web rápida
  • admite alta (er) profundidad de bits
  • admite múltiples espacios de color (RGB / CMYK)
  • soporte para metadatos / versiones / ...

Algunas de esas cosas son mutuamente excluyentes. Y debido a eso, nos quedamos con una multitud de códecs.

Algunos ejemplos

Nota: Ni la lista de códecs está completa, ni se mencionan todas sus características (o la falta de ella). Si esta respuesta resulta útil para alguien, podría agregar más información (y ser un poco más preciso).

Quizás el formato más conocido es JPEG . Es un formato muy amplio, pero antiguo. Utiliza DCT (Transformación discreta de coseno), por lo que si bien ofrece una calidad bastante buena en sus configuraciones de mayor calidad, el bloqueo aparecerá con las más bajas.

Luego apareció JPEG 2000 para reemplazar JPEG: se basa en la Transformación Wavelet, por lo que si bien ofrece aproximadamente la misma calidad que JPEG en las configuraciones de mayor calidad, ofrece una calidad mucho mejor en las configuraciones de menor calidad (los bloques son un poco borrosos ) Además, JPEG 2000 ofrece regiones de interés (alta calidad en un área de la imagen, menor calidad en otro lugar) y soporte de 16 bits. (Además, algunas otras cosas.) Desafortunadamente (?), Debido a que es más costoso computacionalmente que JPEG y debido a algunas preocupaciones de licencia, JPEG 2000 no es tan ampliamente compatible como JPEG.

PNG es otro formato ampliamente conocido: no tiene pérdidas y admite canales alfa, pero no ofrece soporte para espacios de color que no sean RGB (como CMYK). Por lo tanto, es un formato "solo en línea".

Luego están los formatos VFX como OpenEXR . Todos giran en torno a la calidad y la velocidad: OpenEXR es sin pérdidas, admite hasta 64 bits y codifica / decodifica rápidamente. Se utiliza principalmente en la industria de efectos visuales como formato intermedio.

TIFF es otro formato sin pérdidas que es bastante popular entre los fotógrafos. Para la compresión, ofrece ninguno / ZIP / RLE / LZW / JPEG. Es compatible con hasta 32 bits. Con su compresión seleccionable, es bastante adaptable, pero debido a su pérdida, es más un formato fuera de línea.

HEIF es uno de los últimos códecs de imágenes. Utiliza la misma compresión que HEVC / h.265 y, por lo tanto, se espera que proporcione una mejor relación de compresión que JPEG. Sin embargo, debido a que es bastante nuevo y está sujeto a patentes, no es tan ampliamente respaldado como ninguno de los anteriores.

Las imágenes RAW ^{Vea también} no son imágenes reales, realmente: son más un contenedor para los datos de lectura del sensor sin procesar (de ahí el nombre). Solo con un software que sepa cómo interpretar los datos es posible obtener una imagen. Es por eso que los convertidores RAW como Lightroom / Capture One / DarkTable / ... necesitan actualizaciones para admitir nuevas cámaras que usan contenedores ya especificados como * .CR2 para Canon. También es la razón por la cual un RAW de 14 bits ofrece más opciones de edición que un TIFF de 32 bits que exportó del mismo RAW.

Intermisión: sin pérdida vs. con pérdida

Todavía no estoy seguro de lo que realmente está preguntando, así que pensé que no estaría de más agregar una pequeña explicación acerca de sin pérdida versus pérdida.

La compresión sin pérdida funciona mediante codificación de longitud de ejecución (RLE) / codificación Huffman / ... para comprimir los datos. Los datos en sí no se modifican, sino que se guardan en un paquete más pequeño. Por ejemplo, tome RLE: Digamos que tenemos un flujo de bits del canal R (de píxel 0,0a píxel 0,11) de 255,255,255,255,255,215,215,235,100,000,000,000- RLE codificaría esto como 52552215123511003000- esto es mucho más pequeño, y dado que sabemos que se guarda en grupos de 4 dígitos y que el el primer dígito es el contador y los últimos tres dígitos son el valor, luego podemos reconstruir el total 255,255,255,255,255,215,215,235,100,000,000,000.

La compresión con pérdida , por otro lado, intenta comprimir incluso más de lo que puede hacerlo sin pérdida. Para hacer esto, los códecs con pérdida generalmente intentan eliminar cosas que nuestra percepción no capta. Tomemos, por ejemplo, las YUV( YCbCr, en realidad) usos modelo JPEG (y casi todos los codec de vídeo): Y = Luminance, Cb = Chrominance Blue, Cr = Chrominance Red. Un humano no puede distinguir la diferencia entre una imagen codificada 4:2:0(cada píxel tiene un valor de luminancia, pero los colores se guardan en bloques de 2x2 alternativamente) y una 4:4:4imagen codificada (cada píxel tiene luminancia y ambos canales de color). Esto se debe a la fisiología de nuestro ojo : no podemos ver diferencias en el color tan bien como podemos ver diferencias en la luminancia.

Esto funciona bien la mayor parte del tiempo, pero compárelo con un archivo MP3: casi nadie puede distinguir las diferencias entre 192 kbps y 320 kbps, pero vaya por debajo de 64 kbps y las cosas se ponen feas rápidamente. Además, la nueva codificación reducirá aún más la calidad, ya que pueden aparecer artefactos no deseados (por ejemplo, en JPEG, los bloques pequeños de codificaciones de alta calidad se considerarán como detalles de la imagen en codificaciones adicionales).

Línea de fondo

Si no le importan los formatos de imagen o sus características, cualquiera de los dos estará bien. Con configuraciones de calidad lo suficientemente altas, es posible y previsible que ni siquiera vea una diferencia entre ellas.

Sin embargo, si necesita alguna característica específica, puede haber (y casi con seguridad: habrá) un códec que lo tenga cubierto.

Si en el núcleo, las fotos son solo 3 canales de valores de píxeles [0, 255] X RBG

Esa es una suposición seriamente rota y el resto de su pregunta simplemente no tiene respuesta sin separarse de ella.

Quiero decir, ¿qué hace que un RAW sea diferente de un TIFF? ¿No están todos estos limitados a valores entre 0 y 255?

El término "sin formato" puede referirse a dos cosas diferentes, una imagen "sin formato de cámara" o un archivo que contiene datos de imagen sin formato sin encabezados.

Una imagen "sin formato de cámara" almacena los datos sin formato a medida que salen del sensor. La mayoría de los sensores de cámara modernos tienen ADC con más de 8 bits, pero también solo recopilan datos de intensidad para un componente de color en cada ubicación. La lente puede distorsionar la geometría, los valores de intensidad del ADC pueden no hacer un buen trabajo al reflejar la percepción humana de la intensidad, los componentes de color pueden no corresponder exactamente con los utilizados por su monitor, etc.

Se necesita un proceso de mapeo complicado que involucre interpolación para convertir los datos brutos del sensor en una imagen RGB de buena calidad y no hay una forma correcta de hacerlo. Además, debido a la necesidad de interpolar componentes de color, la imagen RGB puede terminar siendo más grande que los datos sin procesar.

La conversión se puede hacer (y a menudo se hace) en la cámara, pero muchos fotógrafos prefieren guardar los datos en bruto para poder modificar el procesamiento después del hecho.

Tiff es un formato de archivo complejo que puede almacenar imágenes en una amplia variedad de formatos diferentes con una amplia variedad de metadatos. En la práctica, aunque generalmente se usa para almacenar imágenes RGB o CMYK sin comprimir o sin comprimir.

Los archivos que contienen datos de imágenes en bruto sin encabezados rara vez se usan porque debe conocer su formato y dimensiones antes de poder leerlos. Sin embargo, algunas herramientas de procesamiento de imágenes los admiten.

Además, desde un punto de vista numérico, ¿qué hace que algo como las imágenes de 16 bits sea diferente de las imágenes de 32 bits?

Lamentablemente "n bit" puede significar dos cosas diferentes. Puede significar que todos los componentes de color están agrupados en un número de bits (por ejemplo, 5 bits para rojo, 5 bits para azul y 6 bits para verde para 16 bits u 8 bits de rojo, 8 bits de verde, 8 bits de azul y 8 bits de alfa para 32 bits) o en puede significar que cada componente de color tiene n bits de información en cada ubicación de píxel.

Continuando con esta perspectiva de que una imagen en el sistema de archivos de una computadora es solo una matriz de enteros de 3 canales entre 0 y 255

Nuevamente, esta perspectiva es simplemente errónea.

Un archivo es una secuencia de bytes, pero esos bytes casi nunca son "solo una matriz de enteros de 3 canales entre 0 y 255"

Podrías almacenar una imagen como esa. Algunas herramientas incluso permiten leer y escribir dichos archivos, pero el problema es que significa que debe conocer el archivo antes de poder leerlo. Supongamos que tiene un archivo con un tamaño de 3000 bytes, ¿tiene 1000 píxeles RGB de 24 bits? 3000 píxeles de escala de grises de 8 bits? 3000 píxeles de 8 bits de una paleta? ¿En qué orden están los componentes de color? ¿De qué forma es la imagen? ¿Están los componentes de color en el orden RGB o BGR? A menos que sepa las respuestas a estas preguntas, no podrá leer de manera significativa dicho archivo.

Por lo tanto, los formatos de imagen prácticos generalmente comienzan con uno o más encabezados que identifican el tipo de archivo, las dimensiones de la imagen y cómo se almacenan los datos reales de la imagen. También pueden contener metadatos opcionales.

¿Cuál es el punto de comprimir una imagen en un formato con pérdida como, por ejemplo, JPG? Digamos que el algo de compresión cambia algunos valores de píxeles de 254 a 255 o lo que sea. ¿Entonces? ¿Cómo proporciona eso algún ahorro en el tamaño del archivo o tiene algún impacto en la calidad visual?

Los algoritmos de compresión no solo "cambian los valores", sino que codifican la información de una manera totalmente diferente, por ejemplo, JPEG puede describirse más o menos como

• Convierta los datos de RGB a YUV
• (opcionalmente) reduce la resolución de los canales de croma en un factor de 2 en una o ambas dimensiones
• Divide los datos de cada canal en bloques de 8x8.
• Convierta los bloques al dominio de frecuencia usando una transformada de coseno discreta
• Cuantifique los resultados, preservando la información de baja frecuencia mientras reduce la precisión de la información de alta frecuencia.
• Codifique los números resultantes como una secuencia de bytes utilizando un esquema de codificación de longitud variable (codificación huffman o codificación aritmética)
• Guarde esos bytes en el archivo junto con los encabezados apropiados.

Por otro lado, los formatos comprimidos sin pérdida a menudo se basan en algoritmos de compresión de datos de uso general, pero a veces se complementan con un preprocesamiento específico de la imagen, por ejemplo, PNG.

• Convierta los datos a uno de los formatos compatibles (por ejemplo, un bit cada uno para Rojo, verde y azul en ese orden)
• Para cada línea de la imagen que realice un proceso de "filtrado", existen varias opciones de filtrado (que no incluyen ningún filtrado), pero el objetivo general es tomar la información específica de la imagen que un píxel probablemente sea similar a sus vecinos y codificar de una manera que "desinfle" puede manejar.
• Comprima los datos filtrados utilizando el algoritmo de compresión de propósito general "desinflar".
• Guarde esos bytes en el archivo junto con los encabezados apropiados.

Hay varias razones por las cuales esta suposición es incorrecta, y todas se reducen a una sola cosa:

¿Qué escala estás usando realmente?

Y eso puede desglosarse un poco más:

¿Qué es 255?

El "color" no es una propiedad del universo físico. Es una sensación que surge en la mente. Y eso incluye cosas como "azul", "verde" y "rojo". Una escala de 0 que significa "sin azul en absoluto" a 255 que significa "todo el azul". En realidad, 255 no puede representar el ideal platónico del azul , porque ... no hay tal cosa perfecta en el mundo real. Entonces, significa:

• ¿El tipo más azul que puedes hacer en el dispositivo que tienes delante?
• tan cerca de la combinación ideal con el azul puro desde el punto de vista del sistema de visión humana, incluso si la mayoría de las pantallas y las combinaciones de impresora / tinta / papel no pueden representarlo?
• ¿un azul bastante bueno que probablemente esté razonablemente representado en una amplia variedad de dispositivos?
• un azul que está fuera del alcance de la visión humana, pero que le permite a su cubierta triple RGB la mayoría de los colores que están dentro del alcance.

¿Sonido artificial? ¡No! Estos son en realidad ejemplos reales . Echa un vistazo a estas representaciones de cada opción. El área curva es un corte 2D del espacio de color de la visión humana, y el triángulo muestra el área que puede representarse dada una opción particular para rojo, verde o azul.

Primero, aquí está el perfil de la pantalla de mi computadora portátil, que es bastante representativa de los dispositivos de rango medio actuales:

Ahora, aquí está el espacio Adobe RGB. ¡Observe cuánto más grande es esto de lo que mi pantalla puede mostrar!

Entonces, aquí está sRGB: el espacio estándar y predeterminado de facto generalmente asumido cuando no se especifica nada. Está destinado a ser "lo suficientemente bueno" en la mayoría de las situaciones.

Y finalmente, ProPhoto RGB, que utiliza colores imaginarios como primarios, para hacer que el triángulo sea lo suficientemente grande como para adaptarse a casi toda la visión humana.

Ahora agregue el color de la luz y la adaptación cromática : la capacidad del sistema de visión humana para ajustar la percepción al medio ambiente. De hecho, no es solo habilidad: algo que sucede si lo quieres o no . ¿"Azul puro" significa que la cosa se ve tan azul como posiblemente podría estar bajo esta luz incandescente? ¿Cuál debería ser el valor si en su lugar fotografiamos a la luz del sol?

Entonces "255" puede significar muchas cosas diferentes.

¿Qué es 0?

Esto es bastante simple: ¿qué tan negro necesitas que sea 0? ¿Es vantablack black? Si es así, pero todas las sombras reales en su escena son mucho menos extremas , ¿realmente quiere "desperdiciar" un montón de valores potenciales para un rango dinámico que no está en su escena y que, como el color, puede ¿No te representará ningún dispositivo o impresora a la que tengas acceso?

Cual es tu curva

Entonces, una vez que tiene sus puntos finales, ¿cómo se pasa de uno a otro? La percepción humana del brillo es decididamente no lineal . En su escala 0-255, ¿debería 100 ser el doble de brillante que 50, o debería ser un factor mayor? ¿Debería la diferencia perceptiva entre, digamos, 3 y 4 ser la misma que entre 203 y 204?

Si decide utilizar un sistema de almacenamiento de registros, ¿debe optimizarse esa curva para que coincida con la visión humana, para la optimización de datos o para otra cosa?

Hay muchas posibilidades, para muchas necesidades diferentes.

En compresión

Usted pregunta.

Digamos que el algo de compresión cambia algunos valores de píxeles de 254 a 255 o lo que sea. ¿Entonces? ¿Cómo proporciona eso algún ahorro en el tamaño del archivo o tiene algún impacto en la calidad visual?

Los algoritmos de compresión modernos son más complicados que esto, pero esto proporciona un buen ejemplo. Voy a usar hexadecimal FFpara representar 255 y FErepresentar 254, e imagino que estamos usando la codificación de longitud de ejecución como una forma de compresión. Y por simplicidad, supongamos blanco y negro en lugar de color. Con eso, si tenemos una fila de datos que se ve así:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

podemos comprimir eso a un muy simple

16×FF 

... que es un ahorro bastante obvio. Básicamente podemos almacenar 16 bytes en dos (uno para el recuento, dos para los datos). Pero digamos que tenemos:

FF FF FE FF FE FF FF FF FF FF FE FE FE FF FE FE

Ahora, la codificación de longitud de ejecución nos da:

2×FF 1×FE 1×FF 1×FE 5×FF 3×FE 1×FF 2×FE

... lo cual no supone ningún ahorro, y de hecho podría haber aumentado el tamaño del archivo. Pero si redondeamos todos los FEvalores a FF, volvemos al primer caso, con una reducción de tamaño significativa, con un impacto pequeño pero probablemente difícil de notar en la calidad del archivo.

Por supuesto, ese es un ejemplo trivial y artificial, pero todos los algoritmos de compresión con pérdida comparten este rasgo básico: la pérdida de datos hace que sea más fácil usar un formato de almacenamiento más compacto, con un cambio que, con suerte, no se percibe demasiado .

En profundidad de bits

Además, desde un punto de vista numérico, ¿qué hace que algo como las imágenes de 16 bits sea diferente de las imágenes de 32 bits? Una vez más, una imagen es solo una matriz con valores enteros entre 0-255.

Entonces ... una matriz de valores enteros entre 0-255 es una matriz de ocho bits . (2⁸ = 256.) Con tres canales, esta es una imagen de 24 bits; algunos formatos también tienen un canal de transparencia ("alfa"), para 32 bits. También se puede usar un valor más alto por canal, que generalmente es lo que queremos decir cuando decimos una "profundidad de 16 bits". Eso significa que la matriz va de 0-65535 (2¹⁶ = 65536) en lugar de 0-255. En general, en este esquema, esto es básicamente un multiplicador donde el valor más alto representa lo mismo en cada escala, pero la profundidad de bits más alta da más matices posibles. (Consulte esta respuesta para obtener más información al respecto). También hay algunos formatos de archivo especializados que utilizan flotantes de 64 bits (!) En lugar de enteros para los valores u otros tipos de datos según el caso de uso, pero el concepto básico es el mismo .

No, una imagen no es solo valores RGB en el rango 0-255. Incluso si ignora los formatos de almacenamiento, hay muchas formas de describir el color. Aquí hay unos ejemplos:

• Componentes rojo, verde y azul (RGB)
• Componentes cian, magenta, amarillo y negro (CMYK)
• Matiz, saturación y luminosidad / valor (HSL / HSV)
• La cantidad de luz que golpea un grupo de sensores en una cámara.
• La cantidad de luz y su dirección cuando golpea los sensores (en una cámara de campo de luz )

Los dos primeros son los más utilizados para mostrar en monitores y para imprimir, respectivamente.

Además, una imagen no es solo píxeles, sino también metadatos. Podrían ser cosas como el ancho en número de píxeles, el ancho físico si lo imprimiera, una imagen en miniatura o incluso la ubicación geográfica de la cámara cuando se tomó la imagen.

Su premisa no es incorrecta: cualquier imagen se puede representar usando una matriz N-dimensional de valores finitos. Personalmente, generalizo que usando geometría discreta en lugar de una matriz, pero la esencia es la misma. Pero ese es el contenido, no el archivo.

Sin embargo, los formatos de archivo son diferentes. Básicamente, hay varias formas diferentes de representar esa misma imagen, como las personas mencionadas: bmp, png, jpg, etc. Por supuesto, una vez que las decodifique, dos versiones codificadas sin pérdida de la misma imagen conducirán a las mismas matrices.
Piense en ello como un archivo .txt que comprimió con zip. Con la rareza añadida de que una codificación sin pérdidas devolvería un texto que no es el mismo que el original, pero que está muy cerca, casi como una versión tonta del texto.

Manteniendo la analogía del texto, digamos que tiene el mismo texto, guardado como .txt, .docx, .pdf, etc. ¿Por qué no todos los archivos son exactamente iguales, si el contenido es el mismo? (Ok, txt no tiene formato, pero los otros sí).

Por cierto, mira cómo la codificación de Netpbm es realmente diferente de JPEG .

Para los formatos RAW y TIFF, hasta donde puedo decir, la respuesta (como han dicho otros) es que en realidad no siempre usan los mismos espacios de color (por ejemplo, los archivos RAW pueden usar más bits por píxel, por lo que pueden almacenar información de color más fina) .

Pero para llegar al meollo de su pregunta, a veces hay imágenes que se almacenan en diferentes formatos, pero cada una de ellas representa exactamente el mismo conjunto de números.

Un buen ejemplo de una razón para esto son las diferencias en la compresión entre un archivo PNG y un archivo TIFF.

Los archivos PNG usan un algoritmo de compresión particular. Eso significa que una imagen no solo se almacenará como una gran lista de números para cada píxel. Ejemplo simplificado: puede almacenar algo que dice "en este bloque de 10x10 píxeles, todos los píxeles son de color XYZ". Luego, en lugar de almacenar esa información 100 veces, la almacena una vez, más un poco de información sobre la región a la que se aplica la información.

El problema es recuperar la matriz original de números (que representan colores), para que pueda mostrarla o editarla o lo que sea, necesita un software que sepa cómo interpretar esa información comprimida.

Los archivos PNG siempre usan el mismo algoritmo de compresión, por lo que es fácil para el software admitir todos los archivos PNG válidos. Por otro lado, algunas imágenes tienen una estructura que no se presta al algoritmo de compresión de PNG, por lo que algunos de sus archivos PNG pueden terminar siendo bastante grandes.

Los archivos TIFF, por otro lado, admiten muchos algoritmos de compresión diferentes. De hecho, incluso puede almacenar diferentes partes de la imagen comprimidas de manera diferente. Y es compatible con 'extensiones', por lo que puede comprimir imágenes utilizando formas propietarias. Entonces, tal vez la mitad superior de su imagen se comprimirá utilizando un método similar a PNG, pero esto no comprimirá muy bien la mitad inferior, por lo que la mitad inferior se comprime utilizando un método diferente.

Por lo tanto, los archivos TIFF son más flexibles: es posible que pueda almacenar exactamente la misma matriz de números usando menos bytes. Pero el software necesario para decodificar la imagen será más complicado y podría no funcionar de manera coherente con cada archivo TIFF que le arroje, por ejemplo, puede guardar un archivo TIFF en un software y no poder abrirlo con un software diferente, aunque Todavía funciona en el original.

Entonces preguntas

Pero no estoy preguntando nada más que una imagen RBC básica de 3 canales. Todo lo que sé es que si alguien me entrega uno de estos, ahora tengo una serie de números. No tengo ninguna razón para saber por qué una matriz de números podría ser diferente de otra matriz de números del 0 al 255.

Para dárselo, alguien tenía que saber cómo se almacenaba la imagen y cómo traducirla en una serie de números. (O posiblemente algún software esté haciendo esa traducción por usted sin que usted lo sepa).

Puede intentar guardar una imagen como PNG y nuevamente como TIFF o GIF y mirarla en un visor hexadecimal para ver cómo cada una representa la misma matriz de números de manera diferente. O lea los detalles de cómo los archivos PNG y los archivos TIFF están representados internamente para darle una idea de lo que debe integrarse en el software para leer matrices idénticas de números de manera diferente.

Mapas de bits

Un mapa de bits (BMP) es esencialmente lo que usted describe, una matriz de números que representan colores de píxeles. Por ejemplo, algo como

1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1

Compresión sin perdidas

Ahora, definamos un esquema de compresión. En nuestro esquema de compresión, tendremos una serie de pares de números. P.ej

3, 1, 1, 0, 7, 1

Ahora, lo primero que quiero señalar es que este esquema de compresión representa los mismos píxeles que la primera matriz. La primera matriz tiene tres 1 seguidos de un solo 0 y luego siete 1. Y eso es lo que estamos representando aquí. Este formato es más corto, ya que representa múltiples píxeles con dos números. El formato de mapa de bits tiene que usar un número para cada píxel.

Obviamente, esta es una vista algo simplificada de una imagen (por ejemplo, es solo una fila) y un esquema de compresión. Pero es de esperar que esto le permita ver cómo un esquema de compresión cambia el formato de una imagen. Así es como un GIF se relaciona con un BMP. GIF utiliza un esquema de compresión llamado Lempel-Ziv-Welch en lugar de este simplista.

Lo que hemos descrito aquí es un esquema de compresión sin pérdidas. Un problema con los esquemas de compresión sin pérdida es que, para algunas entradas, la forma codificada puede ser más larga que la original. Por ejemplo para

1, 0, 1, 0, 1

La codificación es

1, 1, 1, 0, 1, 1, 1, 0, 1, 1

Bueno, eso fue inútil. Hicimos la entrada el doble de tiempo.

Otra compresión sin pérdidas.

Ahora, consideremos un esquema de compresión diferente. En este, representaremos la imagen como círculos superpuestos. Para cada círculo, definiremos un centro, un radio y un color.

Nuestro primer mapa de bits se convertiría

5, 5, 1, 3, 0, 0

Esta es la misma longitud que nuestro primer método de compresión.

Y nuestro segundo podría ser

2, 2, 1, 2, 1, 0, 2, 0, 1

Estos son tres círculos centrados en el elemento central (que en el conteo de computadoras es el número 2, ya que las computadoras comienzan a contar en 0). Un círculo tiene radio 2 y color 1. Luego agregamos un círculo de color 0 y radio 1. Finalmente, tenemos un círculo de color 1 y radio 0. En pasos, esto sería

1, 1, 1, 1, 1
1, 0, 0, 0, 1
1, 0, 1, 0, 1

O

2, 2, 1, 1, 0, 0, 3, 0, 0

Este es el mismo círculo inicial pero cubierto por dos círculos de puntos. En pasos, sería

1, 1, 1, 1, 1
1, 0, 1, 1, 1
1, 0, 1, 0, 1

Ambos son uno más corto que la primera versión codificada pero aún más largo que el original.

Quizás se pregunte por qué estoy hablando de círculos y no de rangos. La razón principal es que los círculos están más cerca de lo que usan las imágenes bidimensionales reales.

Compresión con pérdida

También tenemos el concepto de esquemas de compresión con pérdida. Estos esquemas de compresión sin pérdida se pueden volver a convertir en la matriz de mapa de bits original. Los esquemas de compresión con pérdida pueden no ser reversibles.

Consideremos una versión con pérdida de nuestro método de círculos. En esto, usaremos una regla simple. No almacenaremos ningún círculo con un radio inferior a 1. Por lo tanto, en nuestras dos últimas codificaciones, tendríamos

2, 2, 1, 2, 1, 0

y

2, 2, 1

que convertidos a píxeles de nuevo son

1, 0, 0, 0, 1

y

1, 1, 1, 1, 1

La primera versión es solo un elemento más larga que la original. La segunda versión es más corta. Ambos son válidos, por lo que el algoritmo es libre de desarrollar ambos y elegir el más corto.

Describimos imágenes con reglas más restrictivas como de menor calidad.

Esta representación de imágenes como colecciones superpuestas de formas circulares es similar a cómo funciona el Joint JPEG Photographic Experts Group o el formato JPEG . Sus formas son elipses en lugar de círculos, pero la idea es similar. En lugar de nuestro método simplista, utiliza la transformada discreta del coseno para codificar imágenes.

A diferencia de GIF, JPEG es en realidad una forma diferente de representar la imagen. GIF sigue siendo píxeles. Simplemente se almacenan de una manera diferente. JPEG es formas. Para ver un JPEG, luego convertimos las formas en píxeles porque así es como funcionan las pantallas. En teoría, podríamos desarrollar una pantalla que no funcionara de esta manera. En lugar de píxeles, podría producir formas para que coincida mejor con el formato JPEG. Por supuesto, esa pantalla no podría mostrar mapas de bits. Para mostrar un BMP o GIF, tendríamos que convertir a JPEG.

Si convierte un GIF estándar, digamos 300x300 píxeles, conviértalo en JPEG y reduzca la calidad, las formas de base que usa deben ser visibles. Muchos archivos JPEG evitan estos artefactos comenzando con una imagen de resolución mucho más alta.

Los JPEG escalan bien porque son formas en lugar de píxeles. Entonces, si comienza con una imagen de 8000x8000, la convierte a JPEG y la muestra como una imagen de 300x300, gran parte del detalle que se perdió se habría perdido de todos modos. Si convirtió el mapa de bits de 8000x8000 a un mapa de bits de 300x300 primero y luego a JPEG, los resultados a menudo serán de menor calidad.

MPEG

Hemos estado hablando de imágenes fijas. El formato Grupo de expertos en imágenes en movimiento o MPEG utiliza el mismo tipo de compresión que JPEG, pero también hace algo más. Si bien una forma simple de hacer videos es enviar una secuencia de imágenes fijas, MPEG en realidad envía un cuadro, seguido de cierto número de cuadros que enumeran los cambios, y termina con un cuadro final. Debido a que la mayoría de los cuadros son similares al cuadro anterior, la lista de cambios a menudo es más pequeña de lo que sería una segunda imagen.

La secuencia normalmente no es tan larga, digamos cinco cuadros. Pero ayuda a hacer que la transmisión sea más pequeña de lo que sería.

Simplificaciones

He ignorado mucho Mis imágenes solo tienen dos colores (1 bit), no el 256 de una imagen de 8 bits y ciertamente no el 4,294,967,296 de una imagen de 32 bits. Incluso con imágenes de 8 bits, tenga en cuenta que a menudo puede elegir diferentes paletas para la imagen. Por lo tanto, dos mapas de bits de 8 bits con las mismas secuencias pueden representar imágenes que se ven diferentes (misma forma pero diferentes colores).

Mis imágenes son filas individuales, no bidimensionales. La mayoría de las imágenes tendrán un tamaño de fila específico almacenado, haciendo que las matrices sean bidimensionales.

No he tratado de representar las codificaciones reales en absoluto. Son mucho más complejos que los simples que usé. Hice esto porque quería poder describir las codificaciones en esta publicación. No estoy convencido de que pueda explicar Lempel-Ziv mucho menos el refinamiento más complejo de Lempel-Ziv-Welch en una sola respuesta. Y no entiendo las transformadas de Fourier lo suficientemente bien como para explicarlas en detalle.

Esta es una versión simplificada del manejo real de imágenes. Sin embargo, creo que para fines didácticos, es más fácil de entender que la realidad más compleja mientras se alcanzan los puntos esenciales.

Digamos que era cierto, que cada píxel tenía solo tres números (rojo, verde y azul) cada uno en el rango de 0-255. Otros respondedores han comenzado desafiando (correctamente) esa suposición, pero por simplicidad digamos que es verdad.

Recuerdo (pero lamentablemente no puedo encontrar en línea) una caricatura de un libro de texto de lingüística: dos antiguos talladores de piedra egipcios están sentados exhaustos en la parte inferior de una pared masiva en la que han tallado una gran cantidad de figuras en marcha. Uno le dice al otro: "Seguramente debe haber una manera más fácil de escribir, '¿El faraón tenía 100,000 soldados?'". Ten esa idea en mente.

Ahora, suponga que la primera fila de su imagen contiene 1800 píxeles negros. ¿Cómo se representaría eso?

0 0 0    0 0 0     0 0 0   ....

Entonces, ¿cuánto espacio de almacenamiento requeriría eso? Cada valor es un byte. Tres bytes por píxel, 1800 píxeles en la fila, por lo que ya 5400 bytes por fila. Por lo tanto, una imagen con dimensiones de 1800 x 1200 debe ocupar 1200 veces más, que es más de 6 megabytes. Así que ahora vamos a buscar imágenes en Google y descargar un par de imágenes de 1800x1200, digamos, una .pngimagen y una .jpgimagen. Mira el tamaño del archivo: ¿son 6 MB? De ninguna manera, generalmente es mucho más pequeño que eso. Y eso es algo deseable, por supuesto, todo ese espacio ahorrado y un tiempo de descarga más corto ...

Entonces, ¿qué está pasando? La clave es que, incluso si tiene tantos números para almacenar, hay diferentes formas de representaresos números en el archivo. Hay un ejemplo de una representación más eficiente aquí en mi respuesta, hace dos párrafos. Escribí las palabras "1800 píxeles negros". Son 17 caracteres, por lo que no necesita ocupar más de 17 bytes, sin embargo, describe perfectamente la misma información para la que pensamos que necesitábamos 5400 bytes. Y ciertamente podría obtener mejores resultados que 17 bytes (y también ahorrar mucho esfuerzo en la implementación de codificación / decodificación) si no usara el idioma inglés para codificar esta información, sino más bien un lenguaje de propósito especial. Así que ahora, ya hemos postulado más de un formato de compresión de imagen: uno que usa palabras en inglés y otro que es más eficiente que eso. ¿Ves a dónde va esto?

Bien, dices, eso funciona si un montón de píxeles adyacentes tiene el mismo color. Pero, ¿y si no lo hacen? Bueno, claro, depende del contenido de la imagen en particular: cuanta más redundancia haya, más fácil será comprimir la información. La redundancia significa que partes de la imagen se pueden predecir bastante bien si ya conoce otras partes. La compresión significa solo escribir el mínimo necesario para reconstruir la información. No todas las imágenes posibles tienen redundancia, pero cualquier imagen real que tenga significado para el ojo humano y el cerebro, a pesar de ser más compleja que mi ejemplo en negro puro, seguirá tendiendo bastante redundancia. Y hay muchas formas diferentes de comprimir. Algunos métodos de compresión son sin pérdidas., lo que significa que la información se puede reconstruir para que sea matemáticamente idéntica a la original, como en mi ejemplo de fila negra de píxeles. La mayoría de los .pngarchivos utilizan un método de compresión sin pérdidas. Algunos métodos son con pérdida : la reconstrucción no es perfecta, pero los errores están ocultos de manera tal que el ojo humano y el cerebro apenas los notan. La mayoría de los .jpgarchivos son con pérdida.

Los detalles de cómo reconoce patrones complicados de redundancia, y cómo escribe descripciones comprimidas eficientes de ellos, son altamente matemáticos y no triviales, por lo que hay espacio para tantos formatos diferentes, correspondientes a diferentes estrategias de compresión. Pero espero que entiendas el principio.

Un par de comentaristas anteriores han hecho suposiciones razonables sobre dónde podría haber surgido su error. En su pregunta, parece pensar que la compresión solo cambia un poco los valores de los píxeles (y seguro, los métodos de compresión con pérdida lo hacen en algunos lugares, pero solo como un efecto secundario no deseado) sin cambiar el diseño de la información. Cuando abre el archivo y mira el contenido de la imagen (por ejemplo, como una matriz de números en Matlab o como una imagen en pantalla en Photoshop) no está mirando el contenido del archivo comprimido, sino más bien la reconstrucción, que tiene el mismo diseño que el original (no sería una gran reconstrucción si no recreara el diseño correctamente). El procedimiento de apertura de archivos ha descomprimido la información del archivo en una representación completa sin comprimir en la memoria. Si compara dos reconstrucciones sin comprimir , entonces no hay nada que distinga entre los dos formatos de imagen diferentes de los que provienen (excepto los errores de reconstrucción, si los hay).

Sí, pero cómo llegas a esos 1s y 0s es muy diferente.

Presentaré un ejemplo, pero es falso y se supone que ilustra más que ser preciso. Tenga en cuenta que todas las imágenes digitales se representan en binario en algún nivel.

Para complicar las cosas, hay diferentes canales. CMYK, RGB, B & W, solo por nombrar algunos. No vamos a entrar en eso. También hay diferentes etapas, como captura, almacenamiento y visualización. Vamos a entrar en eso, aunque nuevamente se supone que el ejemplo demuestra que no es exacto. Si desea ejemplos precisos, deberá buscar una tonelada de documentos técnicos.

Entonces, en nuestra muestra, vamos a ver una imagen en blanco y negro.

00067000
00067000
00567800
04056090
40056009

Los números representan lo fuerte que es el "negro". Así es como la cámara capturó la imagen. Es una cámara decente, así que también es cómo almacena la imagen.

Ahora almacena la imagen en una computadora, pero ocupa mucho espacio, así que vamos a comprimirla. Además de mezclarlo, también sabemos que la mayoría de las personas no pueden detectar una diferencia de 1 nivel de negro, por lo que vamos a suavizarlo un poco.

302730
302730
204820
*04056090
1420262019

Ahora así es como almacenamos la imagen en el disco. Ocupa menos espacio y nos permite producir gran parte de la imagen original.

Ahora digamos que queremos imprimirlo en una impresora. La impresora solo imprime un nivel de negro, por lo que una computadora traduce la imagen comprimida almacenada en la impresora hablada.

00011000
00011000
00111100
01011010
10011001

Esto imprime una imagen de aspecto razonable, pero puede ver, incluso en el ejemplo, una extrema falta de calidad. Pero bueno, es culpa de la impresora.

Finalmente, va a imprimir la imagen en una buena impresora con 10 niveles de negro. Igual que tu cámara. Entonces usas la imagen almacenada y comprimida.

00077000
00077000
00888800
04056090
40066009

Como puede ver, la imagen es "mejor" pero ha sido alterada un poco del original.

En cualquier momento está en lo cierto, es que todo es solo la fuerza de un canal. Y aparte de la imagen comprimida, que tiene que descomprimirse de todos modos, se mantiene bastante fiel a eso.

Sin embargo, el formato comprimido pierde mucha "información". ¿Es importante esa información? Bueno, eso depende del artista y la audiencia. Hay varias compensaciones entre ahorrar espacio, tiempo de procesamiento, calidad de la imagen final / almacenada y necesidad. Escaneo la mayoría de mis documentos en un color negro porque eso es todo lo que necesito. Sin embargo, las fotos de mi boda están en formato ENORME SIN PROCESAR porque nunca sé cuándo voy a querer una buena reimpresión de ellas. Dicho esto, cuando las transfiero (fotos) a un marco digital, las convierto a JPEG para ahorrar espacio. Diferentes canales, diferentes filtros y diferentes métodos de compresión son una serie de compensaciones. Es como una versión digital del triángulo de impresoras.

Voy a intervenir con un poco de información complementaria ya que he trabajado con la detección de imágenes y la codificación / compresión, aunque principalmente imágenes en movimiento.

En su forma básica, una imagen (CUALQUIER imagen) mostrada en una pantalla en particular ES de hecho una matriz idéntica de números. Esos números pueden ser todos 0-255 o 0-65535 o 0-lo que sea-32-bits-es-me-olvidé-vaya-google-it.

PERO hay tantas maneras de ALMACENAR y TRANSPORTAR esa información, muchas de ellas son simplemente productos de tecnologías perdidas por las brumas del tiempo.

Además, un detalle que no he visto ninguno de los otros pedantes aquí mencionados es que los datos del sensor de imagen realmente RAW de una cámara digital pueden ser RGrGbB en un patrón bayer o algo que necesita ser procesado al menos un poco para hacer cualquier sentido para el globo ocular humano Mk.1. Lo más probable es que nunca consigas eso incluso en un formato RAW guardado por tu DSLR porque es inútil hasta que lo conviertas en una buena cuadrícula de píxeles RGB o YUV, ya sean de 8, 16, 32 o once mil millones de bits de profundidad.

Las cosas en las que he trabajado usan YUV internamente por cualquier razón, supongo que los códecs las procesan más fácilmente ya que los humanos perciben el brillo con mucha más sensibilidad que el color.

Para leer un poco sobre la hora de acostarse, consulte la sección "formato de imagen de cuadro": http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

De todos modos ... volvamos a su pregunta original sobre la diferencia entre archivos de imagen sin comprimir como TIFF / RAW / IFF / PNG.

Generalmente, la razón por la que existen es que, hace muchas lunas, cada fabricante de computadoras / SO / impresoras presentó sus propios requisitos ligeramente diferentes para alguna forma de almacenar / enviar imágenes.

Por lo tanto, RAW, como lo comentaron otros en este hilo, es un término genérico para varias cosas diferentes guardadas por diferentes cámaras digitales, utilizando cualquier carga de datos que el fabricante de la cámara considera importante, en función de las características que su cámara tenga o pueda tener en el futuro. Entonces, aunque el bit de datos de la imagen principal puede ser muy similar, el "empaque" a su alrededor que describe la imagen y todos los ajustes de la cámara, etc., por lo que un fabricante diferente no entendería un archivo.

Tradicionalmente, esto es para que puedan hacer que usted (o, más probablemente, los fotógrafos profesionales) usen su software patentado (y a veces costoso) para procesar estas imágenes de mayor calidad, de lo contrario, podría comenzar a usar el software costoso de otras personas. Además, tal vez Adobe Photoshop quiera admitir su formato, por lo que tal vez puedan cobrar a Adobe $$$ por esa información para que más fotógrafos profesionales compren PS y tal vez compren esa marca de cámara porque PS lo admite ahora. ¡Acogedor!

RAW también almacena información sobre cómo convertir ese paquete particular de datos nuevamente en una imagen visible para el ser humano, simplemente ponga todos los ajustes que necesita para que los datos hagan que la imagen se vea "correcta".

TIFF era un formato de imagen inicial que, entre otras cosas, se usaba para enviar datos gráficos a las impresoras (cuando las impresoras con capacidad de gráficos comenzaron a ser asequibles). Era bastante básico, muy fácil de procesar en el pequeño microprocesador barato dentro de la impresora.

IFF (sí, eso es una cosa) era un formato similar utilizado en las computadoras Amiga, creo que inventado por ellos o uno de los paquetes de pintura populares. Pero, lo estoy usando aquí como un ejemplo porque, aunque almacena datos de imágenes de mapas de bits como los otros, admite datos sin comprimir o RLE, profundidades de bits variables desde mono de 1 bit a 256 colores de 8 bits (pero con una paleta RGB de 3x8 bits para elegir para cada uno de los colores), así como modos especiales llamados medios tonos y mantener y modificar que permiten muchos más colores que otras máquinas de la época podrían manejar. Ah, y también admitía animación (como GIF) para que un archivo IFF pudiera almacenar cualquier número de cuadros, con retrasos variables entre cuadros, y cada cuadro podría tener su propia paleta. Entonces, IFF incluiría datos adicionales para manejar todo esto en comparación con, por ejemplo, un archivo TIFF.

PNG es otro formato de imagen sin pérdida, que nuevamente almacena datos de mapa de bits, pero admite algunas funciones originales como un canal alfa de 8 bits para una transparencia variable en una imagen (útil en páginas web), por lo que nuevamente la "carga útil" de datos de imagen puede ser muy similar pero la envoltura a su alrededor es diferente, y la carga útil puede contener RGBA en lugar de solo datos RGB por píxel.

Entonces, se describen 4 formatos de archivo de imagen diferentes: puede almacenar una muestra de una imagen en alta definición a todo color de un gato en cualquiera de los 4 y se verá idéntico, cada píxel en su pantalla tendrá el mismo valor EXACTO y no habrá diferencia en la calidad entre los 4 ... pero los 4 archivos probablemente serían diferentes en tamaño, diseño y serían más fáciles o más difíciles de cargar y procesar para el software.

¡Espero que ayude!

Solo pensé en intervenir aquí con la información que debería haber estado en la primera respuesta a esta pregunta.

Los píxeles de una imagen no se almacenan en un byte, a menos que la imagen sea monocromática, es decir, solo en blanco y negro.

Si tiene una imagen en color verdadero, cada píxel está representado por 16 bits, o 2 bytes, como un valor. Si tiene una imagen de 32 bits, cada píxel requiere 32 bits o 4 bytes, nuevamente como un solo valor.

Curiosamente, los archivos de imagen y sonido y cualquier otro tipo de datos en una computadora se reduce a bits de 1s y 0's. Es solo interpretándolos en los trozos del tamaño correcto que se les extrae el significado.

Por ejemplo, una imagen y un documento de Word y un archivo mp3 tienen el mismo contenido de datos básicos (un montón de bytes), y cualquiera de ellos podría interpretarse como uno de los otros tipos; podría interpretar un documento de Word como un sonido archivo y escucharías algo, pero no sería música. Definitivamente podría interpretar un archivo de sonido como una imagen, y mostraría algo, pero no sería una imagen coherente.

Entonces, para resumir, una computadora solo sabe acerca de bits: un bit es 1 o 0. Todas las imágenes, sonidos, documentos, películas, videos, grabaciones, juegos, llamadas telefónicas, mensajes de texto y cualquier otra cosa etiquetada como digital tienen exactamente el mismo contenido: un montón de 1 y 0. Los 1 y 0 se convierten en imágenes, sonidos y documentos y todo lo demás porque el código que los lee sabe leer esos bits en grupos y procesarlos en consecuencia.

Es por eso que tenemos cosas como imágenes de 16 bits y 32 bits, y archivos de audio de 16 bits y 24 bits. Cuantos más bits use para un píxel o una muestra de sonido, más expresivo podrá ser: 16 bits solo pueden definir 64k colores únicos, pero 32 bits pueden definir más de 4 millones de colores únicos. Una imagen monocromática utiliza 1 bit por píxel: está activada o desactivada.

Con los archivos de audio, cuantos más bits use por muestra, más detallada y matizada será la grabación.

No he leído todo el hilo, pero me parece que muchas personas se están olvidando de los formatos de imagen vectorizados. Esos no son conjuntos de píxeles, porque el concepto de píxel ni siquiera existe en ese formato. Depende del renderizador descubrir cómo producir la imagen en una pantalla o en cualquier otro medio.

Incluso sin mencionar dominios de color, compresión, tamaños de bits y formato de canal, hay un conjunto de formatos de archivo que son totalmente diferentes a los mapas de píxeles. Y, sin embargo, los formatos vectoriales también son mucho "mejores" para representar ciertos tipos de imágenes, típicamente producidas por una computadora y no por una cámara.

Esta pregunta fue respondida bastante detallada antes. Sin embargo, a pesar de que hay mucha teoría presentada en las respuestas, creo que hay algunos temas básicos, generalmente relacionados con la programación de computadoras que requieren más aclaraciones. Debo decir que soy ingeniero de software. Después de leer la pregunta, me di cuenta de que hay un malentendido completo de los tipos de datos de programación básicos que generaron esta pregunta.

La primera pregunta aquí es:

Además, desde un punto de vista numérico, ¿qué hace que algo como las imágenes de 16 bits sea diferente de las imágenes de 32 bits? Una vez más, una imagen es solo una matriz con valores enteros entre 0 y 255.

Como se presentó antes: No, no lo es. Una imagen no es solo una matriz de valores enteros entre 0-255. En realidad, puede ser una matriz única o multidimensional de 0 a 65535 valores, una matriz de 0 a 4294967295 o incluso una matriz de bits (un bit puede contener 0 o 1 valores, eso es todo) que el software puede convertir lea los archivos de imagen en números enteros de acuerdo con varias reglas de codificación.

Para comprender esto más a fondo, como se indicó anteriormente, creo que es necesario un debate sobre los tipos de datos de programación básicos. Trataré de explicarlos lo más simple posible para que cualquiera entienda los problemas relacionados con el almacenamiento de valores enteros en los archivos de las computadoras.

En la programación de computadoras usamos algunos tipos básicos de datos primitivos para escribir valores en archivos, leerlos de archivos en la memoria de la computadora, manipular esos valores usando varios tipos de datos de lenguajes de programación específicos y eventualmente guardarlos nuevamente en archivos. Los enteros en la programación de computadoras no son solo enteros. Hay todo tipo de enteros, depende del lenguaje de programación que estemos usando y cuánta memoria necesitemos para cada uno. Por lo general, en la mayoría de los lenguajes de programación tenemos los siguientes tipos de datos (y formas de manipularlos):

• BIT - manteniendo 0 o 1
• UINT8: entero de 8 bits sin signo: pueden contener valores entre [0 a 255] intervalos.
• INT8: entero con signo de 8 bits: pueden contener valores entre [-126 a 127] intervalos.
• UINT16 - Entero sin signo de 16 bits: pueden contener valores entre [0 a 65535] intervalo.
• INT16 - Entero sin signo de 16 bits: pueden contener valores entre [−32768 a 32767] intervalo.
• UINT32 - Entero sin signo de 32 bits: pueden contener valores entre [0 a 4294967295] intervalo.
• INT32 - Entero sin signo de 32 bits: pueden contener valores entre el intervalo [−2147483648 a 2147483647].
• O una combinación de todos esos tipos de datos en un formato más complejo. Por ejemplo, un UINT16 (16 BIT) con 3 valores diferentes, los primeros 4 BIT con valores entre 0 y 127, el siguiente BIT con 0 o 1 y así sucesivamente.

Además, hay algo que los programadores tienen que resolver cuando leen o escriben tipos de datos enteros de archivos. El endianess.Endianness se refiere al orden secuencial en el que los bytes (UINT8 de nuestra tabla) se organizan en valores numéricos más grandes cuando se almacenan en la memoria o en los archivos. Endianness es de interés en informática porque dos formatos conflictivos e incompatibles son de uso común: los valores pueden representarse en formato big-endian o little-endian, dependiendo de si los bits o bytes u otros componentes se ordenan desde el extremo grande (lo más significativo bit) o ​​el pequeño final (bit menos significativo). En pocas palabras, puede almacenar un valor como este 0000000011011111 o ... como este 1101111100000000 dependiendo del orden endian que elija. Y usted es libre de elegir cualquier orden que se ajuste a su propósito. No hay otras reglas que las que haces cuando diseñas un formato de archivo de imagen.

Tenga en cuenta que en la programación de la computadora los enteros están usando más o menos espacio, depende del valor. Al igual que necesita más papel para escribir 255255255, necesita más BIT para escribir un valor mayor. Luego, cuando desee leer el valor, debe conocer exactamente las reglas que creó cuando lo escribió. De lo contrario, es imposible para usted saber cómo leer solo una matriz con valores enteros entre 0 y 255 porque simplemente no sabe dónde se almacenan esos números y cómo se almacenan esos números dada la cantidad de opciones que tiene (BIT, UINT8 , UINT16, UINT32 o una combinación de todos esos tipos de datos de computadora). Y no lo olvides, Endianness. Si no sabe que los datos se escribieron utilizando el orden big-endian o little-endian, no podrá leer el valor adecuado.

Debido a esto, las imágenes NUNCA son solo una matriz con valores enteros entre 0 y 255. Algunas de ellas son matrices de UINT16 (imágenes de 16 bits), otras son matrices de UINT32 (imágenes de 32 bits) u otras son matrices de UINT8 (imágenes de 8 bits). Algún programador informático muy creativo puede incluso usar tipos con signo que le brindan conjuntos de INT8, lo que significa un conjunto de valores entre -126 y 127.

En realidad, cuando lee un archivo de imagen, uno de los primeros datos que encuentra es generalmente algunos BIT que representan el ancho y la altura de la imagen. Y esos no son solo algunos valores de 0-255. Esos también son algunos tipos de datos elegidos por el programador. Algunos programadores pensarán que 16 BIT son suficientes para almacenar un ancho de imagen máximo de 65535 píxeles, porque están diseñando un formato de imagen utilizado en un juego para mantener algunas imágenes de botones pequeños. Algún otro programador puede usar un valor de 32 bits aquí, lo que le permite almacenar imágenes de hasta 4294967295 de ancho. Algunos programadores locos de la NASA pueden incluso usar 64 bits para almacenar una gran foto de la galaxia de hasta 18446744073709551615 píxeles.Si no conoce las reglas, no puede leer esos "valores" como los llama. Porque no sabes dónde comienzan en el archivo de imagen y dónde terminan. Entonces terminas con un montón de BITs de los que no entiendes nada.

Es por eso que el universo está lleno de tantos formatos de imágenes diferentes. Porque no hay una solución estándar para escribir algunos valores enteros en un archivo. Es la elección del programador basada completamente en muchos factores como el Endianess de la máquina en la que está trabajando, el lenguaje de programación que está utilizando para diseñar la implementación del formato de archivo original y muchas otras cosas como el propósito del formato de imagen (como se indicó claramente anteriormente por Otras respuestas).

Un formato de archivo práctico y simple de una imagen en blanco y negro que tiene un solo valor 166 para representar una imagen de 4x2 píxeles:

La imagen (1 - píxel negro, 0 - píxel blanco):

1010 
0110

Este formato de archivo utiliza 1 BIT por PIXEL almacenado como un valor entero INDIVIDUAL de 8 bits 166 (10100110). Eso es todo. No se utiliza una matriz de 0-255 valores, sino 8 valores diferentes de 0 o 1 almacenados como valor 166.

Si utilizó una matriz de valores 0-255 para cada píxel * 3 veces para RGB, terminará con una imagen 24 veces más grande. Este formato de archivo acaba de guardar 24 veces el espacio en disco que necesita para guardar una imagen como esta o 24 veces menos la memoria de la computadora necesaria para leer y mantener esta imagen en la RAM de la computadora cuando usa esta imagen, por ejemplo, en su motor de juegos 3D de alto rendimiento para dibuje algo en la pantalla con él (texturizar miles de partículas de polvo volando podría ser un buen candidato :)).