De nuevo mil disculpas a todos, ando sin internet en casa, así que os podéis imaginar, estoy a la espera de que Telefónica se digne a solucionar el problema...

Os escribo luego, cuando termine el currelo.

Un saludo.

----- Mensaje original ----
De: Antonio Fraga <antoniofga@yahoo.es>
Para: Lista de correo de desarrollo EQAlign <eqalign-devel@lists.sourceforge.net>
Enviado: lunes, 3 de diciembre, 2007 22:59:18
Asunto: Re: [Eqalign-devel] Subsistema de cámaras

Corregido un error que no detecté en el ordenador principal y sí en el protátil:
No es seguro lanzar eventos desde un thread!!!! ya les dije que nos oy especialista en hilos. Bien, después de comerme el coco toda la mañana he aprendido que lo que hay que hacer es enviarle una señal al proceso padre y que sea éste quien dispare el evento.
Además, cuando la webcam pierde un fotograma el sistema fallaba. Bien también he corregido ese bug.
Lo interesante de todo esto (aparte que estoy aprendiendo un montón :)  es que todo el negocio de hilos, bloqueos y demás está centrado en la clase de nivel superior Camera, los drivers de cámara sólo tienen que hacer su trabajo: activar la exposición, responder si la imagen está lista y servirla bajo petición.
 
El sistema de hilos con evento sería el método más eficiente, pues notificaría al programa consumidor de la disponibilidad de la imagen justo cuando lo está.
El sistema de cronómetro es menos eficiente en teoría, pero en algunas situaciones puede ser lo más adecuado.
 
En fin, lo he probado con la webcam y va como una moto a 10ms, la simulación también va, he implementado el driver de las atik pero no lo he podido probar y también he subido una aproximación a lo que podría ser el control de las DSI, sin ninguna documentación en absoluto, con las librerías a pelo (por cierto es un compilado .NET) y totalmente a ciegas (no tengo DSI)
 
¡échenle un vistazo aunque sea en modo simulación!
Un saludo
 
 
----- Original Message -----
From: Antonio Fraga
To: Lista de correo de desarrollo EQAlign
Sent: Saturday, December 01, 2007 10:21 PM
Subject: [Eqalign-devel] Subsistema de cámaras

Acabo de subir el proyecto CamCap. Si lo abren verán que sólo tiene un formulario que controla una instancia de la clase Camera que está en otro proyecto compilado como una librería. Ahí es donde está todo el meollo de cámaras.
 
El proyecto EQCam exporta dos clases:
Camera: es el punto de entrada a todos los drivers de cámara en sí.
 
Imaging: esta clase da soporte al tipo de imagen que trabaja Camera: FloatImage. FloatImage representa una imagen (monocroma) en un array floats normalizado (valores entre 0.0 y 1.0). Contiene los métodos necesarios para importar desde un bitmap o desde otro objeto de tipo FloatImage, exportar a Bitmap, operaciones básicas sobre el histograma, operaciones aritméticas sobre de imágenes con otras imágenes o con valores numéricos, clonación, etc. (lo de etc es más bien porque podemos meter ahí lo que queramos).
Hay un proceso de imagen definido: GaussianBlur, tengo algunos más pero este es el único estrictamente necesario. Bueno, igual es necesario meter los ajustes de histograma más complejos (mediante curvas o ajuste de medios tonos), pero ya veremos.
 
Bien, lo importante es que todos los drivers de la clase Camera y la propia clase camera devuelven FloatImage con lo que pasamos a precisión de 32 bits, más que para la captura, para otros procesos como apilados y promedios es bastante interesante contar con más precisión que la propia cámara.
 
Vale. Sobre las cámaras. He copiado casi literalmente la especificación ascom, con sólo algunos cambios, hasta el conrtol del cooling y "tó". En el interfaz CameraInterface está detallada toda la especificación. Miren este archivo antes de nada.
 
Sólo he implementado SimCamera y WDM para comprobar que el modelo es válido. Si nos ponemos de acuerdo habría que recodificar todos los drivers de cámara.
 
Una de los puntos a favor de este modelo es que los drivers de cámara no hacen “procesos de negocio”, simplemente atienden a las peticiones de imagen y actúan sobre los parámetros básicos de la cámara que controlan: binning, subframe, temperatura del peltier,...
Los “procesos de negocio” (exposición en modo loop, proceso de obtención de darks y resta del dark, histogramas, etc...) estarían en la clase Camera como capa superior y punto de acceso a las cámaras desde “fuera”.
 
De todas maneras, a partir de la clase Camera se tiene acceso directo al driver al que se está conectado, por si se quisiera realizar alguna alguna acción específica. A ver:
Además de implementar el interfaz CameraInterface, los drivers de cámara pueden implementar otras funcionalidades específicas de cada cámara. Por ejemplo:
-el driver de la cámara de simulación necesita conocer los valores de latitud/longitud y las coordenadas donde que apunta el telescopio.
-el driver WDM necesita tener acceso a los parámetros de larga exposición (si es un SC1, etc)
-el driver WDM puede presentar - aparte del diálogo de configuración que todas las cámaras muestran en el método común SetupDialog- otro diálogo de configuración de formato.
 
Algunos se implementan en la propia clase Camera, pero tener acceso a los que no, se hace a travez del propio driver específico a partir de la propiedad:
public CameraInterface CamDriver
 
Por ejemplo, para mostrar el diálogo de formato, específico de las WDM:
 
      if (cam.CameraAccessType == eCameraAccessType.WDM)
        ((EQA.Camera.Drivers.WDMCam)cam.CamDriver).FormatDialog();
 
Otro ventaja que le veo a este modelo es que el subsistema de cámara queda separado en una librería, si detectamos cualquier problema, basta con corregirlo y redistribuir esta librería. Tal como está ahora, el programa consumidor tiene que establecer el tipo de cámara (Sim, WDM, Atik...), pero es fácil aislar eso también, con lo que si se implementan nuevas cámaras no sería necesario siquiera compilar el proyecto EQAlign. Además el acceso a cámaras em una librería separada se puede utilizar en un proyecto totalmente diferente, como es el propio CamCam.
 
Bien, he tratado de hacer robusto el sistema de acceso a las imágenes con semáforos y demás. También he tratado de hacer “buen” (jajaja) uso de los hilos, pero no he estado ni tres días con esto así que si estamos de acuerdo que este es el mejor modelo posible, todavía hay mucho en lo que trabajar.
 
Bueno, en cuanto a la obtención de imágenes: se puede usar un cronómetro y trabajar en cada click, preguntando si la imagene stá disponible para obtenerla etc, o se puede capturar un evento que dispara la calse Cámara cuando tiene la imagen disponible. Dependiendo de qué cosa un método será mejor que otro.
 
En fin, descárgenlo, pruébenlo, mírenlo, busquelen las cosquillas y lo discutimos.
Un saludo!

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

_______________________________________________
Eqalign-devel mailing list
Eqalign-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/eqalign-devel




¿Chef por primera vez? - Sé un mejor Cocinillas.
Entra en Yahoo! Respuestas.