Técnicas

La verdadera e-gestión

Esta semana, y después de varios años sin vernos (aunque sí que hemos hablado por teléfono y cruzado correos habitualmente), he coincidido con un técnico en informática de los "antes". Por supuesto que no estamos anclados al pasado ninguno de los dos e incluso él controla algunas tecnologías que me agradó que me contara a su manera.

Lo que les quería contar son las ideas que se me ocurren fruto de la conversación con él. Conocemos lo evolucionado de la e-administración en nuestro país. Al menos en lo que se refiere en la interlocución con los ciudadanos y empresas, cada vez está más desarrollado. La web ha facilitado la presentación e incluso la cumplimentación de modelos. Hay organismos que proporcionan programas de ayuda y otros que han desarrollado plataformas para la interlocución.

Lo que a él le iba por la cabeza es que, en algunos aspectos, seguimos uno o varios pasos por detrás en la tecnología... Para unos procesos de principio de año estaba esperando a que una administración pública pusiera a disposición en su web unas instrucciones en función de las cuales el tiene que desarrollar o actualizar un algoritmo. Además estaba esperando a que una tabla con datos se publicara para avisar a los "clientes" que la modificaran en la aplicación. Por supuesto la tabla sería publicada en plan tablón de anuncios en HTML y punto y cada uno que la teclee en su programa.

Su idea era sencilla. Lo suyo sería que esta administración tuviera una API y que fuera posible que los programas que él desarrollaba (así como los de la competencia o los hechos a medida) enviaran datos y le devolvieran los resultados. Así el algoritmo sería el mismo para todo el mundo y las modificaciones y mantenimiento se realizarían en el origen evitando errores e interpretaciones. Para la tabla lo mismo, mediante funciones de la API se consultaría y devolvería resultados. Todo esto habría que hacerlo con cuidado y teniendo presente los ciclos de desarrollo y mantenimiento de software ya que por motivos variados si en un momento dado se quisiera utilizar el algoritmo o los datos de hace unos meses o años, éste debería permitir el utilizarlos y devolver los datos que proporcionara en aquella ocasión. Una clave o certificación digital devuelta con la función se podría devolver con los datos y almacenarlos junto con el resultado para evitar cualquier duda de cómo se obtuvo el resultado y cumplir con las prácticas de auditoría y seguridad así como la consistencia de la información.

Visto todo lo anterior, ¿por qué no un lenguaje universal en esta línea? Nuestro equipo  no debería ni saber sumar, sólo enviar los datos y la operación al "control central" y este devolvería la solución. ¿Es la era del cliente super ligero? ¿Y la del super host? Haremos un texto con más reflexiones sobre esto...

Este planteamiento no es nuevo, no deja de ser la paradoja del dato único. Modelo imprescindible de obligado cumplimiento para la higiene de la gestión de cualquier automatización de la gestión de datos. Quizá lo novedoso está en que si bien ahora los sitemas tienden a la centralización (sobre todo en el caso de aplicaciones) esta inciativa no sólo nos llevaría a centralizar si no a ir al origen, que es de alguna manera lo que postula la paradoja mencionada.

En fin sirva de esbozo y de enriquecimiento a otras actividades que estos días vienen desarrollando fernand0 y Antonio con la automatización de la gestión y organización de actividades TIC en Aragón que (un otro) Fernando nos cuenta en su recien inaugurado blog.. Ya que de alguna forma nos están proponiendo algo en la línea de lo indicado, información disponible, centralizada y utilizable mediante desarrollos basados en ellas.

¿Alguien conoce iniciativas en esta línea?

PD. La última pregunta no es vacía. Lo último que inventé , fué el Google Transit, les envié la propuesta (sí a los sres. de google) y les insistí en que lo más importante sería que se definiera un estandard para la publicación de los datos por parte de los actores en el asunto... al final y viendo que no contestaban me mosqueé pero un día lo entendí todo... ya estaba desarrollado y en marcha. No puedo decir que me quitaran la idea ya que parece que el proyecto llevaba tiempo. Solo se me ocurrió que ya me gustaría concluir como el filósofo diciendo "sólo sé que no sé nada". Hablamos hace días con otros de que no es malo que a alguien se le ocurran las ideas antes que a tí, por lo menos estamos en la línea de cosas que hacen los grandes...

Puntos por Pulgada.

Desde los primeros diseños en que trabajé éste ha sido un tema que me ha dado bastante que pensar y probar. Al usar Pov-Ray (o cualquier otra herramienta de trazado de rayos) el acertar con el número de puntos por pulgada para conseguir reproducciones de calidad y que el tiempo de cálculo de las imágenes sea razonable es un objetivo importante. He buscado información en Internet y la verdad es que no he encontrado nada que sea concluyente por lo que me he decidido a incluir aquí mis experiencias para que sirvan a quien le pueda interesar o las complemente quien sepa del tema.

En principio a mayor cantidad de puntos por pulgada mayor calidad tendrá la reproducción. 300 dpi es un estandard de impresión en artes gráficas y desde el punto de vista científico el ojo no distingue mas de 200 dpi. Y hay otro parámetro importante que es a qué distancia se observará la reproduccion.

En mi experiencia no se cumple lo de que a mayor resolución mejores resultados ya que calculando a 400 dpi y obteniendo la reproducción mediante revelado digital en un laboratorio profesional y con una máquina que trabaja a 400 dpi (por lo tanto punto a punto exactamente, el resultado fue un tanto frío excesivamente afilado muy "quirurgico".

En los programas de trazado de rayos podemos también ajustar el antialias que es el parámetro que permite calcular la imágen teniendo en cuenta más de un rayo por cada punto a presentar. Además existen técnicas avanzadas mediante las cuales es posible decir a la herramienta que de forma recursiva calcule más rayos en función de si el color de los rayos adyacentes es muy diferente o que no calcule tanto si son de color parecido. El problema con el antialias es que suele aumentar el tiempo de proceso de forma dramática.

Actualmente utilizo una resolución de 254 dpi y normalmente no uso antialias. Los resultados podrían ser más suaves (si lo usara) pero es bastante satisfactorio y el tiempo de cálculo es razonable, en la mayoría casos al pasar las imágenes a jpg el propio algoritmo de compresión (suelo utilizar entre 85% y 95%) suaviza la imagen. La razón de la utilización de esta resolución es porqué es la más próxima a 300 dpi y que me permite obtener del tamaño de la imagen en puntos el tamaño de la reproducción en centímetros simplemente dividiendo para 100 el alto y el ancho (ya que una pulgada equivale a 2,54 cm.). Así para una reproducción de 10x15 cm. Utilizaré un archivo calculado a 1000x1500 píxel. La mitad, sería una resolución de 127 dpi y en las pruebas que he realizado para mis trabajos no he obtenido buenos resultados. Con 150 dpi ó 175 dpi se pueden obtener buenas reproducciones de fotografía digital pero siempre que sean ampliaciones, formatos 30x40 cm o mas que nos obliguen a mirarlas desde un poco de distancia.

Todo lo indicado hasta aquí se comporta correctamente en impresoras de sublimación de las que se usan para revelado fotográfico. En el caso de imprimir en plotter o impresoras de chorro de tinta o incluso en láser, el disponer de más puntos sí que proporciona mejores resultados. La verdad es que no controlo la tecnología pero hasta donde yo sé los drivers de las impresoras hacen un proceso parecido al del trazado de rayos, ajustandose a la resolución a la que van a imprimir el driver calcula las tramas de los colores puros que es capaz de hacer la impresora para simular los colores del archivo original. Es importante el que estas tecnologías de impresión no son capaces mas que de imprimir en unos pocos colores siguiendo los patrones tipo CMYK y obteniendo el resto de colores por mezcla de los iniciales. Lo importante será cómo se mezclan y que el papel absorba bien las tintas para que no se produzcan micro-emborronamientos que afectan a la falta de nitidez de las reproducciones.

Lo relacionado con el CMYK daría para otro artículo pero les adelanto que mientras las imágenes están generadas en RGB el driver se debe encargar de traducirlas a CMYK lo cual hace que algunos colores no queden igual en los dos espectros de color...

Trazado de Rayos

Con este texto pongo en marcha una nueva sección más técnica. Si les parece interesante díganlo y me comprometo a publicar más contenidos incluso de manejo del propio POV-Ray.

Trazado de Rayos es como se conoce la técnica que emplean los programas que como POV-Ray (que es el que yo uso) para la proyección en dos dimensiones de planteamientos (o escenas en el lenguaje del propio POV-Ray) en 3d. En realidad es un lenguaje de programación el cual nos permite situar objetos en el espacio y proporcionarles características tanto de colores o acabado. Se controla la iluminación (tanto ambiental como las diferentes fuentes que se dispongan) y la forma en que los objetos interactuan con ella.

Hay herramientas de trazado de rayos más intuitivas y que resultan más amigables de manejar. Lo que me gusta particularmente de ésta es que todo se define de forma procedural mediante código al puro estilo de cualquier lenguaje de programación permitiendo bucles y condiciones. Mas adelante ya les contaré más cosas de cómo trabajar en POV.

Técnicamente el trazado de rayos se basa en un esquema simple. Se trata de ir lanzando rayos de luz desde el punto de vista del observador hasta el entorno tridimensional e ir capturando en una pantalla virtual situada entre el observador y la escena los diferentes grados de luz de cada punto "atacado". Es como si delante de nuestros ojos (mejor dicho ojo) situaramos una especie de rejilla. Cada punto de la imágen equivale a una casilla de esa rejilla y lo que hace el algoritmo es decidir de qué color tiene que ser esa casilla para capturar una representación de la imagen en función de lo que haya en la escena, sean cuerpos opacos, transparentes y aplicando sus características de reflexión y refración a la luz. También se puede entender como una cámara de fotos virtual. De lo que se trataría es de ir calculando el color de cada punto de la imagen en función de la escena a "fotografiar". Desde el punto de vista técnico es importante en el algoritmo de Trazado de Rayos el determinar las superficies vistas de la escena, la suerte es que a nosotros esto nos lo dan resuelto en la implementación.

Mas adelante les contaré algunas cuestiones acerca de la resolución pero les adelanto que aquí ocurre lo mismo que con las cámaras fotográficas cuantos más puntos tenga una imágen mayores posibilidades de ampliación proporciona.

La técnica de Trazado de rayos tiene la bondad de conseguir resultados muy realistas (aunque yo en mis propuestas juego con otro tipo de planteamientos) y la desventaja es el tiempo de proceso para la obtención de los resultados.