¿Por qué está buscando algoritmos de compresión con salida comprimida sin cabeza?
Quizás (a) tenga un sistema como telefonía bidireccional que necesita compresión/descompresión de transmisión de baja latencia. La categoría de codificación adaptativa de los algoritmos de compresión mencionados por Zach Scrivena y la familia LZ de los algoritmos dictionary compression mencionados por Diego Sevilla y Javier son excelentes para este tipo de aplicación. Implementaciones prácticas de estos algoritmos generalmente do tienen un byte o dos de metadatos al principio (haciéndolos inútiles para (b) aplicaciones), pero eso tiene poco o ningún efecto sobre la latencia.
Quizás (b) le interese principalmente la criptografía, y oye que comprimir antes de cifrar proporciona algunas propiedades de seguridad mejoradas, siempre que el texto comprimido no tenga el encabezado de metadatos fijo "cuna". Los algoritmos de encriptación modernos no son (hasta donde sabemos) vulnerables a tales "cunas", pero si usted es paranoico, podría estar interesado en "compresión bijectivo" (a, b, c, etc.). No es posible detectar errores en la transmisión (bits volteados, bits insertados, bits eliminados, etc.) cuando un receptor obtiene dicha salida comprimida (lo que hace que estos algoritmos no sean especialmente útiles para aplicaciones (a)).
Quizás (c) esté interesado en la compresión sin cabeza por alguna otra razón. Suena fascinante, ¿cuál es esa razón?
Incluso RLE requiere algún conocimiento de qué son los datos y cómo se codifica el RLE. El algoritmo de descompresión necesita saber si estaba contando bits, o bytes, colores o muestras de sonido, etc. –
Eso está codificado de forma rígida en el algoritmo de compresión/descompresión en sí mismo o en los encabezados. –
Sí, pero en general está codificado en el algoritmo, mientras que las tablas para la codificación huffman generalmente se almacenan con los datos comprimidos. –