¿Cómo comprimir datos RAW RGB de 10 bits?

Esto puede parecer una pregunta general, sin embargo, no pude encontrar una respuesta. Específicamente, estoy usando un sensor de imagen CMOS que tiene las siguientes capacidades generales:

  • Tamaño de matriz: 1280 x 1024 (SXGA), también puede tomar 640 x 480 (VGA)
  • Formatos de salida (10 bits): datos RGB sin procesar

Cuando tomo un SXGA (1280 x 870), almaceno el archivo (pragmáticamente) con una extensión .RAW. El tamaño del archivo es de unos 1000 KB. Cuando tomo un VGA (640 x 480) el tamaño es de unos 300 KB.

¿Ya se consideran como "comprimidos"? ¿Es posible comprimirlos a un tamaño más pequeño (tal vez tanto tiff sin pérdida como jpeg con pérdida)?

Hasta ahora, estoy convencido de que las imágenes que estoy tomando no tienen un formato específico y se consideran mapa de bits sin procesar . ¿Me equivoco?

Las referencias para lograr mi objetivo son muy apreciadas.

¿Cuál es su objetivo general? ¿Se analizarán científicamente los datos de la imagen o se utilizarán únicamente con fines de visualización? Como indicó en otro comentario, el tiempo de transferencia no es esencial en un entorno de ancho de banda limitado, por lo que es posible que desee ser más claro al respecto.
Ambos. Por lo tanto, no necesita ser 100% de resolución o definición. Busco una buena calidad con tiempo de transferencia reducido, estoy tratando de equilibrar entre ambos.
Simplemente comprima los archivos.
La compresión sin pérdida de datos generales es posible a través de zip y muchas otras rutinas. La cantidad de compresión posible depende de la entropía presente en los datos. Dado que tiene conocimiento adicional: que los datos son una imagen (¿color?), Eso puede ayudar a encontrar una codificación sin pérdidas más óptima. Tiff ofrece compresión zip (y posiblemente otras, ya que es un formato extensible abierto). jpeg2000 y otros formatos, ofrecen compresión de imágenes sin pérdida que puede funcionar mejor que zip
FWIW, la clase de archivos de "mapa de bits sin formato" a la que se refiere su enlace es diferente de las imágenes "RAW" que se analizan en este sitio. Un sensor de imagen en color de un solo chip no registra valores RGB para cada píxel. Registra solo rojo para algunos píxeles, solo verde para algunos y solo azul para otros. Una imagen RAW de una cámara no contiene nada más que esos valores de píxeles individuales de un solo color. El proceso de convertir eso en una imagen RGB se llama "desmosaicing". Creo que la cámara que estás usando hace la demostración por ti y luego te da la imagen RGB como un "mapa de bits sin procesar".
@SolomonSlow No creo que haga la demostración porque cuando lo convierto a JPEG usando MATLAB aparece gris, pero cuando hago una demostración y luego lo convierto se vuelve colorido
¡Ups! En realidad no leí la hoja de datos. Me basaba en el hecho de que hablaste de obtener imágenes de diferentes tamaños de la cámara. Eso a menudo significa una salida de demostración, pero según la hoja de datos, incluso las imágenes de menor tamaño de esa cámara realmente están en formato RAW.
@Sarahcartenz ¿Qué está usando para conectarse y extraer datos del sensor? ¿Qué estás fotografiando? ¿ Cuál es tu "objetivo"?
@SolomonSlow Es más complejo que eso. Los filtros "rojos" dejan pasar un poco de luz verde y azul y viceversa. Todo se mide como un único valor de brillo. El color de los filtros "rojos" rara vez, o nunca, es del mismo color que "Rojo" en nuestros dispositivos de salida RGB. Lo mismo para "G" y "B".
@xiota técnicamente, estoy usando una cámara que usa un microcontrolador PIC y un búfer de memoria para obtener los datos de imagen del sensor descrito anteriormente. Luego uso la comunicación UART para obtener la imagen en mi sistema de archivos a través de un búfer. Mi objetivo es comprimir estos datos RAW para poder transmitirlos a través del aire. ¿Responde esto a la pregunta?
@MichaelC, no tenía intención de abrir una discusión sobre las matemáticas de la demostración. Solo quería llamar la atención sobre el hecho de que cada píxel de un archivo RAW tiene solo un valor que representa uno de los tres valores de color posibles, mientras que un archivo de imagen en color más típico tiene (o puede decodificarse para producir) tres valores de color por píxel.
@xiota Estoy fotografiando la naturaleza, el propósito es para mostrar, sin más procesamiento, solo para ver.
@SolomonSlow Pero el punto muy importante es que los datos sin procesar no tienen valores de color. Solo tiene valores de brillo. Cada "pozo de píxeles" registra valores de brillo de una amplia gama de longitudes de onda. Las longitudes de onda permitidas a través de cada filtro de color se superponen significativamente con las longitudes de onda permitidas a través de los otros dos filtros, al igual que las longitudes de onda a las que son sensibles cada tipo de conos en nuestras retinas. Dado que los colores de los filtros no coinciden con los colores de nuestros sistemas de reproducción cromática, los tres valores deben interpolarse.
Decir que los píxeles filtrados "verdes" registran un valor de brillo solo para "verde" es fundamentalmente incorrecto.
@MichaelC, no dije eso.
@SolomonSlow Usted dijo: "Un sensor de imagen en color de un solo chip no registra valores RGB para cada píxel. Registra solo rojo para algunos píxeles, solo verde para algunos y solo azul para otros. Una imagen RAW de una cámara no contiene nada sino esos valores individuales de píxel de un solo color". Eso es fundamentalmente incorrecto. Cada sensel registra un valor de luminancia que incluye algo de luz de las tres bandas. Pero cada sensel responde mejor a la luz más cercana al color del filtro que lo cubre. El color de esos filtros no coincide con las longitudes de onda de la luz que usamos en nuestra reproducción de color...
... sistemas para cada uno de los subpíxeles "R", "G" y "B" emitidos para cada píxel RGB en la salida.
@MichaelC, diría "simplista" en lugar de "fundamentalmente incorrecto". No tenía intención de abrir una discusión sobre las matemáticas de la demostración. Solo quería llamar la atención sobre la diferencia estructural entre una imagen RAW y una imagen "normal". No quería entrar en detalles que probablemente no ayudarían a responder la pregunta original del OP sobre cómo comprimir datos RAW.
La "diferencia estructural" entre los datos del sensor sin procesar y una imagen en color es que los datos sin procesar contienen solo valores de luminancia monocromáticos para cada sensor. Esto es fundamentalmente diferente de cualquier formulario de salida que incluya valores para múltiples colores para cada píxel en la imagen resultante. Inferir que los datos de imagen sin procesar contienen cualquier valor de color a un nivel de "píxel" (la salida medida de un solo sensor en el sensor) es muy engañoso y por qué muchos ni siquiera comienzan a comprender qué información contiene un archivo sin procesar, así como qué no contiene. No se necesitan matemáticas para entender esto.

Respuestas (1)

1280 * 1024 * 10/8 = 1638400 bytes.
640 * 480 * 10 / 8 = 384000.

Cualquier cosa más pequeña que eso debe ser comprimida. Específicamente, si ve diferentes tamaños de archivo según el contenido de la imagen, sabe que se está produciendo algo de compresión.

Pero realmente, si quieres hacer algo con los datos, tienes que conocer el formato de la imagen de todos modos y si sabes cómo decodificarla, sabrás si está comprimida o no.

Una vez que tenga la imagen decodificada, puede almacenarla en cualquier otro formato que desee, ya sea TIFF o JPEG.

Por supuesto, también puede intentar comprimir los archivos sin formato.

La razón por la que debe comprimirse a un tamaño más pequeño es porque una vez que se almacena en un archivo RAW, debe transmitirse por aire con un ancho de banda limitado, el resto del procesamiento se realizará en la parte del receptor. Un tamaño más pequeño le permitirá transferir en un tiempo más corto donde el tiempo es esencial en esta aplicación. ¿Hay alguna forma en que pueda comprimir sin decodificar?
como dije, ciérralo. (o cualquier otro tipo de algoritmo de compresión de propósito general). por definición, no puede aplicar algoritmos específicos de imagen sin obtener primero una imagen, es decir. descodificación.
No puede comprimir un archivo de imagen como lo hace con un archivo de texto. Simplemente no funciona de esa manera.
@ths si quiere decir "decodificarlo" como si lo estuviera viendo, entonces puedo decodificarlo en un archivo BMP. ¿Está diciendo ahora que su BMP puedo comprimirlo en algo más pequeño (como JPEG)? Pero como RAW solo puedo comprimirlo, ¿correcto?
Así que no estamos hablando de un archivo RAW de cámara, estamos hablando de datos directamente desde un chip de imágenes. En cuyo caso, esto no pertenece aquí, pertenece al desbordamiento de pila. Esto va mucho más allá de la "fotografía" y del procesamiento de datos.
bien. pero convertirlo a un JPEG con pérdida no es comprimir per se; está alterando los datos de la imagen real.
Acabo de descubrir que la función (imwrite) en mathlab toma una matriz de imágenes como la mía y la convierte a JPEG, lo que reduce el tamaño. Esto significa que no necesito ZIP directamente como se describe. Sin embargo, esto es un poco confuso. mathworks.com/help/matlab/ref/imwrite.html
@Sarahcartenz Tenga en cuenta que convertir su archivo sin procesar a JPEG es una operación con pérdida, tanto en la conversión como porque JPEG en sí usa un algoritmo de compresión con pérdida. Eso puede o no estar bien para su propósito.
tenga en cuenta que una imagen en bruto de ~300 KB para una cámara a color de 640x480 significa que también necesita un paso de demostración antes de la compresión jpeg; de lo contrario, estaría comprimiendo el patrón bayer en escala de grises, que es lo menos sensato que puede hacer con jpeg
Pregunta rápida, si uso una compresión sin pérdidas como zip y durante la transmisión algunos de los datos se pierden o se invierten algunos bits, ¿se puede descomprimir con éxito?
¿Cómo comprimir datos RAW RGB de 10 bits?
RespuestasAquíPolítica de privacidad1y, 0v