Next:El Actor ImageUp:VisualizaciónPrevious:bicotiImageImplmentation

La necesidad del Pixel Converter

Ya habíamos visto como lidiar con la generalidad del pixel en (2.2) haciendo uso de los PixelConverter's. Esta solución se mostró muy conveniente en su momento así que volveremos a usarla ahora con el propósito de unificar la forma en que BiCoTI habla con el resto del mundo.
En los mappers se había adoptado el pixel RGBA como pixel central desde el cual se escribía la imagen en un pixel particular usando el Pixel Converter adecuado. Por ejemplo si la bicotiImageImplementation era monocromática con 256 niveles de gris, el tipo unsigned char era suficiente para el PixelType. Digamos que usamos bicotiImageImplementation2DArray<unsigned char> para fijar ideas. Necesitamos un Pixel Converter entonces capaz de convertir entre pixeles RGBA y unsigned char y este sería el bicotiPixelConverterChar2RGBA de Fig.23.

Figure 23: El bicotiPixelConverterChar2RGBA.

Si la imagen BiCoTI usara color formato RGB con componentes en el rango [0,255], hubiéramos elegido un pixel bicotiRGB<unsigned char> y a bicotiPixelConverterRGBChar2RGBA para leer y escribir en archivos gráficos.

Figure 24: El bicotiPixelConverterRGBChar2RGBA.

En Fig.25 se ve el esquema usado para los mappers.

Figure 25: El Pixel Converter en los mappers.

Para leer una imagen desde un archivo en formato jpeg sobre una implementación BiCoTI de pixeles HSV, el mapper es responsable luego de leer un pixel del archivo, de pasarlo en formato RGBA al PixelConverter para que este los convierta al formato adecuado, en este caso bicotiHSV<int>.
Al ser clases paramétricas, los Pixel Converter's no necesitan heredar de una interfaz común; solo es necesario que implementen como métodos estáticos: Convert() y Unconvert() con los parámetros adecuados al caso.
Para la visualización el esquema sería ligeramente distinto. Cada biblioteca gráfica tiene su propio pixel definido, y como es en estos donde hay que escribir en última instancia, habría inevitablemente que tener implementaciones de Pixel Converter para cada una. Adoptar el bicotiPixelRGBA como pixel intermedio implicaría dos conversiones para refrescar cada pixel de la implementación al homólogo. Si quisiéramos ver la imagen leída en el ejemplo anterior usando QT deberíamos usar nuevamente un bicotiPixelConverterHSVInt2RGBA para convertir cada pixel a RGBA y otro para pasar a QRgb, el pixel color de la biblioteca.

Figure 26: Una alternativa para la visualización.

En la visualización la performance es especialmente crítica y por lo tanto optamos por otro esquema en el que se suprime RGBA como pixel intermedio y se escribe directamente al pixel de la biblioteca gráfica. El esquema elegido puede verse en Fig.27. Para la misma función habría bastado un bicotiPixelConverterHSVInt2QRGB.

Figure 27: La alternativa elegida.

Para evaluar la conveniencia de la estrategia elegida comenzaremos viendo que perdemos respecto a la anterior:

1. En primer lugar perdemos la posibilidad de re-usar lo conversores ya implementados para los mappers.

2. Aumenta geométricamente el número de conversores al tener que implementar todas las combinaciones de estos.

3. Se vuelve necesario que los bicotiHomologousFactory sean templates de PixelConverter. En consecuencia manejar simultáneamente más de un tipo de pixel en una misma aplicación, requiere la misma cantidad de factories.

Con la segunda alternativa se consigue una mejora en la velocidad de refresco de alrededor del 30%. ¿Vale este 30% las complicaciones acarreadas?. Estamos seguros que sí.

• Los puntos (a) y (b) no son tan críticos por la sencillez de los conversores, que realmente no suelen ser más de una par de lineas de código.

• El factory de todos modos iba a ser un template de pixel como veremos en (3.2.3) y en cualquier caso, la solución propuesta en (4) aligera el problema.

Next:El Actor ImageUp:VisualizaciónPrevious:bicotiImageImplmentation