Hace 1 año y medio decidí abordar el proyecto de diseñar un programa que permitiera realizar la exploración de la motilidad ocular extrínseca. Para ello elegí la prueba subjetiva de Hess y Lancaster (Procedimiento de Hess-Lancaster).

Su implementación requiere diferentes fases:

1. Datos técnicos originales del Test y su compresión.

2. Características del Programa que simule el Test con la mayor garantía de fidelidad y reproductibilidad.

3. Creación del programa, su depuración y probado.

4. Características del soporte físico necesario.

 

Datos Originales del Test

PANTALLA

La obtención de las características técnicas del test de Hess-Lancaster no ha sido difícil. Existe aún bibliografía en la que se exponen los datos necesarios para el diseño. En concreto el Libro de Hugonnier, "Estrabismos, Heterofórias y parálisis oculomotoras" de 1973 expone con claridad en qué consiste la pantalla y los test, su tamaño... También el libro de Castanera, "Estrabismos y Heteroforias" de 1968 resulta ilustrativo. Junto a ello, artículos originales de los autores me clarificaron la situación técnica.

En este punto resulta imprescindible diferenciar la pantalla de Hess y la pantalla de Hess-Lancaster. La pantalla de Hess es curvilínea y por tanto más precisa. La pantalla de Hess-Lancaster es rectilínea. El procedimiento de Hess-Lancaster puede usar cualquiera de las 2 pantallas, aunque es preferible la de Hess, como se ha indicado, por su mayor precisión.

No dispongo de las ecuaciones para realizar las líneas y columnas de la pantalla de Hess. No deben ser muy difíciles, pero no las encuentro. El ingenio me llevó a usar la pantalla de Hess que existe en el servicio de Oftalmología del Hospital Universitario Torrecárdenas de Almería. La medí, fotografié y con el programa Coreldraw conseguí sus datos esenciales. De esta forma pueden calcularse los porcentajes en los que están situados los puntos esenciales de exploración.

En un principio usé como referencia un sistema cartesiano de coordenadas. Por tanto el punto 0,0 estaría situado en el centro de la gráfica. Usando una hoja de Microsoft Excell incluí todos los datos y realicé los cálculo pertinentes para definir los porcentajes a los que se encuentra cada punto del eje 0,0 cartesiano. Se han calculado los porcentajes para poder ser dibujado en cualquier tamaño de pantalla.

Este sistema de coordenadas ha sido usado en gran parte del desarrollo del programa. Esto es así debido a que, por mi ignorancia, usé un sistema de proyección en 3D. Concretamente GLScene para Delphi. Cuando usas el sistema "habitual" de gráficos, al rotar los objetos aparece el borde serrado típico. Por tanto no puede usarse para este fin y debe obtarse por un motor de gráficos diferente. GLScene puede representar un mundo 3D o 2D. Elegí mal, pues al usar el mundo 3D, pasar la localización de un punto en pantalla real (pixel) al mundo 3D es complejo y biceversa peor. No obstante conseguí calcular las posiciones y movimientos... pero seguía sin convencerme. Volví a releer artículos y explorar ejemplos, llegando a la conclusión que debería usar el mundo 2D si quería obtener algo funcional. En el mundo 2D puede controlarse perfectamente la posición real de un pixel y su correspondiente en el mundo 2D. Pero el sistema de coordenadas es diferente, el punto 0,0 está en la esquina inferior izquierda. Conclusión a rehacer todos los cálculos en Excell y cambiar toda la programación.

Y ya para complicar más aún el asunto, es preciso saber que el "lienzo" sobre el que se dibuja en un objeto (llamado Canvas en inglés) tiene un sistema de coordenadas diferente. en el Canvas el origen de coordenadas 0,0 es la esquina superior izquierda. Y la posición del ratón está referenciada así. Por tanto hay que trasladar la posición del Canvas a la del mundo 2D de GLScene. Pero para eso están las matemáticas.

La pantalla de Hes-Lancaster no presente ninguna dificultad de diseño, pues es cuadrada y el cálculo es muy sencillo.

Ya dispongo de los datos concretos de cada tipo de pantalla y puedo recrearla a cualquier tamaño.

 TESTIGOS

El diseño de los testigos ha condicionado el sistema de programación. Como se ha dicho, cuando dibujas un objeto, los bordes tienen aspecto de "serrados". Para evitarlo ha debido de usarse un sistema de gráficos más sofisticado. Se optó por GLScene.

La forma del testigo me creó muchas dudas. Al final decidí usar rectángulos. Estos pueden rotarse con facilidad y su rotación es percibida perfectamente. Es cierto que en otros sistemas se usan círculos o segmentos, pero no me parecieron convenientes.

El color si es un problema. Debido a la naturaleza de las pantallas y su forma de crear el color, las gafas rojo-verde no funcionan bien. El filtro rojo sí cumple su labor, pero el verde no. Con el filtro verde aún se percibe el testigo rojo. Para resolver el problema se ha optado por incluir un selector de colores y una barra RGB. Los pixels en la pantalla están formados por 3 puntos luminosos: rojo, verde y azul. Los diferentes colores se forman cambiando la intensidad de cada punto. Al incluir la barra RGB se puede apagar el punto que deseemos y pueden adaptarse mejor a las gafas que usemos. De esta forma se puede elegir el color de cada testigo y adecuarse a las gafas de que dispongamos. Además he probado varios tipos de gafas y al final he llegado a la conclusión que las  mejores son aquellas que usan un filtro rojo y otro azul. Con estas sí puede ajustarse el color de los testigos para ser vistos sólo por el ojo correspondiente. Todas las que he podido conseguir tienen el filtro rojo en el ojo izquierdo, pero esto tampoco es algo no superable.

Al final se ha incluido un selector de color RGB, de esta forma se pueden apagar completamente los pixels del color primario que deseemos. De esta manera el filtro verde ya funciona correctamente.

SOFTWARE

El programa ha sido escrito completamente en Pascal. Se ha usado la versión de Codetyphon 6.9 para windows. El compilado final puede hacerse para microprocesadores de 32 y 64 bits. En un principio sólo existirán versiones para Windows y Linux. Verdaderamente ha sido un reto que ha merecido la pena. Ha habido momentos difíciles. Tanto, que tras meses de trabajo en una dirección, comprobaba con desesperación, que el final del camino era una muralla infranqueable. Esto me ha ocurrido en 3 ocasiones y me ha obligado a replantear todo el proyecto y a reescribir cientos de lineas. Los escollos siempre han estado relacionados con los gráficos. 

De igual manera he tenido que recurrir a algún que otro tomo de matemáticas para no fallar en los cálculos.

En esta primera versión uno dispone del sistema digital completo para realizar las exploraciones, grabar los datos e imprimirlos. En una segunda fase deseo implementar un sistema de diagnóstico automatizado, así como de comparación de diferentes pruebas seriadas.

Como siempre puede haber algún nostálgico de tiempos pasados, he incluido un modo de exploración 'analógico', nada se guarda y uno tiene el control completo de la exploración. Por supuesto he incluido la pantalla de Hess y la de Hess-Lancaster. Más nostalgia no cabe ya.