How to act on a set of images in a single operation | C?mo actuar sobre un conjunto de im?genes en una ?nica operaci?n

Juan Conejero

Juan Conejero

PixInsight Staff
Staff member
[Versi?n en Espa?ol al final]

Suppose you have generated a good bunch of working images, and you no longer need them. For example, you may have several background models generated with the DBE tool:

myImage_background
myImage_background1
myImage_background2
myImage_background3
...

and so on. It may be nasty having to close all of them by clicking their 'X' buttons, or by selecting File > Close for each one. Wouldn't it be nice being able to close all of them in a single and quick operation?

Of course, and as long as the images can be characterized by common parts it their identifiers (patterns), they can be closed very easily using PixInsight's console. Following the example above, we can enter this command on the Processing Console window:

Code: 
close *background*

press Enter, and job done! note that this will close only those images whose identifiers include the word "background". For example:

backgroundTest
the_background

would be closed. However, since identifiers are case-sensitive in PixInsight, these wouldn't be closed:

TheBackground
myBackground

In a similar way, this is equivalent to the File > Close All command:

Code: 
close *

Of course, close is just one command available on PixInsight's command line, but there are many more that you can use to speed up and simplify your workflow. Let's say that you want to convert all open images to the 32-bit floating point format:

Code: 
f32 *

or rotate a set of images 90 degrees counter-clockwise:

Code: 
r90 *_test

In the example above, only images whose identifiers end with "_test", as "the_test", "one_test", "nebula_test", and so on, would be rotated.

Who said that command lines are dead? Not in PixInsight! 8)




=====================================================================




Imagina que has generado un buen pu?ado de im?genes de trabajo, y ya no las necesitas. Por ejemplo, podr?as haber generado varios modelos del fondo con la herramienta DBE:

myImage_background
myImage_background1
myImage_background2
myImage_background3
...

y puede que muchas m?s parecidas. Puede resultar tedioso tener que cerrarlas todas haciendo clic en sus botones 'X', o seleccionando File > Close para cada una de ellas. ?No ser?a genial poder cerrarlas todas en una ?nica operaci?n sencilla?

Claro que s?, y de hecho, si podemos caracterizar las im?genes mediante partes en com?n en sus identificadores (patrones), las podemos cerrar muy f?cilmente usando la consola de PixInsight. Continuando con el ejemplo de arriba, podemos introducir este comando en la ventana Processing Console:

Code: 
close *background*

pulsar Intro, y ?ya est?! Tened en cuenta que esta orden cerrar? s?lo las im?genes cuyos identificadores contengan la palabra "background". Por ejemplo:

backgroundTest
the_background

se cerrar?an. Sin embargo, como PixInsight diferencia entre may?sculas y min?sculas en los identificadores de imagen, ?stas no se cerrar?an:

TheBackground
myBackground

De forma similar, esto es equivalente a la opci?n File > Close All del men?:

Code: 
close *

Por supuesto, close es s?lo uno de los comandos disponibles en la l?nea de comandos de PixInsight, pero hay muchos m?s que pod?is usar para acelerar y simplificar vuestro trabajo. Digamos que queremos convertir todas las im?genes que tengamos abiertas al formato de punto flotante en 32 bits:

Code: 
f32 *

o girar un conjunto de im?genes 90 grados en el sentido contrario a las agujas del reloj:

Code: 
r90 *_test

En el ejemplo anterior, s?lo las im?genes cuyos identificadores terminen con "_test", como "the_test", "one_test", "nebula_test", etc., ser?an giradas.

?Qui?n dijo que las l?neas de comandos estaban muertas? ?No en PixInsight! 8)
 
Hola Juan:

Me recuerda los "felices" tiempos del MSDOS, donde uno sab?a lo que estaba haciendo.
Desde que llego el Windows ya uno no sabe lo que la criatura har?.
Yo a consecuencia de esto abandon? la poca programaci?n que era capaz de realizar. No fui capaz de reconvertirme.

Saludos.
 
Me recuerda los "felices" tiempos del MSDOS
Click to expand...

Era divertido, s?. Todo era much?simo m?s sencillo, aunque entonces no ?ramos conscientes. Hay muchas cosas que se echan de menos de cuando us?bamos disquetes de 5 1/4, de cuando un disco de 100 MB era casi infinito, de la INT 21h y la INT 10h, ... :) Bueno, me callo, que parezco el abuelo cebolleta :lol:
 
[quote author="Juan Conejero"]
Code: 
close *
[/quote]

Ayer prob? "save all", y en la ayuda de save no vi nada de esta clase de globbing (lo sab?a de antemano, pero ayer no me acordaba). Estar?a bien una menci?n aunque fuera as? de pasada sin necesidad de profundizar, y aunque eso implicara repetir la misma historia en la ayuda de cada comando. En estas cosas pienso que es mejor repetir que omitir!
 
No, "save all" no est? implementado. El comando save s?lo guarda una imagen en cada invocaci?n, o sea que no es posible hacer algo como "save *" porque no acepta listas de im?genes.

La verdad es que lo de "save all" es una muy buena idea, y no me explico c?mo no se me ocurri? cuando escrib? este comando... ser?a Lunes :lol:
 
mejor "save *", que es m?s consistente! (y flexible adem?s).
Click to expand...

Cierto. La verdad es que quiero darle un buen impulso a la l?nea de comandos, que la tengo bastante abandonada (ya se sabe, tanto eye candy y eso... :lol: ). Quiero a?adir bastantes comandos nuevos e implementar funcionalidad en l?nea de comandos para muchos m?s procesos. ?Se agradecen sugerencias!
 
[quote author="Juan Conejero"]?Se agradecen sugerencias![/quote]

Para m? hay una sugerencia obvia, que probablemente ya hayas pensado:

Code: 
./PixInsight script.scp image*.jpg

O sea, poder crear un script con comandos de estos (como el startup.scp) y pas?rselo a Pixi de forma que lo ejecute sobre las im?genes especificadas. Esto en Unix tiene una ventaja directa, y es que el script a partir de ese momento puede tener shebang y ser ejecutable directamente:

Code: 
$ cat > script.scp
#!/usr/bin/PixInsight

blah blah blah
^D
$ chmod 755 script.scp
$ ./script.scp image*.jpg

A partir de ah?, un interface para llamar a scripts JS desde la consola y as? tambi?n se podr?a acceder a los JS desde la l?nea de comando de Unix, no s?lo a los procesos PCL nativos.

Veo dos problemas principales: uno es el path al ejecutable, que tiene que ir a pi??n en el script. Otro es que actualmente no se reconoce el car?cter '#' como comentario, sino como otra cosa (pero se podr?a hacer una excepci?n para la primera l?nea del script, en plan de ignorarla si no es una directiva v?lida).
 
Esto es m?s que interesante. Es la lexe. Gracias gracias :)

Respecto del # una pregunta: ?Funciona igual si ponemos dos seguidas en la primera l?nea, o sea ##? Lo digo porque de esta forma estar?a solucionado. Bastar?a con que la secuencia ## al principio de una l?nea fuera interpretada como //.

Si no, pues tampoco es ning?n problema hacer la excepci?n de que # no se interprete como una directiva de preprocesador si est? en la primera l?nea (no vac?a) del script, sino como un comentario.

Respecto del path al ejecutable de PI, no veo mayor problema. Al fin y al cabo, eso pasa tambi?n con #!/bin/bash por ejemplo. No cuesta nada crear un enlace simb?lico al ejecutable de PI en /bin o /usr/bin, por ejemplo, con lo cual asunto resuelto.

Por lo dem?s, no veo mayores problemas. La ?nica modificaci?n "importante" es que cuando PI encuentra un .scp o un .js en la l?nea de comandos lo que hace ahora es cargarlo en Script Editor. Habr?a que cambiar eso para que lo ejecutara directamente. Por otra parte, me parece bastante m?s l?gico que sea as?.

El tema de las im?genes es m?s complicado, pero tampoco mucho. Al invocar PI indirectamente de la forma que dices:

Code: 
./script.scp *.jpg

o directamente, que es lo mismo:

Code: 
./PixInsight script.scp *.jpg

va a ocurrir lo siguiente:

- PI se va a inicializar de la manera habitual, va a cargar los m?dulos y a desplegar toda la interfaz gr?fica.

- PI va a cargar todas las im?genes *.jpg y las va a colocar en ventanas, de la forma habitual.

- Despu?s va a ejecutar el script script.scp

Esto significa que no va a existir una relaci?n directa entre las im?genes especificadas en l?nea de comandos y el script. El script tendr?a que hacer algo como:

Code: 
var myImages = ImageWindow.wndows;

nada m?s empezar, para saber qu? im?genes est?n abiertas, y procesarlas.

Entonces falta algo para que este tinglado funcione como se espera, ?no? Porque cuando el script termine, PI seguir? abierto normalmente. Esto no es lo que se supone que tendr?a que pasar.

Podr?amos a?adir un m?todo al PJSR (no s? muy bien d?nde) para que un script pueda terminar la ejecuci?n de PI. Por supuesto, esto no sirve:

Code: 
Console.execute( "exit" );

porque requiere permisos para ejecutar comandos desde un script, lo cual es un problema de seguridad (por defecto est? desactivado).

Hmmm, esto tiene muy buena pinta. ?C?mo lo ves?
 
[quote author="Juan Conejero"]Respecto del # una pregunta: ?Funciona igual si ponemos dos seguidas en la primera l?nea, o sea ##?[/quote]

No. Cuando ejecutas un script, es el n?cleo quien mira si empieza por "#!" y, de ser as?, ejecuta lo que haya a continuaci?n y le pasa como par?metros el nombre del script que estamos ejecutando y los par?metros que nosotros hayamos puesto. Esto es del n?cleo:

Code: 
static int load_script( [...] )
{
    [...]

    if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!') || (bprm->sh_bang)) 
        return -ENOEXEC;



[quote author="Juan Conejero"]Si no, pues tampoco es ning?n problema hacer la excepci?n de que # no se interprete como una directiva de preprocesador si est? en la primera l?nea (no vac?a) del script, sino como un comentario.[/quote]

Confirmo lo de "no vac?a". Pens? que el n?cleo miraba los dos primeros bytes absolutos del archivo, pero una prueba r?pida me confirma que no es as? y que es lo suficientemente listo como para saltarse l?neas en blanco al principio. Bienvenidos al siglo 0x15 ;)


[quote author="Juan Conejero"]Respecto del path al ejecutable de PI, no veo mayor problema. Al fin y al cabo, eso pasa tambi?n con #!/bin/bash por ejemplo. No cuesta nada crear un enlace simb?lico al ejecutable de PI en /bin o /usr/bin, por ejemplo, con lo cual asunto resuelto.[/quote]

Ya hombre, pero eso complica la instalaci?n, que ahora mismo se efect?a totalmente como usuario.


Con respecto al workflow en general, mi idea era que no se lanzara el interface gr?fico en absoluto (o como m?ximo, una barra de progreso o algo as?, ya que esto tiene potencial para durar bastante tiempo) y que al acabar el script, las im?genes aparecieran m?gicamente modificadas en el filesystem (ya sea sobreescritas o con copia).

Me confunde esto:

[quote author="Juan Conejero"]El script tendr?a que hacer algo como:

Code: 
var myImages = ImageWindow.wndows;

nada m?s empezar, para saber qu? im?genes est?n abiertas, y procesarlas.[/quote]

Pero eso es sintaxis JS, no de consola ?verdad? En consola habr?a que habilitar un m?nimo parsing de comandos, o simplemente planchar todo en el t?pico ARGV y que cada script hiciera su propio parsing (hmmm... c?digo reutilizable == bibliotecas... ;)). Sobre JS hablo m?s abajo.


[quote author="Juan Conejero"]Entonces falta algo para que este tinglado funcione como se espera, ?no? Porque cuando el script termine, PI seguir? abierto normalmente. Esto no es lo que se supone que tendr?a que pasar.[/quote]

Claro. Pixi tendr?a que saber que se est? ejecutando "en modo batch" y salir cuando el script terminase. O cuando el usuario hiciera click en alg?n bot?n "Cancel" que aparecer?a junto a la barra de progreso.


[quote author="Juan Conejero"]Podr?amos a?adir un m?todo al PJSR (no s? muy bien d?nde) para que un script pueda terminar la ejecuci?n de PI. Por supuesto, esto no sirve:

Code: 
Console.execute( "exit" );

porque requiere permisos para ejecutar comandos desde un script, lo cual es un problema de seguridad (por defecto est? desactivado).[/quote]

Mi idea era que los scripts JS apenas fueran diferenciables de los procesos PCL, al menos desde el punto de vista de los scripts de consola. As? pues, dado que la ayuda de (por ejemplo) ACDNR es as?:

Code: 
Usage: ACDNR [<arg_list>] [<view_list>]

Argument suffix selects parameter set: L=luminance, C=chrominance.

When no suffix is used, arguments apply to both luminance and chrominance,
as applicable.

-L[+|-] | -applyL[+|-]
<blah blah blah>

la ayuda de un script JS podr?a ser similar:

Code: 
Usage: MST.js [<arg_list>] [<view_list>]

<contenido de #feature-info, por ejemplo>

<par?metros blah blah>

y el script JS no se tiene que preocupar de cerrar Pixi, de la misma forma que ACDNR tampoco lo hace. Lo que s? a?adir?a al motor de JS es un "entry point", que ser?a la funci?n que se ejecuta por defecto cuando se le llama desde la consola. Podr?a ser el obvio "main". Habr? que modificar los scripts existentes para que acepten como par?metros de main las im?genes sobre las que trabajar, en lugar de ir a ImageWindow a buscarlas. Esto me huele que no te va a encajar bien con la filosof?a de Pixi ;).

Y, totalmente aparte de toda esta conversaci?n, yo cambiar?a la sintaxis '!grep' por 'system (grep)' y eliminar?a el bang. Es lo mismo que el "save all", por consistencia nada m?s, y tambi?n porque es mucho m?s d?ficil ejecutar comandos por error usando system que con un simple bang.
 
Todo esto necesita una buena digesti?n por mi parte. Espera, que voy a por Almax... :lol:

Cuando la primera l?nea no vac?a de un script, descartando todos los caracteres trimables a la izquierda, empiece por la secuencia #! PI la ignorar? completamente.

Con respecto al workflow en general, mi idea era que no se lanzara el interface gr?fico en absoluto
Click to expand...

Correcto. Pero yo lo dejar?a como una opci?n; es decir, a?adir?a un par?metro que permitiera forzar la entrada del GUI, o tal vez incluso invocable desde .scp. S?lo porque as? lo hacemos m?s flexible. Por la misma raz?n, tambi?n a?adir?a un m?todo a PJSR para que un script JS pueda forzar la entrada del GUI.

Una cosa al margen. En realidad, todo el GUI se va a generar igual que en ejecuci?n normal, s?lo que la ventana principal de la aplicaci?n no va a ser visible. En una aplicaci?n como PI, el GUI est? demasiado imbricado con todo y por todas partes; hay muchas cosas que dependen directamente de elementos de la interfaz, que tienen que existir y funcionar.

Todo esto puede dar problemas m?ltiples y en m?ltiples momentos. ?No es maravilloso? 8)

y que al acabar el script, las im?genes aparecieran m?gicamente modificadas en el filesystem (ya sea sobreescritas o con copia).
Click to expand...

Ufff. Eso es complejo/dif?cil/peligroso/<a?ada_usted_algo_chungo>. Eso hay que pensarlo muy bien, y certamente rompe con muchos esquemas existentes. Hala, a darle al coco...

Me confunde esto:
Click to expand...

S?, claro, me dej? llevar por la emoci?n :) Habr?a que a?adir cosas similares a .scp, o una interfaz con argc/argv como t? dec?as (mira que eres cl?sico, t?o ;) ).

Mi idea era que los scripts JS apenas fueran diferenciables de los procesos PCL, al menos desde el punto de vista de los scripts de consola.
Click to expand...

Se puede implementar mediante m?s directivas del tipo #feature. Podr?a ser un grupo de directivas #batch por ejemplo.

Habr? que modificar los scripts existentes para que acepten como par?metros de main las im?genes sobre las que trabajar, en lugar de ir a ImageWindow a buscarlas. Esto me huele que no te va a encajar bien con la filosof?a de Pixi
Click to expand...

No te preocupes por eso :) Yo soy muy borde (con b) con mi propio c?digo...

yo cambiar?a la sintaxis '!grep' por 'system (grep)' y eliminar?a el bang.
Click to expand...

Yo pondr?a system como opci?n, aparte de bang. El bang me gusta (y system tambi?n).
 
[quote author="Juan Conejero"]Cuando la primera l?nea no vac?a de un script, descartando todos los caracteres trimables a la izquierda, empiece por la secuencia #! PI la ignorar? completamente.[/quote]

Bueno, rectificar es de sabios, dicen. Realmente antes lo dije mal adrede para que ahora me pueda autoproclamar sabio xD. Antes hice la prueba con un script de shell, y el n?cleo funcion? como yo esperaba, lo que me indujo a pensar que el n?cleo era sabio y listo y que hab?amos entrado por fin en el siglo 0x15. No es as?, ahora he probado con un script de Perl y es sencillo: el n?cleo mira los dos primeros bytes absolutos del archivo. Si consigue parsear un int?rprete, lo llama y listos. De lo contrario, llama a /bin/sh (por eso me funcion? en la primera prueba). Por tanto, si PixInsight se ejecuta y ve un script es que el n?cleo ha detectado bien un int?rprete, y el script empieza por '#!' sin nada m?s antes.


[quote author="Juan Conejero"]
Con respecto al workflow en general, mi idea era que no se lanzara el interface gr?fico en absoluto
Click to expand...

Correcto. Pero yo lo dejar?a como una opci?n[/quote]

S?, yo tambi?n lo pensaba. Siempre opciones :^).


[quote author="Juan Conejero"]Una cosa al margen. En realidad, todo el GUI se va a generar igual que en ejecuci?n normal, s?lo que la ventana principal de la aplicaci?n no va a ser visible. [...] Todo esto puede dar problemas m?ltiples y en m?ltiples momentos. ?No es maravilloso? 8)[/quote]

Lo de "se genera pero no es visible" tambi?n era evidente. Pero eso de que pueda dar errores s?lo porque el GUI no se ve... hmmm... no me dice mucho a favor de Qt o de lo que sea. Y no te veas tentado por la chapucilla de "Bueno, pues dibujo la ventana en las coordenadas 1e5 x 1e5 y listos" porque algunos sistemas "avanzados" permiten configurar una opci?n seg?n la cual nunca se mostrar?n ventanas fuera del escritorio visible ;).


[quote author="Juan Conejero"]
y que al acabar el script, las im?genes aparecieran m?gicamente modificadas en el filesystem (ya sea sobreescritas o con copia).
Click to expand...

Ufff. Eso es complejo/dif?cil/peligroso/<a?ada_usted_algo_chungo>. Eso hay que pensarlo muy bien, y certamente rompe con muchos esquemas existentes. Hala, a darle al coco...[/quote]

No veo el peligro, quiz? no nos hemos entendido. Yo me refer?a a que "al acabar el script de consola, las im?genes aparecen desde el punto de vista del usuario m?gicamente modificadas en el filesystem". El script de consola recibe las im?genes como sea, llama a los procesos PCL y JS que crea convenientes y al final ejecutar?a una serie de comandos 'save' para guardar los resultados. No es m?s peligroso que un usuario que hace un shell script por su cuenta; obviamente ?l no va a hacer un 'rm -rf *'.

Y si un usuario ejecuta ciegamente un script de consola que ha recibido por correo, merece el mismo premio que si ejecuta ciegamente un shell script que ha recibido por correo.

Inciso, quiz? ya un poco offtopic en este hilo: estos archivos .scp funcionar?an pr?cticamente como un .psm pero con m?s flexibilidad. Propongo tambi?n que sea posible './PixInsight foobar.psm *.jpg'. O tambi?n con una sintaxis m?s expl?cita en ambos casos: './PixInsight --run [ file.scp | file.psm ] images*.jpg'.
 
[quote author="Nocturnal"]Well the beginning of the thread was interesting.[/quote]

Just a matter of perception... for me, the end of the thread is interesting! xD.

It's some brain dumping about possible new features of PixInsight regarding automation via the ProcessingConsole.
 
[quote author="Juan Conejero"]T

yo cambiar?a la sintaxis '!grep' por 'system (grep)' y eliminar?a el bang.
Click to expand...

Yo pondr?a system como opci?n, aparte de bang. El bang me gusta (y system tambi?n).[/quote]

:shock: :eek: :D
 
[quote author="David Serrano"]Propongo tambi?n que sea posible './PixInsight foobar.psm *.jpg'. O tambi?n con una sintaxis m?s expl?cita en ambos casos: './PixInsight --run [ file.scp | file.psm ] images*.jpg'.[/quote]

Hmm, veo que ya hay una opci?n -r. Para diferenciar la nueva de la existente, la nueva entonces podr?a ser --batch por ejemplo.
 
No,

I agree with Sander, the 'beginning' of the thread was interesting.

The remainder of the thread doesn't benefit from the cooperation of many, many interested parties - none of whom speak Spanish.

I'm sorry to have to say this - but keeping your exchanges in Spanish just doesn't help. It's like not providing the documentation that is so necessary to keep PI alaive.

I know from personal experience that many potential users are put off PixInsight for these two reasons alone :-

a.) Insufficient documentation

and

b.) Such documentation as does exist often being provided in Spanish only

Now, (a) can be excused, providing (b) is avoided.

Similarly, if the development team wish to converse ENTITELY in Spanish, that would be perfectly acceptable, but the documentation MUST then be made available - in English.

Now, I can speak French, and can get on pretty well in Spanish (reading only, providing I know the basic subject material) - so this 'complaint' is not just to cover my 'linguistic laziness'. I really just feel that PixInsight would benefit hugely if the PI Forum was conducted in the 'Language of the Internet'.

Cheers,
 
An old topic, but now we have Google Translate so any english-only reader interested in this discussion can just click this:

  https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fpixinsight.com%2Fforum%2Findex.php%3Ftopic%3D968.0&edit-text=
 
Yes - Google Translate has its usefulness. But, not for 'technical translations'.

I performed technical translations throught my 35-year working career (French to English), but the only way I believe technical translations can be truly meaningful is if they are translated *into* the translator's *native* language, by a translator who already has a thorough technical, and proficient, understanding of the material in question. Once translated, the information should be proof-read by a second technical person (or the original author) who has a *good* understanding in the new language of the document. That way, errors in the translation process can be avoided, or corrected.

You don't get that with an automated system. You could conceivably end up with a totally erroneous understanding of a topic, simply because the original document was not some form of 'casual text'. A computerised translator does not 'learn' from what it translates - there is highly likely to be no form of AI in the process (so the 'machine' never actually 'learns' from the translated information), and there will not be an external, 'human', closed-loop to correct translation errors.

My whole family, for three generations, has been heavily involved in the world of translation. My grandfather performed 'live' translation for the United Nations (English - French - German) and I was invited to watch the translator's ('behind the scenes' - the voices in their headphones) ar work. They were only mentally (and physically) capable of performing 'live' translation work for 15 minutes at a time, once per working day. They had to be ONE HUNDRED PERCENT CORRECT. At the first error, or upon the expiry of their alotted 15-minute session, they handed over to the next person on the team, and then they took over the #2 role - checking on the accuracy of the #1 translator. Then they fell back to a #3 position, and checked the accuracy of the #1 and #2 translators for the next three hours, before ensuring that all conversations from that day were handed to the stenographers for typing-up. The following day involved proof-reading the hard-copy against the tape-recordings from earlier sessions.

Some of these guys stopped wars  :police:
 
You must log in or register to reply here.
Back
Top