Hi listers,
I´m still considering the different possibilities to use ImageJ as an external "processor" for another App. One idea clearly is to use the macro and batch options. However, this has some disadvantages, one being that when repeatedly doing this, ImageJ will be restarted all over again any time, which will make processing slow. So I was wondering, another option would be to have ImageJ already running from the start and send "commands" to ImageJ via a network socket. What exactly a command is, would need to be defined, however I think that re-using Albert Cardonas CLI interface that relies on macro language would be a very valid option. So, has anybody already done something similar? Any suggestions? Joachim ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
Hi Joachim,
On Fri, 23 Oct 2009, Joachim Wesner wrote: > I´m still considering the different possibilities to use ImageJ as an > external "processor" for another App. > > One idea clearly is to use the macro and batch options. However, this > has some disadvantages, one being that when repeatedly doing this, > ImageJ will be restarted all over again any time, which will make > processing slow. > > So I was wondering, another option would be to have ImageJ already > running from the start and send "commands" to ImageJ via a network > socket. What exactly a command is, would need to be defined, however I > think that re-using Albert Cardonas CLI interface that relies on macro > language would be a very valid option. > > So, has anybody already done something similar? Any suggestions? default, but it is not the regular socket listener, but an RMI-based one, so it is safe enough). With such a socket listener, starting ImageJ again with command line options (such as -eval <commands>) will send the commands to the existing instance. Hth, Dscho |
Hi Dscho,
thanx a lot, I was somehow aware of the "Socket listener" in ImageJ, but from the docs that I had see had the impression that it´s only used or useful to synchronize multiple ImageJ instances, not for sending commands. GREAT, I´currently taking a look at the source code. At that would be missing for my planned task would be a simple (C?) frontend that can be compiled into a standlaone exe that sends commands (maybe given as its command line args) to that socket. I will start to make one if there is nothing already available. Cheers Joachim Johannes Schindelin <Johannes.Schinde An [hidden email]> [hidden email] Gesendet von: Kopie ImageJ Interest Group Thema <[hidden email]. Re: Remote controlling ImageJ via GOV> a socket? 23.10.2009 01:12 Bitte antworten an ImageJ Interest Group <[hidden email]. GOV> Hi Joachim, On Fri, 23 Oct 2009, Joachim Wesner wrote: > I´m still considering the different possibilities to use ImageJ as an > external "processor" for another App. > > One idea clearly is to use the macro and batch options. However, this > has some disadvantages, one being that when repeatedly doing this, > ImageJ will be restarted all over again any time, which will make > processing slow. > > So I was wondering, another option would be to have ImageJ already > running from the start and send "commands" to ImageJ via a network > socket. What exactly a command is, would need to be defined, however I > think that re-using Albert Cardonas CLI interface that relies on macro > language would be a very valid option. > > So, has anybody already done something similar? Any suggestions? ImageJ optionally runs with a socket listener (in Fiji, it is on by default, but it is not the regular socket listener, but an RMI-based one, so it is safe enough). With such a socket listener, starting ImageJ again with command line options (such as -eval <commands>) will send the commands to the existing instance. Hth, Dscho ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
Free forum by Nabble | Edit this page |