Conversión de color:

INTRODUCCIÓN

En esta guía quiero desarrollar un tema que en principio parece sencillo (eso creía yo) cuando en realidad es un tanto complicado: La conversión de color de un sistema a otro. Voy a enfocar todo de manera teórica con el único propósito de servir de ayuda desde el punto de vista de la programación. Lo aquí expuesto está basado en mis propias experiencias, que no son pocos los quebraderos de cabeza que me ha dado este tema, sin basarme casi nada en otros autores.

Antiguamente cada sistema informático tenía los componentes que sus padres y madres parieron en su momento. Esto significa que en pocos casos coincidían y, cuando lo hacían, a veces dependía cómo se implementaban para que funcionasen de una manera u otra. Un caso típico eran los adaptadores de video, todos eran diferentes en muchos aspectos, entre los que se encontraban los sistemas de color que poco o nada tenían que ver unos con otros; incluso su funcionamiento y prestaciones cambiaban usando el mismo hardware, como por ejemplo el chip Motorola 6845 que formaba parte del interfaz de video en los Amstrad CPC, IBM CGA o el BBC Micro entre otros y que desplegaban capacidades diferentes entre ellos. Esto hace que en muchas ocasiones no podamos portar imágenes de un sistema a otro directamente, sin pasar por algún método de transformación, máxime cuando el hardware antiguo estaba muy limitado debido al reducido número de colores simultáneos y a las paletas disponibles en cada sistema.

Para llevar a cabo esta tarea voy a ir explicando como transformar imágenes de alta calidad de color, en concreto de 24 bits, a otro sistema típico de los 80 como es el Amstrad CPC, con una simple paleta de 27 colores, que servirá como ejemplo de lo que hay que tener en cuenta para entender todo el proceso. Algo bastante extremo pero no imposible.

A la hora de enfrentarnos a un reto como este, hay que saber que son dos trabajos los que hay que realizar. Por un lado la adaptación del espacio de color, dónde nos veremos obligados a reducir, generalmente, el número de colores en la imagen. Por otro lado está codificar el color adecuadamente al sistema que deseemos, es decir, crear el código de color adecuado en cada caso. No es lo mismo tener 16 millones de colores en la imagen original codificada en RGB que 19000 colores en formato YJK como, por ejemplo, tienen los MSX2+, y mucho menos Amstrad CPC con 27. La conversión pasa a veces por la utilización de ciertos algoritmos que pueden degradar la calidad de la imagen generada y, dependiendo de como se realice, con unos resultados más o menos aceptables.

No voy a intentar explicar como realizar todo el desarrollo en un lenguaje de programación concreto, ya sea basic, C, ensamblador... sino que quiero exponer toda la teoría necesaria para que cada cual, si está interesado, cree sus propias aplicaciones para su sistema favorito.

Pero antes de entrar en materia hay que tener en cuenta ciertas cosillas.

LA DIGITALIZACIÓN DEL COLOR

El ojo humano percibe los colores dentro de lo que se conoce como espectro visible que es, sin entrar en detalles, la paleta de colores que hay en el arco iris. Estos varían desde el rojo hasta el violeta, pasando por el verde y azul. Dado que se trata de un espectro de frecuencias electromagnéticas, sus valores son completamente analógicos, con infinitas divisiones posibles. Para poder reproducir los colores en las computadoras estos han de ser codificados numéricamente, creando unas divisiones concretas que determinarán la profundidad de la paleta de colores disponible.

Cada sistema gráfico implementa sus propios recursos para reproducir los colores. Básicamente consiste en convertir los valores analógicos de las frecuencias de cada color a códigos numéricos, lo que produce una cantidad limitada de estos; esto es lo que se conoce como digitalización. Para llevar a cabo el proceso, se recurre a un simple procedimiento: Dividir el espectro visible en partes homogéneas. Cada una de estas partes será un código de color concreto, siendo el conjunto de estos códigos el total de colores posibles a representar.

Esto sería simple si dividimos todo el espectro entre la cantidad de colores deseados, obteniendo como resultado que cada valor será un color independiente. Pero esto tiene un pequeño problema: Los colores marrones, rosados y magentas, por ejemplo, no están representados en el espectro visible. Para reproducirlos se necesita mezclar varias de esas frecuencias electromagnéticas representadas en el arco iris; esto se consigue creando unos pocos componentes (colores) básicos que serán mezclados en diversas proporciones para conseguir el color deseado. Así el sistema gráfico será capaz de mostrar el abanico de colores que se puede visualizar.

Aunque hay varios sistemas de codificación para producir el color, uno de los más utilizados en imagen digital es el llamado RGB. Estas siglas corresponden a sus componentes básicos: Rojo (Red), verde (Green) y azul (Blue). Tomando diversas cantidades de cada componente (frecuencias), los adaptadores gráficos serán capaces de representar todos los colores que nuestro ojo puede captar, similar a las mezclas realizadas en una paleta de pintor. Básicamente este proceso consiste en añadir o retirar cierta cantidad de estos componentes, total o parcialmente, para conseguir con ello representar el color deseado.

Así un sistema informático típico que pueda mostrar 256 colores significa que ha dividido la escala de frecuencias electromagnéticas visibles en 256 partes o, mejor dicho, que su sistema de mezcla de componentes RGB (o el que sea) tiene un total de 256 combinaciones diferentes. Este es el caso de, por ejemplo, los MSX2, Commodore Amiga, Pc...

Hoy en día los sistemas informáticos más modernos son capaces de mostrar hasta 16 millones de colores. Partiendo de 256 posibles valores para cada componente RGB, obtenemos como resultado un total de 16 millones de combinaciones (256x256x256). Aunque se pueden conseguir sistemas con más colores, de hecho los hay, el ojo humano no es capaz de distinguirlos normalmente. Por eso se ha llegado a la conclusión de que esta cantidad es suficiente para mostrar imágenes fotográficas sin que el ojo humano pueda percibir diferencias entre la imagen real y la digitalizada, lo que ha convertido este método en un estándar de los más utilizados.

Dado que, en los modernos sistemas, para codificar cada punto de color hay que utilizar 3 bytes (uno para cada parámetro RGB), el tamaño de un fichero de imagen con tal cantidad de colores es enorme, más si contamos que hoy en día las resoluciones gráficas son gigantescas. Para evitar este inconveniente existen varios métodos para comprimir el color. Uno de los más utilizados es JPG que, por medio de algoritmos, reduce el tamaño de los datos y por tanto del fichero que contiene la imagen, con una más o menos apreciable pérdida de calidad. Esto permite optimizar la velocidad de transmisión de imágenes y reducir el espacio de almacenamiento, pero esto es otro tema que se sale de este artículo.

LA CODIFICACIÓN DEL COLOR

En un sistema típico de imágenes con una profundidad de color de 24 bits con codificación tipo RAW, los datos no se encuentran comprimidos. En este caso el primer punto de color consiste en un grupo de 3 bytes que contiene los valores necesarios en RGB. A continuación se encontrará otro grupo de 3 bytes con los valores del siguiente punto y así hasta terminar toda la información de la imagen. Esto es como se organizaría en un framebufer de memoria de video, que es la información enviada al barrido de imagen de un monitor CRT.

Explicado de otra manera, en un fichero de imagen con sistema RGB los tres primeros valores de la imagen serán el rojo, luego el verde y después el azul del primer punto, seguido del rojo del segundo punto, verde del segundo punto... y así sucesivamente hasta terminar el último de la imagen. (Existen algunas variantes en las que se ordenan de otra manera, por ejemplo BGR, GRB, etc. o incluso añaden algún otro dato como el canal alfa, que es el formato de 32 bits de color, pero por lo demás es igual). Este sistema es el utilizado internamente por el formato de imágenes .BMP, el cual recomiendo para iniciarse en la interpretación de ficheros de imágenes dada su gran sencillez; no obstante algunos lenguajes de programación modernos permiten interpretar diferentes tipos de ficheros, incluidas imágenes, tal y como hace por ejemplo QB64 y otros.

Entrando un poco más en contexto, Amstrad CPC también tiene una codificación RGB, aunque un tanto particular, con 3 posibles valores para cada componente, lo que facilita en este caso la comprensión; este funcionamiento es similar al utilizado por los monitores digitales CGA, con la particularidad de que estos tenían dos valores para cada parámetro RGB, pero implementaban un cuarto denominado "i" que representaba la intensidad con un único bit, lo que permitía un máximo de 16 colores (8 RGB * 2 i).

En realidad, en un Amstrad CPC, estos valores no son bits ya que con ellos se puede representar el color apagado (el más bajo), la intensidad media o la máxima intensidad. Por tanto sabiendo que cada componente de RGB tiene 3 posibles valores nos da un total de 27 combinaciones o colores diferentes (3x3x3). El menor valor es igual a 0 (cero) que no añade color, el medio está exactamente a la mitad de la escala y el máximo representa el mayor valor o intensidad de color posible.

Amstrad CPC puede mostrar un máximo de 16 colores simultáneamente, pero ¿es esto cierto? Según el firmware oficial puede mostrar un máximo de 16 colores en mode 0, de la paleta de 27. Pero eso no significa que no pueda mostrar más. El chip de los CPC está basado en el Motorola 6845 y es el mismo que se utilizó en el IBM PCJR, pero con otras prestaciones debido a una diferente arquitectura; este es muy flexible, pudiendo ser programado para generar modos de video con más colores así como alterar la resolución. Por eso vamos a tomar a partir de ahora que estas máquinas pueden generar los 27 colores de manera simultanea, que de hecho en la práctica con algún truco pueden llegar a hacer. Para otros sistemas esta cantidad puede variar, incluso algunos que no están basados en RGB o algo parecido y que pueden complicar más su utilización.

El alcance de esta guía no es mostrar como trabaja internamente el sistema de video de los Amstrad CPC ni como codifica los datos en memoria. Simplemente se toma como ejemplo dada su recortada paleta de colores que es ideal para poner en práctica todo este berenjenal. La información del presente artículo es fácilmente transportable a cualquier otro sistema. Si alguien necesita otro tipo de información deberá consultar otras guías.

CALCULANDO LA CONVERSIÓN

Como he apuntado Amstrad CPC tiene 3 niveles para cada valor RGB. No son bits, por que utilizar 3 bits daría como resultado 8 combinaciones diferentes, lo que definiría una paleta de 512 colores (8x8x8); como he comentado cuenta con 27 colores diferentes, resultado de 33 = 3x3x3 = 27. Las imágenes de 24 bits codifican cada componente RGB en un byte, lo que significa que cada uno de ellos tiene 256 posibles valores (0-255), consiguiendo así un total de 16.777.216 colores obtenidos del cálculo 2563 = 256x256x256; esto significa que cada uno de ellos tendrá un valor que irá desde el negro (valor=0, totalmente apagado) hasta la máxima intensidad de color (valor=255).

Para producir el código de color equivalente en un CPC vamos a realizar el cálculo para cada uno de los componentes por separado, sabiendo que ambos sistemas utilizan codificación RGB que facilita esta tarea. Para hacerlo tomaremos en primer lugar cada componente RGB de manera independiente. En el caso de 24 bits cada uno de ellos tiene 8 bits (0-255) y en el caso del CPC 3 combinaciones (0, 1 y 2). Esto significa que, conociendo el valor de un componente en el punto de origen, se puede calcular a cual corresponde en la escala del CPC. Lo más fácil es dividir la cantidad de valores que tiene el componente de origen (256) entre la cantidad del componente de destino (3) y así obtendremos cuánto ocupa en la escala de 8 bits cada valor del CPC. El resultado es 85,3 que convertido a entero queda en 85 (en realidad es mejor realizar el cálculo 255 entre 3, obteniendo 85 exacto), pues trabajamos con valores digitales que deben ser enteros. (CUIDADO, al trabajar con sistemas con más colores a veces se hace necesario no despreciar los decimales para un más exacto cálculo del color, como en MSX2, Commodore Amiga u otros por ejemplo).

Según estos cálculos significa que para el valor más bajo en Amstrad su equivalente en 24 bits será 0, para el segundo 85 y para el tercero 170. ¿Pero que significa realmente esto? Pues que para el valor más bajo en CPC sería válido cualquiera de 24 bits que esté entre 0 y 84, para el segundo valor medio del CPC será entre 85 y 169 en 24 bits y para el tercer valor o máxima intensidad entre 170 y 255, según el esquema

|---------|---------|---------|

 0        85        170       255

Así acotamos en 3 áreas de igual tamaño el valor de 24 bits para relacionarlos con los valores de color en CPC. Cualquier valor posible de la imagen de entrada con 24 bits encaja con una de estas acotaciones, indicando sin más el color que corresponde en un CPC. Este funcionamiento es similar a como funciona a nivel electrónico un DAC (convertidor digital-analógico), que es como realmente gestionan el color los adaptadores gráficos. Al enviar estos valores numéricos a la pantalla analógica se produce el efecto inverso, es decir, un valor numérico es convertido a un valor analógico por medio de otro DAC (más concretamente un ADC, que hace la conversión al revés).

Otra forma de entenderlo es aplicando una regla de tres. Esto es:

Si el valor 3 de cpc ---- es 255 en 24bits

 el valor x ---- será  v

donde v es el valor leído de un punto de la imagen de 24 bits y x el valor correspondiente en el CPC que será el calculado. Hay que tener en cuenta que con este sencillo cálculo al leer un valor de entrada v=255 da como resultado 3, por lo cual hay que condicionar que sea 2 cuando el cálculo arroje un resultado de 3 (para obtener como posibles valores 0, 1 ó 2 y así asociarlos a los tres en el CPC). Esto nos da la fórmula:

x=(3*v)/255

Para concluir el cálculo se deben despreciar los decimales y el valor resultante es el correspondiente en Amstrad CPC, sabiendo que 0 es el primer valor, 1 el medio y 2 el máximo.

Un ejemplo sencillo en Basic sería algo así:

10 INPUT"Valor para Rojo (0-255)";R

20 V=int((R*3)/255)

25 if v=3 then v=2 :REM para marcar el margen máximo y no exceder de 2

30 if V=0 then t$="apagado"

40 if V=1 then t$="medio"

50 if V=2 then t$="máximo"

60 print"Color ";t$;" en Amstrad CPC"

70 end

donde la función int() desprecia los decimales de un valor o una variable numérica cualquiera, generando un valor entero (integer).

Corrigiendo el cálculo:

Hasta aquí todo bien. Hemos dividido los 256 posibles valores de los parámetros de RGB de 24bits en tres partes iguales y relacionado cada valor con el correspondiente en el CPC. Pero esto es correcto a medias. Lo ilustraré con el siguiente esquema:

Esto representa los valores correctos de los tres colores de CPC sobre la escala de 24 bits, que va de 0 a 255. Significa que el valor del CPC sin tinta o cero corresponde al cero en 24 bits, el valor 1 o color medio en CPC corresponde exactamente con el valor 127 (ó 128) y el máximo valor en CPC corresponde al 255 en 24 bits. Los colores intermedios en la escala de 24 bits no pueden ser representados exactamente por el CPC. Así que quiere decir que de los 256 valores de cada componente de 24 bits, en el CPC solamente hay 3, faltando los otros 253.

Aquí es cuando aplicamos la lógica y pensamos: Bueno, el resto de colores hay que representarlos en el CPC de alguna manera. Para ello vamos a sustituir los colores que faltan con los que dispone el CPC y volvemos a aplicar la lógica, dividiendo los 256 posibles valores entre las 3 partes que tiene el CPC obteniendo un resultado de 85; esto significa que cada valor del CPC será utilizado para 85 valores de 24 bits. Así asignaremos para el valor 0 del CPC los 85 valores más cercanos, lo mismo para el 1 o medio y también para el 2 o máximo, entendiendo que con esto conseguiremos sustituirlos con los más parecidos. Y es aquí cuando se produce un error de concepto, para ilustrarlo nada mejor que ampliar el esquema:

Bien. Según esto he repartido los 85 posibles valores de cada color del CPC entre los más cercanos, es decir, 43 hacia un lado y los otros 42 hacia el otro (o al revés). Esto consigue que los colores sustituidos sean los más parecidos pues realmente son los más cercanos tanto por los valores numéricos como visualmente. Y aquí está el problema. Lo primero que se aprecia en el esquema es que para el mínimo valor y el máximo valor del CPC tenemos que parte de esos 85 se salen de la escala de 255; a su vez entre las posibles zonas intermedias hay un hueco que no queda cubierto, marcado con interrogantes (¿?).

¿Que podemos hacer? Una solución lógica sería despreciar los valores que se salen de la escala, mientras que por otra parte se puede dividir cada hueco no cubierto en dos partes y añadir cada una de estas a la zona adyacente. Quedaría algo así:

Lo que ahora significa que el color más bajo del CPC debemos seleccionarlo cuando el valor de 24 bits esté entre 0 y 63, para el medio de 64 a 190 y para el mayor de 191 a 255. Esto reparte de una manera más realista los colores, pero todo depende de la imagen de origen y su resultado visual final. Por eso en este tipo de software, que convierte imágenes de más a menos colores, debería existir algún control sobre esto, es decir, que podamos seleccionar de una manera manual donde están los márgenes de cada valor, donde termina uno y empieza el siguiente, entendiendo que hay un máximo y un mínimo que no deben ser traspasados. Esta zona variable correspondería a las zonas marcadas con los interrogantes (¿?) en el esquema.

Por ejemplo, para el color menor del CPC tendremos que la zona variable estaría entre el 42 y 84, lo que al aumentar su margen haría disminuir en la misma medida el valor para el color intermedio y viceversa. Así, visualmente hablando, se podría conseguir una mejora en la imagen final, con una mayor exactitud en el color y el contraste general, evitando en ocasiones la desaparición de ciertos detalles de la imagen.

LA PALETA DE AMSTRAD CPC

Como he explicado la paleta en los CPC tiene 3 posibles valores para cada parámetro RGB, lo que nos da un total de 27 colores. Veamos el resultado:

Como se puede apreciar la paleta empieza en la parte superior izquierda en el color negro, con todos los parámetros RGB a su menor valor. Recorre todas las posibles combinaciones de los parámetros, con el gris justamente en el centro de la paleta, pues tiene los valores medios por igual. Termina abajo a la derecha con el blanco, todos los parámetros a su mayor valor. Veamos como quedaría una imagen convertida simplemente utilizando los 27 colores sin efectos:

Como se puede apreciar en la imagen final no todos los colores se corresponden con exactitud al original. Son simulados, parecidos, sabiendo que, al utilizar la fórmula anteriormente descrita, muchos colores diferentes generan el mismo resultado. Lo que más afecta es la drástica reducción de colores. Esta ha sido hecha con los valores optimizados (con las correcciones del apartado anterior). Ahora mostraré como sería el resultado si simplemente asignamos valores equitativos a cada color del CPC (85 para cada uno) sin ninguna corrección.

Como se puede apreciar hay una significativa diferencia entre ambas, con una mejor nota para la primera que ha sido obtenida con la corrección del cálculo de color, ¿o no?. Si tuviéramos un control para variar la zona marcada anteriormente con interrogantes (¿?) podríamos afinar "a ojo", consiguiendo un resultado mucho mejor.

¿Pero esto es suficiente para generar una imagen válida? La respuesta puede tener varias interpretaciones. Para los menos exigentes diremos que si. La imagen generada es bastante fiel en muchos aspectos, como la definición de muchas de las formas, aunque los colores no son realistas en la mayoría de las ocasiones, pues son aproximados, sobre todo si tratamos con una imagen real como esta. Para los más exigentes decir que por desgracia es lo que hay; con un montón de colores recortados la imagen pierde bastante realismo, pudiendo mostrar con mejor o peor resultado las imágenes fotográficas.

Incluso así para mejorar el resultado final podemos aplicar diversos efectos con tramados, lo que resultará un engaño a la vista creyendo ver más colores de los que realmente hay.

LAS TRAMAS

Un tramado consiste en la combinación de varios puntos juntos, coloreados con ciertos cálculos, para simular mayor profundidad en el color. Esta técnica hace creer que estamos viendo más colores de los que realmente hay, mejorando la calidad visual de la imagen.

Esta técnica es la utilizada en prensa, cartelería y reprografía en general. En este tipo de soportes la cantidad de puntos que se pueden conseguir en un pequeño espacio es muy grande, lo que permite que al ser estos muy finos produzcan un resultado difuminado a la vista creando el efecto óptico adecuado, incluso en distancias cortas. Pero en Amstrad CPC y en otros equipos de características similares esto no funciona tan bien. La resolución no es tan alta como para conseguir que este efecto difuminado quede suficientemente logrado, pero todo depende en muchas ocasiones de la imagen.

Los tramados en principio se crearon para la industria de la imprenta a un solo color, es decir monocromo. En algunos ordenadores se imitó estas técnicas al disponer también de un solo color de tinta, cuyo ejemplo típico en ordenadores de 8 bits está en los Amstrad PCW o en adaptadores MDA-Hercules en PC. Mas tarde apareció esta técnica en color con distintas combinaciones para simular una mayor paleta de colores. Un ejemplo muy gráfico de esto es el que se encuentra en algunos envases de cartón de los productos de los comercios, donde en alguna parte oculta al exterior suele aparecer unas referencias impresas de la paleta de colores y tramas empleados. Los envases tipo Tetra-Brick a veces los tienen en la parte inferior y en las cajas de galletas en alguna pestaña interior.

En informática los tramados también se pueden utilizar con técnicas parecidas, basando las combinaciones con las mismas reglas que el RGB tradicional. Esto es, si juntamos un punto rojo con otro verde nos dará un efecto de un único punto de tonalidad amarilla, rojo con azul tonalidad magenta, etc. Para una imagen de un determinad tamaño, sería necesario al menos duplicar la resolución, pues cada punto de la imagen original será simulado, al menos, por dos en la pantalla. Como esto no es muy práctico en un CPC por no disponer de suficiente resolución en modos de color, lo que haré será variar el color final de cada punto respecto a una trama creada. Así, en posiciones alternas, aplicaré parte del filtro para unos puntos y otra parte para el resto, de manera que producirá en general un mejor efecto visual.

En el caso de la paleta de 27 colores del CPC, vamos a empezar creando una trama de dos puntos de colores adyacentes; como ejemplo, en lugar de tener 3 posibles rojos obtendremos 5 sumando las mezclas de estos, aplicando la misma técnica para el verde y el azul. Para ello utilizaremos una trama como esta:

Donde el negro es el primer color a aplicar y el blanco el segundo. Continuando con el ejemplo, rojo medio y rojo máximo mostrarían una trama con una tonalidad simulada de rojo entre medias de estos. Cada parámetro de RGB quedaría ahora como 0 : 0+1 : 1 : 1+2 : 2. Esto significa que un punto que obtenga el primer valor de la escala, es decir cero, siempre será cero; otro punto que obtenga el segundo valor, trama 0+1, mostrará alternativamente el valor 0 y el 1; para el tercer valor, el 1, siempre será 1 y así sucesivamente hasta terminar la escala.

Como he dicho, el CPC no tiene mucha resolución lo que no permite aplicar esto con mucha efectividad. En lugar de sustituir cada punto por dos nuevos (lo que obligaría a duplicar la resolución), voy a aplicar a cada punto de origen uno solo en la imagen de destino. Lo que habrá que tener en cuenta es que, para un punto con trama (0+1 y 1+2), el primer punto será el equivalente al primero de la trama y el siguiente por el segundo. Esto significa que, en una línea concreta de la imagen, para las columnas pares se aplicará el primer valor de la trama y para las impares el segundo valor; en la siguiente línea se invierten, es decir, el primero a los impares y el segundo a los pares, consiguiendo con ello una mezcla homogénea a lo largo de toda la imagen similar a un tablero de ajedrez. Como se trata de un patrón regular, el efecto visual se disimula aún teniendo una baja resolución de pantalla.

Ahora los componentes RGB no tienen 3 posibles valores si no 5, pues he intercalado dos tramados, lo que modifica nuestra fórmula en:

x =(5*v)/255

Dando como posibles resultados de 0 a 4. (Al igual que en el ejemplo anterior en Basic, convertir 5 a 4 cuando el valor v=255). Entonces debemos tener en cuenta que cuando los valores sean 1 ó 3 estos serán tramados alternos y 0, 2 ó 4 lisos sin trama. El resultado en la imagen de prueba es:

Como se puede observar la imagen en general ha mejorado bastante respecto a los resultados anteriores, sin variar en ningún momento la resolución. Ahora aparecen ciertos colores tramados, que consigue un efecto visual de mayor profundidad de color, aunque sea simulado. También se aprecian mejoras en los colores en general, sobre todo los de primer plano que están mejor definidos, pareciéndose ahora más al original; los fondos difuminados consiguen un peor resultado debido a que los colores son muy cercanos entre sí, perdiendo su diversidad al ser representados con los mismos tonos en el CPC. En un Amstrad CPC real el resultado es más brusco debido a que la imagen ocupa toda la pantalla, por lo que los píxeles son más grandes y provocan un efecto menos pulido. En general ha ganado en riqueza visual, aunque esto dependerá al final de cada imagen.

Pero ¿puedo simular más colores? ¿Cómo? Sencillo, creando tramas más complejas. Para ello voy a crear no un color tramado entremedias de dos reales, si no a crear tres. Si, si, tres, lo que nos va a dar mayor juego a la hora de representar. Si antes era una trama simple entre dos colores ahora la cosa se complica:

Y se complica bastante. Si antes teníamos una trama de dos posibles puntos unidimensionales de 2x1, ahora tenemos 4 bidimensionales formando un cuadrado de 2x2. Estos se aplicarán cada 2 líneas, es decir, en la primera línea de la imagen aplicaremos los dos puntos superiores de la trama, igual que en el anterior ejemplo, y en la siguiente línea los dos inferiores con el mismo método, alternándolos constantemente. Esto nos dibujará áreas tramadas de 2x2 más elaboradas que en el primer método, lo que redundará en un mejor resultado (al menos teóricamente...). Si el objetivo es sustituir un punto de origen con una trama completa, tendríamos que cuadruplicar la resolución, algo imposible en un CPC; en su lugar voy a sustituir, como en la prueba anterior, un punto de origen por uno en el destino, alternando los tramados según su posición en el plano. Veamos como quedaría teóricamente la paleta de colores:

Como se puede apreciar, con este nuevo tramado se crean 3 nuevos colores con trama entre dos colores reales del CPC, donde antes no había ninguno. Esto significa que por cada 2 colores adyacentes en la paleta tenemos ahora 5 colores, lo que hace una cifra de unos 153 colores representables (según mis cálculos). Un aumento más que significativo de la paleta.

En una imagen sin tramas los valores, para cada parámetro de 24bits correspondientes a los 3 del CPC, son 0-84 | 85-169 | 170-255. En el caso de usar las tramas simples esto queda como 0-51 | 52-101 | 102-152 | 153-203 | 204-255. Veamos como queda ahora la escala con el nuevo sistema de tramado:

      28        85       141       198       255

|----|----|----|----|----|----|----|----|----|

0        56        113       170       226

Al aplicar esta nueva trama el resultado sería algo así:

El resultado en cuanto a color es mucho más exacto, pareciéndose bastante más que las versiones anteriores, apreciando una mejora sobre todo en las partes más oscuras como las que hay por debajo del ala. Pero la baja resolución juega en esta ocasión una mala pasada, haciendo que los degradados de color no sean todo lo suaves que se desearía. Curiosamente el fondo verdoso aparece en tonos grisáceos. Esto es debido a que está desenfocado y las tonalidades se muestran bastante difuminadas, problema muy común de colores erróneos en este tipo de reducciones. Sin embargo el resultado de la imagen del pájaro, en primer plano, está mejor definida y por tanto los colores también, debido principalmente al gran contraste entre los colores, produciendo un mejor efecto en toda su área.

Estos sistemas de tramados permiten conseguir una mejor exactitud de color, al menos simulado, pero se pierde definición en el contorno de determinadas figuras de la imagen lo que conlleva a una peor definición general. Estos efectos positivos son muy apropiados en sistemas con mucha resolución, pero empeoran en aquellos donde esta es muy baja como en la mayoría de los sistemas de 8 bits de los '80, lo que la convierte en una opción poco recomendable.

En los programas de conversión de formato y editores de imágenes podemos encontrar diferentes métodos de tramados, llamados en inglés 'dither', que brindan diversas opciones para ajustar el resultado final, basados principalmente en otros tipos de lógica. En este artículo se han tratado las tramas desde un punto de vista más orientado a la programación teórica que a otra cosa, con ejemplos sencillos de entender y poner en práctica. Por ello no pensemos que es lo único que se puede conseguir, por que también se pueden utilizar otras técnicas combinadas para mejorar significativamente el resultado.

Para finalizar una instantánea con el original y los tres posibles resultados: