Re: [Eqalign-devel] Soporte QHY5 en EQAlign. Primera fase completada
Brought to you by:
antoniofga,
isoplut
Menu
▾
▴
Re: [Eqalign-devel] Soporte QHY5 en EQAlign. Primera fase completada
|
From: Antonio F. <ant...@ya...> - 2007-10-09 18:21:33
|
Sem=E1foros... no soy un experto en paralelismo, pero creo que est=E1 =
funcionando de perlas. Tuve un problema al verlo con la webcam =
modificada: m=E1s que a menudo, cuando se invocaba el m=E9todo GetFrame =
la imagen no estaba disponible porque la variable booleana imgready =
estaba a false (la hab=EDa puesto a false el hilo de Exposure) aunque =
s=ED que hab=EDa una imagen disponible.
Creo que est=E1n bien implementados, los he incluido en QHY5Cam, Atik16 =
y WDMCam, no puedo probar la Atik16 porque no la tengo, as=ED que =
deber=EDas comprobarlo en la QHY5.
Todav=EDa falta recopilar la lista de c=E1maras activas y dem=E1s, me =
pongo a ello.
Francisco, tengo una duda con el m=E9todo Bitmap24FromUnmanagedCode:
for (int y =3D 0; y < bmp.Height; y++)
{
CopyMemory(dest, source, len);
source =3D new IntPtr(source.ToInt32() + len);
dest =3D new IntPtr(dest.ToInt32() + bmData.Stride);
}
la imagen de destino es de 3 bytes (1 byte por canal) y la imagen =
original de 1 byte, si copias CopyMemory(dest, source, len);, s=F3lo =
deber=EDas tener iformaci=F3n en el primer tercio de la imagen =BFno?, =
creo que el c=F3digo deber=EDa ser algo as=ED como:
byte* dst =3D (byte*)bmData.Scan0.ToPointer();
byte* src =3D (byte*)image.Scan0.ToPointer();
int offsetdst =3D dstData.Stride - width * 3;
int offsetsrc =3D image.Stride - width * 3;
for (int y =3D 0, idx =3D 0; y < height; y++)
{
ushort* pDst =3D dst + y * width;
ushort* pSrc =3D src + y * width;
for (int x =3D 0; x < width; x++, pDst++)
{
// single input channel (greyscale)
ushort v =3D *pSrc++;
byte b =3D (byte)val;
*pDst ++ =3D b;
*pDst ++ =3D b;
*pDst =3D b;
}
pDst +=3D offsetdst;
pSrc +=3D offsetsrc;
}
pero deber=EDas comprobarlo.
Bueno, pues un saludo!
----- Original Message -----=20
From: Antonio Fraga=20
To: Lista de correo de desarrollo EQAlign=20
Sent: Tuesday, October 09, 2007 3:09 PM
Subject: Re: [Eqalign-devel] Soporte QHY5 en EQAlign. Primera fase =
completada
Buf!, un rollo patatoso! He modificado las especificaciones de =
CameraInterface:
Propiedades p=FAblicas:
string Driver nombre del dispositivo
bool IsConnected informa si la c=E1mara est=E1 conectada
int Width ancho de la imagen=20
int Height alto de la imagen
Rectangle SubframeRegion region del subframe=20
bool Subframe devuelve/establece el modo de subframa
int ExposureTime tiempo de exposici=F3n (s=ED, como propiedad)
eCameraReadOutMode ExposureMode modo de exposici=F3n (lo vemos)
bool ImageReady informa si hay una imagen diponible
DateTime CronoStart informa del momento en que se efectivamente se =
inici=F3 la exposici=F3n (para sincronizar la barra de presentaci=F3n de =
crono)
M=E9todos p=FAblicos:
void Connect() trata de establecer la conexi=F3n con la c=E1mara
void Disconnect() desconecta la c=E1mara
void Settings() lanza el di=E1logo de settings
void Config() lanza el di=E1logo de configuraci=F3n (lo siento en =
WDM Config y Settings son dos cosas distintas)
Bitmap GetFrame() devuelve el =FAltimo fotograma disponible.
Adem=E1s hay que tener en cuenta que cuando se sirve al =FAltimo =
fotograma el buffer interno se vac=EDa: fotograma servido/fotograma =
perdido. Esto es as=ED para que el sistema de autoguiado (en caso de =
p=E9rdida de fotograma) no piense que no hay efectos sobre un comando =
gu=EDa.
Sobre el modo de exposici=F3n. Un rollo, a ver si no me enrollo:
Por una parte no interesa que el sistema est=E9 esperando en un bucle =
por una exposici=F3n, por eso antes el control de usuario era quien =
establec=EDa el inicio de exposici=F3n, controlaba el crono y luego =
cerraba la exposici=F3n; mientras ocurre todo esto, el sistema sigue =
activo.
Pero tanto la Atik16, como la QHY (y probablemente todas las =
demaisss), el tiempo de exposici=F3n se establece en la llamada y luego =
hay que estar pendiente hasta que la imagen est=E1 disponible.
Vale, soluci=F3n de en medio:
Cuando la c=E1mara se conecta, se crea un hilo de exposici=F3n:
//hilo de exposici=F3n
ThExpose =3D new Thread(new ThreadStart(Exposure));
ThExpose.TrySetApartmentState(ApartmentState.STA);
ThExpose.Start();
Este hilo est=E1 haciendo, en un loop "infinito" exposiciones =
continuas de tiempo (exposureTime), el hilo se queda esperando hasta que =
la imagen est=E1 disponible y entonces la carga en la propiedad privada =
Bitmap bmp.
GetFrame, simplemente comprueba que la c=E1mara est=E1 conectada, que =
la propiedad bmp no es nula y que la imagen est=E1 disponible (por si =
acaso tambi=E9n que no estamos en un momento cr=EDtico: se est=E1 =
leyendo la imagen). En esos casos devuelve bmp.Clone() y libera bmp =
(fotograma servido, fotograma perdido).
Para probar que todo esto funciona:
-(y no perder el antiguo driver WDM) he reescrito otro driver WDMCam =
que se comporta de este modo. Simplemente tambi=E9n porque no tengo la =
Atik (est=E1 en el taller de reparacioones) as=ED que quer=EDa probar el =
tema de hilos con la webcam
-he incorporado un driver m=EDnimo para la atik16
-(para no perder QHY tal como estaba) he redise=F1ado QHYCam =
(copia/pega) para que cumpla el interfaz. Sobre QHY, cuidado, s=F3lo he =
a=F1adido las propiedades m=EDnimas del interfaz que debe cumplir para =
que compile.
No lo he podido comprobar con la webcam modificada para LX, s=ED con =
una webcam CMOS barata.
Vale uno de los problemas que me encontr=E9 era la sincronizaci=F3n =
entre el timmer de exposici=F3n del control de usuario y la =
disponibilidad efectiva de la imagen. Para minimizar las diferencias, =
a=F1ad=ED la propiedad CronoStart, que cada c=E1mara debe establecer =
como DateTime.Now justo antes de lanzar la larga exposici=F3n. A=FAn =
as=ED sigue habiendo alguna discrepancia que crea un efecto un poco =
raro, pero no se me ocurre otra cosa (excepto eliminar el progressBar)
Esa es una. Otra es el modo de lectura:
public enum eCameraReadOutMode
{
ContinueShortMode =3D 0,
LXContinueMode,
SingleShoot
};
Vamos, el modo ContinueShortMode en WDM es video en tiempo real, =
LXContinueMode es exposici=F3n LX cont=EDnua y SingleShoot, un solo =
"disparo" (no creo que tenga utilidad, excepto APRA las c=E1maras de =
luz)
En WDM ok, pero para las QHY /Luna. Bien!! El tiempo de captura de una =
imagen no es muy largo, entonces podremos hacer algo as=ED como =
exposiciones de corto periodo para ir simulando un RealTimeVideo, ese =
ser=EDa el modo ContinueShortMode. No hay ninguna diferencia con =
respecto a LXContinueMode!!!! Es lo mismito. En este caso habr=E1 que =
establecer el tiempo de exposici=F3n a algo as=ED como 100ms y listo (lo =
hace el driver al establecer la propiedad ExposureMode).
Tambi=E9n est=E1 el tema de Subframe y SubframeRegion. La Atik lo =
permite aunque todav=EDa no me funcionaba (cuando me venga de vuelta, lo =
retomar=E9).
Me imagino que en las QHY s=F3lo hay que llamar a:
uint ms =3D ProgramCamera(subframeregion.X, subframeregion.Y,=20
ubframeregion.Width, subframeregion.Height,=20
(int)convertGain(255));
, as=ED lo puse en el m=E9todo set de la propiedad (despu=E9s de =
comprobar si la regi=F3n es v=E1lida)
En fin, como no tengo la Atik no puedo hacer pruebas. Si hay otras =
ideas pues a contar!!! Lo he implementado lo m=E1s r=E1pidamente posible =
para que no afecte al actual desarrollo de la beta y no he tocado WDM =
para poder tirar para atr=E1s.
Otra cosa: ahora falta que Camera comience a hacer Connects a todo =
"quisque" para saber si est=E1 "presente" o no y poder construir la =
lista de c=E1maras disponibles. Luego MainWindow ya podr=EDa =
manej=E1rselas.. . si puedo lo hago esta noche.
Y otra cosa, en la exposici=F3n (m=E9todo GetFrame) ten=EDais algo =
as=ED como:
System.Drawing.Bitmap bmp =3D new System.Drawing.Bitmap(1280, 1024, =
format);
System.Drawing.Imaging.BitmapData bmpData =3D bmp.LockBits(new =
System.Drawing.Rectangle(0, 0, bmp.Width, bmp.Height), =
System.Drawing.Imaging.ImageLockMode.ReadOnly, format);
bmp.UnlockBits(bmpData);
GETBUFFER(bmpData.Scan0, 1310720);
// Obtenci=F3n del bitmap
Bitmap bp =3D this.Bitmap24FromUnmanagedCode(bmpData.Scan0, 1280, =
1024);
En QHYCam (recuerda que est=E1 en el m=E9todo Exposure que es un =
thread), lo he dejado as=ED:
Bitmap bp =3D new System.Drawing.Bitmap(1280, 1024, format);
BitmapData bmpData =3D bp.LockBits(new System.Drawing.Rectangle(0, 0, =
bmp.Width, bmp.Height), System.Drawing.Imaging.ImageLockMode.ReadOnly, =
format);
GETBUFFER(bmpData.Scan0, 1310720);
bmp =3D this.Bitmap24FromUnmanagedCode(bmpData.Scan0, 1280, 1024);
bp.UnlockBits(bmpData);
, la diferencia es que la l=EDnea bp.UnlockBits(bmpData), est=E1 =
despu=E9s de la llamada a Bitmap24FromUnmanagedCode. Mira si funciona, =
lo he hecho a ojo.
Un saludo
Francisco Jos=E9 <is...@ya...> escribi=F3:
Hola Antonio!
=BFSabes si han arreglado o tienen intenci=F3n de arreglar el tema =
de los 16 bits en .Net 3.0? En fin, sin comentarios... para trabajar con =
FITs, tambi=E9n tenemos FitsIO de la NASA =
(http://heasarc.gsfc.nasa.gov/docs/software/fitsio/) la usan muchos =
programas y est=E1 portada a varios sistemas operativos (Linux entre =
ellos), es software abierto aunque desconozco su licencia concreta.
Sobre la QHY5 o Luna 1.3 o QGuider... pues va sobre USB 2.0, la =
descarga es muy r=E1pida y m=E1s a=FAn si trabajamos con subframes (es =
posible hacerlo), lo cual ser=EDa muy recomendable para el futuro.
Hoy he subido un commit que resuelve un fallo en el control de =
ganancia de la c=E1mara, ha sido el propio Tom el que me lo ha =
corregido, la verdad, me alegro que haya cambiado tanto su =
comportamiento con nosotros, la c=E1mara est=E1 funcionando ahora =
perfectamente, me muero de ganas de verla en funcionamiento, tanto en la =
puesta en estaci=F3n como en el guiado, a ver si para este puente lo =
tenemos y me canso de hacer pruebas.
Sobre las ideas que comentas, me parecen correctas, ten en cuenta =
que a la larga m=E1s y m=E1s c=E1maras ser=E1n a=F1adidas y la mayor=EDa =
tendr=E1n cron=F3metro interno, por mi parte, la siguiente en caer a no =
mucho tardar ser=E1 la Artemis, mas que para guiar (ser=EDa de g=E9nero =
absurdo usarla para eso), para poner en estaci=F3n, ser=E1 una gozada =
por el enorme campo que da.
Ya me cuentas!
Un saludo!
----- Mensaje original ----
De: Antonio Fraga <ant...@ya...>
Para: Lista de correo de desarrollo EQAlign =
<eqa...@li...>
Enviado: lunes, 8 de octubre, 2007 18:34:58
Asunto: Re: [Eqalign-devel] Soporte QHY5 en EQAlign. Primera fase =
completada
Hola Francisco!
Pues mejor, 24bpp nos va a ahorrar algunos quebraderos de cabeza, =
sobre todo a la hora de dibujar el ret=EDculo.
No s=F3lo Net2.0 sino el 1.0 (claro) tienen roto el modo 16bits. Por =
eso en su d=EDa evalu=E9 el proyecto FreeImage para trabajar a 16 bits. =
De todas maneras todav=EDa estamos en la fase de "C=E1mara gu=EDa", =
cuando lleguemos a "C=E1mara de luz" habr=E1 que plantearse guardar las =
im=E1genes en .FIT, FreeImage no lo soporta, as=ED que tendremos que =
trabajar sobre el formato.
Sobre la rapidez: =BFcu=E1nto tarda en descargarse una imagen =
completa?, me imagino que si no es USB2.0 tardar=E1 m=E1s de un par de =
segundos =BFno?
En ese caso, como c=E1mara gu=EDa, lo ideal es se lo m=E1s r=E1pido =
posibles y eso se podr=EDa conseguir si el driver de la c=E1mara permite =
trabajar sobre "corps"
Sobre el tiempo de exposici=F3n, lo mejor es aumentar el interfaz de =
c=E1mara y a=F1adir los m=E9todos LX. Tal como lo tenemos, el control de =
usuario de c=E1mara es el que cronometra el shutter, as=ED es como =
funcionan las webcam, pero el driver de las QHY, por lo que veo, tienen =
el crono interno y hay que especificarle en la llamada el tiempo de =
exposici=F3n.
Podr=EDamos generalizarlo y ver c=F3mo encajan las webcamLX:
para:
StartLXMode
StopLXMode
las QHY no har=EDan nada, los implementan por compatibilidad
el actual
void startLXExposure(void)
podr=EDa convertirse en=20
void startLXExposure(int milliseconds)
y en lugar de que el control de usuario de c=E1mara cronometre el =
tiempo de exposici=F3n, sea el propio startLXExposure quien lance un =
hilo.=20
Actualmente el crono del control de usuario es el que termina la =
exposici=F3n cuando el tiempo se ha cumplido llamando a=20
void stopLXExposure(void)
este m=E9todo podr=EDa desaparecer y en su lugar, el hilo cuando =
termina la exposici=F3n se encargar=EDa de realizar el trabajo de =
stopLXExposure (en webcamLX) y lanzar un evento para informar que la =
imagen est=E1 disponible.
S=F3lo hay que cambiar un par de cosas en:
WDM.cs
CameraInterface.cs
UCCamControl.cs
GetFrame() tal como est=E1 concebido s=F3lo se encargar=EDa de =
servir el =FAltimo fotograma almacenado, no de la exposici=F3n en s=ED, =
de eso se encargar=EDa:
startLXExposure
Excepto en modo video real, que s=ED se encarga de capturar la =
=FAltima imagen de la webcam.
En las QHY, si el tiempo de descarga es peque=F1o (o si se puede =
trabajar con crops), entonces GetImage() podr=EDa estar capturando en =
tiempos peque=F1os (0.1, 0.2, ... 0.5seg) configurables, tal como hace =
el actual WDM.
Y sobre el men=FA de c=E1maras disponibles: Ok, Camera.cs debe =
capturar tanto la disponibilidad de c=E1maras WDM, como QHY y en el =
futuro DSI, Atik16IC, etc (jeje), para eso hay que modificar el m=E9todo =
GetDeviceList para que pregunte por la disponibilidad de cada c=E1mara =
que hayamos implementado. En la QHY b=E1sicamente habr=E1 que conectarla =
y desconectarla. Pero en lugar de mostrar mensajes, como haces ahora, =
deber=EDamos establecer un tipo enumerado con errores gen=E9ricos y =
devolver el error en una variable de status, de los mensajes ya ese =
encargar=E1n los "jefes" (por cierto habr=E1 que internacionalizar esos =
mensajes).
>> Bueno, vaya mamotreto me ha quedado, lo dicho, gracias a los dos =
por la ayuda que me hab=E9is >> prestado, aunque mucho me temo que la =
volver=E9 a necesitar para mejorar el tema.
=A1Venga ya! No me lo puedo creer :) p=E1-eso estamos aqu=ED =BFno?
Bueno, d=E9jame un par de d=EDas para buscar c=F3mo las webcamLX =
(producto estrella hasta la llegada del driver QHY :) encajan con el =
nuevo modelo, esta noche lo tengo jo**do pero creo que ma=F1ana puedo =
dejarlo esbozado. Si hay alguna sugerencia o no est=E1n de acuerdo con =
el modelo ... a discutir!!!
Un saludo
----- Original Message -----=20
From: Francisco Jos=E9=20
To: Lista correo EQAlign=20
Sent: Monday, October 08, 2007 12:39 AM
Subject: [Eqalign-devel] Soporte QHY5 en EQAlign. Primera fase =
completada
Pues el soporte preliminar de las QHY5 y derivadas ya est=E1 en el =
repositorio de EQAlign, como podr=E9is ver, al final y tras much=EDsimas =
pruebas me he decidido a trabajar directamente en 24bpp:
- .NET 2.0 s=F3lo soporta 8 bits (que creo ser=EDa lo m=E1s =
eficiente) en modo indexado y en color, con lo que habr=EDa que =
transformar a escala de grises empleando recursos, lo que ganamos por un =
lado se pierde por otro.
- .NET 2.0 tiene rotos todos los formatos de imagen de 16 bits, =
sabido es mi cari=F1o por los creadores del framework, de modo que evito =
comentarios que puedan resultar hirientes; en definitiva, descartado =
tambi=E9n.
- Lo =FAnico que da buen resultado es trabajar directamente a =
24bpp, la c=E1mara puede retornar una imagen de este formato, y aunque =
pueda resultar un desperdicio de memoria he comprobado que es lo m=E1s =
r=E1pido al no tener que realizar transformaciones adicionales, esa es =
la soluci=F3n que he adoptado. No obstante ah=ED est=E1 el c=F3digo, lo =
pod=E9is modificar a vuestro antojo.
Aunque el driver que implementa la interfaz CameraInterface est=E1 =
lista, quedan ciertos detalles para pulirla, a saber:
- Necesito conocer el tiempo de exposici=F3n justo cuando se =
lanza =E9sta, con lo que de alguna manera habr=E1 que comunic=E1rselo al =
driver, tal y como est=E1 ahora dise=F1ado el sistema no lo veo trivial; =
podr=E9is ver que actualmente es el procedimiento GetFrame() el que =
realiza las tareas de:
- Lanzar la exposici=F3n (en un hilo)
- Esperar a que termine la exposici=F3n..
- Retornar la imagen (Bitmap)
Sobre esto, una duda, cuando EQAlign lance la exposici=F3n =
=BFquedar=E1 bloqueado a la espera de que GetFrame() retorne la imagen?, =
Antonio, com=E9ntame si es as=ED. Como ves, el modo de funcionamiento de =
la c=E1mara es "iniciar exposici=F3n -> esperar -> obtener imagen", no =
tiene sentido un stopLx() o similar.=20
Por compatibilidad con WDM he implementado las principales =
funciones LX de las webcams, pero como te digo, es que con el modo de =
funcionamiento de esta c=E1mara no les veo el sentido en este driver. La =
idea ser=EDa que lanzara una llamada no bloqueante a GetFrame cada x =
periodo de tiempo.
Para concluir, falta la integraci=F3n final; no he querido tocar, =
por que es muy tarde y el sue=F1o puede hacer que destroce algo, pero en =
la interfaz principal hay que a=F1adir la nueva c=E1mara:
- Que el men=FA C=E1mara se active si se detecta la QHY5
- En caso de tener QHY y adem=E1s un WDM, permitir seleccionar =
uno de los dos.
Para ello, creo que, al menos, habr=E1 que modificar el =
procedimiento GetDeviceList() de Camera.cs para a=F1adir soporte a m=E1s =
c=E1maras; y m=E1s cosillas, si no es mucha molestia, Antonio, dime =
exactamente lo que es necesario realizar.
Bueno, vaya mamotreto me ha quedado, lo dicho, gracias a los dos =
por la ayuda que me hab=E9is prestado, aunque mucho me temo que la =
volver=E9 a necesitar para mejorar el tema.
Un saludo.
-------------------------------------------------------------------------=
-
S=E9 un Mejor Amante del Cine
=BFQuieres saber c=F3mo? =A1Deja que otras personas te ayuden! .
=
-------------------------------------------------------------------------=
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a =
browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/=20
_______________________________________________
Eqalign-devel mailing list
Eqa...@li...
https://lists.sourceforge.net/lists/listinfo/eqalign-devel
-------------------------------------------------------------------------=
---
S=E9 un Mejor Amante del Cine
=BFQuieres saber c=F3mo? =A1Deja que otras personas te ayuden! .
=
-------------------------------------------------------------------------=
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a =
browser.
Download your FREE copy of Splunk now >> =
http://get.splunk.com/_______________________________________________
Eqalign-devel mailing list
Eqa...@li...
https://lists.sourceforge.net/lists/listinfo/eqalign-devel
-------------------------------------------------------------------------=
-----
S=E9 un Mejor Amante del Cine
=BFQuieres saber c=F3mo? =A1Deja que otras personas te ayuden! .
-------------------------------------------------------------------------=
-----
=
-------------------------------------------------------------------------=
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a =
browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
-------------------------------------------------------------------------=
-----
_______________________________________________
Eqalign-devel mailing list
Eqa...@li...
https://lists.sourceforge.net/lists/listinfo/eqalign-devel
|
