Si la compresión sin pérdida es completamente reversible, ¿por qué no omitimos un paso y solo usamos los archivos en su estado comprimido?

El problema es que, si bien el archivo comprimido tiene la misma información, no tiene una forma fácil de trabajar. Por lo tanto, podríamos operar en él, excepto que tendríamos que hacer un poco de trabajo extra en cada paso, lo que rápidamente agrega más trabajo que simplemente descomprimirlo en primer lugar.

Por ejemplo, con una gran cantidad de datos, necesitamos poder saltar rápidamente. En una forma sin comprimir, podemos saltar directamente a la parte del archivo que necesitamos, ya que está almacenado en la memoria contigua. Una forma razonable de comprimir un archivo como ese implicaría eliminar secciones repetidas y crear un índice en ellas, que mueva todo el contenido del archivo. Ahora, para saltar a un punto específico, tendríamos que expandir al menos parte del archivo. Hacer esto una o dos veces puede ser más barato que descomprimir todo el archivo, pero si tiene que hacerlo repetidamente, rápidamente se vuelve más costoso.

Aquí hay otra forma de pensarlo: todo lo que ha dicho se aplica al cifrado . El cifrado, dada la clave, siempre es perfectamente reversible. Y, sin embargo, claramente, el cifrado, incluso con la clave, será mucho más difícil de trabajar. Cualquier estructura que podríamos haber aprovechado en el archivo se pierde porque es una especie de punto de encriptación: ocultar la estructura.

Sin embargo, es posible comprimir datos de manera que ciertas operaciones sean eficientes . Podemos diseñar estructuras de datos que almacenen datos en un formato comprimido pero que aún admitan ciertas operaciones de manera eficiente. Esta área de investigación se conoce como estructuras de datos sucintas y sigue siendo bastante avanzada: no conozco ninguna que tenga un uso generalizado. Sin embargo, ¡son ciertamente interesantes!

Si desea más detalles técnicos, Alex Bowe tiene un par de excelentes publicaciones en el blog que presentan dos estructuras de datos sucintas: RRR: un índice sucinto de clasificación / selección para vectores de bits y árboles Wavelet (una generalización de RRR).

Entonces: normalmente, no podemos operar en un archivo comprimido porque, aunque la información almacenada es la misma, la estructura no es lo que significa que requeriría trabajo adicional para cualquier operación que quisiéramos realizar. Sin embargo, también podemos almacenar nuestros datos de manera más inteligente en una estructura de datos sucinta que se comprime de una manera que todavía proporciona suficiente estructura para realizar ciertas operaciones de manera eficiente.

Para comenzar con operaciones de cualquier tipo (edición o actualización), el archivo específico lo complica en su estado comprimido. Las razones son simples, un archivo comprimido (sin importar el algoritmo de compresión utilizado) no es lo mismo que un archivo sin comprimir (o un archivo descomprimido), para ahorrar espacio, varias funciones de aspecto y la memoria utilizada para almacenarlas también están comprimidas.

¿Qué significa esto?

Supongamos que está trabajando en un archivo comprimido (comprimido sin pérdida), cualquier cambio o actualización que realice aquí requiere que Windows (o cualquier otro sistema operativo) invoque varias funciones y aspectos del archivo, que son (al menos algunos de los cuales son) en memoria contigua y no se puede acceder mientras el archivo está en formato comprimido, por lo que para ayudar a la descompresión (ya sea manualmente o algunas aplicaciones y el sistema operativo pueden hacer esto automáticamente de manera temporal) o se requiere una asignación especial de memoria.

La descompresión es una mejor idea aquí?

Ahora, varias de estas descompresiones o asignaciones especiales son realmente costosas (en memoria y como resultado de la velocidad funcional del sistema operativo (dispositivo), por lo que es una mejor idea descomprimir el archivo de primera mano.

Esto se aplica incluso incluso a ver una imagen (archivo) en formato comprimido, no todas las funciones (como hacer clic con el botón derecho en la imagen) ya que el archivo todavía está en formato comprimido, o al menos tarda más tiempo en cargarse.

En general, es velocidad, pero también que los algoritmos de compresión tienden a requerir que descomprimas los datos que no necesitas obtener en los datos que sí.

Por ejemplo, puede haber comprimido una imagen y decir que desea obtener el valor de píxel en la fila 583 y la columna 892, no puede simplemente solicitar esos datos de la imagen comprimida, ya que esos datos no existen, solo los datos existe una vez que ha sido descomprimido.

La razón de esto es que la compresión tiende a detectar secuencias o patrones en los datos y describe esa secuencia, porque a menudo se requiere una menor cantidad de espacio para describir cómo crear datos, que almacenar los datos en sí.

Entonces, para conocer el valor de un píxel en 583,892, debe calcular el valor, que probablemente proviene de valores anteriores aplicados a un algoritmo dado.

Eso se vuelve muy complicado y sería increíblemente lento en comparación con el C requerido para leer un valor de píxel de 32 bits de una imagen en bruto en C:

int pixel = imagen [(583 * rowsize) + 892];

Ya hacemos esto. El video (MPEG-2, MPEG-4), audio (MP3, AAC, etc.), imágenes (JPEG, GIF, PNG) y documentos (DOCX, XLSX, PDF, etc.) ya están en formatos comprimidos.

Sin embargo, el uso de los archivos aún requiere que se descompriman en la memoria. Por ejemplo, su computadora solo puede mostrar una imagen como una matriz de píxeles. Cuando ve una imagen JPEG, debe convertirse a este formato. Todos estos formatos comprimidos están diseñados para descomprimirse rápidamente. Esto normalmente requiere intercambiar algo de espacio de almacenamiento por velocidad.

Hacemos eso todo el tiempo.

A menos que trabaje en imágenes médicas o fotografía de alta gama, estoy dispuesto a apostar que nunca ha tenido fotos digitales en ningún dispositivo (computadora, teléfono o tableta) que no se hayan almacenado en forma comprimida. Y el algoritmo de compresión de imágenes más común (JPEG) ni siquiera es sin pérdidas.

Lo mismo es cierto para las películas.

¿Alguna vez intercambiaste música o sonidos sin comprimir? Apuesto a que no lo has hecho.

¿Sabía que todos los documentos de OpenOffice son literalmente archivos .zip, simplemente nombrados con una extensión diferente y que contienen una estructura de directorios interna estandarizada?

¿Sabía que los documentos PDF están comprimidos?

Entonces, su pregunta tendría que reducirse a “¿por qué no almacenamos todos los tipos de flujos de datos en un formato comprimido?”.

Mi respuesta intuitiva es que no vale la pena.

Una vez que las imágenes, películas y música se comprimen, ¿qué más queda? No es mucho en términos de tamaño, lo que significa que el beneficio marginal es pequeño.

Comprimir ejecutables no es tan popular. Las bases de datos se comprimen en determinadas circunstancias, según sus requisitos de rendimiento.

Porque es “incómodo” y nos hará realizar todas las operaciones con mayor complejidad.
Su pregunta es como preguntar: “si doblar un periódico es reversible, por qué no lo usamos simplemente en la posición plegada”
Doblamos el periódico porque será más cómodo meterlo en una bolsa mientras está doblado … Pero es menos cómodo leerlo mientras está doblado …

Algunos formatos se desarrollaron para facilitar su uso, no teniendo en cuenta la compresión. Los programas no reconocen una versión comprimida del archivo, por lo que primero debe extraerlos.

Sin embargo, encontrará que algunos formatos están comprimidos, como sugiere. Solo que no todos lo hacen.

Algunos sistemas de archivos permiten la compresión sobre la marcha. Lo hacen en el fondo y ni siquiera sabes que el archivo está almacenado comprimido en el disco duro. Simplemente se ve como el archivo normal, pero debajo del sistema de archivos lo ha comprimido para ahorrar espacio en el disco.