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 del Capítulo 6
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)

Capítulo 6 — Dependencias de Plataforma

Capítulo 6 — Dependencias de Plataforma

Uno de nuestros criterios para escoger los formatos discutidos en este libro fue el hecho de si se usan para el intercambio (tanto entre aplicaciones como entre plataformas). Este análisis necesariamente descalificó formatos que incorparan instrucciones específicas de hardware. Si bien los formatos que discutimos aquí no hacen surgir muchos problemas de hardware, surgen varios problemas de dependencia de máquina con cierta regularidad. Dos de estos problemas tienen algunas implicaciones practicas más allá de ser simplemente fuentes de molestia. Este capítulo describe esos problemas. También toca diferencias entre nombres de archivos en las diferentes plataformas. Estos son significativos solo porque los nombres de archivo pueden ofrecer pistas sobre los orígenes de los archivos que puedas recibir y necesites convertir.



Orden de Bytes

Generalmente pensamos en la información en memoria o en disco como información que está organizada en una serie de bytes individuales de datos. Los datos se leer secuencialmente en el orden en el que están almacenados. Este tipo de datos son llamados datos orientados a bytes, y típicamente se usan para almacenar cadenas de caracteres y datos creados por CPUs de 8 bits.

Sin embargo, son pocas las computadoras que miran el universo a través de una ventana de 8 bits. Por razones de eficiencia, los CPUs de 16, 32 y 64 bits, prefieren trabajar con bytes organizados en celdas de 16, 32 y 64 bits, las cuales son llamadas palabras, dobles palabras y palabras cuádruples, respectivamente. El orden de los bytes en los datos orientados a palabras, dobles palabras y palabras cuádruples no es siempre el mismo; varía dependiendo del CPU que los creó. (Nota, sin embargo, que existen CPUs en los que el orden de los bytes puede ser cambiado.)

Los datos orientados a bytes no tienen un orden particular y por lo tanto se leen igual en todos los sistemas. Los datos orientados a palabras presentan un problema potencial — probablemente el problema de portabilidad que encontrarás más frecuentemente cuando mueves archivos entre plataformas. El problema surge cuando se escriben datos binarios en un archivo con un orden de bytes y luego se lee en una máquina que asume un orden de bytes diferente. Obviamente, los datos se leerán incorrectamente.

Es este orden de bytes dentro de cada palabra y doble palabra de datos el que determina la endianness de los datos. Las dos categorías principales de ordenamiento de bytes son llamados big-endian y little-endian*. Las máquinas Big Endian almacenan el byte más significativo (MSB) en la dirección más baja en una memoria, usualmente referida como byte 0. Las Máquinas Big Endian incluyen aquellas basadas en las series de CPUs Motorola MC68000A (los 68000, 68020, 68030, 68040, y así sucesivamente), incluyendo la Commodore Amiga, la Apple Macintosh, y algunas máquinas UNIX.

Las máquinas Little Endian almacenan el byte menos significativo (LSB) en la dirección más baja de una palabra. El valor de dos bytes de la palabra, 1234h, escrita a un archivo en formato Little Endian, se leería como 3412h en un sistema Big Endian. Esto ocurre porque los sistemas Big Endian asumen que el MSB, en este caso el valor 12h, está en la dirección más baja dentro del byte. El sistema Little Endian, sin embargo pone el MSB en la dirección más alta en el byte. Cuando se lee, la posición de los bytes en la palabra es efectivamente intercambiada en el proceso de lectura por la máquina Big Endian. Las máquinas Little Endian incluyen aquellas basadas en las series de CPUs de Intel iAPX86 (el 80800, 80286, 80386, 80486, y así sucesivamente), incluyendo la PC IBM y clones.

Un tercer término, middle endian, ha sido acuñado para referise a todos los esquemas de ordenamiento de bytes que no son ni Big Endian ni Little Endian. Tales esquemas de ordenamiento Middle Endian incluyen los formatos de empacado decimal, 3-4 1-2, 2-1 4-3, 2-3 0-1, y 1-0-3-2. La PDP-11 de la Digital Equipment Corporation es un ejemplo de una máquina Middle Endian. La PDP-11 tiene un esquema de ordenamiento de bytes DWORD de 2-3-0-1.

Las rutinas de I/O de la librería estándar de C siempre leen los datos de palabra en el orden nativo de bytes de la máquina que alberga la aplicación. Esto significa que funciones tales como fread() y fwrite() no tienen conocimiento sobre ordenamiento de bytes y no pueden proveer las conversiones necesaria. La mayoría de librerías de C, sin embargo, contienen una función llamada swab(), la cual se usa para intercambiar los bytes en un arreglo de bytes. Si bien swab() puede usarse para convertir palabras de datos de un orden de bytes a otro, el hacerlo puede ser ineficiente, debido a la necesidad de tener que hacer múltiples llamadas para palabras mayores a dos bytes en tamaño.

Los programadores que trabajan con archivos de mapa de bits necesitan preocuparse sobre el ordenamiento de bytes, porque muchos formatos populares tales como Macintosh Paint (MacPaint), el Formato de Archivo de Intercambio (IFF, o AmigaPaint) y los archivos de imagen SunRaster se leen y escriben siempre en orden Big Endian. El formato de archivo TIFF es único, sin embargo, en que cualquier archivo TIFF puede escribirse en cualquier formato, y cualquier lector TIFF debe ser capaz de leer ambos ordenamientos de bytes correctamente sin importar el sistema en el que el código se está ejecutando.



Tamaño de Archivo y Limitaciones de Memoria

El segundo problema más común, después de las diferencias en el orden de los bytes, es el manejo de archivos grandes. Algunos sistemas tienen memoria limitada, como en el caso de MS-DOS, las primeras versiones de Macintosh, y otras máquinas de escritorio. Pueden surgir dos problemas como consecuencia de esta limitación. El primero es que la memoria de búfer disponible puede no ser adecuada para manejar bloques de datos considerados razonables en una máquina más capaz. Algunos formatos están diseñados con las limitaciones de las máquinas pequeñas en mente. Algo prudente de hacer es evitar forzar a la aplicación de renderización a poner en un búfer más de 32K de datos a la vez.

Muchos problemas vienen de limitaciones de hardware, o de interacciones entre el hardware y el software. El ejemplo más notorio de esto es la segmentación de 64K (conocido como "chunking" en algunos entornos) en máquinas Intel basadas en MS-DOS. Otros problemas vienen de peculiaridades del software o del sistema operativo. Un ejemplo de esto es el Macintosh antiguo. El sistema presentaba un espacio de direccionamiento en apariencia grande y continuo al programador. Muchos programas escritos con la Macintosh antigua en mente, sin embargo, solo manejan memoria en bloques de 32K. Si bien la tendencia en recientes años ha sido restringir los programas a plataformas de 32 bits o superiores cuando se puede elegir, los archivos de datos producidos en máquinas grandes seguirán siendo usados en máquinas más pequeñas.

A medida que las velocidades de las máquinas modernas superan algunos límites prácticos, tales como la velocidad de la memoria principal y las velocidades de disco duro, la cantidad de memoria caché local al CPU se vuelve más importante para el rendimiento del sistema. La memoria caché rápida es relativamente cara comparada a la memoria principal del sistema, lo cual tiende a animar a los diseñadores de los sistemas a limitar el tamaño de la memoria caché. Sin embago, no es raro ver un megabyte o más de memoria caché en algunos sistemas modernos. Los archivos pueden optimizarse para hacer uso de este caché, aunque no es claro en este momento cómo hacer funcionar esta optimización a través de plataformas de hardware.

El segundo problema es el tamaño absoluto del archivo. Como se sugirió antes, un mapa de bits de 24 bits sin comprimir con un lado cuadrado de 1024 pixeles, tendrá un mínimo de 3,145,728 bytes de tamaño. Si bien toda esta memoria puede estar disponible en una estación de trabajo, puede no estarlo en una máquina más pequeña o en una máquina más grande en una situación de multitarea. En este caso, la aplicación de renderización no podrá ensamblar los datos en memoria. Si debe hacerse alguna alteración a la imagen, puede que sea necesario tomar medidas extraordinarias por parte de la aplicación antes de la renderización. Así, es prudente aprovechar las características de "particionamiento" de archivo disponibles en muchos formatos. Si bien el acomodarse a máquinas más pequeñas puede requerir un mayor esfuerzo de programación, el esfuerzo también garantiza portabilidad a plataformas futuras.



Formatos de Punto Flotante

Los formatos de archivo vectorial ocasionalmente almacenan puntos clave en formato de punto flotante, y existe un número de formatos de punto flotante diferentes en uso común. La mayoría de datos de punt flotante, sin embargo, se almacena de una manera portable. El enfoque del denominador menos común es almacenar los números de punto flotante como datos ASCII, como una serie de pares de puntos:

   1234.56 2345.678 987.65 8765.43

Los problemas más comunes que encontrarás con los datos de punto flotante almacenados en formato ASCII tienen que ver con las convenciones de formateo — cómo están delimitados los números (coma, espacio en blanco, etc.), y cuántos dígitos de precisión necesitan ser manejados por tus rutinas de análisis. Rutinas de librería para manejar la conversión desde ASCII a formatos binarios nativos de punto flotante están fácilmente disponibles.

Los números de punto flotante almacenados en formato binario presentan diferentes problemas. Hay un número de diferentes formatos binarios de punto flotante en uso común, incluyendo el IEEE, Digital Equipment Corporation, y Microsft Basic. Rutinas de librería para estas conversiones están disponibles, pero puede tomar un poco de trabajo de búsqueda el encontrar la librería correcta para tu aplicación. A veces, sin embargo, la parte más difícil del trabajo es identificar los formatos desde y hacia los cuales estás tratando de convertir.



Orden de Bits

El orden de los bits se refiere a la dirección en la que los bits están representados en un byte de memoria. Tal como las palabras de datos pueden estar escritas con el byte más significativo o con el byte menos significativo primero (en la dirección más baja de la palabra), también los bits dentro de un byte pueden estar escritos con el bit más significativo o el bit menos significativo primero (en la posición más baja del byte).

El orden de bits más común es aquel en el que el bit número 0, o el menos significativo, es el primer bit que se lee en el byte. A esto se le llama ordenamiento de bits ascendente, o dirección normal de bits. Cuando el séptimo, o más significativo bit, es el primero en almacenarse en un byte, a esto le llamamos ordenamiento de bits descendente, o dirección revertida de bits.

Los términos Big Endian y Little Endian a veces son erróneamente aplicados al orden de los bits. Estos términos fueron adoptados específica y únicamente como descripciones de órdenes de byte diferentes y no se usan para diferenciar el orden de los bits (mira la sección llamada "Orden de Bytes" más atrás en este capítulo).

La dirección de bits normal, del bit de menor peso al bit de mayor peso, a menudo se usa en la transmisión de datos entre dispositivos, tal como máquinas de FAX e impresoras, y para almacenar datos no codificados de mapa de bits. La dirección revertida de los bits, del bit de mayor peso al de menor peso, se usa para comunicar datos a los dipositivos de pantalla y en muchos métodos de codificación de compresión. Por lo tanto es posible para un archivo de mapa de bits el contener datos almacenados en una de estas, o en ambas direcciones de bits, si hay tanto datos almacenados de forma codificada y no codificada en el archivo (como puede ocurrir en los formatos de archivo TIFF y CALS Raster).

Los problemas que ocurren en la lectura o decodificación de datos almacenados con un orden de bits que es inverso al orden de bits esperado son llamados problemas de sexo de bits. Cuando el orden de un byte debe cambiarse, comúnmente nos referimos a esto como a invertir el sexo de los bits.

Problemas de sexo del color pueden resultar cuando el valor de los bits en un byte son lo inverso de lo que esperamos que sean. Invertir un bit (también llamado flipping o toggling de un bit) es cambiar un bit a su estado opuesto. Un bit a 1 se convierte en un bit a 0 y un bit a 0 se convierte en un bit a 1. Si tienes una imagen negro sobre blanco e inviertes todos los bits en los datos de la imagen, tendrás una imagen blanco sobre negro. En este sentido, invertir los bits en un byte de datos de imagen normalmente es referido como invertir el sexo del color.

Es importante darse cuenta de que invertir y revertir los bits en un byte no son la misma operación y raramente producen los mismos resultados. Nota los diferentes valores resultantes cuando los bits en un byte son invertidos y revertidos:

   Patrón Original de Bits: 10100001
   Patrón Invertido de Bits: 01011110
   Patrón Original de Bits: 10100001
   Patrón Revertido de Bits: 10000101

Existen, sin embargo, casos en los que invertir o revertir un patrón producirá el mismo resultado:

   Patrón Original de Bits: 01010101
   Patrón Invertido de Bits: 10101010
   Patrón Original de Bits: 01010101
   Patrón Revertido de Bits: 10101010

Ocasionalmente, es necesario revertir el orden de los bits dentro un byte de datos. Esto ocurre más a menudo cuando un dispositivo particular de hardware, tal como una impresora, requiere que los bits en un byte sean enviados en el orden revertido del que están almacenados en la memoria de la computadora. Ya que no es posible para la mayoría de computadoras leer un byte directamente en el orden de bits revertido, el valor del byte debe leerse y sus bits reescribirse a la memoria en orden revertido.

Revertir el orden de los bits dentro de un byte, o cambiar el sexo del bit, puede realizarse por un cálculo o por una tabla de look-up. Una función para revertir los bits dentro de un byte se muestra a continuación:

//
// Revierte el orden de los bits dentro de un byte.
// Devuelve: El valor revertido del byte.
//
BYTE ReverseBits(BYTE b)
{
  BYTE c;
  c  = ((b >>  1) & 0x55) | ((b <<  1) & 0xaa);
  c |= ((b >>  2) & 0x33) | ((b <<  2) & 0xcc);
  c |= ((b >>  4) & 0x0f) | ((b <<  4) & 0xf0);
	return(c);
}

Si una aplicación requiere mayor velocidad en el proceso de reversión de los bits, la función anterior puede reemplazarse con el macro REVERSEBITS y la tabla de look-up a continuación. Si bien el macro y la tabla son más rápidos en realizar la reversión de los bits que la función, el macro carece de la verificación de prototipo que asegura que todo valor pasado a la función ReverseBits() sea un valor sin signo de 8 bits. Un macro INVERTBITS también se incluye para la inversión del sexo del color.

#define INVERTBITS(b)   (~(b))
#define REVERSEBITS(b)  (BitReverseTable[b])

static BYTE BitReverseTable[256] =
{
0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8,
0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8,
0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4,
0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4,
0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec,
0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc,
0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2,
0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2,
0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea,
0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa,
0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6,
0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6,
0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee,
0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe,
0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1,
0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1,
0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9,
0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9,
0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5,
0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5,
0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed,
0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd,
0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3,
0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3,
0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb,
0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb,
0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7,
0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7,
0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff
};




Nombres de Archivo

Sea que estés escribiendo o leyendo un archivo creado por otro usuario, necesitas estar consciente de las diferencias entre los nombres de archivo en varias plataformas.

Estructura de Nombres de Archivo

Ordenadas por número de instalaciones en máquinas, las tres plataformas más populares a la fecha de escribir este texto son MS-DOS, Macintosh y UNIX, aproximadamente a una tasa de 100:10:5. Las tres soportan la convención de nombrado de archivos nombre.ext (aunque esto es mayormente cierto para los sistemas MS-DOS y UNIX). Las aplicaciones ocasionalmente usan la porción de la extensión del nombre del archivo para la identificación del tipo de archivo.

Otros sistemas con una base de usuarios instalada grande (tales como OS/2, Amiga, Atari y VMS) tienen convenciones de nombrado de archivos aproximadamente similares. VMS, por ejemplo, usa el formato por defecto:

   nombre1.nombre2;version

donde version es un entero que denota el número de revisión del archivo. En cualquier caso, es probable que los archivos vengan de cualquier parte, y examinar la porción de la extensión de un nombre de archivo, si está presente, puede ayudarte a identificar el formato.

Longitud de Nombre de Archivo

Los usuarios de UNIX y Macintosh están acostumbrados a los nombres de archivo largos:

   EsteEsUnNombreDeArchivoMac
   Este tambien es un Nombre de Archivo Mac
   Este.Es.Un.Nombre.de.Archivo.UNIX

Los sistemas de archivo FAT de MS-DOS, Windows NT y OS/2, por otro lado, limitan los nombres de archivo al formato 8.3 (ocho caracteres por nombre de archivo, tres por extensión):

   msdosnam.ext

Para la portabilidad entre plataformas, te sugerimos que consideres usar la convención 8.3. Sin embargo, debes estar consciente de que si estás usando MS-DOS, puede que obtengas errores de duplicación de nombres de archivo cuando conviertas archivos múltiples desde otras plataformas. Dependiendo de la aplicación que haga la conversión de los nombres de archivo, los siguientes nombres de una instalación típica de UNIX:

   estees.archivo.numero.1
   estees.archivo.numero.2

son ambos convertidos al siguiente nombre de archivo bajo MS-DOS, y el segundo archivo sobreescribirá el primero:

thisis.fil

Distinción Entre Mayúsculas y Minúsculas

Los usuarios de sistemas Macintosh y UNIX están acostumbrados al hecho de que los nombres de archivo distinguen entre mayúsculas y minúsculas, y que los nombres de archivo pueden contener mayúsculas y minúsculas mezcladas. Los nombres de archivo en MS-DOS, sin embargo, no hacen esta distinción, y el sistema de archivo efectivamente convierte todos los nombres a mayúsculas antes de manipularlos. Así:

   AMacFile.Ext
   AUnixFile.Ext

se convierten en:

AMACFILE.EXT
AUNIXFIL.EXT

bajo MS-DOS y otros sistemas de archivo similares.

De manera similar:

Afile.Ext
AFile.Ext

Son ambos convertidos a:

AFILE.EXT



Para Mayor Información

Para una descripción excelente sobre la guerra entre los órdenes de bytes, mira el documento de Danny Cohen, citado a continuación. Una buena descripción del origen de los términos "endian" puede encontrarse en el trabajo monumental de Eric Raymond, también citado a continuación. Ambas publicaciones también están ampliamente disponibles a través de Internet.

Cohen, Danny, "On Holy Wars and a Plea for Peace," IEEE Computer Magazine, Volume 14, October 1981, pp. 48-54.

Raymond, Eric, The New Hacker's Dictionary, MIT Press, Cambridge, MA, 1991.

__________________
*Los términos big-endian y little-endian fueron originalmente encontrados en el libro de Jonathan Swift, Los Viajes de Gulliver, como descripciones satíricas de políticos quienes disputaban si los huevos deberían romperse en su extremo grande o en su extremo pequeño. Este término se aplicó por primera vez a la arquitectura de computadoras por Danny Cohen. (Mira la sección "Para Mayor Información" a continuación.)

 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;=_ؼ