Posted by
ctrueden on
Jun 11, 2014; 5:34pm
URL: http://imagej.273.s1.nabble.com/Overlaying-ROIs-very-costly-tp5008136p5008140.html
Hi Oli,
> The system is brand new, see below
Right, thanks, sorry. Missed that in the original post.
If you are using ImageJ2 (e.g., via Fiji) then you can press Ctrl+\ to dump
a stack trace while waiting for the zoom operation to kick in. It will
print a full trace of everything that Java is currently doing, which might
shed some light on where the performance bottleneck is.
In this case though, you need to do it from the console since the zoom
operation blocks the event dispatch thread; see:
http://wiki.imagej.net/Debugging#Debugging_JVM_hangsI tried doing this from the console when zooming from 50% down to 33%. The
stack trace snapshot during that time has the following info:
"AWT-EventQueue-0" prio=6 tid=10c0d7000 nid=0x12056d000 waiting on
condition [12056a000]
java.lang.Thread.State: RUNNABLE
at ij.gui.ShapeRoi.parsePath(ShapeRoi.java:936)
at ij.gui.ShapeRoi.getRois(ShapeRoi.java:463)
at ij.gui.ShapeRoi.getLength(ShapeRoi.java:649)
at ij.gui.Roi.equals(Roi.java:1669)
at java.util.Vector.indexOf(Vector.java:361)
- locked <6d81c6258> (a java.util.Vector)
at java.util.Vector.contains(Vector.java:320)
at ij.gui.Overlay.contains(Overlay.java:76)
at ij.gui.Roi.isActiveOverlayRoi(Roi.java:1656)
at ij.gui.ShapeRoi.draw(ShapeRoi.java:999)
at ij.gui.ImageCanvas.drawRoi(ImageCanvas.java:217)
at ij.gui.ImageCanvas.paint(ImageCanvas.java:179)
at ij.gui.ImageCanvas.update(ImageCanvas.java:151)
Which leads me to believe it is a problem with the slowness of
synchronization, since the Vector class is synchronized. This may be
something that Wayne could fix in the ImageJ1 source code. To speculate: it
may be that object synchronization (to avoid multi-threading related
problems) is slower on Windows than on OS X. Using ArrayList instead of
Vector would very likely avoid the issue.
Regards,
Curtis
On Wed, Jun 11, 2014 at 12:04 PM, Burri Olivier <
[hidden email]>
wrote:
> Hi Curtis,
>
> The system is brand new, see below
>
> > > This happened running Fiji under Win7 x64, Corei7 3.4GHz with 24Gb RAM
>
> Olivier Burri
> Engineer - Image Processing
> & Software Development
> EPFL - SV - PTECH - PTBIOP
>
> > -----Original Message-----
> > From: ImageJ Interest Group [mailto:
[hidden email]] On Behalf Of
> > Curtis Rueden
> > Sent: mercredi 11 juin 2014 18:16
> > To:
[hidden email]
> > Subject: Re: Overlaying ROIs very costly
> >
> > Hi Oli,
> >
> > > Any attempt to zoom in or pan on the image is extremely slow (seconds
> > > or 10s of seconds).
> >
> > You have a lot of objects in that overlay, so a little sluggishness is
> not surprising.
> > That said, on my system (2.4 GHz Intel Core i7) the zoom is rather
> instantaneous,
> > except for between the 33% and 50% zoom settings, where it takes ~500ms.
> >
> > How old is your system?
> >
> > Regards,
> > Curtis
> >
> >
> > On Wed, Jun 11, 2014 at 10:37 AM, Burri Olivier <
[hidden email]>
> > wrote:
> >
> > > Hi all,
> > >
> > > Just curious if anyone else is experiencing very slow response time
> > > from the image window when there is an overlay.
> > >
> > > I have an RGB Image with two overlays corresponding to segmentations
> > > in different channels. The image is 2500x1800px.
> > > Overlays are 2px thick and of different colors
> > >
> > > Any attempt to zoom in or pan on the image is extremely slow (seconds
> > > or 10s of seconds).
> > >
> > > You can find the image being troublesome here:
> > >
https://dl.dropboxusercontent.com/u/86578924/overlayProblem.tif (18Mb,
> > > RGB)
> > >
> > > This happened running Fiji under Win7 x64, Corei7 3.4GHz with 24Gb RAM
> > >
> > > All the best
> > >
> > > Oli
> > >
> > > --
> > > ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> > >
> >
> > --
> > ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html