ImageJ problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ImageJ problem

robert atwood
Hi, All:
We find ImageJ to be extremely useful here at Diamond Syncrotron, especially for experiments in X-ray imaging and tomography.  However, we've encountered some issue with the framework that causes some frustration when trying to use the wonderful functionality provided by this program.


>I also wanted to let you know that launching ImageJ remotely is not working for both Ched and myself: it looks like it is running, but nothing is opening in the >X window.


I found what the problem is, but I don't know what the solution is. So I am inviting a few others (Sysadmin, imageJ program author and User group)  to comment in case they can shed any light on this!

ImageJ has a mode. "Single Listener",  in which a new call to ImageJ causes the requested image to open in an existing session. This is very convenient to use here because it allows a way to get around the problem of slow dialog box opening  (see below) However, if a session is running on another real or  virtual terminal, the window opens there instead of on the session where the command is issued.

However, to make matters  worse ..  is the fact that I , as one user,  am running ImageJ grabbing the windows from your ImageJ session as another user? The 'single listener' is  accepting command from a different user than the one who launched the session. I've verified this with two local users here.

Can anyone suggest a way around this, obviously apart from not selecting 'single listener' , the trouble is if anyone selects 'single listener' then nobody else can use ImageJ on the big-memory machine.


Some details:

This is running ImageJ 1.46a / Java 1.6.0_10 on a 64bit RedHat 5 machine. Often some people log into it remotely and use ImageJ in a remote X-window session to make use of the large memory of this machine and the 10-gig network connection to the central data storage system, often for basic viewing while undertaking some data manipulation,  interactive cropping to produce small subsets for downloading, or similar but sometimes for more advanced macros and ImageJ is usually ideal for these tasks, but we've noticed  a few issues cropping up particulary to do with the remote X-window sessions

- the problem mentioned above where 'single listener' mode interacts in a strange way with the user system,
- and another issue where dialog boxes take a long time to open, though image container windows do not take an excessive time to open.  (can be mitigated by using that mode above)


Thanks for any suggestions!
Robert

  ____________________
  Dr. Robert C. Atwood
  Research Associate
  Beamline I12-JEEP
  The Joint Engineering and Environmental Processing Beamline
  Diamond Light Source
  The Harwell Science and Innovation Campus
  Didcot,OXON
  OX11 0DE
  +44 (0) 1235 778 670







Hi Robert,

...

I also wanted to let you know that launching ImageJ remotely is not working for both Ched and myself: it looks like it is running, but nothing is opening in the X window.

Best,

Kristina



--

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.

Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.

Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.

Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

 







Reply | Threaded
Open this post in threaded view
|

Re: ImageJ problem

dscho
Hi,

On Wed, 4 Jan 2012, Robert Atwood wrote:

> ImageJ has a mode. "Single Listener",  in which a new call to ImageJ
> causes the requested image to open in an existing session. This is very
> convenient to use here because it allows a way to get around the problem
> of slow dialog box opening  (see below) However, if a session is running
> on another real or  virtual terminal, the window opens there instead of
> on the session where the command is issued.
>
> However, to make matters  worse ..  is the fact that I , as one user,
> am running ImageJ grabbing the windows from your ImageJ session as
> another user? The 'single listener' is  accepting command from a
> different user than the one who launched the session. I've verified this
> with two local users here.

We had the same problem at my former workplace, where a real nice machine
(128G RAM, 16 cores, _real_ fun!) was used by multiple users.

So I made a fix in ImageJA/Fiji (which did not make it into ImageJ1) which
should solve the problem.

Ciao,
Johannes

P.S.: for the technically inclined, the fix was this:
http://fiji.sc/cgi-bin/gitweb.cgi?p=ImageJA.git;a=commitdiff;h=c0edc3994832f093378864fd276b98a9575d6766;hb=refs/heads/master
Reply | Threaded
Open this post in threaded view
|

Re: ImageJ problem

pcloetens
In reply to this post by robert atwood
Hello,
Did you try using a more recent version of Java 1.6? We had speed issues
like you mention with java 1.6 on RedHat (4) until we switched to the
java version bundled with ImageJ.
On multiple user machines we avoid selecting 'single listener'.
Peter

On 01/04/2012 03:23 PM, Robert Atwood wrote:

> Hi, All:
> We find ImageJ to be extremely useful here at Diamond Syncrotron, especially for experiments in X-ray imaging and tomography.  However, we've encountered some issue with the framework that causes some frustration when trying to use the wonderful functionality provided by this program.
>
>
>> I also wanted to let you know that launching ImageJ remotely is not working for both Ched and myself: it looks like it is running, but nothing is opening in the>X window.
>
> I found what the problem is, but I don't know what the solution is. So I am inviting a few others (Sysadmin, imageJ program author and User group)  to comment in case they can shed any light on this!
>
> ImageJ has a mode. "Single Listener",  in which a new call to ImageJ causes the requested image to open in an existing session. This is very convenient to use here because it allows a way to get around the problem of slow dialog box opening  (see below) However, if a session is running on another real or  virtual terminal, the window opens there instead of on the session where the command is issued.
>
> However, to make matters  worse ..  is the fact that I , as one user,  am running ImageJ grabbing the windows from your ImageJ session as another user? The 'single listener' is  accepting command from a different user than the one who launched the session. I've verified this with two local users here.
>
> Can anyone suggest a way around this, obviously apart from not selecting 'single listener' , the trouble is if anyone selects 'single listener' then nobody else can use ImageJ on the big-memory machine.
>
>
> Some details:
>
> This is running ImageJ 1.46a / Java 1.6.0_10 on a 64bit RedHat 5 machine. Often some people log into it remotely and use ImageJ in a remote X-window session to make use of the large memory of this machine and the 10-gig network connection to the central data storage system, often for basic viewing while undertaking some data manipulation,  interactive cropping to produce small subsets for downloading, or similar but sometimes for more advanced macros and ImageJ is usually ideal for these tasks, but we've noticed  a few issues cropping up particulary to do with the remote X-window sessions
>
> - the problem mentioned above where 'single listener' mode interacts in a strange way with the user system,
> - and another issue where dialog boxes take a long time to open, though image container windows do not take an excessive time to open.  (can be mitigated by using that mode above)
>
>
> Thanks for any suggestions!
> Robert
>
>    ____________________
>    Dr. Robert C. Atwood
>    Research Associate
>    Beamline I12-JEEP
>    The Joint Engineering and Environmental Processing Beamline
>    Diamond Light Source
>    The Harwell Science and Innovation Campus
>    Didcot,OXON
>    OX11 0DE
>    +44 (0) 1235 778 670
>
>
>
>
>
>
>
> Hi Robert,
>
> ...
>
> I also wanted to let you know that launching ImageJ remotely is not working for both Ched and myself: it looks like it is running, but nothing is opening in the X window.
>
> Best,
>
> Kristina
>
>
>


--
Peter Cloetens
X-Ray Imaging Group
Tel: +33 4 76 88 26 50
Mailto: [hidden email]

European Synchrotron Radiation Facility (ESRF)
6 rue Jules Horowitz
F-38043 Grenoble
http://www.esrf.eu
Reply | Threaded
Open this post in threaded view
|

Re: ImageJ problem

robert atwood
In reply to this post by dscho
Dear Johannes

I did not so far try Fiji for that issue, though I do have it installed and stil explore the available features. Since 'Fiji Is Just Imagej' I didn't realize that some differences to the core code might accumulate, I thought Fiji was really integration of the suite of plugins and jython scripting?


Wayne also sent me a method to automatically disable the Single Listener by default in the startup script.

What is the change in ImageJA , how does it solve this?

Our machine is 96 G RAM, 16 cores, so rather similar , I think the board with slots to allow a bit more memory was missing the slot for an extra GPU card so 96 seemed like the best deal at that time .

Robert




> -----Original Message-----
> From: Johannes Schindelin [mailto:[hidden email]]
> Sent: 04 January 2012 16:42
> To: Atwood, Robert (DLSLtd,RAL,DIA)
> Cc: [hidden email]
> Subject: Re: ImageJ problem
>
> Hi,
>
> On Wed, 4 Jan 2012, Robert Atwood wrote:
>
> > ImageJ has a mode. "Single Listener",  in which a new call to ImageJ
> > causes the requested image to open in an existing session. This is
> > very convenient to use here because it allows a way to get around the
> > problem of slow dialog box opening  (see below) However, if a session
> > is running on another real or  virtual terminal, the window opens
> > there instead of on the session where the command is issued.
> >
> > However, to make matters  worse ..  is the fact that I , as one user,
> > am running ImageJ grabbing the windows from your ImageJ session as
> > another user? The 'single listener' is  accepting command from a
> > different user than the one who launched the session. I've verified
> > this with two local users here.
>
> We had the same problem at my former workplace, where a real nice
> machine (128G RAM, 16 cores, _real_ fun!) was used by multiple users.
>
> So I made a fix in ImageJA/Fiji (which did not make it into ImageJ1)
> which should solve the problem.
>
> Ciao,
> Johannes
>
> P.S.: for the technically inclined, the fix was this:
> http://fiji.sc/cgi-
> bin/gitweb.cgi?p=ImageJA.git;a=commitdiff;h=c0edc3994832f093378864fd276
> b98a9575d6766;hb=refs/heads/master

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Reply | Threaded
Open this post in threaded view
|

Re: ImageJ problem

robert atwood
In reply to this post by pcloetens
Dear Peter:

That is an interesting point. Did you specifically have speed issues for dialog boxes opening rather than actual image processing routines? For example , if applying 'median filter' it takes ages for the box to select the radius to open, then ages more for the box to confirm that you want to apply to the whole stack, but then the actual filtering and redisplay is as fast as expected.


It seems that the module launches ImageJ with its own bundled Java, it's been done via Modules here, and in the module we launch via:

set-alias "imagej" "/dls_sw/apps/ImageJ/$arch/$version/ImageJ/jre/bin/java $memsize -jar /dls_sw/apps/ImageJ/$arch/$version/ImageJ/ij.jar -ijpath /dls_sw/apps/ImageJ/$arch/$version/ImageJ/ $@"

where $version is constant but $arch is picked up from the machine (either 32 bits or 64 bits Linux Redhat 5)

If it's 64 bits then memsize is set to 16000m

The ImageJ Help dialog reports that Java is "1.6.0_10 (64 bit)"
Do you use a later version of java than that?

Thanks
Robert









> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Peter Cloetens
> Sent: 04 January 2012 17:07
> To: [hidden email]
> Subject: Re: ImageJ problem
>
> Hello,
> Did you try using a more recent version of Java 1.6? We had speed
> issues like you mention with java 1.6 on RedHat (4) until we switched
> to the java version bundled with ImageJ.
> On multiple user machines we avoid selecting 'single listener'.
> Peter
>
> On 01/04/2012 03:23 PM, Robert Atwood wrote:
> > Hi, All:
> > We find ImageJ to be extremely useful here at Diamond Syncrotron,
> especially for experiments in X-ray imaging and tomography.  However,
> we've encountered some issue with the framework that causes some
> frustration when trying to use the wonderful functionality provided by
> this program.
> >
> >
> >> I also wanted to let you know that launching ImageJ remotely is not
> working for both Ched and myself: it looks like it is running, but
> nothing is opening in the>X window.
> >
> > I found what the problem is, but I don't know what the solution is.
> So I am inviting a few others (Sysadmin, imageJ program author and User
> group)  to comment in case they can shed any light on this!
> >
> > ImageJ has a mode. "Single Listener",  in which a new call to ImageJ
> causes the requested image to open in an existing session. This is very
> convenient to use here because it allows a way to get around the
> problem of slow dialog box opening  (see below) However, if a session
> is running on another real or  virtual terminal, the window opens there
> instead of on the session where the command is issued.
> >
> > However, to make matters  worse ..  is the fact that I , as one user,
> am running ImageJ grabbing the windows from your ImageJ session as
> another user? The 'single listener' is  accepting command from a
> different user than the one who launched the session. I've verified
> this with two local users here.
> >
> > Can anyone suggest a way around this, obviously apart from not
> selecting 'single listener' , the trouble is if anyone selects 'single
> listener' then nobody else can use ImageJ on the big-memory machine.
> >
> >
> > Some details:
> >
> > This is running ImageJ 1.46a / Java 1.6.0_10 on a 64bit RedHat 5
> > machine. Often some people log into it remotely and use ImageJ in a
> > remote X-window session to make use of the large memory of this
> > machine and the 10-gig network connection to the central data storage
> > system, often for basic viewing while undertaking some data
> > manipulation,  interactive cropping to produce small subsets for
> > downloading, or similar but sometimes for more advanced macros and
> > ImageJ is usually ideal for these tasks, but we've noticed  a few
> > issues cropping up particulary to do with the remote X-window
> sessions
> >
> > - the problem mentioned above where 'single listener' mode interacts
> > in a strange way with the user system,
> > - and another issue where dialog boxes take a long time to open,
> > though image container windows do not take an excessive time to open.
> > (can be mitigated by using that mode above)
> >
> >
> > Thanks for any suggestions!
> > Robert
> >
> >    ____________________
> >    Dr. Robert C. Atwood
> >    Research Associate
> >    Beamline I12-JEEP
> >    The Joint Engineering and Environmental Processing Beamline
> >    Diamond Light Source
> >    The Harwell Science and Innovation Campus
> >    Didcot,OXON
> >    OX11 0DE
> >    +44 (0) 1235 778 670
> >
> >
> >
> >
> >
> >
> >
> > Hi Robert,
> >
> > ...
> >
> > I also wanted to let you know that launching ImageJ remotely is not
> working for both Ched and myself: it looks like it is running, but
> nothing is opening in the X window.
> >
> > Best,
> >
> > Kristina
> >
> >
> >
>
>
> --
> Peter Cloetens
> X-Ray Imaging Group
> Tel: +33 4 76 88 26 50
> Mailto: [hidden email]
>
> European Synchrotron Radiation Facility (ESRF)
> 6 rue Jules Horowitz
> F-38043 Grenoble
> http://www.esrf.eu

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Reply | Threaded
Open this post in threaded view
|

Re: ImageJ problem

dscho
In reply to this post by robert atwood
Dear Robert,

On Fri, 6 Jan 2012, [hidden email] wrote:

> I did not so far try Fiji for that issue, though I do have it installed
> and stil explore the available features. Since 'Fiji Is Just Imagej' I
> didn't realize that some differences to the core code might accumulate,
> I thought Fiji was really integration of the suite of plugins and jython
> scripting?

The plan was always to put all the improvements back into ImageJ proper.
As has happened with the menu structure, with the Command Finder, etc.

> What is the change in ImageJA , how does it solve this?

ImageJA does not use a socket, but rather a file which is readable only to
the appropriate user. It uses a Java technique called RMI and is therefore
relatively safe, even in a multi-user environment (which I had in my
previous job). The file name contains the user name and therefore multiple
users cannot interfer with each other's ImageJ instance.

Unfortunately, on Wayne's computer there were some unexpected problems and
I never could reproduce the problem (and therefore I could not fix it,
either).

So until Fiji switches to ImageJ2, we indeed have that small deviation
from ImageJ, but it should not affect any normal operation.

Ciao,
Johannes