1 #LyX 1.3 created this file. For more info see http://www.lyx.org/
11 \paperpackage widemarginsa4
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation indent
21 \quotes_language english
25 \paperpagestyle default
29 Organización de Datos (75.06)
46 Leandro Lucarella (77891)
48 Ricardo Markiewicz (78226)
51 Primera Entrega, 28 de Junio del 2004
55 \begin_inset LatexCommand \tableofcontents{}
65 Método de compresión utilizado
68 Dada la asignación de confeccionar un compresor de archivos de cualquier
69 índole, con alguna optimización particular para archivos de texto, hemos
70 optado por la implementación del esquema:
72 Block Sorting + Move to front + Huffman Estático.
76 Si bien un compresor estadístico final más robusto como el
84 podrían producir niveles de compresión un tanto mejores, a fines de resguardar
85 la confección de un compresor estable y poseer tiempo suficiente para realizar
86 pruebas y optimizaciones, se optó por el
91 No obstante, se comparó con una implementación de
95 de ejemplo obtenida de Internet y se observaron que los resultados eran
96 muy similares, a veces obteniendo un mejor nivel de compresión y a veces
97 obteniendo uno peor, descartando luego de estas pruebas la posibilidad
98 de extender el estático al dinámico.
101 Además de la capacidad natural de todo compresor (esto es, de comprimir/descompr
102 imir), la implementación que describiremos a continuación cuenta con característ
103 icas especiales que se verán detallados en la
106 \begin_inset LatexCommand \ref{sec:Features-Especiales}
113 Dichas características se resumen a:
116 Persistencia del Modelo Orden-0 de
131 (Agrupación de Ceros, aplicado a la salida del
142 (Optimización para textos detallada posteriormente)
148 Antes de pasar a la descripción de la implementación de nuestro compresor,
149 detallaremos el modo de uso.
157 Como hemos ancitipado anteriormente, el compresor cuenta con features especiales
158 que pueden ser utilizados a través de opciones en la invocación del programa.
159 Antes de pasar a su descripción, notamos la invocación general para comprimir
160 y descomprimir un archivo como se pidió en el enunciado
170 es un enlace simbólico a
174 , nombre real del ejecutable.
186 ./grupo11 -c [-t volsize] sourcefile targetfile
195 el nombre del archivo a comprimir y
199 el nombre del archivo comprimido.
208 ./grupo11 -d sourcefile targetfile
217 el nombre del archivo a descomprimir y
221 el nombre del archivo descomprimido.
231 pcional que permite generar un archivo comprimido multivolumen, donde volsize
232 será el tamaño en kbytes de cada volúmen, excepto el último que podrá ser
237 \begin_inset LatexCommand \label{sub:Execution-Flags}
244 Ademas de los flags standards que hemos visto recién, nuestro compresor
245 cuenta con otra serie de ellos para la utilización de los features especiales
246 que veremos más adelante.
247 A fines de documentar la totalidad de los flags de ejecución, detallamos
248 los anteriores y los adicionales a continuación:
250 \labelwidthstring 00.00.0000
256 Indica que se desea comprimir un archivo (mutualmente exclusivo con
260 , al menos uno debe estar presente).
262 \labelwidthstring 00.00.0000
268 Indica que se desea descomprimir un archivo (mutualmente exclusivo con
273 , al menos uno debe estar presente).
275 \labelwidthstring 00.00.0000
281 Indica que se desea un archivo comprimido en multivolumenes.
282 Seguido a dicho flag se debe indicar el tamaño en KBytes que se desea para
285 \labelwidthstring 00.00.0000
291 Puede ser utilizado únicamente en una compresión y activa el feature de
298 \labelwidthstring 00.00.0000
304 Puede ser utilizado únicamente en una compresión y graba el modelo de orden-0
309 generado durante la compresión del archivo (en un archivo de extensión
317 ), para que luego pueda ser reutilizado en otra compresión.
319 \labelwidthstring 00.00.0000
325 Puede ser utilizado únicamente en una compresión y carga un modelo de orden-0
330 para ser utilizado en la compresión del archivo especificado, evitando
331 el escaneado del archivo a comprimir.
332 Deberá ser sucedido por el nombre del archivo que posee el modelo.
334 \labelwidthstring 00.00.0000
340 Especifica la calidad (nivel) de compresión.
341 Puede ser un valor entre 0 y 9, siendo 0 el menor nivel de compresión (más
342 rápido) y 9 el máximo (más lento).
343 Por omisión se utiliza un nivel de compresión 5.
344 \layout Subsubsection*
349 Damos a continuación unos breves ejemplos de invocación utilizando diferentes
353 Compresión multivolumen (de 1024KB, cada uno):
357 ./grupo11 -c -t 1024 libro.txt libro.j
368 ./grupo11 -cz libro.txt libro.j
371 Compresión grabando modelo de
379 ./grupo11 -cs libro.txt libro.j
382 Compresión con carga de
390 ./grupo11 -c libro.txt libro.j -m modelo.ftb
393 Compresión de máxima calidad y volúmenes de 100KB:
397 ./grupo11 -czt100 -q9 libro.txt libro.j
400 Descompresión de cualquiera de los anteriores:
404 ./grupo11 -d libro.j libro_descomprimido.txt
422 Si bien no ahondaremos en detalles de implementación que pueden observarse
423 en la documentación generada por doxygen que acompaña este informe, pasamos
424 a presentar la interfaz a través de la cual el usuario podrá utilizar este
426 Antes, es necesario comentar que el estado del compresor, se mantiene a
427 través de una estructura definida como
431 , en la cual se especificarán cosas tales como si el compresor actua sobre
432 archivos o chunks de datos, si es un huffman canonico o standard, archivo
433 a comprimir, archivo destino, etc.
438 El compresor y/o descompresor Huffman Estático, será inicializado y desinicializ
439 ado utilizando las rutinas:
445 HUFF_STATE *shuff_init_encoder_byfile(char *inputfile, char *outputfile,
452 HUFF_STATE *shuff_init_encoder_bychunk(char *outputfile, long volsize);
458 HUFF_STATE *shuff_init_decoder(char *inputfile, char *outputfile);
464 void shuff_deinit_encoder(HUFF_STATE *shuff);
470 void shuff_deinit_decoder(HUFF_STATE *shuff);
473 Para llevar a cabo la compresión efectiva de un archivo o chunks de datos,
474 se cuentan con las siguientes rutinas:
479 int shuff_encode_file(HUFF_STATE *shuff);
484 int shuff_decode_file(HUFF_STATE *shuff);
489 int shuff_scanfreq_chunk(HUFF_STATE *shuff, char* chunk, int chunksize);
494 int shuff_decode_chunk(HUFF_STATE *shuff, char *chunk, int chunksize, int
498 Operación sobre archivos o chunks
503 Dado que se requería la utilización de este compresor en la etapa final
504 de un BS+MTF, el mismo proporciona funcionalidad para comprimir directamente
505 un archivo especificado, o bien para realizar la compresión de chunks de
506 datos, que en nuestro caso serán las salidas del Move to Front.
509 Persistencia del Modelo Estadístico de Orden 0
514 A fines de poder grabar o cargar un modelo de orden-0 el cual simplemente
515 consiste en una tabla de frecuencias/probabilidades de los 255 symbolos
516 posibles en un archivo, dando lugar al Huffman Canónico que será explicado
517 posteriormente, se cuenta con dos funciones:
527 \begin_inset LatexCommand \label{sec:Features-Especiales}
531 Optimizaciones y Características adicionales
534 Como fue anticipado al inicio de este documento, nuestro compresor cuenta
535 con funcionalidad extra que permite en ciertos casos obtener mejores niveles
537 Pasamos a describir las mismas una por una, terminando por último con una
538 optimización específica para textos.
544 Dada la naturaleza del Huffman Estático que hemos implementado como el compresor
545 estadístico final de la cadena
549 , el mismo se vale de un modelo estadístico de orden-0, el cual es obtenido
550 realizando una pasada inicial al archivo a comprimir, en la cual obtiene
551 una tabla de frecuencias/probabilidades, y la cual es utilizada para generar
552 el árbol de Huffman, que a su vez da origen a una tabla de códigos prefijos
553 que finalmente es utilizada en el compresor, para codificar los símbolos
554 o caracteres del archivo original.
557 Dicho esto, destacamos la extensión que hemos realizado a nuestro compresor
558 de Huffman para que pueda guardar y/o cargar un modelo estadístico de orden-0
559 y el usuario pueda por ejemplo utilizar para comprimir cualquier archivo
560 de texto, un modelo que él crea óptimo para la compresión de dichos archivos,
561 en vez de generar un modelo diferente para cada archivo que comprime.
564 Esta capacidad de un compresor de Huffman, se la conoce como Huffman Canónico,
565 y se encuentra presente en nuestro compresor.
566 Para saber más sobre su modo de uso, dirigirse a la sección
569 \begin_inset LatexCommand \ref{sub:Execution-Flags}
581 Este algoritmo se aplica a la salida del
589 que aumenta la localidad, genera estadísticamente muchas secuencias de
591 Como el Huffman Estático no aprovecha esta característica (comprime igual
600 ), se buscó un método que sí la explote para optimizar el compresor y se
601 llegó a un algoritmo muy simple que bautizamos
608 Cada secuencia de ceros se codifica con 2 bytes, el primero es siempre 0
613 ) y el segundo indica la cantidad de ceros que le siguen.
614 En el caso de haber un byte de valor cero aislado, también se codifica
619 , que indica que viene un cero y luego de ese cero no viene ningún cero
620 más), expandiendo la salida, pero estos son casos aislados que estadísticamente
621 se ven superados por la cantidad de secuencias largas de ceros que son
622 comprimidas a sólo 2 bytes.
623 Además, la salida del
627 (Zero Grouping) es comprimida con Huffman por lo que en casos extremos
628 la expansión no se manifiesta en forma notoria.
631 Como la cantidad de ceros que le siguen al primero en una secuencia es expresada
632 con un byte, sólo se pueden comprimir a 2 bytes secuencias de hasta 256
633 ceros (el primer cero más los 0-255 siguientes).
634 De haber secuencias con mayor cantidad de ceros, simplemente se generan
647 la cantidad de ceros en la secuencia dividido 256, redondeando hacia arriba)
649 Por ejemplo, una secuencia de 257 ceros será expresada como
653 (2 grupos) y una de 525 como
655 0x00 0xFF 0x00 0xFF 0x00 0x0B
658 Nuevamente, se comprobó estadísticamente que las secuencias de ceros rara
659 vez superan los 50 ceros seguidos, por lo que de utilizar más de un byte
660 para expresar la cantidad de ceros que siguen al primero se obtendrían
662 \layout Subsubsection*
669 Salida de MTF: 0 0 0 0 0 0 1 5 3 0 0 0 0 12 0 1 0 0 0 0 0 0 0 0 0 1 1
675 Salida de ZG: 0 5 1 5 3 0 3 12 0 0 1 0 8 1 1
691 Como se puede ver, la salida del MTF es de 33 bytes, mientras que la del
696 es de 22 (incluso cuando hubieron expansiones).
697 Como se podrá ver en las pruebas del capítulo
698 \begin_inset LatexCommand \vref{cha:Benchmarks}
702 , en la mayoría de los casos se logra una mejora introduciendo este algoritmo,
703 y en casos extremos esta mejora llega obtener resultados con la mitad de
704 bpb (bits por byte) que la salida original del
714 Esta optimización se ha realizado específicamente para mejorar la compresión
715 de archivos de texto.
716 La base de esta técnica es la previa confección de un diccionario de palabras
717 (en nuestro caso 255 palabras máximo), a través del cual aplicando un pre-proce
718 samiento al archivo a comprimir, reemplazamos las palabras de ese diccionario
719 que se encuentren en el archivo, por un código de escape sucedido por el
720 índice en el diccionario de la palabra que se abrevia.
723 Es decir, si tenemos el siguiente diccionario de 4 palabras:
739 ; y poseemos el texto:
742 \begin_inset Quotes eld
754 \begin_inset Quotes erd
759 , luego del pre-procesamiento tendremos:
762 \begin_inset Quotes eld
778 \begin_inset Quotes erd
786 Para la confección de un buen diccionario, hemos desarrollado una utilidad
787 que contabiliza las 255 palabras que más aparecen dentro de una fuente
788 especificada, y luego del análisis de varios textos en castellano de toda
789 índole (informáticos, novelas, noticias), se obtiene el diccionario que
790 será entregado con el software.
793 Documentación de la API
796 Para obtener una documentación de la API, se incluye en formato HTML en
797 el CD-ROM la documentación generada con Doxygen para los distintos componentes
799 Esta documentación se encuentra en el directorio
807 \begin_inset LatexCommand \label{cha:Benchmarks}
814 Prueba Calgary Corpus
817 El set de prueba Calgary Corpus Test es utilizado internacionalmente para
818 la prueba y comparación de compresores, contando con archivos diseñados
819 especificamente para estos fines.
820 Es por ello que hemos utilizado dicho set y a continuación exponemos los
824 Bench 1) JACU vs GZIP vs BZIP2
827 Se prueba el set de Calgary utilizando nuestro compresor, y enfrentandolo
828 al GZIP y BZIP2 en términos de tiempo utilizado para la compresion y nivel
829 de compresión (Bits per Byte).
830 Los resultados a continuación: