Mostrar/Ocultar TOC

Tabla de Contenidos del Libro
Prefacio
Capítulo 1: Introducción
Capítulo 2: Fundamentos
Capítulo 3: Mapas de Bits
Capítulo 4: Archivos Vectoriales
Capítulo 5: Metaarchivos
Capítulo 6: Dependencias de Plataforma
Capítulo 7: Conversión de Formatos
Capítulo 8: Trabajando con Archivos Gráficos  
Capítulo 9: Compresión
Capítulo 10: Multimedia
Formato: Adobe Illustrator
Formato: Adobe Photoshop
Formato: Atari ST
Formato: AutoCAD DXF
Formato: Autodesk 3D Studio
Formato: BDF
Formato: BRL-CAD
Formato: BUFR
Formato: CALS Raster
Formato: CGM
Formato: CMU
Formato: DKB
Formato: Dore Raster
Formato: DPX
Formato: Dr. Halo
Formato: DVM Movie
Formato: PostScript Encapsulado
Formato: FaceSaver
Formato: FAX
Formato: FITS
Formato: FLI
Formato: GEM Raster
Formato: GEM VDI
Formato: GIF
Texto en Inglés de Este Formato de Archivo
Imagen del CD-ROM de la 2° Edición
Imagen del CD-ROM de la 1° Edición (Torrent y HTTPS)
Versión Hipertexto del CD-ROM de la 2° Edición (En Inglés)
Versión Hipertexto del CD-ROM de la 2° Edición (En Ruso)

Formato de Archivo — FLI

Formato de Archivo — FLI


NOMBRE: FLI
TAMBIÉN CONOCIDO COMO: Animación FLI, Flic, FLC, FII
TIPO: Animación
COLORES: 64, 256
COMPRESIÓN: Crudo, RLE, y delta
TAMAÑO MÁXIMO DE IMAGEN: 320x200, 64Kx64K
MÚLTIPLES IMÁGENES POR ARCHIVO:
FORMATO NUMÉRICO: Little Endian
ORIGINADOR: Autodesk
PLATAFORMA: Intel
APLICACIONES SOPORTADAS: Autodesk Animator y Animator Pro
ESPECIFICACIÓN EN CD: Sí (descripción resumida por su autor)
CÓDIGO EN CD: No
IMÁGENES EN CD:
MIRA TAMBIÉN: GRASP
UTILIZACIÓN: Usado para almacenar secuencias de animación encontradas en aplicaciones gráficas, sistemas CAD, y juegos de computadora.
COMENTARIOS: Actualmente ocupa un nicho de mercado colonizado por video.




Resumen

El formato de archivo FLI (a veces llamado Flic) es uno de los formatos de animación más populares encontrados en los entornos MS-DOS y Windows actualmente. FLI es usado ampliamente en programas de animación, juegos de computadora, y aplicaciones CAD que requieren manipulación 3D de dibujos vectoriales. Flic, en común con la mayoría de formatos de animación, no soporta datos de audio o video, sino que en su lugar almacena solamente secuencias de datos de imagen estática.

FLI es popular por su diseño simple. Es fácil implementar lectores y escritores FLI en aplicaciones de solo software. FLI también permite la reproducción rápida de animación y no requiere hardware especial para codificar o decodificar sus datos.

FLI es más adecuado para secuencias de animación generadas por computadora o dibujadas a mano, tales como aquellas creadas usando programas de animación y CAD. Estas imágenes logran las mejores tasas de compresión cuando se almacenan usando el formato FLI.

Las imágenes naturales del mundo real también pueden animarse por FLI, pero dichas imágenes usualmente contienen una cantidad moderada de ruido que degradará la capacidad de los algoritmos de codificación de FLI para comprimir los datos y por lo tanto afectará posiblemente la velocidad de la reproducción de la animación. También, entre menos colores haya en la animación, mejores serán las tasas de compresión.

Solo hay dos tipos de archivos de animación FLI. El formato FLI original tiene una extensión de .FLI, tiene una resolución máxima de pantalla de 320x200 pixeles, y solo es capaz de soportar 64 colores. Este formato se creó para usarse por la aplicación Autodesk Animator.

El nuevo formato FLI tiene la extensión .FLC, tiene una resolución máxima de pantalla de 64Kx64K pixeles, y soporta hasta 256 colores. El esquema de compresión de datos usado por los archivos .FLC también es más eficiente que el esquema usado por los archivos .FLI. Las aplicaciones tales como IBM Multimedia Tool Series, Microsoft Video para Windows, y Autodesk Animator Pro soportan todos los archivos .FLC.

Cualquier aplicación capaz de leer los archivos .FLC más recientes debería poder leer y reproducir los archivos .FLI más antiguos también. Sin embargo, la mayoría de escritores de archivo FLI más recientes pueden tener solo la capacidad de crear archivos .FLC. Realmente no hay razón para crear archivos .FLI, a menos que la animación que estés produciendo deba correr bajo software que lea solo el formato .FLI.



Organización del Archivo

Las animaciones FLI son secuencias de imágenes estáticas llamadas cuadros. Cada cuadro contiene una rebanada de los datos de animación. La velocidad de reproducción de la animación se controla especificando la cantidad de demora que ha de ocurrir entre cada cuadro.

Los datos en cada cuadro siempre están mapeados a color. Cada pixel en un cuadro contiene un valor de índice en un mapa de color definido para ese cuadro. Los colores en el mapa pueden cambiar entre uno y otro cuadro según se necesite. Y, sibien el archivo FLI está limitado a desplegar un máximo de 256 colores por cuadro, cada pixel tiene 24 bits de profundidad, lo que resulta en una paleta de más de 16 millones de colores de los cuales elegir.

El formato FLI también soporta varios tipos de compresión de datos. Cada cuadro de una animación FLI típicamente se comprime usando un esquema de codificación delta entre cuadros. Este esquema solo codifica las diferencias entre cuadros adyacentes de imagen y no los cuadros en sí. Esta estrategia resulta en archivos significativamente más pequeños que si cada cuadro estuviera codificado independiente (codificación entre cuadros). Los datos codificados entre cuadros son también muy rápidos de descomprimir y de desplegar.

El primer cuadro de toda animación FLI está comprimido en su totalidad, usando un algoritmo de codificación run-length simple. Ya que solo las diferencias entre cada cuadro sucesivo se codifican, tienens que comenzar en algún lugar. Si un cuadro está delta codificado y los datos comprimidos resultantes son más grandes que los datos originales descomprimidos (bastante posible con imágenes ruidosas naturales), entonces el cuadro puede almacenarse descomprimido.



Detalles del Archivo

La cabecera de un archivo FLI tiene 128 bytes de longitud. Los primeros nueve campos (22 bytes) son los mismos tanto para los archivos .FLI como .FLC. Los últimos 10 campos (106 bytes) contienen datos válidos solo en archivos .FLC y están puestos a 00h en archivos .FLI.

La cabecera del archivo FLI tiene el siguiente formato:

typedef struct _FlicHeader
{
  DWORD FileSize;       /* Tamaño total del archivo */
  WORD  FileId;         /* Indicador de formato de archivo */
  WORD  NumberOfFrames; /* Número total de cuadros */
  WORD  Width;          /* Anchura de pantalla en pixeles */
  WORD  Height;         /* Altura de pantalla en pixeles */
  WORD  PixelDepth;     /* Número de bits por pixeles */
  WORD  Flags;          /* Puesto a 03h */
  DWORD FrameDelay;     /* Demora de tiempo entre cuadros */
  WORD  Reserved1;      /* No usado (puesto a 00h) */
  // Los siguientes campos están a 00h en un archiv .FLI
  DWORD DateCreated;    /* Fecha/Hora de creación de archivo */
  DWORD CreatorSN;      /* Número de serie del programa creador */
  DWORD LastUpdated;    /* Fecha/Hora de creación de última modificación */
  DWORD UpdaterSN;      /* Númer de serie del programa modificador */
  WORD  XAspect;        /* Eje X de la tasa de aspecto de pantalla */
  WORD  YAspect;        /* Eje Y de la tasa de aspecto de pantalla */
  BYTE  Reserved2[38];  /* No usado (puesto a 00h) */
  DWORD Frame1Offset;   /* Offset del primer cuadro */
  DWORD Frame2Offset;   /* Offset del segundo cuadro */
  BYTE  Reserved3[40];  /* No usado (puesto a 00h) */
} FLICHEADER;

FileSize contiene el tamaño total del archivo FLI en bytes.

FileId contiene un valor que identifica el tipo de archivo Flic. Un valor de AF11h indica un archivo .FLI, y un valor de AF12h indica un archivo .FLC.

NumberOfFrames contiene el número total de cuadros de datos de animación. Un archivo .FLC puede contener un máximo de 4000 cuadros; esto no incluye el cuadro de anillo (ring frame).

Width y Height especifican el tamaño de la animación en pixeles.

PixelDepth indica el número de bits por pixel; el valor de este campo siempre es 08h.

Flags siempre está puesto a 03h, como indicación de que el archivo se actualizó apropiadamente.

FrameDelay indica la cantidad de tiempo entre cuadros y se usa para controlar la velocidad de reproducción. Para archivos .FLI, este valor se interpreta en unidades de 1/70 de un segundo. Para archivos .FLC, este valor es unidades de 1/1000 de un segundo.

Reserved1 no se usa y está a 00h.

DateCreated es una marca de fecha/hora (el número de segundos que han ocurrido desde la media noche de Enero 1, 1970) de la fecha en que fue creado el archivo FLI.

CreatorSN contiene el número de serie de la aplicación Animator Pro que creó el archivo FLI. Si el archivo se creó por una aplicación usando la librería de desarrollo FlicLib, el valor de este campo será 46h 4Ch 49h 42h ("FLIB").

LastUpdated es una marca de fecha/hora de MS-DOS que indica la última vez que el archivo FLI se modificó (también en número de segundos desde la media noche de Enero 1 de 1970).

UpdaterSN contiene el número de serie del programa que modificó por última vez el archivo Flic.

XAspect y YAspect contienen la tasa de aspecto de la pantalla usada para crear la animación. Para una pantalla con una resolución de 320x200, la tasa de aspecto es 6:5, y estos campos contienen los valores 6 y 5 respectivamente. Para todaslas otras resoluciones, la tasa de aspecto típicamente es 1:1.

Reserved2 no se usa y está puesto a 00h.

Frame1Offset y Frame2Offset contienen el offset del primer y segundo cuadro, respectivamente, de la animación desde el inicio del archivo. El offset del primer cuadro se usa para identificar el inicio de la animación. El segundo offset se usa como el punto inicial en que la animación vuelve en un ciclo al inicio de la animación desde el cuadro de anillo.

Reserved3 no se usa y está puesto a 00h.

Porciones

Todos los datos en un archivo FLI están encapsulados en porciones. Cada porción es una colección de datos que comienzan con una cabecera y se sigue por los datos de esa porción. Las porciones también pueden contener subporciones de datos con el mismo formato básico. Si un lector Flic encuentra una porción que no reconoce, debería simplemente saltársela.

Cada porción en un archivo FLI comienza con una cabecera de 16 bytes que contiene el siguiente formato:


typedef struct _ChunkHeader
{
  DWORD ChunkSize;        /* Tamaño total de porción */
  WORD  ChunkType;        /* Identificador de porción */
  WORD  NumberOfChunks;   /* Número de subporciones en esta porción */
  BYTE  Reserved[8];      /* No usado (puesto a 00h) */
} CHUNKHEADER;

ChunkSize es el tamaño de la porción en bytes. Este valor incluye el tamaño de la cabecera en sí y cualquier subporción contenida dentro de la porción.

ChunkType es un valor de identificación que indica el formato de la porción y el tipo de datos que contiene.

NumberOfChunks especifica el número de subporciones contenidas dentro de esta porción.

Reserved no se usa y está puesto a 00h.

Como hemos dicho, una porción puede contener subporciones. De hecho, el archivo FLI entero en sí es una única porción que comienza con la estructura FLICHEADER. En archivos .FLC, una estructura CHUNKHEADER opcional puede seguir la estructura FLICHEADER. Esta cabecera secundaria es llamada una cabecera de prefijo. Si está presente, esta cabecera contiene información específica a la animación Animator Pro que no se usa durante la reproducción de la animación. Otras aplicaciones pueden saltarse con seguridad la cabecera de prefijo e ignorar la información que contiene. Las aplicaciones aparte de Animator Pro nunca deberían incluir una cabecera de prefijo en ningún archivo .FLC que creen.

Para la cabecera de prefijo, ChunkSize es el tamaño del archivo FLI entero menos 128 bytes de la cabecera FLICHEADER. ChunkType es F100h. NumberOfChunks contiene el número total de subcabeceras en el archivo.

Siguiendo la cabecera de prefijo está una serie de porciones de cuadros. Cada porción de cuadro contiene un único cuadro de datos de la animación. Para la porción de cuadro, ChunkSize es el número total de bytes en el tamaño, incluyendo la cabecera y todas las subporciones. ChunkType siempre es F1FAh. NumberOfChunks contiene el número total de subporciones en el cuadro. Si NumberOfChunks es 0, entonces este cuadro es idéntico al cuadro anterior, así que no se almacenan datos de mapa de color o de cuadro, y el cuadro anterior se repite con la demora especificada en la cabecera.

Lo siguiente lista todas las subporciones que pueden encontrarse en una porción de cuadro:

Valor de ChunkType Nombre de Porción Descripción de Datos de Porción
04h COLOR_256 Paleta de color de 256 niveles (solo archivos .FLC)
07h DELTA_FLC Datos de cuadro delta comprimidos (solo archivos .FLC)
0Bh COLOR_64 Paleta de colores de 64 niveles (solo archivos .FLI)
0Ch DELTA_FLI Datos de cuadro delta comprimidos (solo archivos .FLI)
0Dh BLACK Datos negros de cuadro
0Fh BYTE_RUN Datos de cuadro comprimidos con RLE
10h FLI_COPY Datos de cuadro descomprimidos
12h PSTAMP Imagen de estampilla postal (solo archivos .FLC)

Lo siguiente lista el arreglo interno general de un archivo FLI:

Cabecera FLI
Cabecera prefija (opcional)
Cuadro 1 (comprimido con RLE)
   subporción PSTAMP (opcional)
   subporción COLOR_256 (256 colores)
   subporción BYTE_RUN
   subporción COLOR_256 (256 colores)
   subporción BYTE_RUN
Cuadro 2 (Delta comprimido)
   subporción COLOR_256 (colors diferentes al mapa anterior)
   subporción DELTA_FLC
Cuadro 3 (descomprimido)
   subporción COLOR_256 (colores diferentes al mapa anterior)
   subporción FLI_COPY
Cuadro 4 (negro)
   subporción BLACK
Cuadro n (Delta comprimidos)
   subporción COLOR_256 (colores diferentes al mapa anterior)
   subporción DELTA_FLC

Cada porción de cuadro contiene al menos dos subporciones: un mapa de color y los datos del cuadro. Los datos del cuadro pueden almacenarse en uno de varios diferentes formatos comprimidos o descomprimidos. El primer cuadro de una animación Flic puede también contener una subporción de estampilla postal adicional. A continuación está una explicación de cada subporción.

Porción DELTA_FLI
La porción DELTA_FLI contiene un único cuadro de datos, el cual se comprime usando codificación delta. Los datos en esta porción contienen las diferencias de valores de pixel entre el cuadro actual y el cuadro anterior. Cada scan line del cuadro que contiene cambios de pixel se codifica en paquetes, y solo se almacenan los valores de los pixeles en la línea que han cambiado.

El esquema de codificación DELTA_FLI es un esquema más antiguo encontrado mayormente en archivos .FLI, aunque los archivos .FLC también pueden contener porciones DELTA_FLI.

El formato de una porción DELTA_FLI se muestra a continuación:

typedef struct _DeltaFliChunk
{
  CHUNKHEADER Header;   /* Cabecera para esta porción */
  WORD LinesToSkip;     /* Número de líneas iniciales a saltar */
  WORD NumberOfLines;   /* Número de líneas codificadas */
  /* Línea codificada (una por número de líneas 'NumberOfLines') */
  struct _Line
  {
   BYTE NumberOfPackets; /* Número de paquetes en esta línea */
   BYTE LineSkipCount;   /* Número de líneas a saltar */
   struct _Packet        /* Paquete codificado (uno/NumberOfPackets) */
    {
     BYTE SkipCount;     /* Número de pixeles a saltar */
     BYTE PacketType;    /* Tipo de codificación usado en este paquete */
     BYTE PixelData[];   /* Datos de pixel para este paquete */
    } Packet[NumberOfPackets];
  } Lines[NumberOfLines];
} DELTAFLICHUNK;

LinesToSkip contiene el número de líneas desde la parte alta de la imagen que no han cambiado desde el cuadro anterior. Este valor se usa para encontrar el primer scan line que contiene deltas.

NumberOfLines indica el número de scan lines codificadas en esta porción.

NumberOfPackets indica el número de paquetes usados para codificar este scan line. Cada scan line codificado comienza con este valor.

LineSkipCount es el número de líneas a saltar para ubicar la siguiente línea codificada.

Cada paquete en cada línea codificada contiene dos valores. SkipCount indica la ubicación de los deltas de pixel en esta línea que están codificados en este paquete. PacketType especifica el tipo de codificación usado en este paquete. Un valor positivo indica que los siguientes pixeles "PacketType" deberían leerse literalmente desde la porción y escribirse a la pantalla. Un valor negativo indica que el valor absoluto de "PacketType" pixeles ha de leerse literalmente desde los datos codificados.

Por ejemplo, supón que tenemos un cuadro con tres scan lines codificadas. El primer número de línea es 25, el cual contiene deltas en los pixeles 4, 22, 23, 24, y 202. El segundo es el número de línea 97, el cual contiene deltas en los pixeles 20 y 54 hasta 67. El tercero es el número de línea 199, en el cual todos los 320 pixeles de la línea han cambiado al mismo color. La secuencia de línea y valores de campos de paquete se muestra a continuación:

LinesToSkip 24 Saltar 24 líneas a la primer línea codificada
NumberOfLines 3 Tres líneas codificadas en este cuadro
Line Línea 1
   NumberOfPackets 3 Tres paquetes codificados en esta línea
   LineSkipCount 71 Saltar 71 líneas a la siguiente línea codificada
      Packet Paquete 1
         SkipCount 4 Saltar 4 pixeles
         PacketType 1 Leer un pixel literalmente
         PixelData 23 Nuevo valor de pixel 4 es 23
      Packet Paquete 2
         SkipCount 17 Saltar 17 pixeles
         PacketType -3 Leer un pixel y repetir 3 veces
         PixelData 65 Nuevo valor de pixeles 22, 23 y 24 es 65
      Packet Paquete 3
         SkipCount 176 Saltar 17 pixeles
         PacketType 1 Leer un pixel y literalmente
         PixelData 65 Nuevo valor de pixel 202 es 17
Line Línea 2
   NumberOfPackets 2 Dos paquetes codificados en esta línea
   LineSkipCount 102 Saltar 102 líneas a la siguiente línea codificada
      Packet Paquete 1
         SkipCount 20 Saltar 20 pixeles
         PacketType 1 Leer un pixel literalmente
         PixelData 121 Nuevo valor de pixel 20 es 121
      Packet Paquete 2
         SkipCount 32 Saltar 32 pixeles
         PacketType 13 Leer los siguientes 13 pixeles literalmente
         PixelData 255 Nuevo valor de pixeles 54 a 67 es 255
Line Línea 3
   NumberOfPackets 2 Dos paquetes codificados en esta línea
   LineSkipCount 0 Última línea codificada en el cuadro
      Packet Paquete 1
         SkipCount 0 Iniciar en el primer pixel en la línea
         PacketType -256 Leer un pixel y repetir 256 veces
         PixelData 0 Nuevo valor de pixeles 0 a 255 es 0
      Packet Paquete 2
         SkipCount 256 ´Saltar 256 pixeles
         PacketType -64 Leer un pixel y repetir 64 veces
         PixelData 0 Nuevo valor de pixeles 256 a 319 es 0

Porción DELTA_FLC
La porción DELTA_FLC es una versión más nueva de la porción DELTA_FLI y se encuentra en todos los archivos .FLC. Esta porción es esencialmente la misma que la porción DELTA_FLI con unas pocas modificaciones de campos. Los valores PixelData almacenados en una porción DELTA_FLC tienen 16 bits de tamaño en lugar de los 8 bits de tamaño de pixel encontrados en la porción DELTA_FLI.

La estructura de una porción DELTA_FLC es como se ve a continuación:

typedef struct _DeltaFlcChunk
{
CHUNKHEADER Header;     /* Cabecera para esta porción */
WORD NumberOfLines;     /* Número de líneas codificadas en la porción */
struct _Line            /* Línea codificad (uno/'NumberOfLines') */
  {
  WORD PacketCount;     /* Cuenta de paquete, cuenta de salto, o último valor de byte */
  /*
  ** WORDs adicionales de datos pueden aparecer en esta ubicación
  */
  struct _Packet        /* Paquete codificado (uno por cuenta 'Count') */
    {
    BYTE SkipCount;     /* Número de pixeles a saltar */
    BYTE PacketType;    /* Tipo de codificación usado en este paquete */
    WORD PixelData[];   /* Datos de pixeles para este paquete */
    } Packet[NumberOfPackets];
  } Lines[NumberOfLines];
} DELTAFLCCHUNK;

El número de campos que ocurren entre el PacketCount y el primer paquete variará dependiendo del valor almacenado en PacketCount. Los dos bits más significativos en PacketCount determinan la interpretación del valor almacenado en este campo. Si estos dos bits son 0, entonces el valor es el número de paquetes que ocurren en esta línea. Los datos de paquete siguen inmediatamente a este campo y no hay valores de WORD adicionales que le sigan.

Un valor de 0 en este campo indica que solo el último pixel en la línea ha cambiado.

Si el bit más significativo (bit 15) es 1 y el siguiente bit (bit 14) es 0, el byte bajo en este WORD ha de almacenarse en el último byte de la línea actual. Un campo WORD que contiene el número de paquetes en esta línea le sigue a este valor.

Si ambos bits, 14 y 15, están a 1, PacketCount contiene una cuenta de salto en la siguiente línea codificada. A PacketCount puede entonces seguirle valores adicionales WORD que contienen una cuenta de paquete, cuenta de salto, o últimos valores de byte.

Porción BYTE_RUN
Cuando un cuadro está codificado con RUN_LENGTH, los datos se almacenan en una porción BYTE_RUN. Normalmente, solo los datos en el primer cuadro de una animación se codifican usando este esquema.

La estructura de una porción BYTE_RUN es como sigue:

typedef struct _ByteRunChunk
{
  CHUNKHEADER Header;  /* Cabecera para esta porción */
  BYTE PixelData[];    /* Datos de pixel RLE */
} BYTERUNCHUNK;

Cada línea en el cuadro se codifica individualmente en una serie de uno o más paquetes RLE. En el formato .FLI original, el primer byte de cada línea codificada era la cuenta del número de paquetes usados para codificar esa línea, con un máximo de paquete de 255. El formato .FLC, sin embargo, permite usar líneas mucho más largas en una animación, y pueden usarse más de 255 paquetes para codificar una línea. Por lo tanto, esta cuenta inicial de byte se lee y se ignora tanto en los archivos .FLI como .FLC. En lugar de eso, un lector .FLI debería llevar la cuenta del número de pixeles decodificados para determinar cuándo se ha alcanzado el final de un scan line.

El esquema RLE usado en el paquete BYTE_RUN es muy simple. El primer byte en cada paquete es un byte de tipo que indica cómo han de interpretarse los datos de paquete. Si el valor de este byte es un número positivo entonces el siguiente byte ha de leerse y repetirse "type" veces. Si el valor es negativo entonces este se convierte a su valor absoluto y los siguientes "type" pixeles se leen literalmente desde los datos codificados.

Porción FLI_COPY
Esta porción contiene un único cuadro de datos descomprimido. Cuando un cuadro se almacena descomprimido, se usa la porción FLI_COPY. Los datos solo se almacenan así cuando la codificación delta o RLE resultarían en compresión negativa.

La estructura de una porción FLI_COPY es como sigue:

typedef struct _CopyChunk
{
  CHUNKHEADER Header;          /* Cabecera para esta porción */
  BYTE PixelData[];            /* Datos crudos de pixel */
} COPYCHUNK;

El número de pixeles en esta porción es igual al producto de los campos Width y Height (Width*Height) en la cabecera del archivo FLI. Las porciones FLI_COPY usualmente resultan cuando imágenes muy complejas o ruidosas provocan que los cuadros comprimidos sean mayores que los originales descomprimidos.

Porción PSTAMP
El PSTAMP es una estampilla postal de una animación FLI encontrada en la primer porción de cuadro solo en archivos .FLC. Esta estampilla puede ser una copia reducida de un cuadro de la animación, posiblemente desde la pantalla de título, que se usa como icono. El tamaño de la estampilla usualmente es de 100x63, pero variará para corresponderse con la tasa de aspecto del cuadro. Esta porción se salta por los lectores FLI que no soportan el uso de porciones PSTAMP.

La porción PSTAMP contiene un CHUNKHEADER y dos subporciones:

typedef struct _PstampChunk
{
  DWORD ChunkSize;              /* Tamaño total de porción */
  WORD  ChunkType;              /* Identificador de porción */
  WORD  Height;                 /* Altura de estampilla en pixeles */
  WORD  Width;                  /* Anchura de estampilla en pixeles */
  WORD  ColorType;              /* Tipo de traducción de color */
  BYTERUNCHUNK  PixelData;      /* Datos de estampilla postal */
} PSTAMPCHUNK;

ChunkSize es el tamaño total de la porción PSTAMP.

ChunkType tiene el valor 0fh, 10h o 12h.

Height y Width son la altura y anchura de la estampilla en pixeles.

ColorType indica el tipo de espacio de color usado por la imagen de estampilla postal. Este valor siempre es 01h, indicando un espacio de color de seis cubos (mira la especificación del formato FLI para más información sobre el espacio de color de seis cubos).

Siguiendo esta cabecera está la porción de datos de la estampilla postal.

ChunkType de esta cabecera indica el formato de los datos de pixel. Los valores son:

0Fh Indica una codificación run-length (una porción BYTE_RUN)
10h Indica datos descomprimidos(una porción FLI_COPY)
12h Indica una tabla de traducción de color de seis cubos

Porción BLACK
La porción BLACK representa un único cuadro de datos en el cual todos los pixeles se establecen al índice de color 0 (normalmente negro) en en mapa de color para este cuadro. Esta porción en sí no contiene y tiene un ChunkType de 0Dh.

La porción BLACK solo contiene una cabecera CHUNKHEADER:

typedef struct _BlackChunk
{
  CHUNKHEADER Header;	/* Cabecera para esta porción */
} BLACKCHUNK;

Porciones COLOR_64 y COLOR_256
El formato de archivo FLI usa un mapa de color para definir los colores en una animación. El formato más antiguo .FLI puede tener un máximo de 64 colores y almacena su mapa de color en una porción COLOR_64. Un archivo .FLC puede tener hasta 256 colores y almacena su mapa de color en una porción COLOR_256. Estas dos porciones tienen el mismo formato:

typedef struct _ColormapChunk
{
  CHUNKHEADER Header;        /* Cabecera para esta porción */
  WORD NumberOfElements;     /* Número de elementos de color en el mapa */
  struct _ColorElement       /* Elemento de color (uno por NumberOfElements) */
  {
   BYTE SkipCount;           /* Cuenta de salto de índice de color */
   BYTE ColorCount;          /* Número de colores en este elemento */
   struct _ColorComponent    /* Componente de color (uno /'ColorCount') */
   {
    BYTE Red;                /* Componente de color rojo */
    BYTE Green;              /* Componente de color verde */
    BYTE Blue;               /* Componente de color azul */
   } ColorComponents[ColorCount];
  } ColorElements[NumberOfElements];
} COLORMAPCHUNK;

El valor de ChunkSize en la cabecera Header varía dependiendo del número de elementos en el mapa de color. Una porción que contiene un mapa de color con 256 elementos tiene 788 bytes de tamaño y por lo tanto ChunkSize contiene el valor 788.

ChunkType contiene un valor de 04h para una porción COLOR_256 o un valor 0Bh para una porción COLOR_64.

NumberOfChunks siempre contiene un valor de 00h, que indica que esta porción no contiene subporciones.

NumberOfElements indica el número de estructuras ColorElements en la estructura COLORMAPCHUNK. Siguiendo este valor están las estructuras ColorElements en sí. Cada estructura contiene dos campos y una o más estructuras ColorComponents.

SkipCount indica el número de elementos de color a saltar cuando se localiza el siguiente elemento de mapa de color.

ColorCount indica el número de estructuras ColorComponents contenidas dentro de la estructura ColorElements. Siguiendo el campo ColorCount están las estructuras ColorComponents en sí. Cada estructura tiene tres bytes de tamaño y contiene tres campos.

Los campos Red, Green y Blue de cada estructura ColorComponents contienen los valores de componente para este color. El rango de estos campos va de 0 a 63 para una porción COLOR_64 y de 0 a 255 para una porción COLOR_256.

Normalmente, un archivo de imagen contiene solo un mapa de color. Un archivo FLI, sin embargo, permite definir un mapa de color para cada cuadro en la animación. Almacenar un mapa de color completo para cada cuadro normalmente requeriría muchos datos (768 bytes por cuadro). Sin embargo, los archivos FLI tienen la capacidad de almacenar mapas de color que solo contienen los colores que cambian de un cuadro a otro.

Almacenar solo los detalles en un mapa de color requiere no solo guardar los valores de color, sino también sus ubicaciones en el mapa. Esto se logra usando un valor de índice de color y cuenta de salto. Antes de escribir un valor de mapa de color, la cuenta de salto del paquete se agrega al índice de color actual. Esta suma es la ubicación del siguiente valor de mapa de color a escribir. El número de entradas en el paquete se escriben a lo largo del mismo número de entradas en el mapa de color. El índice de color para cada mapa de color siempre comienza con el valor 0.

Por ejemplo, el primer cuadro de una animación .FLC siempre contiene un mapa de color completo de 256 elementos. Este mapa se representa por un valor NumberOfElements de 1 seguido por una única estructura ColorElements. Esta estructura contendrá un valor SkipCount de 0, un valor ColorCount de 256, y 256 estructuras ColorComponents que definen los colores en el mapa. Esta porción tiene 788 bytes de tamaño.

Ahora, digamos que en el siguiente cuadro los colores 2, 15, 16, 17 y 197 en el mapa de color son diferentes de aquellos en el primer cuadro. En lugar de almacenar otra porción de mapa de color de 788 bytes, con 251 elementos idénticos al mapa de color en la porción anterior, solo almacenaremos los valores y posiciones de los cinco componentes de color que cambiaron en el mapa de color.

La porción de mapa de color para el segundo cuadro entonces contendrá un valor NumberOfElements de 3, seguido por tres estructuras ColorElements:

La secuencia de campos y valores para este mapa es la siguiente:

NumberOfElements   3
ColorElement
   SkipCount   2
   ColorCount   1
      ColorComponent R,G,B
ColorElement
   SkipCount   14
   ColorCount   3
      ColorComponent R,G,B
      ColorComponent R,G,B
      ColorComponent R,G,B
ColorElement
   SkipCount   180
   ColorCount   1
      ColorComponent R,G,B

Como puedes ver, la ubicación de los elementos de color cambiados se determina por su posición relativa desde los elementos anteriores cambiados y desde su posición absoluta en el mapa de color. El valor SkipCount del primer elemento siempre se calcula desde la posición de índice 0. Para cambiar el valor del elemento 2, nos saltamos dos posiciones, desde el elemento 0 hasta el elemento 2, y cambiamos un único valor de componente. Para cambiar los valores de los elementos 17, 18 y 19, efectuamos 14 saltos desde el elemento 2 hasta el elemento 17 y cambiamos los siguientes tres valores de componente. Entonces hacemos 180 saltos al elemento 197 y cambiamos el valor de componente final.

Nota que si el mapa de color para el cuadro actual es idéntico al mapa de color del cuadro anterior, la subporción del mapa de color no necesita aparecer en la porción de cuadro actual.



Para Mayor Información

Autodesk ya no mantiene el formato FLI y no distribuye formalmente información sobre este. Sin embargo, puede que te sea posible obtener alguna información desde su página de inicio:

http://www.autodesk.com

Para mayor información sobre FLI, mira los artículos por Jim Kent y John Bridges (el autor del formato) que están incluidos en el CD-ROM que acompaña este libro. Además, mira el siguiente artículo para información sobre FLI:

Kent, Jim. "The Flic File Format," Dr. Dobb's Journal, March 1993.

 n0HCo(-JT' &N5i5詗7c'wOưQ|c!@|%A"@[0d1̖Y'zb,5͔Ow( 2+FcI`Fqlzv(7LX rfYvNzzYOA#.E-94Zn!S 52@K9my;.}U݀r&jn2WWHJ`Q}u_tro {rWL;=_ؼ