El algoritmo de Huffman es un algoritmo para la construccin de cdigos de Huffman, desarrollado

por David A. Huffman en 1952 y descrito en A Method for the Construction of Minimum-Redundancy Codes.
1

Este algoritmo toma un alfabeto de n smbolos, junto con sus frecuencias de aparicin asociadas, y produce
un cdigo de Huffman para ese alfabeto y esas frecuencias.
El algoritmo consiste en la creacin de un rbol binario que tiene cada uno de los smbolos por hoja, y
construido de tal forma que siguindolo desde la raz a cada una de sus hojas se obtiene el cdigo Huffman
asociado.
1. Se crean varios rboles, uno por cada uno de los smbolos del alfabeto, consistiendo cada uno de
los rboles en un nodo sin hijos, y etiquetado cada uno con su smbolo asociado y su frecuencia de
aparicin.
2. Se toman los dos rboles de menor frecuencia, y se unen creando un nuevo rbol. La etiqueta de la
raz ser la suma de las frecuencias de las races de los dos rboles que se unen, y cada uno de
estos rboles ser un hijo del nuevo rbol. Tambin se etiquetan las dos ramas del nuevo rbol:
con un 0 la de la izquierda, y con un 1 la de la derecha.
3. Se repite el paso 2 hasta que slo quede un rbol.
Con este rbol se puede conocer el cdigo asociado a un smbolo, as como obtener el smbolo asociado a un
determinado cdigo.
Para obtener el cdigo asociado a un smbolo se debe proceder del siguiente modo:
1. Comenzar con un cdigo vaco
2. Iniciar el recorrido del rbol en la hoja asociada al smbolo
3. Comenzar un recorrido del rbol hacia arriba
4. Cada vez que se suba un nivel, aadir al cdigo la etiqueta de la rama que se ha recorrido
5. Tras llegar a la raz, invertir el cdigo
6. El resultado es el cdigo Huffman deseado
Para obtener un smbolo a partir de un cdigo se debe hacer as:
1. Comenzar el recorrido del rbol en la raz de ste
2. Extraer el primer smbolo del cdigo a descodificar
3. Descender por la rama etiquetada con ese smbolo
4. Volver al paso 2 hasta que se llegue a una hoja, que ser el smbolo asociado al cdigo
En la prctica, casi siempre se utiliza el rbol para obtener todos los cdigos de una sola vez; luego se
guardan en tablas y se descarta el rbol.

Para poder utilizar el algoritmo de Huffman es necesario conocer de antemano las frecuencias de aparicin
de cada smbolo, y su eficiencia depende de lo prximas a las frecuencias reales que sean las estimadas.
Algunas implementaciones del algoritmo de Huffman son adaptativas, actualizando las frecuencias de cada
smbolo conforme recorre el texto.
La eficiencia de la codificacin de Huffman tambin depende del balance que exista entre los hijos de cada
nodo del rbol, siendo ms eficiente conforme menor sea la diferencia de frecuencias entre los dos hijos de
cada nodo.

REFERENCIA: http://es.wikipedia.org/wiki/Algoritmo_de_Huffman

El algoritmo de Huffman se usa para la compresin o encriptacin de datos mediante el estudio de la
frecuencia de aparicin de caracteres. Fue desarrollado por el norteamericano David Albert Huffmanen
1952 mientras haca el doctorado en el MIT. El mtodo fue publicado en una revista como A Method for the
Construction of Minimum-Redundancy Codes (el artculo original). El algoritmo funciona a partir de un
conjunto dado de smbolos con sus respectivos pesos. Los pesos son la frecuencia de aparicin en una
cadena. Por ejemplo en la cadena Genciencia el peso del smbolo i es 2, ya que aparece en dos ocasiones. La
salida del algoritmo es el mismo conjunto de smbolos de entrada codificado mediante un cdigo binario con
un tamao menor. La descripcin matemtica del algoritmo de Huffman es la siguiente:
Entrada
Conjunto de Smbolos:

Pesos asociados:

Donde n es la cantidad de smbolos diferentes que existe en la cadena de entrada. As pues los pesos
asociados a los smbolos pertenecientes al conjunto A se encuentran en un rango comprendido entre 1 y n
(entendiendo que la entrada no va a ser una cadena vaca), es decir:
Salida
Conjunto de cdigo binarios:

Meta
Conseguir que el peso de C sea menor que el de A:

El algoritmo se basa en el uso de un rbol binario dnde las hojas representan los smbolos del conjunto de
entrada. Para conseguir el cdigo de Huffman asociado a cada smbolo nicamente hay que seguir las aristas
que unen la raz con la hoja determinada. Vamos a comprimir la cadena de ejemplo: pablito clavo un
clavito.

REFERENCIA: http://www.xatakaciencia.com/matematicas/algoritmo-de-huffman

El algoritmo de Huffman es un algoritmo de compresin de informacin. Este algoritmo est basado en la
idea de que algunos caracteres aparecen muchas ms veces que otros. Es especialmente eficaz en archivos
de texto, donde ms de la mitad de los caracteres difcilmente aparezcan alguna vez. Y entre los caracteres
que aparecen, hay algunos que aparecen mucho ms que otros.
Cada caracter se almacena en una secuencia de 8 bits. Este algoritmo se encarga de asignar cdigos ms
cortos a los caracteres que ms se repiten, y cdigos ms largos a los que menos se repiten. De esta manera
a cada caracter se le asigna una longitud que puede variar entre 1 y 255 bits.
Cmo se hace esto?
Mediante un rbol binario. Veamos un ejemplo.
Supongamos que en un archivo tenemos el texto: mi mama me mima. Este texto ocupa 120 bits (15
bytes). Lo que propone el algoritmo de Huffman es lo siguiente:
1. Contemos cuantas veces aparece cada letra: m(6), i(2), espacio(3), a(3), e(1) (De ahora en
adelante llamemos ~ al espacio para hacer las cosas ms faciles).
2. Ordenamos las letras por su frecuencia, de mayor a menor:
m(6)~(3)a(3)i(2)e(1)
3. Sumamos las ltimas dos hojas, y en su lugar ponemos un nodo que tendr la frecuencia de
las dos hojas sumadas (y hagamos esto sucesivamente).

m(6) ~(3) a(3) (3)// Sumamos.
/ \
i(2) e(1)


m(6) ~(3) (6)// Sumamos.
/ \
a(3) (3)
/ \
i(2) e(1)


m(6) (6) ~(3)// Reordenamos por frecuencia.
/ \
a(3) (3)
/ \
i(2) e(1)


m(6) (9)// Sumamos.
/ \
(6) ~(3)
/ \
a(3) (3)
/ \
i(2) e(1)


(15)// Reordenamos y sumamos.
/ \
(9) m(6)
/ \
(6) ~(3)
/ \
a(3) (3)
/ \
i(2) e(1)


4. Ahora debemos crear una convencin. En este ejemplo, convengamos: 0 a la izquierda y 1 a
la derecha. De esta manera debemos recorrer el rbol hasta las hojas para crear los cdigos de
los caracteres. Por ejemplo, el carcter i est a: izquierda-izquierda-derecha-izquierda. Esto
equivale a: 0010. Podemos hacer lo mismo con los otros, y obtendramos estos cdigos:

m = 1.
~ = 01.
a = 000.
i = 0010.
e = 0011.

5. Y ahora nos resta leer el archivo y por cada caracter ledo escribir su correspondiente cdigo en el
archivo de salida. Para hacerlo ms simple para nuestro anlisis humano pondremos un punto
entre cada cdigo, pero en el archivo lo escribiremos todo junto. En el caso de mi mama me
mima, tendramos un archivo de salida as:
6. 1.0010.01.1.000.1.000.01.1.0011.01.1.0010.1.000.
Esto suma un total de 33 bits. Mucho menos que el archivo original de 120 bits.
No habr ambigedades?
Ahora, como el lector sabe que en el archivo no escribiremos los puntos, se estar preguntando: Y que pasa
si al leer la informacin comprimida imagino los puntos en otras ubicaciones, que voy a interpretar?.
Hagamos la prueba, no le pongamos ningn punto: 100100110001000011001101100101000.
Pero recordemos seguir esta regla: Teniendo el rbol a mano situmonos en el nodo principal y vayamos
leyendo la informacin. Cada vez que leamos un bit, movmonos al nodo inferior que est a la derecha o a
la izquierda segn indique el bit. Cuando nos encontremos con que nos movimos a una hoja en vez de a un
nodo, escribamos el carcter de la hoja, movmonos al principio del rbol y sigamos leyendo bit por bit
desde donde nos habamos quedado. Repitamos este proceso hasta el ltimo bit.
Esto es lo que leeremos para nuestro ejemplo:
o Derecha (hoja). Ponemos la m. Volvemos arriba.
o Izquierda-izquierda-derecha-izquierda (hoja). Ponemos la i. Volvemos arriba.
o Izquierda-derecha (hoja). Ponemos ~. Volvemos arriba.
o Etc
Al final habremos formado: mi mama me mima. Y no habr posibilidades de formar otra frase con ese rbol
y esa secuencia de bits. Haga algunos intentos y quedar convencido de que es as.
Debemos notar que para cada archivo habr un rbol diferente de acuerdo a las frecuencias de los
caracteres en ese archivo en particular, y una secuencia de bits diferente de acuerdo a la ubicacin de los
caracteres.
Ahora el lector habr notado que el descompresor abre el archivo comprimido y ve la secuencia de bits,
pero se estar preguntando cmo sabe el descompresor cual es el rbol de ese archivo? Claro, habamos
dicho que para cada archivo hay un rbol y una secuencia de bits diferentes! As que el descompresor
tambin deber conocer el rbol.
Guardando el rbol.
Veamos una manera sencilla de guardar el rbol, aunque no es tan sencillo explicarlo.
Para guardar la secuencia de bits nosotros sabamos si estbamos en un nodo o en una hoja, y lo que
anotbamos era la direccin hacia la que nos movamos.
Ahora hagamos justamente lo opuesto. Recorramos el rbol en una direccin (secuencia) conocida y
anotemos si estamos en un nodo o en una hoja, y si estamos en una hoja anotemos su caracter.
Para eso convengamos esta regla: Cada nodo/hoja al ser llamado anotar un 1 si es una hoja y un 0 si es un
nodo. Luego si es una hoja anotar los 8 bits que representan el caracter de esa hoja. Y si es un nodo,
llamar al nodo/hoja de la izquierda y luego al de la derecha para que hagan lo mismo (recursivamente). Por
ltimo, despus de hacer todo lo que tiene que hacer, devolver el mando al nodo que lo llam.
De esta forma nuestro rbol de ejemplo (ms abajo) quedara guardado as:
1. (15) dice: Soy nodo, escribo 0. Llamo a nodo (9)
2. (9) dice: Soy nodo, escribo 0. Llamo a nodo (6).
3. (6) dice: Soy nodo, escribo 0. Llamo a hoja a(3).
4. a(3) dice: Soy hoja, escribo 1. Escribo mi cdigo: 01100001. Retorno a (6).
5. (6) dice: Ahora llamo a nodo (3).
6. (3) dice: Soy nodo, escribo 0. Llamo a hoja i(2).
7. i(2) dice: Soy hoja, escribo 1. Escribo mi cdigo: 01101001. Retorno a (3).
8. (3) dice: Ahora llamo a hoja e(1).
9. e(1) dice: Soy hoja, escribo 1. Escribo mi cdigo: 01100101. Retorno a (3).
10. (3) dice: Retorno a (6).
11. (6) dice: Retorno a (9).
12. (9) dice: Ahora llamo a hoja ~(3).
13. ~(3) dice: Soy hoja, escribo 1. Escribo mi cdigo: 00100000. Retorno a (9).
14. (9) dice: Retorno a (15).
15. (15) dice: Ahora llamo a hoja m(6).
16. m(6) dice: Soy hoja, escribo 1. Escribo mi cdigo: 01101101. Retorno a (15).
17. (15) dice: Terminamos (retorno a quien sea que haya preguntado el cdigo del rbol).
rbol:
(15)
/ \
(9) m(6)
/ \
(6) ~(3)
/ \
a(3) (3)
/ \
i(2) e(1)
Tamao de la descripcin del rbol.
El cdigo que se acaba de generar sera el siguiente:
0001011000010101101001101100101100100000101101101 (49 bits).
ste cdigo debe ir antes que la secuencia de bits del archivo para que el descompresor pueda armar el
rbol antes de leer la secuencia de bits. En total el archivo generado tendr 82 bits. Esto equivale a 10,25
bytes. Pero como no podemos guardar medio byte, tendremos que redondear a 11 bytes. As un archivo de
15 bytes qued reducido a 11 bytes.
Note el lector que casi el 60% del archivo comprimido est ocupado por la descripcin del rbol. Ya que una
descripcin de rbol vara entre los 0 bits, en caso de un archivo vaco, y los 2559 bits (320 bytes), en caso de
que un caracter se repita ms que todos los otros juntos, y que el siguiente que ms se repite se repita ms
que todos los otros que se repiten menos que l juntos y as sucesivamente, vemos que la descripcin del
rbol ocupar a lo sumo 320 bytes.
Esto es prcticamente insignificante para archivos de varios KB, por lo tanto el porcentaje de compresin va
a ser mayor que para este ejemplo ya que aqu ms del 59,75% del archivo es la pura descripcin del rbol,
(en este caso es muy significante).
Leyendo la descripcin del rbol.
Para descomprimir el archivo basta armar el rbol a medida que vamos leyendo su descripcin. Dejmoslo
como tarea para el lector Est bien, hagmoslo juntos. En la descripcin leemos:
0: Dibujamos un nodo.
( )
/ \
0: Dibujamos otro nodo.
( )
/ \
( )
/ \
0: Dibujamos otro nodo.
( )
/ \
( )
/ \
( )
/ \
1: Dibujamos una hoja y leemos los 8 bits de su cdigo (01100001=a).
( )
/ \
( )
/ \
( )
/ \
a( )
Nos movemos al prximo lugar vaco y leemos: 0: dibujamos un nodo.
( )
/ \
( )
/ \
( )
/ \
a( ) ( )
1: Dibujamos una hoja y leemos los 8 bits de su cdigo (01101001=i).
( )
/ \
( )
/ \
( )
/ \
a( ) ( )
/ \
i( )
1: Dibujamos una hoja y leemos los 8 bits de su cdigo (01100101=e).
( )
/ \
( )
/ \
( )
/ \
a( ) ( )
/ \
i( ) e( )
1: Dibujamos una hoja y leemos los 8 bits de su cdigo (00100000=~).
( )
/ \
( )
/ \
( ) ~( )
/ \
a( ) ( )
/ \
i( ) e( )
1: Dibujamos una hoja y leemos los 8 bits de su cdigo (01101101=m).
( )
/ \
( ) m( )
/ \
( ) ~( )
/ \
a( ) ( )
/ \
i( ) e( )
El nodo principal devuelve el control al que lo llam. Y podemos ver que esto ocurre justamente cuando se
terminan los bits. No hay ambigedades.
REFERENCIA: http://www.danielmunoz.com.ar/blog/2010/07/07/el-algoritmo-de-huffman/
4.
La codificacion de Huffman es una tecnica para la compresion o encriptacion de datos, mediante el estudio
de la frecuencia de aparicion de caracteres,ampliamente usada y muy efectiva. Fue desarrollado por el
norteamericano David Albert Huffman en 1952 mientras hacia el doctorado en el MIT. El algortimo funciona
a partir de un conjunto dado de simbolos con sus respectivos pesos. Los pesos son la frecuencia de aparicion
en una cadena.
Ejemplo: Archivo con 100,000 caracteres. Se sabe que aparecen 6 caracteres diferentes y la frecuencia de
aparicion de cada uno de ellos es:
Como codificar los caracteres para comprimir el espacio ocupado utilizando uncodigo binario?

Solucion 1: Codigo de longitud fija
Para seis caracteres se necesitan 3 bits (300,000 bits)
Solucion 2: Codigo de longitud variable en el que los mas frecuentes tienen elcodigo mas corto. Restriccion:
ningun codigo es prefijo de otro.
Esta tecnica de codificacion se denomina codigo prefijo.
Un arbol binario es una forma de representar el codigo prefijo que significa el proceso de descodificacion:
Las hojas con los caracteres.
El camino de la raiz a las hojas con la interpretacion 0 a la izquierda y 1 a la derecha nos da el codigo de cada
hoja.

REFERENCIA: http://www.buenastareas.com/ensayos/Algoritmo-De-Huffman/1959556.html





El Algoritmo Lempel-Ziv
Fue ideado por Jacob Ziv y Abraham Lempel, y publicado en el IEEE Transactions on Information Theory, vol.
IT-23, No 3 de Mayo de 1977, si bien ya haba sido presentado anteriormente en el IEEE International
Symposium on Information Theory celebrado en Ronneby, Suecia, en Junio de 1976.
Desde entonces recibe el nombre de compresin Lempel-Ziv o, para abreviar, LZ.
Existe una variante de LZ, denominada LZW (Lempel-Ziv-Welch), que se ha hecho muy famosa por ser la que
se utiliza para comprimir en el formato de imgenes GIF. Se trata de una modificacin de LZ que, a costa de
un menor ratio de compresin, ofrece mejoras en cuanto a velocidad y uso de memoria, lo que hizo que se
usara en los modems que soportan el protocolo V42bis. Es tambin el algoritmo empleado en el programa
compress. Sin embargo, a pesar de su atractivo, no lo trataremos aqu porque, desgraciadamente, se trata de
un algoritmo sujeto a patentes. Pese a que la informacin sobre su funcionamiento se encuentra accesible
lbremente ("A Technique for High-Performance Data Compression'', Terry A. Welch, IEEE Computer, Junio
1984, pginas 8-19), su funcionamiento en cambio no lo es. Contrariamente a lo que se podra pensar, la
patente no es de Terry Welch, que durante 7 aos, y hasta que en 1983 se march a DEC, estuvo trabajando
en el Sperry Research Center de Sudbury, Massachusetts. Desde el principio fue Sperry el propietario de la
patente, aunque nunca trat de sacarle partido. Al menos hasta que en 1986 se uni a Burroughs para formar
Unisys. Fue entonces cuando empezaron a utilizarla contra los fabricantes de modems. Actualmente la patente
pertenece a Unisys, que legalmente puede cobrar por su uso, como ya hizo con Compuserve, con la que lleg
a un acuerdo para crear una licencia para productores de software sobre el formato GIF, que antes era libre.
No obstante lo dicho, Unisys al final decidi no cobrar derechos de patentes por cdigo libre que se hubiera
publicado con anterioridad a la decisin de hacer efectiva la patente, y por ello hay una librera -giflib- que se
puede usar para cdigo libre sin pagar patentes; la librera est ahora mantenida por Eric S.
Raymond: http://www.ccil.org/ esr/giflib.
La idea en que se basa LZ resulta simple, visto todo lo que le hemos pedido al algoritmo en la seccin
anterior: bsicamente busca secuencias repetidas dentro de los datos, y cada vez que encuentra una de ellas
la reemplaza por un puntero a la zona en la que comienza la primera secuencia, ms la longitud que se debe
tomar a partir de esa posicin. En caso de que no haya repeticiones, se emite la secuencia como un literal.
Lo ms importante, y lo que conforma el ncleo de la idea, es identificar lo que Lempel-Ziv llaman extensin
reproducible de una cadena dentro de otra y que difiere un tanto de lo que coloquialmente llamamos
"repeticiones''.
Vemoslo con el mismo ejemplo del artculo original de los autores, pero desde un punto de vista ms
descriptivo y menos matemtico para facilitar un poco su lectura: supongamos que tenemos la secuencia
S=00101011. Pongmoslo tabulado, de forma que podamos hacer referencia a cada elemento de la secuencia
fijndonos en el orden en el que aparece dentro de esta. La primero fila de la figura 1 indica la posicin dentro
del buffer y la segunda su contenido. Consideraremos la posicin ms a la izquierda como posicin 1.

Supongamos tambin que los tres primeros elementos, 001, ya han sido codificados; en este momento nos da
igual que hayan sido comprimidos o tomados como literales. Posteriormente nos ocuparemos de ese aspecto,
pero ahora tenemos que codificar lo que sigue: 01011. Llamaremos a la secuencia ya codificada secuencia 1 y
a la que est siendo codificada ahora secuencia 2.
Si a una persona normal le pedimos que encuentre en 01011 una secuencia que est repetida a partir de lo
que ya hemos codificado (001), nos dir que los dos primeros elementos de la secuncia a codificar (posiciones
4 y 5 dentro del buffer) son iguales a los dos ltimos de 001 (posiciones 2 y 3), y que ah hay una repeticin.
Y tendr razn, pero la genialidad de LZ est en darse cuenta de que se puede ir ms all y utilizar la propia
secuencia a codificar como lugar donde seguir buscando repeticiones. Eso a pesar de que an no la hemos
codificado!
Vemoslo: la secuencia 2 empieza por 0101 (posiciones 4 a 7). Si empezamos a mirar en lo que ya hemos
codificado, la secuencia 1, tenemos que finaliza en 01, pero si seguimos entrando en la secuencia 2 ahora
veremos que empieza por 01. Si juntamos el final de la secuencia 1 con el principio de la secuencia 2, tenemos
0101, que es igual al comienzo de la secuencia a codificar o secuencia 2. Es decir: los elementos 4, 5, 6 y 7 de
la secuencia total son una "repeticin'' de los elementos 2, 3, 4 y 5. Por tanto se codificarn como un puntero
a la posicin nmero 2 ms una longitud de 4. Luego veremos en un ejemplo cmo esto, aunque parezca
imposible, funciona a la hora de decodificar.
La codificacin se lleva a cabo introduciendo los datos dentro de un buffer de una longitud prefijada, n, dentro
del cual se van buscando subcadenas ya repetidas haciendo uso del mtodo que acabamos de explicar. En
gzip, la longitud mxima de esas subcadenas, Ls, es de 258 bytes. Si una cadena no ocurri dentro de los 32
Kbytes anteriores, se emite literalmente.
Un ejemplo ayudar a ver cmo se llevan a cabo la compresin y la descompresin. Utilizaremos una
simplificacin de uno propuesto por los creadores del algoritmo. Supongamos que queremos codificar la
secuencia S=001010210210212021021200... Por razones didcticas (aunque no prcticas) usaremos un buffer
de longitud n=18 y una longitud mxima de cadena Ls de 9. Inicialmente se llenan las n-Ls posiciones del
buffer con ceros, y las Ls restantes con los primeros datos de la secuncia, con lo que el buffer en la posicin
inicial quedara como se ve en la figura 2.

La extensin reproducible de Ls, empezando a buscar en la parte ya "codificada" (las n-Ls primeras posiciones
del buffer), aparece en gris. La primera subcadena a codificar se formar a partir de esa extensin
reproducible, 00, seguida del siguiente elemento que ya no est repetido 1, luego S1=001. La palabra cdigo
que representa a esa subcadena ser, por convenio y en ese orden, el puntero al comienzo de la repeticin
menos 1, seguido de la longitud de la repeticin, seguido del elemento final, que no entraba en la repeticin.
Es decir, para este caso: C1=021.
Puesto que S1 tena longitud 3, todo el contenido del buffer es despplazado hacia la izquierda 3 posiciones. En
esta situacin 2 seguiremos, como siempre, a partir de la posicin 10, buscando la extensin reproducible de
0102... La encontramos en la figura 3.

Aqu, la extensin peridica de los elementos a partir de la posicin 10 se haya en la posicin 8. Empezando
tanto por 8 como por 10 encontramos la secuencia 010, as que S2 es la parte que se repite del comienzo de
Ls, 010 (posiciones 10 a 12), ms el siguiente elemento, 2, que ya no se repite (posicin 13). Luego S2=0102,
que se codifica cmo C2=732. Desplazamos 4 posiciones a la izquierda, que es lo que mide S2, y la "repeticin''
de la secuencia Ls se encuentra en la zona marcada en la figura 4.

En ella se observa con claridad que, dado que Ls empieza por 10, haba una repeticin en las posiciones 5 y 6,
que tambin son 10, que sin embargo no hemos marcado en negrita dentro de la figura. Esto es debido a que
la secuencia formada por las posiciones 5 y 6, si bien representa una repeticin de lo que aparece en Ls, no se
trata de su extensin peridica ya que tiene longitud 2, mientras que la coloreada en la figura tiene longitud
mayor: 7. Por ello S3=10210212 y C3=672. Por ltimo, tras desplazar las 8 posiciones que ocupa S3, se
obtiene S4=021021200 y C4=280 (figura 5).

Comprobemos que la secuencia comprimida C=821732672280 puede decodificarse unvocamente dando como
resultado la secuancia original S=001010210210212021021200. Es importante darse cuenta de que, si bien la
longitud de las subcadenas no es fija (aunque s limitada), la de las palabras cdigo s lo es: en este caso, 3
caracteres. Esto permite separar a partir de C palabra cdigo de palabra cdigo de forma simple. Incluso
dentro de una misma palabra cdigo, los tamaos asignados a una u otra funcin (posicin a partir de la que
empieza una repeticin, longitud de esta y elemento siguiente a ella), son tambin fijos, y fcilmente
separables,
La longitud de cada uno de estos campos, y de la palabra cdigo como suma de todos ellos, est directamente
relacionada con el tamao del buffer, n, y con el de la mxima subcadena, Ls. Ms detalles se pueden
encontrar en el artculo de Lempel-Ziv.
Para descomprimir se emplea un buffer de longitud n-Ls donde se van guardando los smbolos descodificados.
Inicialmente el buffer se pone todo a 0.
Seguidamente se van leyendo palabras cdigo, lo cual puede hacerse sin especiales cuidados al tener todas la
misma longitud. Tambin en este caso ilustraremos la descompresin paso por paso. El primero se ilustra en la
figura 6.

La primera palabra que se lee es '021'. El '0' sirve de puntero en el buffer, y lo llamaremos "p''. Se debe leer el
carcter que est en la posicin p+1, luego se lee el de la posicin 1. Como inicialmente el buffer estaba
puesto a 0, no sorprende que lo que encontremos en la posicin 1 sea un '0'. Tal y como est el buffer, se
desplazan todos sus elementos una posicin hacia la izquierda, y en el hueco que queda a la derecha se
introduce el carcter ledo con anterioridad en esa posicin 1. El segundo carcter de la palabra cdigo es un
'2'. Ello indica que la operacin anterior de leer y desplazar se debe hacer dos veces, por lo que la repetimos:
nuevamente se lee la posicin 1. Aunque la posicin es la misma, el dato ledo no tiene por qu serlo, ya que
el buffer se desplaz hacia la izquierda. En este caso volvemos a tener un '0', y el buffer tiene el mismo
aspecto que antes. Al segundo elemento de las palabras cdigo lo llamaremos a partir de ahora "n''. Puesto
que ya hemos hecho dos veces la operacin, tantas como indicaba el n de la palabra cdigo que estamos
decodificando, ahora se desplaza una vez ms a la izquierda, y en el hueco que ha aparecido se introduce el
tercer carcter de la palabra cdigo (a partir de ahora "c''), sin modificar: el '1'.
Al final de todas las figuras se resalta en negrita la parte del buffer que corresponde a la descodificacin de la
palabra cdigo. Evidentemente, este tramo se encuentra siempre al final del buffer, y su longitud es bien
simple de calcular: n+1.
La siguiente palabra a decodificar es 732. Como antes, y esta vez por 3 veces, se guarda el carcter de la
posicin 7+1 y se coloca a la derecha del buffer tras desplazarlo. El ltimo carcter que se introduce por la
derecha nos viene dado en la palabra cdigo: ahora es un '2' (figura 7).

El proceso con las dos palabras cdigo restantes es exactamente igual, y no requieren mayor explicacin. No
obstante, se ofrecen las figuras correspondientes para que el lector interesado pueda seguir el proceso hasta
el final (figuras 8 y 9).


Extrayendo los tramos en negrita del final de cada paso, obtenemos 001, 0102, 10210212 y 021021200, que
juntos vuelven a conformar la secuencia original S.

REFERENCIA:
http://www.programacion.com/articulo/introduccion_a_la_compresion_de_datos:_lempel-ziv-
_gzip_186/4

LZW (Lempel-Ziv-Welch) es un algoritmo de compresin sin prdida desarrollado por Terry Welch
en 1984 como una versin mejorada del algoritmo LZ78 desarrollado por Abraham Lempel y Jacob
Ziv.
La mayora de los mtodos de compresin se basan en un anlisis inicial del texto para identificar
cadenas repetidas para armar un diccionario de equivalencias, asignando cdigos breves a estas
cadenas. En una segunda etapa, se convierte el texto utilizando los cdigos equivalentes para las
cadenas repetidas. Esto requiere dos etapas, una de anlisis y una segunda de conversin y
tambin requiere que el diccionario se encuentre junto con el texto codificado, incrementando el
tamao del archivo de salida.
Codificacion Fuente Lempel-Ziv
Las estadsticas de fuente a menudo no son conocidas
La mayora de las fuentes no son independientes

Las letras del alfabeto tienen un alto grado de correlacin
P.ej., despus de la I va la E, despus de la G va la H, etc.
Se pueden codificar bloques de letras, sin embargo, se requerira un cdigo muy largo y
complejo.
Algoritmo Lempel-Ziv
Cdigo universal - funciona sin conocimiento de estadsticas de fuente
Analiza sintcticamente el archivo de entrada en frases unvocas
Codifica frases empleando palabras cdigo de longitud fija
Codificacin de longitud variable a fija

Algoritmo De Lempel-Ziv
Analizar el archivo de entrada en frases que an no han aparecido
Entrar frases en un diccionario
Numerar su ubicacin
Observe que cada frase nueva debe ser una frase vieja seguida por un 0 o un 1.
Puede codificar la nueva frase utilizando la ubicacin del diccionario de la frase anterior seguida
por el 0 o el 1

Notas Acerca De Lempel-Ziv
El decodificador slo puede decodificar unvocamente la secuencia enviada
El algoritmo no es eficiente para secuencias cortas (datos de entrada)
El rendimiento del cdigo se aproxima a la entropa de fuente para secuencias largas
El tamao del diccionario debe elegirse con antelacin para que se pueda establecer la longitud
de la palabra cdigo
Lempel-Ziv se usa frecuentemente para codificar archivos de texto/binarios
Comprimir/descomprimir bajo unix
Mismo software de compresin para PC y MAC
REFERENCIA: http://ovandos-blog.blogspot.com/2010/05/codificacion-o-algoritmos-de-lempel-
ziv.html

Lempel-Ziv-Welch (LZW) es un universal de compresin sin prdida de datos algoritmo creado
por Abraham Lempel , Jacob Ziv y Welch Terry . Fue publicado por Welch en 1984 como una mejor
aplicacin de la LZ78 algoritmo publicado por Lempel y Ziv, en 1978. El algoritmo es simple de
implementar, y tiene el potencial de rendimiento muy alto en las implementaciones de hardware.
Idea
El escenario descrito en 1984 Welch papel
[1]
codifica las secuencias de datos de 8 bits como de
longitud fija de 12 bits cdigos. Los cdigos de 0 a 255 representan una secuencia de caracteres
que consta de los correspondientes caracteres de 8 bits, y los cdigos 256 al 4095 se crean en un
diccionario para las secuencias encontradas en los datos, ya que est codificado. En cada etapa
de compresin, bytes de entrada se reunieron en una secuencia hasta que el carcter siguiente
sera hacer una secuencia para la que no hay ningn cdigo pero en el diccionario. El cdigo para
la secuencia (sin que el personaje) se emite, y un nuevo cdigo (de la secuencia con el personaje)
se aade al diccionario.
La idea se adapt rpidamente a otras situaciones. En una imagen basada en una tabla de
colores, por ejemplo, el alfabeto carcter natural es el conjunto de los ndices de tabla de colores, y
en la dcada de 1980, haba muchas imgenes pequeas mesas de color (del orden de 16
colores). Para ser un alfabeto reducido, los 12 bits cdigos de compresin producido pobres a
menos que la imagen era grande, as que la idea de un cdigo de ancho variable se introdujo:
cdigos suelen comenzar un poco ms ancho que los smbolos estn codificados, y como cada
uno del tamao del cdigo se agota, la anchura del cdigo se incrementa en un poco, hasta un
cierto mximo establecido (normalmente 12 bits).
Otras mejoras incluyen la reserva de un cdigo para indicar que la tabla de cdigos debe ser
borrado (un "cdigo de claro", por lo general el primer valor inmediatamente despus de los valores
de los caracteres del alfabeto individual), y un cdigo para indicar el final de los datos (una parada "
cdigo ", por lo general mayor que el cdigo de un claro). El cdigo transparente permite que la
tabla se reinicializa despus de que se llene, que permite la codificacin de adaptarse a los
cambios en los patrones en los datos de entrada. Codificadores inteligente puede monitorizar la
eficacia de la compresin y limpiar la mesa cada vez que el cuadro actual no coincide con la
entrada tambin.
Puesto que los cdigos se aaden en la forma determinada por los datos, el decodificador imita la
construccin de la mesa, ya que considera que los cdigos resultantes. Es muy importante que el
codificador y decodificador de acuerdo en que la variedad de LZW se utiliza: el tamao del
alfabeto, la anchura mxima del cdigo, ya sea de ancho variable de codificacin se est
utilizando, el tamao del cdigo inicial, si se utiliza la clara y dejar de cdigos (y los valores que
tienen). La mayora de los formatos que emplean LZW construir esta informacin en la
especificacin de formato o proporcionar campos explcitos para ellos en una cabecera de
compresin para los datos.
[ editar ]Codificacin
Una vista de alto nivel del algoritmo de codificacin se muestra aqu:
1. Inicializar el diccionario que contiene todas las cadenas de longitud uno.
2. Encontrar el W cadena ms larga en el diccionario que coincida con la entrada actual.
3. Emiten el ndice del diccionario para W a la salida de W y eliminar de la entrada.
4. Aadir W seguido por el smbolo al lado de la entrada en el diccionario.
5. Vaya al paso 2.
Un diccionario es inicializado para contener el nico cadenas de caracteres que corresponde a
todos los personajes posibles de entrada (y nada ms, excepto los cdigos claros y se detendr si
se estn utilizando). El algoritmo trabaja escaneando a travs de la cadena de entrada para
subcadenas sucesivamente ms, hasta que encuentra uno que no est en el diccionario. Cuando
una cadena se encuentra, el ndice de la cadena menos el ltimo carcter (es decir, la subcadena
ms larga que est en el diccionario) se recupera en el diccionario y enva a la salida, y la nueva
cadena (incluyendo el ltimo carcter) que se aade es en el diccionario con el cdigo
disponible. El ltimo carcter ingresado se utiliza como punto de partida siguiente para buscar
subcadenas.
De esta manera, las cadenas de forma sucesiva ya estn registrados en el diccionario y puestos a
disposicin para la codificacin posterior de los valores de salida nica. El algoritmo funciona mejor
en los datos con los patrones que se repiten, por lo que la parte inicial de un mensaje se ve poca
compresin. A medida que el mensaje crece, sin embargo, la relacin de compresin tiende
asintticamente al mximo.
[2]

[ editar ]Decodificacin
El algoritmo de decodificacin de la lectura de obras de un valor de la entrada codificada y la salida
de la cadena correspondiente del diccionario inicializado. Al mismo tiempo, se obtiene el siguiente
valor de la entrada, y se agrega al diccionario de la concatenacin de la cadena de produccin y
slo el primer carcter de la cadena obtenida por descifrar el valor de entrada. El decodificador
entonces procede al valor de entrada al lado (que ya fue ledo en el "siguiente valor" en el paso
anterior) y repite el proceso hasta que no haya entrada de ms, momento en el que el valor de la
entrada final es decodificada sin adiciones ms en el diccionario.
De este modo, el decodificador se acumula un diccionario que es idntica a la utilizada por el
codificador, y lo utiliza para descifrar los valores de entrada posterior. As, el diccionario completo
no necesita ser enviado con los datos codificados, slo el diccionario inicial que contiene los
caracteres de las cadenas es suficiente (y por lo general se define de antemano en el codificador y
decodificador en lugar de ser enviado de forma explcita con los datos codificados.)
[ editar ]ancho variable cdigos
Si la variable de ancho de cdigos se utilizan, el codificador y decodificador debe tener cuidado
para cambiar el ancho en los mismos puntos en los datos codificados, o que no estn de acuerdo
acerca de dnde estn los lmites entre los cdigos individuales de la cada en el flujo. En la
versin estndar, el codificador aumenta el ancho de la p a p + 1, cuando una secuencia de + s
se encuentra que no est en la mesa (de modo que el cdigo se debe agregar para ello), pero el
siguiente cdigo disponible en la tabla es 2
p
(el primer cdigo que requieren p + 1 bits). El
codificador emite el cdigo de en p ancho (ya que el cdigo no requiere que p + 1 bits), y
aumenta el ancho de cdigo para que el siguiente cdigo emitido ser p + 1 bits de ancho.
El decodificador es siempre un cdigo detrs del codificador en la construccin de la mesa, as que
cuando se ve el cdigo de , se generar una entrada para el cdigo 2
p
- 1. Dado que este es el
punto donde el codificador aumentar el ancho del cdigo, el decodificador debe aumentar el ancho
de aqu, as: en el punto donde se genera el mayor cdigo que se ajuste en bits p.
Lamentablemente, algunas primeras implementaciones del algoritmo de codificacin de aumentar
el ancho de cdigo y luego emiten en el nuevo ancho en lugar de la anchura de edad, de modo
que el decodificador que parece que el cambiar el ancho de un cdigo antes de tiempo. Esto se
llama "Cambio temprana", que caus tanta confusin que Adobe permite ahora a las dos versiones
de los archivos PDF, pero incluye un indicador explcito en la cabecera de cada corriente de
comprimidos con LZW para indicar si el cambio precoz est siendo utilizada. La mayora de
formatos de archivos grficos no el cambio de uso temprano.
Cuando la tabla se borra en respuesta a un cdigo claro, tanto codificador y decodificador de
cambiar el ancho de cdigo despus de la vuelta de cdigo claro para la anchura del cdigo inicial,
comenzando con el cdigo inmediatamente despus del cdigo claro.
[ editar ]para embalaje
Puesto que los cdigos emitidos por lo general no entran en los lmites de bytes, el codificador y
decodificador debe ponerse de acuerdo sobre cmo los cdigos estn empaquetados en
bytes. Los dos mtodos ms comunes son LSB-En primer lugar ("bit menos significativo en
primer") y MSB-En primer lugar ("bit mas significativo primero"). En primer lugar LSB-embalaje, el
primer cdigo est alineada de forma que el bit menos significativo del cdigo de las cadas en el
bit menos significativo del flujo de bytes en primer lugar, y si el cdigo tiene ms de 8 bits, los bits
de orden superior izquierda alineados son ms con los bits menos significativos del byte siguiente,
otros cdigos estn llenos de LSB de entrar en el bit menos significativo an no se utilizan en el
flujo de bytes actual, procediendo en bytes adicionales que sean necesarias. MSB-primero de
embalaje se alinea el primer cdigo de modo que su bit ms significativo se cae en el MSB del flujo
de bytes en primer lugar, con rebosadero alineado con el MSB del siguiente byte; otros cdigos se
escriben con MSB entrar en el bit ms significativo an no se utilizan en el byte de secuencia
actual.
Los archivos GIF utilizan LSB-En primer lugar el fin de embalaje. Los archivos TIFF y PDF uso
MSB-de primer orden de empaque.
[ editar ]Ejemplo
El siguiente ejemplo ilustra el algoritmo LZW en la accin, que muestra el estado de la salida y
el diccionario en todas las etapas, tanto en la codificacin y decodificacin de los datos. En este
ejemplo se ha construido para dar la compresin razonable en un mensaje muy corto. En los datos
de texto real, la repeticin suele ser menos pronunciada, por lo que ya los flujos de entrada suelen
ser necesarios antes de la compresin se acumula la eficiencia.
El texto a ser codificados (a partir de un alfabeto utilizando slo las letras maysculas) es la
siguiente:
TOBEORNOTTOBEORTOBEORNOT #
El # es un marcador utilizado para demostrar que el final del mensaje se ha alcanzado. As pues,
hay 26 smbolos en el alfabeto de texto plano (las 26 letras maysculas de la A a la Z), ms el
cdigo de la parada #. Arbitrariamente asignar estos valores de la 1 a 26 para las letras, y 0 para el
'#'. (La mayora de los sabores de LZW que poner el cdigo de la parada despus de que el
alfabeto de datos, pero nada en el algoritmo bsico que requiere. El codificador y decodificador
slo tiene que ponerse de acuerdo en el valor que tiene.)
Un equipo que har que estas en forma de cadenas de bits de . Cdigos de cinco bits se necesitan
para dar combinaciones suficientes para abarcar el conjunto de 27 valores. El diccionario se inicia
con estos 27 valores. Como el diccionario crece, los cdigos se necesitan para crecer en anchura
para dar cabida a las entradas adicionales. Un cdigo de 5 bits ofrece 2
5
= 32 combinaciones
posibles de los bits, as que cuando la palabra del diccionario 33a se crea, el algoritmo tiene que
cambiar en ese punto a partir de cadenas de 5 bits para las cadenas de 6 bits (para todos
los valores del cdigo, incluyendo los que antes eran de salida con slo cinco bits). Tenga en
cuenta que dado que el cdigo de cero todos los 00000 se utiliza, y la etiqueta es "0", la entrada
del diccionario se etiqueta 33a 32. (Anteriormente la produccin generada no se ve afectado por el
cambio de cdigo de ancho, pero una vez que un valor de 6 bits se genera en el diccionario, que
posiblemente podra ser el siguiente cdigo emitido, por lo que el ancho de la salida posterior se
desplaza a 6 bits para adaptarse a eso. )
El diccionario inicial, entonces, se compondr de las siguientes entradas:
Smbolo Binario Decimal
# 00000 0
A 00001 1
B 00010 2
C 00011 3
D 00100 4
E 00101 5
F 00110 6
G 00111 7
H 01000 8
Yo 01001 9
J 01010 10
K 01011 11
L 01100 12
M 01101 13
N 01110 14
O 01111 15
P 10000 16
Q 10001 17
R 10010 18
S 10011 19
T 10100 20
U 10101 21
V 10110 22
W 10111 23
X 11000 24
Y 11001 25
Z 11010 26
[ editar ]Codificacin
Buffer de entrada de caracteres en una secuencia de hasta + carcter siguiente no est en el
diccionario. Emite el cdigo de y + aadir el siguiente carcter en el diccionario. Inicio bfer de
nuevo con el siguiente carcter.
Secuencia
actual
Siguiente
carcter
Salida
Diccionario
extendido
Comentarios
Cdigo Bits
NULL T

T O 20 10100 27: A
27 = primer cdigo disponible despus
del 0 al 26
O B 15 01111 28: OB

B E 2 00010 29: SER

E O 5 00101 30: EO

O R 15 01111 31: O

R N 18 10010 32: RN
32 exige que 6 bits, por lo que para
utilizar la salida de la prxima 6 bits
N O 14 001110 33: NO

O T 15 001111 34:
Antiguo
Testamento

T T 20 010100 35: TT

A B 27 011011 36: TOB

SER O 29 011101 37: BEO

O T 31 011111 38: ORT

TOB E 36 100100 39: TOBE

EO R 30 011110 40: EOR

RN O 32 100000 41: RNO

Antiguo
Testamento
# 34 100010

# Detiene el algoritmo, enviando la
siguientes act

0 000000

y el cdigo de la parada
Longitud = 25 sin codificar smbolos x 5 bits / smbolo = 125 bits
Longitud codificada = (6 x 5 cdigos de bits / cdigo) + (11 6 cdigos de bits / cdigo) = 96 bits.
Usando LZW ha salvado 29 bits de 125, lo que reduce el mensaje de casi el 22%. Si el mensaje
eran ms largos, entonces las palabras del diccionario que empiezan a representar a las secciones
ms largas de texto, permitiendo que las palabras repetidas que se enviar muy compacta.
[ editar ]Decodificacin
Para descifrar un archivo comprimido con LZW, hay que saber de antemano el diccionario inicial
utilizado, pero los ingresos adicionales se puede reconstruir, ya que siempre son
simplementeconcatenaciones de las entradas anteriores.
Entrada
Secuencia de
salida
Nueva entrada de diccionario
Comentarios
Bits Cdigo Completo Conjetura
10100 20 T

27: T?

01111 15 O 27: A 28: O?

00010 2 B 28: OB 29: B?

00101 5 E 29: SER 30: E?

01111 15 O 30: EO 31: O?

10010 18 R 31: O 32: R?
crea el cdigo 31 (ltima para caber
en 5 bits)
001110 14 N 32: RN 33: N? para empezar a usar 6 bits
001111 15 O 33: NO 34: O?

010100 20 T 34:
Antiguo
Testamento
35: T?

011011 27 A 35: TT 36: A?

011101 29 SER 36: TOB 37: SER? 36 = A + smbolo primero (B) de
011111 31 O 37: BEO 38: O?
siguiente secuencia codificada
recibida (BE)
100100 36 TOB 38: ORT 39: TOB?

011110 30 EO 39: TOBE 40: EO?

100000 32 RN 40: EOR 41: RN?

100010 34
Antiguo
Testamento
41: RNO 42: OT?

000000 0 #

En cada etapa, el decodificador recibe un cdigo X, X se ve en la tabla y los resultados de la
secuencia que codifica, y conjeturas +? como la entrada del codificador acaba de agregar -
porque el codificador X emitidos por + precisamente porque? no estaba en la mesa, y el
codificador sigue adelante y lo aade. Pero cul es la letra que falta? Es la primera letra en la
secuencia codificada por el siguiente cdigo Z que el decodificador recibe. As que el decodificador
Z, lo decodifica en la secuencia de y toma la primera letra Z y tachuelas que en el extremo de
en la entrada del diccionario al lado.
Esto funciona siempre y cuando los cdigos recibidos se encuentran en el diccionario del
decodificador, por lo que puede ser decodificado en secuencias. Qu sucede si el decodificador
recibe un cdigo Z que todava no est en su diccionario? Puesto que el decodificador es siempre
apenas un cdigo detrs del codificador, Z puede estar en el diccionario codificador slo si el
codificador slogener, al emitir la X de cdigo anterior para . ? Por lo tanto los cdigos Z algunos
que es + , y el decodificador puede determinar el carcter desconocido de la siguiente manera:
1. El decodificador ve X y Z.
2. Se sabe que los cdigos de la X secuencia y cdigos Z alguna secuencia desconocida.
3. Se sabe que el codificador acaba de agregar al cdigo Z + un personaje desconocido,
4. y sabe que el personaje desconocido es la primera letra z de .
5. Sin embargo, la primera letra de (= +?), Entonces tambin debe ser la primera letra de
.
6. Por lo tanto debe ser + x, donde x es la primera letra de .
7. As, las cifras decodificador qu cdigos Z a pesar de que no est en la mesa,
8. y al recibir la Z, el decodificador decodifica como + x, y aade + x en la tabla como el
valor de Z.
Esta situacin se produce cuando el codificador se encuentra la entrada de la cScSc forma,
donde c es un carcter nico, S es una cadena y cS ya est en el diccionario, pero CSC no lo
es. El codificador emite el cdigo para el CS, poniendo un nuevo cdigo de CSC en el
diccionario. A continuacin se ve CSC en la entrada (a partir de la segunda cScSc c) y emite el
nuevo cdigo que acaba de insertar. El argumento anterior muestra que cada vez que el
decodificador recibe un cdigo que no en su diccionario, la situacin debe verse as.
A pesar de la entrada de cScSc forma podra parecer poco probable, este patrn es bastante
comn cuando el flujo de entrada se caracteriza por la repeticin significativa. En las cadenas de
particular, siempre de un solo personaje (que son comunes en los tipos de imgenes LZW se utiliza
a menudo para codificar) en repetidas ocasiones generan los patrones de este tipo.
[ editar ]Adems de codificacin
El sencillo esquema descrito anteriormente se centra en el algoritmo LZW s mismo. Muchas
aplicaciones se aplicarn, adems de codificacin para la secuencia de smbolos de
salida. Algunos paquetes del flujo codificado como caracteres imprimibles usando alguna forma
de binario a codificacin de texto , lo que aumentar la longitud codificada y disminuir la frecuencia
de compresin. Por el contrario, la compresin mayor a menudo se puede lograr con un codificador
de entropa de adaptacin. Como un codificador calcula la distribucin de probabilidad para el valor
del smbolo al lado, sobre la base de las frecuencias observadas de los valores hasta ahora. Un
estndar de codificacin de la entropa como Huffman o aritmtica de codificacin se utiliza
cdigos ms cortos para los valores con mayores probabilidades.
[ editar ]Usos
Compresin LZW se convirti en el primero ampliamente utilizado mtodo universal de compresin
de datos en las computadoras. Una gran Ingls archivo de texto por lo general puede ser
comprimido a travs de LZW a la mitad de su tamao original.
LZW se utiliza en el programa de dominio pblico comprimir , que se convirti en una utilidad ms o
menos estndar en Unix de sistemas alrededor del ao 1986. Desde entonces, ha desaparecido de
muchas distribuciones, tanto por infringir la patente LZW y porque gzip produjo mejores tasas de
compresin con la LZ77 basado DESINFLAR algoritmo, pero a partir de 2008, al menos en
FreeBSD incluye comprimir y descomprimir , como parte de la distribucin. Varias otras utilidades
de compresin LZW populares tambin se utiliza, o estrechamente relacionados con los mtodos.
LZW se hizo muy utilizado cuando se convirti en parte del GIF formato de imagen en
1987. Tambin puede (opcionalmente) se utiliza en TIFF y PDF archivos. (Aunque LZW est
disponible en Adobe Acrobat software, Acrobat utiliza, por omisin DESINFLAR para la mayora de
texto y el color de mesa basado en datos de imagen en archivos PDF.)
[ editar ]Las patentes
Diversas patentes han sido emitidas en el Estados Unidos y otros pases de algoritmos LZW y
similares. LZ78 fue cubierto por la patente de EE.UU. 4.464.650 por Lempel, Ziv, Cohn, y Eastman,
asignada a Sperry Corporation , ms tarde Unisys Corporation, presentada el 10 de agosto de
1981. Dos patentes de los EE.UU. fueron emitidos por el algoritmo LZW: la patente de EE.UU.
4.814.746 por Victor S. Miller y Mark N. Wegman y asignado a IBM , presentada originalmente el 1
de junio de 1983, y patentes de EE.UU. 4.558.302 por Welch, asignada a Sperry Corporation,
despus de Unisys Corporation, presentada el 20 de junio de 1983. El 20 de junio de 2003, esta
patente del algoritmo LZW expir [1] . Todas las patentes en todo el mundo en el algoritmo LZW
tambin han vencido (ver Graphics Interchange Format # Unisys y la aplicacin de las patentes
LZW ).
Patente de EE.UU. 4.558.302 recibido una gran cantidad de prensa negativa despus de la
compresin LZW se utiliza en el formato de imagen GIF.
[ editar ]Variantes
LZMW (1985, por V. Miller, M. Wegman)
[3]
- Bsquedas de entrada para la cadena ms larga
que ya estn en el diccionario (el "actual" partido), aade la concatenacin del partido anterior
con el partido actual en el diccionario. (Las entradas de diccionario por lo tanto crecer ms
rpidamente, pero este esquema es mucho ms complicada de implementar.) Miller y
Wegman tambin sugiere eliminar las entradas de baja frecuencia del diccionario cuando el
diccionario se llena.
LZAP (1988, por James Storer,)
[4]
- la modificacin de LZMW: en lugar de aadir slo la
concatenacin del partido anterior con el partido actual en el diccionario, aadir las
concatenaciones del partido anterior con cada subcadena inicial de la partida actual. (. "AP" se
refiere a "todos los prefijos") Por ejemplo, si el partido anterior es "wiki" y el partido actual es
"pedia", el codificador LZAP aade cinco nuevas secuencias en el diccionario: "wikip", "wikipe"
"wikiped", "wikipedi", y "wikipedia", donde el codificador LZMW slo agrega la secuencia de
una "wikipedia". Esto elimina parte de la complejidad de LZMW, a costa de aadir ms
entradas de diccionario.
LZWL slaba es una variante basada en LZW.

REFERENCIA:
http://translate.google.com.mx/translate?hl=es&langpair=en|es&u=http://en.wikipedia.org/wiki/
Lempel%25E2%2580%2593Ziv%25E2%2580%2593Welch

Lempel-Ziv [1977], o LZ77 es una adaptacin diccionario basado en
elalgoritmo de compresin. LZ77 utiliza el texto visto anteriormente
paraconstruir un diccionario. El diccionario se compone de todas las
cadenas en una ventana en la corriente de entrada ledo previamente.
Su estructura principal de datos es una ventana de texto, dividido en
dos partes. La primera parte es un gran bloque de texto decodificado a
cabo en una ventana de tamao fijo y la segunda parte es un buffer de
preanlisisque ha ledo en los caracteres de la entrada, pero todava no
codificado.
Smbolos de la memoria intermedia se comparan con los datos en la
ventana de tamao fijo. El algoritmo intenta hacer coincidir el contenido
del bfer delectura en adelanto a una cadena en la ventana de tamao
fijo.
En general, un diccionario basado en la compresin reemplaza frases
con fichas. Si el nmero de bits de la seal es menor que el nmero
de bits en la frase, la compresin se producir.

LZW Fundamentos
El original enfoque de Lempel Ziv de compresin de datos fue publicado por primera vez en en 1977,
seguido por un mtodo alternativo en 1978. Refinamientos Terry Welch para el algoritmo de 1978 se
public en 1984. El algoritmo es sorprendentemente simple. En pocas palabras, la compresin LZW
reemplaza las cadenas de caracteres con los cdigos individuales. No hace ningn anlisis del texto de
entrada. Por el contrario, slo se suma cada nueva cadena de caracteres que ve a una tabla de cadenas. La
compresin se produce cuando un nico cdigo es la produccin en lugar de una cadena de caracteres.
El cdigo que las salidas algoritmo LZW puede ser de cualquier longitud arbitraria, sino que debe tener ms
bits en l de un solo carcter. Los primeros 256 cdigos (cuando se utiliza ocho caracteres bits) por defecto
que se asigna al conjunto de caracteres estndar. Los cdigos restantes se asignan a las cadenas a medida
que avanza el algoritmo. El programa de ejemplo se ejecuta como se muestra con 12 cdigos de bits. Esto
significa que los cdigos de 0 a 255 se refieren a los bytes individuales, mientras que los cdigos se refieren
al 256-4095 subcadenas.
Compresin
El algoritmo de compresin LZW en su forma ms simple se muestra en la Figura 1. Un rpido examen del
algoritmo LZW muestra que siempre est tratando de cdigos de salida para las cadenas que ya se
conocen. Y cada vez que un nuevo cdigo de salida, una nueva cadena se aade a la tabla de cadenas.
Rutina LZW_COMPRESS
Texto sin formato
CDIGO:
1. CADENA = conseguir carcter de entrada
2. Si bien todava hay caracteres de entrada DO
3. CARACTER = conseguir carcter de entrada
4. Si la cadena + personaje se encuentra en la tabla de cadenas se
5. CADENA = cadena + personaje
6. ELSE
7. salida el cdigo de CADENA
8. CADENA DE CARACTERES + aadir a la tabla de cadenas
9. CADENA = PERSONAJE
10. FIN de SI
11. FIN de MIENTRAS
12. salida el cdigo de CADENA

El algoritmo de compresin
Figura 1
Una cadena de ejemplo para demostrar que el algoritmo se muestra en la Figura 2. La cadena de entrada es
una breve lista de palabras en Ingls separados por el carcter '/'. Paso a paso por el inicio del algoritmo
para esta cadena, se puede ver que el primer paso por el bucle, se realiza una comprobacin para ver si la
cadena "/ W" est en la tabla. Dado que no es, el cdigo de '/' es la produccin, y la cadena "/ W" se agrega
a la tabla. Ya que tenemos 256 caracteres ya definidos para los cdigos de 0 a 255, la definicin de la
primera cadena se puede asignar el cdigo 256. Despus de la tercera letra, 'E', que se ha ledo en el cdigo
de la segunda cadena, "NOSOTROS" se agrega a la tabla, y el cdigo de 'W' es la carta de salida.Esto contina
hasta que en la segunda palabra, '/' los personajes y la 'W' se leen, igualando el nmero de cuerda 256. En
este caso, el cdigo 256 es el producto, y una cadena de tres caracteres que se aade a la tabla de
cadenas. The process continues until the string is exhausted and all of the codes have been output.

Input String = /WED/WE/WEE/WEB/WET
Character Input Code Output New code value New String
/ W / 256 / W
E W 257 NOSOTROS
D E 258 ED
/ D 259 D /
NOSOTROS 256 260 / WE
/ E 261 E /
WEE 260 262 /WEE
/ W 261 263 E / W
EB 257 264 WEB
/ B 265 B /
MOJADO 260 266 /WET
EOF T

The Compression Process
Figura 2
The sample output for the string is shown in Figure 2 along with the resulting string table. As can be seen,
the string table fills up rapidly, since a new string is added to the table each time a code is output. In this
highly redundant input, 5 code substitutions were output, along with 7 characters. If we were using 9 bit
codes for output, the 19 character input string would be reduced to a 13.5 byte output string. Of course, this
example was carefully chosen to demonstrate code substitution. In real world examples, compression
usually doesn't begin until a sizable table has been built, usually after at least one hundred or so bytes have
been read in.
Descompresin
The companion algorithm for compression is the decompression algorithm. It needs to be able to take the
stream of codes output from the compression algorithm, and use them to exactly recreate the input stream.
One reason for the efficiency of the LZW algorithm is that it does not need to pass the string table to the
decompression code. The table can be built exactly as it was during compression, using the input stream as
data. This is possible because the compression algorithm always outputs the STRING and CHARACTER
components of a code before it uses it in the output stream. This means that the compressed data is not
burdened with carrying a large string translation table.
Routine LZW_DECOMPRESS
Texto sin formato
CDIGO:
1. Read OLD_CODE
2. output OLD_CODE
3. WHILE there are still input characters DO
4. Read NEW_CODE
5. STRING = get translation of NEW_CODE
6. output STRING
7. CHARACTER = first character in STRING
8. add OLD_CODE + CHARACTER to the translation table
9. OLD_CODE = NEW_CODE
10. END of WHILE

The Decompression Algorithm
Figura 3
The algorithm is shown in Figure 3. Just like the compression algorithm, it adds a new string to the string
table each time it reads in a new code. All it needs to do in addition to that is translate each incoming code
into a string and send it to the output.
Figure 4 shows the output of the algorithm given the input created by the compression earlier in the article.
The important thing to note is that the string table ends up looking exactly like the table built up during
compression. The output string is identical to the input string from the compression algorithm. Note that the
first 256 codes are already defined to translate to single character strings, just like in the compression code.

Input Codes: / WED 256 E 260 261 257 B 260 T
Input/
NEW_CODE
OLD_CODE
STRING/
Salida
CARCTER New table entry
/ / /

W / W W 256 = /W
E W E E 257 = WE
D E D D 258 = ED
256 D / W / 259 = D/
E 256 E E 260 = /WE
260 E / WE / 261 = E/
261 260 E / E 262 = /WEE
257 261 NOSOTROS W 263 = E/W
B 257 B B 264 = WEB
260 B / WE / 265 = B/
T 260 T T 266 = /WET
The Decompression Process
Figura 4
La trampa
Unfortunately, the nice simple decompression algorithm shown in Figure 4 is just a little too simple. There is
a single exception case in the LZW compression algorithm that causes some trouble to the decompression
side. If there is a string consisting of a (STRING,CHARACTER) pair already defined in the table, and the input
stream then sees a sequence of STRING, CHARACTER, STRING, CHARACTER, STRING, the compression
algorithm will output a code before the decompressor gets a chance to define it.
A simple example will illustrate the point. Imagine the the string JOEYN is defined in the table as code 300.
Later on, the sequence JOEYNJOEYNJOEY occurs in the table. The compression output will look like that
shown in Figure 5.

Input String: ...JOEYNJOEYNJOEY
Character Input New Code/String Code Output
JOEYN 300 = JOEYN 288 (JOEY)
A 301 = NA N
. . .
. . .
. . .
JOEYNJ 400 = JOEYNJ 300 (JOEYN)
JOEYNJO 401 = JOEYNJO 400 (???)
A problem
Figura 5
When the decompression algorithm sees this input stream, it first decodes the code 300, and outputs the
JOEYN string. After doing the output, it will add the definition for code 399 to the table, whatever that may
be. It then reads the next input code, 400, and finds that it is not in the table. This is a problem, what do we
do?
Fortunately, this is the only case where the decompression algorithm will encounter an undefined code.
Since it is in fact the only case, we can add an exception handler to the algorithm. The modified algorithm
just looks for the special case of an undefined code, and handles it. In the example in Figure 5, the
decompression routine sees a code of 400, which is undefined. Since it is undefined, it translates the value
of OLD_CODE, which is code 300. It then adds the CHARACTER value, which is 'J', to the string. This results in
the correct translation of code 400 to string "JOEYNJ".
Routine LZW_DECOMPRESS
Texto sin formato
CDIGO:
1. Read OLD_CODE
2. output OLD_CODE
3. CHARACTER = OLD_CODE
4. WHILE there are still input characters DO
5. Read NEW_CODE
6. IF NEW_CODE is not in the translation table THEN
7. STRING = get translation of OLD_CODE
8. STRING = STRING+CHARACTER
9. ELSE
10. STRING = get translation of NEW_CODE
11. END of IF
12. output STRING
13. CHARACTER = first character in STRING
14. add OLD_CODE + CHARACTER to the translation table
15. OLD_CODE = NEW_CODE
16. END of WHILE

The Modified Decompression Algorithm
Figura 6
The Implementation Blues
The concepts used in the compression algorithm are very simple -- so simple that the whole algorithm can
be expressed in only a dozen lines. Implementation of this algorithm is somewhat more complicated, mainly
due to management of the string table.
In the code accompanying this article, I have used code sizes of 12, 13, and 14 bits. In a 12 bit code program,
there are potentially 4096 strings in the string table. Each and every time a new character is read in, the
string table has to be searched for a match. If a match is not found, then a new string has to be added to the
table. This causes two problems. First, the string table can get very large very fast. If string lengths average
even as low as three or four characters each, the overhead of storing a variable length string and its code
could easily reach seven or eight bytes per code.
In addition, the amount of storage needed is indeterminate, as it depends on the total length of all the
strings.
The second problem involves searching for strings. Each time a new character is read in, the algorithm has to
search for the new string formed by STRING+CHARACTER. This means keeping a sorted list of strings.
Searching for each string will take on the order of log2 string comparisons. Using 12 bit words means
potentially doing 12 string compares for each code. The computational overhead caused by this would be
prohibitive.
The first problem can be solved by storing the strings as code/character combinations. Since every string is
actually a combination of an existing code and an appended character, we can store each string as single
code plus a character. For example, in the compression example shown, the string "/WEE" is actually stored
as code 260 with appended character E. This takes only three bytes of storage instead of 5 (counting the
string terminator). By backtracking, we find that code 260 is stored as code 256 plus an appended character
E. Finally, code 256 is stored as a '/' character plus a 'W'.
Doing the string comparisons is a little more difficult. Our new method of storage reduces the amount of
time for a string comparison, but it doesn't cut into the the number of comparisons needed to find a match.
This problem is solved by storing strings using a hashing algorithm. What this means is that we don't store
code 256 in location 256 of an array. We store it in a location in the array based on an address formed by
the string itself. When we are trying to locate a given string, we can use the test string to generate a hashed
address, and with luck can find the target string in one search.
Dado que el cdigo de una determinada cadena ya no es conocida slo por su posicin en la matriz, tenemos
que almacenar el cdigo de una determinada cadena, junto con los datos de cadena. En el programa
adjunto, existen tres elementos de la matriz de cada cadena. Son code_value [i], prefix_code [i], y
append_character [i].
Cuando queremos aadir un nuevo cdigo de la tabla, se utiliza la funcin hash en find_match rutina para
generar el valor correcto de i. En primer lugar find_match genera una direccin, a continuacin, comprueba
si el lugar ya est en uso por una cadena diferente. Si es as, se realiza una investigacin secundaria hasta un
lugar abierto se encuentra.
La funcin de hash en el uso de este programa es un tipo simple XOR funcin hash. El prefijo y el carcter
aadido se combinan para formar una direccin de la matriz. Si el contenido del prefijo y el carcter de la
matriz son un partido, la direccin correcta se devuelve. Si ese elemento de la matriz est en uso, una sonda
fija de compensacin se utiliza para buscar nuevas ubicaciones. Esto contina hasta que un espacio vaco se
encuentra, o se encuentra una coincidencia. Mediante el uso de una mesa cerca de 25% mayor que el
necesario, el nmero medio de bsquedas en la tabla general se mantiene por debajo de 3. El rendimiento
puede mejorarse aumentando el tamao de la tabla.
Tenga en cuenta que para que la sonda secundaria para trabajar siempre, el tamao de la tabla debe ser un
nmero primo. Esto se debe a que la sonda puede ser cualquier nmero entero entre 0 y el tamao de la
tabla. Si la sonda y el tamao de la tabla no primos entre s, una bsqueda de una ranura abierta puede
fallar incluso si todava hay plazas disponibles abierto.
Implementar el algoritmo de descompresin tiene su propio conjunto de problemas. Uno de los problemas
del cdigo de compresin desaparece. Cuando se comprime, tenemos que buscar en la tabla de una
determinada cadena. Durante la descompresin, estamos buscando un cdigo particular. Esto significa que
podemos guardar los cdigos de prefijo y los caracteres adjunta en la tabla indexada por su cdigo de
cadena. Esto elimina la necesidad de una funcin hash, y libera la matriz utilizada para almacenar los valores
de cdigo.
Por desgracia, el mtodo que est utilizando el almacenamiento de valores de cadena causa de las cuerdas
para ser decodificados en el orden inverso. Esto significa que todos los personajes de una determinada
cadena tiene que ser decodificado en un bfer de pila, entonces la salida en orden inverso. En el programa
de aqu esto se hace en la funcin decode_string. Una vez que este cdigo est escrito, el resto del
algoritmo se convierte en un cdigo muy fcilmente.
Uno de los problemas encontrados al leer en los flujos de datos es determinar cundo se ha llegado al final
del flujo de entrada de datos. En esta aplicacin particular, se han reservado el ltimo cdigo definido,
MAX_VALUE, como un fin especial del indicador de datos. Si bien esto puede no ser necesaria cuando se lee
en los archivos de datos, es muy til cuando la lectura de buffers comprimido sin memoria. La costa de
perder un cdigo definido es mnimo en comparacin con la comodidad.
Resultados
Es algo difcil de caracterizar los resultados de cualquier tcnica de compresin de datos. El nivel de
compresin alcanzado vara un poco dependiendo de varios factores. Destaca la compresin LZW cuando se
enfrentan a flujos de datos que tiene algn tipo de cadenas repetidas. Debido a esto, lo hace muy bien
cuando se comprime el texto Ingls. Niveles de compresin de 50% o ms se debe esperar. Del mismo
modo, la compresin de las pantallas de guarda y muestra por lo general se muestran muy buenos
resultados.
Tratando de comprimir los archivos de datos binarios es un poco ms arriesgado. Dependiendo de los datos,
la compresin puede o no puede dar buenos resultados. En algunos casos, los archivos de datos se
comprimen an ms que el texto. Un poco de experimentacin por lo general le dar una idea de si sus
datos se comprimen bien o no.
Su ejecucin
El cdigo que acompaa a este artculo funciona. Sin embargo, se ha escrito con el objetivo de ser
esclarecedor, no eficiente. Algunas partes del cdigo son relativamente ineficaces. Por ejemplo, la entrada
de longitud variable y las rutinas de produccin son cortos y fciles de entender, pero requieren una gran
cantidad de gastos generales. Un programa de LZW con longitud fija 12 cdigos de bits podra experimentar
una mejora real en la velocidad de grabacin con slo estas dos rutinas.
Un problema con el cdigo que aparece aqu es que no se adapta bien a la compresin de archivos de
diferentes tamaos. Utilizando 14 o 15 cdigos de bits proporciona una mejor relacin de compresin de
archivos de gran tamao, (porque tienen una tabla de cadenas ms grandes para trabajar), pero en realidad
tiene un peor rendimiento en un pequeo archivo. Programas como ARC solucionar este problema
mediante el uso de cdigos de longitud variable. Por ejemplo, mientras que el valor de next_code es entre
256 y 511, ARC entradas y salidas de 9 cdigos de bits. Cuando aumenta el valor de next_code hasta el
punto en 10 cdigos de bits son necesarios, tanto en la compresin y descompresin de las rutinas de
ajustar el tamao del cdigo. Esto significa que los 12 bits y 15 bits versiones del programa va a hacer igual
de bien en archivos pequeos.
Otro de los problemas en los archivos de tiempo es que con frecuencia la relacin de compresin empieza a
degradarse a medida que ms se lee el archivo in La razn de esto es simple. Desde la tabla de cadenas es de
tamao finito, despus de un cierto nmero de cadenas se han definido, no se pueden agregar ms.Sin
embargo, la tabla de cadenas slo es bueno para la parte del archivo que fue ledo en tiempo de su
construccin. Ms tarde, las secciones del archivo puede tener caractersticas diferentes, y realmente
necesita una tabla de cadenas diferentes.
La manera convencional de resolver este problema es controlar la relacin de compresin. Despus de la
tabla de cadenas est lleno, el compresor observa para ver si la relacin de compresin degrada. Despus de
un cierto grado de degradacin, toda la tabla se vaca, y se reconstruy a partir de cero. El cdigo de
expansin se marca cuando esto ocurre al ver un cdigo especial de la rutina de compresin.
Un mtodo alternativo sera realizar un seguimiento de la frecuencia con que las cadenas se van a utilizar y
lavar peridicamente los valores que se usan muy poco. Una tcnica de adaptacin, como esto puede ser
muy difcil de implementar en un programa de tamao razonable.
Una ltima tcnica para la compresin de los datos es tomar los cdigos LZW y ejecutar a travs de una
adaptacin Huffman filtro. Esto generalmente se explotan unos pocos puntos porcentuales ms de
compresin, pero a costa de una considerable complejidad mayor en el cdigo, as como un poco ms de
tiempo de ejecucin.
Portabilidad
El cdigo de enlace a continuacin fue escrito y probado en MS-DOS mquinas, y ha compilado y ejecutado
con xito con varios compiladores de C. Debe ser portable a cualquier mquina que soporta enteros de 16
bits y 32 largos en C. MS-DOS compiladores C suelen tener problemas para trabajar con matrices de ms de
64 Kbytes, la prevencin de una fcil implementacin de 15 o 16 cdigos de bits en este programa. En las
mquinas con procesadores diferentes, tales como VAX, estas restricciones se levantan, y con tamaos ms
grandes cdigo se convierte en mucho ms simple.
Adems, portar el cdigo a lenguaje ensamblador debe ser muy sencillo en cualquier mquina que soporta
16 bits y 32 de matemticas. Mejoras significativas en el rendimiento podra verse de esta
manera.Implementaciones en otros lenguajes de alto nivel debera ser simple.
Bibliografa
1. Terry Welch, "una tcnica de compresin de datos de alto rendimiento", Informtica, junio 1984
2. J. Ziv y Lempel A., "Un algoritmo universal para la compresin de datos secuenciales", IEEE
Transactions on Information Theory, mayo de 1977
3. > Rudy Rucker, "Herramientas de la Mente", Houghton Mifflin Company, 1987