Según esta noticia la atmósfera tarda 4 dias en completar una rotación.

http://www.esa.int/esaCP/SEMEHFMJC0F_Spain_0.html

Unas pocas cuentas y seguro que das con el dato que buscas, yo ahora no estoy para números.

Saludos
Maximo

Pues no tengo ni idea, pero si estuviese en tu caso sacaría un video largo, y si las nubes salen mov¡das lo partiría en trozos más pequeños hasta que saliese bien. No se si servirá para algo, pero es lo que se me ocurre así de entrada.
un saludo. alejandro

Bueno, después de cenar se piensa mejor:

Se me escurre por mis pocas neuronas lo siguiente, una regla de tres:

Tamaño en segundos de arco de venus --- en 2 días (solo vemos la mitad)
Resolución del equipo --- X días

Probablemente es algo muy teórico bajo condiciones perfectas y no sea del todo exacto. Esto presupune que se va a notar el movimiento de la atmosfera de venus solo con que se mueva un pixel, seguro que la realidad es mucho menos exigente.

Que comedura de tarro, es que no tego nada mejor que hacer, o igual me quedan pocas neuronas...

Saludos
Maximo

Pda: He editado el mensaje un par de veces, creo que después de un plato de langostinos y una botella de Albariño no es bueno pensar en estas cosas.

Hola,

pues lo he estado calculando... A la distancia que está ahora, 0,3" (la mitad de resolución de un 21 cm) equivalen a 213 km. He encontrado por ahí que las nubes van a 400 km/h; por lo tanto, el tiempo máximo es de una media hora. O sea, 54000 frames con la DMK.

Saludos,
Vicent.

Ya sin el efecto del Albariño, creo que no voy mal encaminado con mi regla de tres. Calculando para la resolución que me dices de tu telescopio 0.3" de arco:

Para venus:

Mínimo 10" de arco => 2días x 0.3" / 10 =0.06 días=86.4 minutos
Máximo 64" de arco => 2días x 0.3" / 64 = 0.009375 días= 13.5 minutos

Comprobando con Júpiter (que sabemos que con 5 minutos ya se nota el movimiento de la atmósfera y su rotación media es de 9.84h):

Mínimo 30" de arco => 4.92h x 0.3" /30 =0.0492h= 2.9 minutos
Máximo 59" de arco => 4.92h x 0.3"/59 = 1.5 minutos

Los resultados de Júpiter están bastante cerca de la realidad.

Fin de la comida de tarro, lo prometo.
Saludos
Maximo

Pues a mi me encantan estas comeduras de tarro, sobre todo porque sirven para aprender muchas cosas.

como por ejemplo que la resolución del telescopio es de 105/D. Que para no tener pérdidas en la imagen debo captar en segundos de arco la mitad. Y que por los famosos radianes, con la distancia al planeta, eso equivale a 213km, y que si los vientos van a 400km/h eso equivale a media hora.

J*er, tenemos que desoxidar bastante las neuronas para seguir estos temas!!

De todas formas eso será si quieres sacar videos muy laaaargos. A ver que sucede en la práctica con esos videos, nunca he visto tratamientos de videos de media hora para planetas. si es un "invento" nuevo entonces "mola" Ya contareis que tal.

Si salen movidas las nubes, (me reafirmo ) , siempre le podras cortar un trozo. ¿o no?
un saludo. alejandro

Por cierto, todas estas nuevas ideas bien merecen unos langostinos con albariño.

¡No hombre!, no creo que Vicent quiera hacer un video de 30 minutos, ni yo tampoco, supongo que lo que quiere es saber el tiempo maximo del video para que no se muevan las nubes e ir a tiro hecho.
Yo por lo menos en Venus, no tenía ni idea, ni se me había ocurrido pensarlo, pero está claro que una vez calculado (aunque no sea del todo exacto) no es un problema a tener en cuenta en este planeta.

En Júpiter es otro cantar, incluso habría que tener en cuenta que las nubes no se mueven a la misma velocidad en el ecuador que en los polos, o la velocidad de traslación de los satélites o sus sobras para que no salgan movidos.

Saludos
Maximo

Pd: Al final casi me como hasta las cabezas de los langostinos para ver si las neuronas de sus pequeños cerebros me ayudaban.

Je, me habéis pillado. Ayer hice media hora de vídeos de Venus. 50.000 fotogramas!

Lo que pasa es que ayer había un seeing bastante horripilante, así que no me ha servido de nada. El problema es que, cuando el viento viene de poniente, la turbulencia es de pequeña escala y muy alta frecuencia, y eso destroza por completo los detalles pequeños de los planetas; no sirve de nada capturar vídeos, no hay ni un sólo frame nítido. En fin, paciencia, que esta tarde vuelvo a la carga.

Saludos,
Vicent.

Ños, dicen en mi pueblo.
Va a ser que kepler_t2kr3 llebaba razón y ¿cuanto ocupa ese video?, el ¿Registax puede con eso?, ummm, me parece que tienes un as guardado en la manga, somos todo oídos
Saludos
Maximo

😯 Ños, dicen en mi pueblo.
Va a ser que kepler_t2kr3 llebaba razón y ¿cuanto ocupa ese video?, el ¿Registax puede con eso?, ummm, me parece que tienes un as guardado en la manga, somos todo oídos
Saludos
Maximo

No, un sistema operativo de 32 bits no puede con un archivo de más de 2 GB. Lo que hago yo es hacer vídeos de entre 1 - 2 minutos de duración, y los proceso por separado con Registax. Luego, todas las imágenes resultantes, las vuelvo a combinar.

En fin, ahora sólo queda que pare el viento de poniente.

De todas formas, si podemos tirar 30 minútos, qué razón hay para que grabemos sólamente 1 minuto de vídeo??

Lo mismo pasa con la Luna... En media hora tampoco se nota en absoluto un cambio en las sombras. Para qué grabar sólo un cortito vídeo? Si hacemos 10 ó 20 mil imágenes y luego cogemos las 2.000 mejores, vamos a tener seguramente una imagen muy nítida a la que podremos aplicarle wavelets o deconvolución sin miedo.

Vicent.

Para mi la única razón de no hacerlo es que... joer no hay tiempo para dedicarle al procesado de tanto vídeo. Yo a lo sumo he juntado tres videos de unos 5 minutos a 5fps, total 4500 imágenes y me pasé medio día con él (un saturno).
Afortunados aquellos que pueden, que envidia les tengo, suerte con el experimento.

Saludos
Máximo

Pues no he respondido antes porque he estado un poco ocupado, pero bueno que soy de los que opina que hay que probar "inventos" nuevos aunque a veces no salgan a la primera, pues es la única forma de progresar.
un saludo. alejandro

No, un sistema operativo de 32 bits no puede con un archivo de más de 2 GB.

Tenía casi la seguridad de que esta afirmación era falsa, pero no quería responder sin comprobarlo antes sólo por si las moscas. Así que bueno, me acabo de crear un archivo de más de 4 Gb en este cacharro. Supongo que debe de ser un error o una generalización excesiva.

Hola,

intenta abrirlo (si supongo bien que es un vídeo) con el Registax, verás como no puedes.

Vicent.

No, un sistema operativo de 32 bits no puede con un archivo de más de 2 GB.

Tenía casi la seguridad de que esta afirmación era falsa, pero no quería responder sin comprobarlo antes sólo por si las moscas. Así que bueno, me acabo de crear un archivo de más de 4 Gb en este cacharro. Supongo que debe de ser un error o una generalización excesiva.

Aprovecho que estoy recompilando en background para soltaros un buen rollo

Las rutinas "clásicas" de manejo de archivos no son capaces de acceder a archivos por encima de 2 GB en sistemas de 32 bits. Esto es porque se utilizan enteros con signo para expresar posiciones de byte en los archivos. Por ejemplo, la función fseek de la biblioteca estándar de C tiene este prototipo:

int fseek( FILE *stream, long offset, int whence );

(véase por ejemplo: http://www.opengroup.org/onlinepubs/009 ... fseek.html)

fseek nos permite movernos a través de un archivo para direccionar un byte en particular. En la función anterior, offset es la posición del byte deseado. El tipo long es un entero con signo que en plataformas de 32 bits tiene precisamente 32 bits, así que es imposible con la función anterior acceder a un archivo que sobrepase 2^31 bytes de longitud. Por supuesto, en plataformas de 64 bits, long tiene también 64 bits, así que este problema desaparece.

Con el estándar ISO de C (C99) se introdujeron funciones estándar para romper la barrera de los 32 bits en archivos. Por ejemplo, existe un reemplazo para fseek:

int fseeko( FILE *stream, off_t offset, int whence );

donde se utiliza el tipo off_t para expresar la posición sobre el archivo. El tipo off_t está definido como un entero de 64 bits con signo, tanto en plataformas de 32 bits como de 64 bits, así que esta función es capaz de acceder a archivos por encima de 2 GB; concretamente, de 2^63 bytes de longitud.

Así que el problema no es realmente del sistema operativo, sino de la aplicación. Esto es lo que suele ocurrir cuando gente que no es sional del desarrollo se dedica a escribir aplicaciones que manejan datos y problemas que no son triviales. En el caso de Registax, este problema es especialmente grave porque un vídeo puede superar 2 GB muy fácilmente. La solución sería tan simple como sustituir todas las llamadas a fseek por fseeko, y lo mismo con todas las funciones de manejo de archivos. En este caso, el problema es que Registax está escrito en un lenguaje (Delphi) que no está pensado para resolver este tipo de problemas.

Vale, vuelvo al trabajo...