Fin de la estereoscopía con gafas activas

NVidia ha abandonado el desarrollo de gafas estereoscópicas así como el soporte de estereoscopía en los drivers de sus tarjetas gráficas.

La fabricación de gafas activas se paralizó hace más de 6 meses ya y además, según la nota de prensa de Nvidia (https://nvidia.custhelp.com/app/answers/detail/a_id/4781), el último driver que soporta estereoscopía es el driver con número de versión Release 418 publicado en abril 2019.

Nvidia dispone de un histórico de drivers en su página web, de manera que si necesitas un driver compatible con tus gafas estereoscópicas en un futuro, siempre podrás descargarlo, pero el problema de depender de un driver antiguo es que si en un futuro se realiza algún cambio en el sistema operativo referente al subsistema gráfico, ese driver es posible que deje de funcionar.

A día de hoy es prácticamente imposible encontrar gafas activas en el mercado, así que si quieres tener alguna de sobra por si se estropean las que usas para trabajar, te recomendamos que te pongas a buscarlas cuanto antes en eBay o en tiendas online tanto en España como en el extranjero.

Digi3D.NET siempre podrá mostrar estereoscopía con gafas de anaglifo, monitores auto-estereoscópicos, monitores con gafas polarizadas y estereóscopos, pero de estas opciones quizás únicamente el estereóscopo se podría considerar profesional.

Hemos estado dándole muchas vueltas a cómo solucionar este problema que se nos plantea, pues aunque ahora mismo el mercado de la fotogrametría está como está, nosotros tenemos que seguir dando soporte a los usuarios que confían en Digi3D.NET para su profesión.

Hemos analizado todas la soluciones que hay en el mercado (gafas de realidad aumentada que tienen un precio de 3000€, y cascos de realidad virtual, y al final hemos optado por comenzar a desarrollar el módulo estereoscópico en realidad virtual para el casco Oculus Rift S, de manera que para final de año esperemos tener la primera BETA de Digi3D.NET para realidad virtual.

Este casco de los más baratos del mercado (450€) y lo desarrolla una empresa que se dedica únicamente a eso, de manera que no parece que vayan a interrumpir nunca el desarrollo de cascos de realidad virtual.

Mejoras en el panel de proyecto fotogramétrico

Acabamos de añadir a Digi3D.NET una mejora en el panel fotogramétrico.

Hasta ahora, cuando cargábamos un proyecto fotogramétrico el panel de proyecto fotogramétrico nos mostraba todas las pasadas/modelos que había podido cargar (es decir, para todas aquellas en las que había localizado tanto orientación como las imágenes en el disco duro). En caso de que algún modelo no se hubiera podido cargar algún modelo, éste se mostraba deshabilitado, pero se mostraba igualmente.

La mejora que presentamos hoy consiste en que ahora podemos configurar mediante la opción del menú Herramientas/Configuración/Proyecto fotogramétrico una nueva opción: Mostrar solo modelos cargados.

Si activamos esta opción el programa filtrará los modelos que no ha podido cargar (porque no ha localizado las imágenes en el directorio) y nos mostrará únicamente aquellos que ha podido cargar.

Puedes ver esta nueva funcionalidad en acción en el siguiente vídeo:

Añadida compatibilidad con Esri Projection Engine

Acabamos de añadir a Digi3D.NET la posibilidad de crear sistemas de referencia de coordenadas compatibles con Esri Projection Engine.

Gracias a esta nueva característica, podrás crear archivos Shapefile con sistemas de referencia de coordenadas y que ArcMap los cargue sin problemas.

Puedes activar esta característica mediante la opción del menú Herramientas/Configuración/Sistemas de referencia de coordenadas/Crear cadenas WKT compatibles con, donde nos encontramos con dos opciones:

  • Esri Projection Engine sin incluir código EPSG
  • Esri Projection Engine incluyendo código EPSG
  • OpenGis Coordinate Transformation Service

Si activamos cualquiera de las opciones de tipo Esri Projection Engine y creamos sistemas de referencia de coordenadas horizontales, es decir, con el sistema vertical desconocido, los archivos .PRJ creados por Digi3D.NET serán exactamente iguales a los creados por Esri Projection Engine.

La diferencia entre las dos primeras opciones es que la primera incluye el código EPSG como por ejemplo en el siguiente ejemplo para el sistema WGS84 / UTM Zona 30N:

PROJCS["WGS_1984_UTM_Zone_30N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-3.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0],AUTHORITY["EPSG",32630]]

y la segunda no lo incluye, como por ejemplo en el siguiente ejemplo para el mismo sistema de referencia de coordenadas:

PROJCS["WGS_1984_UTM_Zone_30N",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-3.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

Puedes ver esta nueva funcionalidad en acción en el siguiente vídeo:

Mejorando la compatibilidad WKT con programas que no siguen el estándar OpenGIS Transformations Service

Digi3D.NET crea cadenas WKT compatibles con el estándar OpenGis Coordinate Transformation Service, y ese estándar dicta que si un sistema es tridimensional (que es como trabaja Digi3D.NET) debe crear sistemas de referencia o puramente 3D como los Geográficos 3D o compuestos en los que hay dos partes: una horizontal y otra vertical.

En el caso de sistemas compuestos es legal que tanto la componente horizontal como la vertical pueden ser locales (desconocido), de manera que si en Digi3D.NET creas un sistema de referencia de coordenadas en el que conoces la parte horizontal (por ejemplo WGS84 / UTM Zona 30N) y desconoces la vertical, el programa va a crear un sistema compuesto del tipo WGS84 / UTM Zona 30N + vertical local.

Esto está muy bien para los programas que siguen el estándar, pero vuelve locos a los programas que no lo siguen o que no son 3D, de manera que para mejorar la compatibilidad con esos programas, hemos añadido una opción en Digi3D.NET que nos va a permitir configurarlo para que en el caso de que el usuario cree un sistema 3D en el que el sistema vertical sea desconocido, al crear archivos .PRJ con cadenas WKT, estas se creen como sistemas 2D puros. Si por el contrario el sistema vertical no es local o desconocido, aunque tengas esta opción activada, el programa va a crear una cadena 3D.

Puedes activar esta funcionalidad en la opción del menú Herramientas/Configuración/Sistemas de referencia de coordenadas/Trabajar con sistemas 2D (horizontales) si el vertical es desconocido.

Modificación en el módulo de carga de archivos de PhotoScan

Hemos añadido una modificación en el módulo de carga de proyectos de PhotoScan en Digi3D.NET que nos va a permitir trabajar correctamente en el escenario en el que el usuario de PhotoScan le hace pasar coordenadas con altura ortométricas por coordenadas con alturas elipsoidales.

PhotoScan internamente trabaja siempre con altitudes elipsoidales. Si le proporcionamos correctamente coordenadas con altitudes ortométricas, él las transforma internamente a elipsoidales y almacena en el archivo de proyecto un sistema de referencia que indica que el operador introdujo correctamente coordenadas con altitudes ortométricas.

El problema es que en la práctica no hemos visto ni un único proyecto de PhotoScan con coordenadas ortométricas. Todos, y cuando digo todos quiero decir todos los archivos que nos han llegado tienen coordenadas elipsoidales, sin embargo los operadores nos aseguran que lo son.

De manera que nos hemos acercado a una empresa que dispone de una licencia y hemos hecho un estudio para aclarar las cosas de una vez por todas. De paso hemos modificado Digi3D.NET para poder asumir los tres escenarios posibles que son:

  1. Al crear el proyecto de PhotoScan el operador ha introducido coordenadas de puntos de apoyo con altitudes elipsoidales.
  2. Al crear el proyecto de PhotoScan el operador ha introducido coordenadas de puntos de apoyo con altitudes ortométricas indicándoselo así a PhotoScan
  3. Al crear el proyecto de PhotoScan el operador ha introducido coordenadas de puntos de apoyo con altitudes ortométricas haciéndose pasar por elipsoidales.

La manera de trabajar correctamente con PhotoScan es la 1 o la 2, pero repito: el 100% de los proyectos de PhotoScan que han llegado a nuestras manos (mediante tickets de soporte técnico, archivos que hemos cargado vía TeamViewer en los equipos de nuestros clientes, etc.) están hechos mediante el método 3.

¿Y cual es la causa por la cual todos los modelos que vemos están por el método 3?

Pueden ser varios motivos (desconocimiento, no leer las instrucciones de PhotoScan o al menos donde se habla de los modelos de geoide, etc.), pero vamos a centrarnos en el interfaz de usuario, y el problema es que el interfaz de usuario no ayuda a localizar sistemas de referencia con alturas ortométricas como vas a comprobar a continuación:

PhotoScan tiene un cuadro de diálogo en el que podemos indicar el sistema de referencia de coordenadas de los puntos de apoyo:

Este cuadro de diálogo tiene un desplegable (titulado Sistema de coordenadas) que te permite seleccionar los últimos sistemas de referencia empleados. Si el sistema de referencia que buscas no está en el desplegable, tienes que seleccionar la opción de los tres puntos que se muestra un cuadro de diálogo de búsqueda que tiene todos los sistemas EPSG soportados por PhotoScan:

Este cuadro de diálogo no es tán versátil como el de Digi3D.NET y no te permite crear tus propios sistemas, únicamente te permite seleccionar alguno preconfigurado, y como puedes ver en la captura anterior, no hay ni un solo sistema de referencia preconfigurado con componente vertical (bueno, en realidad si que hay uno o dos que son los únicos sistemas de referencia compuestos que publica la base de datos EPSG pero que en la práctica no creo que utilice nadie).

En la captura anterior puedes ver que hemos seleccionado WGS84 / UTM Zona 30N, pero no somos capaces de seleccionar
WGS84 / UTM Zona 30N + EGM2008 por ejemplo, pues no existe en la base de datos preconfigurada de PhotoScan.

Este cuadro de diálogo no tiene ningún botón del tipo “Crear mi propio sistema de referencia compuesto” de manera que no podríamos crear el sistema WGS84 / UTM Zona 30N + EGM2008, pero lo que sí que podemos hacer es importar un archivo .PRJ que defina ese sistema. Para ello, tendremos que irnos a otro programa como Digi3D.NET y crear un archivo PRJ mediante el cuadro de diálogo de Sistemas de Referencia de Coordenadas, seleccionando el sistema que nos interesa y pulsando el botón Exportar.

Una vez exportado, lo podemos importar en PhotoScan pulsando el botón de la carpeta en el cuadro de diálogo Seleccionar sistema de coordenadas y una vez importado, éste aparecerá en la sección de Sistemas de coordenadas definidos por el usuario tal y como puedes ver en la siguiente captura de pantalla:

Pero ¡aún no podrías seleccionar este sistema! pues para poderlo seleccionar, previamente tendrás que haberte descargado de la página de Agisoft el modelo de geoide EGM2008 y copiarlo en la carpeta correspondiente del programa. Una vez instalado el modelo de geoide, ya sí que puedes seleccionar este sistema personalizado tal y como puedes ver en la siguiente captura:

Como puedes comprobar, no ha sido sencillo, pero ahora PhotoScan sabrá transformar las coordenadas Z de los puntos de apoyo de ortométricas a elipsoidales, porque como he indicado al principio de este post: PhotoScan trabaja siempre en elipsoidales.

Si te quieres ahorrar los pasos anteriores y quieres trabajar bien, tendrías que transformar las coordenadas de los puntos de apoyo de ortométricas a elipsoidales antes de introducirlas en PhotoScan. Y personalmente creo que esta es la mejor opción, pues en el caso de España no utilizamos el modelo de geoide EGM2008, sino que utilizamos el modelo REDNAP Península o REDNAP Canarias que son modelos con mayor precisión para nuestro país y esos modelos de geoide no están disponibles para PhotoScan (que yo sepa).

En la práctica, no hemos visto ningún proyecto bien hecho: lo que hacen los usuarios habitualmente es buscar en el listado de sistemas de referencia el 2D (por ejemplo WGS84 / UTM Zona 30N), y como no hay mención alguna al sistema vertical, pues aceptan y dan por supuesto que la magia de PhotoScan sabrá qué hacer con esas alturas. Lo que se está haciendo entonces es engañar a PhotoScan.

El problema es que los usuarios de PhotoScan están seguros de que lo están haciendo bien y nos aseguran que están introduciendo coordenadas ortométricas. Esta afirmación tan rotunda nos hizo pensar que PhotoScan no creaba cadenas WKT correctas, e incluso creamos una entrada en este mismo blog (en la cual hoy hemos tachado unos cuantos párrafos) porque pensábamos que PhotoScan se olvidaba de poner el sistema vertical en la cadena WKT del archivo de proyecto, pero no es así. Si el usuario de PhotoScan no le engaña a PhotoScan al introducir coordenadas con altitud ortométrica, PhotoScan crea correctamente una cadena WKT para un sistema compuesto en el que se proporciona información del sistema vertical.

Sabiendo ahora que PhotoScan crea cadenas WKT correctas (es la primera vez que vemos un programa que no sea Digi3D.NET que acepta cadenas WKT de sistemas compuestos) nos encontramos con tres posibilidades:

  1. Que la cadena WKT del sistema de referencia del archivo de PhotoScan sea compuesta. En esta caso, podemos asumir sin posibilidad de error que las alturas de los puntos de apoyo que se introdujeron en PhotoScan son ortométricas y que además se introdujeron correctamente en PhotoScan.
  2. Que la cadena WKT del sistema de referencia del archivo de PhotoScan sea horizontal y que las coordenadas que se introdujeron tenían alturas elipsoidales.
  3. Que la cadena WKT del sistema de referencia del archivo de PhotoScan sea horizontal y que las coordenadas que se introdujeron tenían alturas ortométricas aunque PhotoScan piensa que son elipsoidales.

Si Dig3D.NET se encuentra con un archivo de proyecto de PhotoScan del caso 1, asume que debe trabajar en coordenadas ortométricas y por lo tanto, utilizará un modelo de geoide.

Si por el contrario Digi3D.NET se encuentra con un archivo de proyecto de PhotoScan que no sea el caso 1, no tiene forma de saber si estamos en el caso 2 o en el 3 y esto es muy importante, pues si estamos en el caso 2, pero creemos que estamos en el caso 3 o viceversa, en casos como España que la diferencia de altitud elipsoidal ortométrica ronda los 50 metros, ¡tendremos diferencias de Z de 50 metros!.

De manera que hemos tenido que añadir a Digi3D.NET una opción de configuración para indicarle al programa cómo se ha comportado el operador de PhotoScan al crear el proyecto.

Esta opción de configuración la tenemos en el menú Herramientas/Configuración/PhotoScan/Coordenadas Z en proyecto haciéndose pasar por elipsoidales y tenemos dos opciones a elegir:

  • Si, PhotoScan piensa que son elipsoidales pero son ortométricas.
  • No, las coordenadas se introdujeron en PhotoScan correctamente.

¿Cómo se comporta a partir de ahora Digi3D.NET si se le indica en la configuración que el operador de PhotoScan ha introducido las coordenadas correctamente?

  • Si se encuentra con un archivo de proyecto con sistema de referencia compuesto, asumirá que las alturas de las coordenadas serán ortométricas y por lo tanto utilizará un modelo de geoide. La ventana fotogramétrica en este caso emitirá/recibirá coordenadas en el sistema de referencia que aparece en el archivo de proyecto y en la barra de mensajes de ésta veremos coordenadas en ese sistema (que serán habitualmente UTM con alturas ortométricas).
  • Si se encuentra con un archivo de proyecto con sistema de referencia horizontal, asumirá que se está trabajando con alturas elipsoidales, de manera que la ventana fotogramétrica emitirá/recibirá coordenadas geográficas (latitud, longitud, altitud elipsoidal).

¿Cómo se comporta a partir de ahora Digi3D.NET si se le indica en la configuración que PhotoScan piensa que son elipsoidales pero son ortométricas?

La ventana fotogramétrica en este caso va a trabajar de una forma especial: Va a asumir (en las operaciones matemáticas que tienen que ver con PhotoScan) que las coordenadas Z son elipsoidales, de manera que no va a utilizar en ningún caso un modelo de geoide, pero va a publicar al resto de componentes de Digi3D.NET que tiene un sistema vertical que no es elipsoidal.

  • Si se encuentra con un archivo de proyecto con sistema de referencia horizontal (como por ejemplo WGS84 / UTM Zona 30N) y el usuario tiene configurada la opción Herramientas/Configuración/Sistema de referencia de coordenadas/Solicitar sistema vertical para sensores a No, la ventana fotogramétrica va a comunicar al resto de componentes de Digi3D.NET que emite/recibe coordenadas en el sistema compuesto por el horizontal que aparece en el archivo de proyecto y el vertical desconocido.
  • Si se encuentra con un archivo de proyecto con sistema de referencia horizontal (como por ejemplo WGS84 / UTM Zona 30N) y el usuario tiene configurada la opción Herramientas/Configuración/Sistema de referencia de coordenadas/Solicitar sistema vertical para sensores a Sí, al cargar el modelo Digi3D.NET va a solicitar en un cuadro de diálogo el sistema vertical. A partir de este momento la ventana fotogramétrica va a comunicar al resto de componentes de Digi3D.NET que emite/recibe coordenadas en el sistema compuesto por el horizontal que aparece en el archivo de proyecto y el vertical seleccionado por el usuario.
  • Si se encuentra con un archivo de proyecto con sistema de referencia compuesto, la ventana fotogramétrica comunicará al resto de componentes de Digi3D.NET que su sistema de referencia es exactamente el compuesto que aparece en el archivo de proyecto de PhotoScan.


Ya no es necesario ser administrador para almacenar la configuración de Digi3D.NET

CuadroDialogoConfigurarNuevoCuadroDialogoConfigurarNuevo.PNGPresentamos hoy un cambio que llevaban solicitado los usuarios empresariales desde hace tiempo: La posibilidad de poder almacenar la configuración para usuarios que no sean administrador.

Hasta hoy Digi3D.NET almacenaba la configuración en el registro de Windows. El registro de Windows tiene dos carpetas importantes:

  • Una (HKEY_CURRENT_USER) en la que se almacena la configuración del usuario activo. Esta es una carpeta propia por cada usuario de la máquina. Un usuario siempre tiene permisos de lectura/escritura sobre esta carpeta, pues es su propia carpeta. Un usuario no tiene permiso de visualizar o modificar datos en la carpeta de usuario del resto de usuarios de la máquina.
  • Otra (HKEY_LOCAL_MACHINE) en la que se almacena la configuración de la máquina. Habitualmente los usuarios normales no tienen permiso de escritura en esta carpeta y hace falta ser administrador para poder almacenar cosas aquí.

Digi3D.NET almacena configuraciones en ambas carpetas:

  • Las configuraciones específicas del usuario, como por ejemplo el color del índice a mostrar en la ventana fotogramétrica, se almacenan en la carpeta HKEY_CURRENT_USER, pues puede que comparta máquina con otro usuario que prefiera otro color de índice.
  • Las configuraciones específicas de la máquina, como por ejemplo el tipo de visualización estereoscópica se almacenan en la carpeta HKEY_LOCAL_MACHINE.

El problema de la carpeta HKEY_LOCAL_MACHINE es que requiere elevación, es decir, requiere ser administrador para poder almacenar información ahí. Eso en un usuario particular no suele ser un problema, pero los usuarios empresariales habitualmente se quejan de que sus usuarios no tienen permiso para almacenar HKEY_LOCAL_MACHINE y cada vez que quieren realizar un cambio en la configuración deben molestar a un administrador de la red.

Hoy presentamos una novedad que soluciona este problema. A partir de la versión 2018.14.0.0 hemos solucionado este problema pues ahora la información de la máquina no se almacena más en el registro de Windows, sino que se almacena en una base de datos sqlite ubicada en el directorio %ProgramData%\Digi3D.NET denominada Digi3DNET.db.

La carpeta %ProgramData% es una carpeta en la cual todos los usuarios tienen permiso de escritura y es la que se utiliza para almacenar datos de los programas.

¿Qué cambios voy a notar?

  • Hemos simplificado el cuadro de diálogo de Configuración, que hasta hoy no era nada intuitivo pues tenía dos botones para aceptar:
    CuadroDialogoConfigurarAntiguo
    Como puedes ver, había uno para almacenar la información de máquina y de usuario (que requería elevación) y otro para almacenar únicamente la información del usuario. Esto era completamente anti-intuitivo.Ahora el aspecto del cuadro de diálogo de configuración es este otro:
    CuadroDialogoConfigurarNuevo
    Puedes comprobar que ahora es mucho más intuitivo.
  • Ahora el programa nunca solicitará elevación en ningún cuadro de diálogo.
  • Se ha mejorado el rendimiento a la hora de leer datos de configuración pues las bases de datos sqlite son muy rápidas haciendo consultas.

¿Qué pasa con mis configuraciones existentes?

El programa a partir de hoy cada vez que intenta localizar una configuración de máquina, la intenta localizar primeto en la base de datos. Si no la localiza ahí, intenta localizarla en el registro (en HKEY_LOCAL_MACHINE). Si la encuentra en el registro la almacena en la base de datos de manera que la próxima vez que se intente localizar dicha configuración ya no sea necesaria localizarla en el registro.

Ahora el programa nunca almacena información en la carpeta HKEY_LOCAL_MACHINE del registro, sino que almacena siempre en la base de datos.