very very very slow process
Locked
very very very slow process
 
|
Re: very very very slow process
|
|
Re: very very very slow process
|
|
Re: very very very slow process
|
|
Re: very very very slow process
|
|
Re: very very very slow process (what is different in Fiji?)
|
|
Re: very very very slow process (what is different in Fiji?)
|
|
Re: very very very slow process (what is different in Fiji?)
|
|
In reply to this post by Michael Schmid
Prime candidates:
* parallel garbage collection * other JVM Have you tried to limit the number of threads to 1 or 2 less then the maximum number of processors if the number of available processors is very large? Thanks, Stephan On Thu, 2018-02-15 at 15:25 +0100, Michael Schmid wrote: > Hi everyone, > > after some off-list discussion and tests run by Philippe: > > The problem of unexpectedly poor performance on a Xeon 44-core > machine > only appears in Fiji, not in plain ImageJ. > The problem is not limited to the "RankFilters" > (Process>Filters>Mean, > Median, Minimum, etc., everything that uses the "Circular Masks" for > the > neighborhood) but one can see parallelization problems also in other > functions, though not as severe. > > From all the evidence, it seems that sometimes one core or a few > cores > are not available for processing for rather long time (at least > milliseconds, probably they do something else during that period). > This > has especially bad consequences for the current RankFilters because > they > expect all threads to work continuously and eventually the other > threads > have to wait if one thread (core) is inactive. > (Due to optimized memory access, the RankFilters parallelization > strategy has been very fast on machines like the Core i5 that were > popular at the time when I developed it, but it gets poor under such > circumstances). > > So the question: What is different on Fiji vs. plain ImageJ, > concerning > threads? > > The problems could be explained e.g. slower switching between threads > in > case one core has to handle several threads, or by some background > activity that does not happen in plain ImageJ. > I suspect different java options in the Launcher of Fiji vs. plain > ImageJ, but I know nothing about Fiji. > > > Michael > ________________________________________________________________ > > > On 13/02/2018 12:01, Philippe Mailly wrote: > > > > Hi, > > Some new tests. > > > > If I run Fiji in 32bits the median filter speed is similar to > > other > > computers. > > In 64bits, all 2D filters (median, mean, variance ....) on a image > > stack > > are very slow (40s) > > Same type of filters in 3D (median3D, mean3D, variance 3D ...) take > > only > > 10s > > > > Philippe > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: very very very slow process (what is different in Fiji?)
|
|
Yes as you can see on the plots.
Philippe Le 15/02/2018 à 15:43, Saalfeld, Stephan a écrit : > Prime candidates: > > * parallel garbage collection > * other JVM > > Have you tried to limit the number of threads to 1 or 2 less then the > maximum number of processors if the number of available processors is > very large? > > Thanks, > Stephan > > > > On Thu, 2018-02-15 at 15:25 +0100, Michael Schmid wrote: >> Hi everyone, >> >> after some off-list discussion and tests run by Philippe: >> >> The problem of unexpectedly poor performance on a Xeon 44-core >> machine >> only appears in Fiji, not in plain ImageJ. >> The problem is not limited to the "RankFilters" >> (Process>Filters>Mean, >> Median, Minimum, etc., everything that uses the "Circular Masks" for >> the >> neighborhood) but one can see parallelization problems also in other >> functions, though not as severe. >> >> From all the evidence, it seems that sometimes one core or a few >> cores >> are not available for processing for rather long time (at least >> milliseconds, probably they do something else during that period). >> This >> has especially bad consequences for the current RankFilters because >> they >> expect all threads to work continuously and eventually the other >> threads >> have to wait if one thread (core) is inactive. >> (Due to optimized memory access, the RankFilters parallelization >> strategy has been very fast on machines like the Core i5 that were >> popular at the time when I developed it, but it gets poor under such >> circumstances). >> >> So the question: What is different on Fiji vs. plain ImageJ, >> concerning >> threads? >> >> The problems could be explained e.g. slower switching between threads >> in >> case one core has to handle several threads, or by some background >> activity that does not happen in plain ImageJ. >> I suspect different java options in the Launcher of Fiji vs. plain >> ImageJ, but I know nothing about Fiji. >> >> >> Michael >> ________________________________________________________________ >> >> >> On 13/02/2018 12:01, Philippe Mailly wrote: >>> Hi, >>> Some new tests. >>> >>> If I run Fiji in 32bits the median filter speed is similar to >>> other >>> computers. >>> In 64bits, all 2D filters (median, mean, variance ....) on a image >>> stack >>> are very slow (40s) >>> Same type of filters in 3D (median3D, mean3D, variance 3D ...) take >>> only >>> 10s >>> >>> Philippe >>> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html *Philippe Mailly* /Phd, Research Engineer/ Imaging Core Facility CIRB, CNRS, UMR 7241/ INSERM 1050, Collège de France 11 place Marcelin Berthelot, 75005, PARIS, FRANCE -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html  2DMedian timesFiji1.51u_44CPU.tif (293K) Download Attachment 2DMedian timesImageJ1.51u_44CPU.tif (293K) Download Attachment 3DMedian timesFiji1.51u_44CPU.tif (293K) Download Attachment 3DMedian timesImageJ1.51u_44CPU.tif (293K) Download Attachment |
Re: very very very slow process (what is different in Fiji?)
|
|
Thanks! Have you tried other garbage collectors?
./fiji -Xmx8g -Xincgc -- ./fiji -Xmx8g -XX:+UseParallelGC -- ./fiji -Xmx8g -XX:+UseConcMarkSweepGC -- The last one is my favorite for working with BDV and lazy caches, but utilizes parallel threads, not sure what Fiji's defaults are at this time. Thanks, Stephan On Thu, 2018-02-15 at 16:50 +0100, Philippe Mailly wrote: > Yes as you can see on the plots. > > Philippe > > > Le 15/02/2018 à 15:43, Saalfeld, Stephan a écrit : > > > > Prime candidates: > > > > * parallel garbage collection > > * other JVM > > > > Have you tried to limit the number of threads to 1 or 2 less then > > the > > maximum number of processors if the number of available processors > > is > > very large? > > > > Thanks, > > Stephan > > > > > > > > On Thu, 2018-02-15 at 15:25 +0100, Michael Schmid wrote: > > > > > > Hi everyone, > > > > > > after some off-list discussion and tests run by Philippe: > > > > > > The problem of unexpectedly poor performance on a Xeon 44-core > > > machine > > > only appears in Fiji, not in plain ImageJ. > > > The problem is not limited to the "RankFilters" > > > (Process>Filters>Mean, > > > Median, Minimum, etc., everything that uses the "Circular Masks" > > > for > > > the > > > neighborhood) but one can see parallelization problems also in > > > other > > > functions, though not as severe. > > > > > > From all the evidence, it seems that sometimes one core or a > > > few > > > cores > > > are not available for processing for rather long time (at least > > > milliseconds, probably they do something else during that > > > period). > > > This > > > has especially bad consequences for the current RankFilters > > > because > > > they > > > expect all threads to work continuously and eventually the other > > > threads > > > have to wait if one thread (core) is inactive. > > > (Due to optimized memory access, the RankFilters parallelization > > > strategy has been very fast on machines like the Core i5 that > > > were > > > popular at the time when I developed it, but it gets poor under > > > such > > > circumstances). > > > > > > So the question: What is different on Fiji vs. plain ImageJ, > > > concerning > > > threads? > > > > > > The problems could be explained e.g. slower switching between > > > threads > > > in > > > case one core has to handle several threads, or by some > > > background > > > activity that does not happen in plain ImageJ. > > > I suspect different java options in the Launcher of Fiji vs. > > > plain > > > ImageJ, but I know nothing about Fiji. > > > > > > > > > Michael > > > ________________________________________________________________ > > > > > > > > > On 13/02/2018 12:01, Philippe Mailly wrote: > > > > > > > > Hi, > > > > Some new tests. > > > > > > > > If I run Fiji in 32bits the median filter speed is similar to > > > > other > > > > computers. > > > > In 64bits, all 2D filters (median, mean, variance ....) on a > > > > image > > > > stack > > > > are very slow (40s) > > > > Same type of filters in 3D (median3D, mean3D, variance 3D ...) > > > > take > > > > only > > > > 10s > > > > > > > > Philippe > > > > > > > -- > > > 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 |
Re: very very very slow process (what is different in Fiji?)
|
|
Re: very very very slow process (what is different in Fiji?)
|
|
Re: very very very slow process (what is different in Fiji?)
|
|
-Xmx785g
On Thu, 2018-02-15 at 17:12 +0100, Philippe Mailly wrote: > Hi Stephan, > > The computer on which I run the test have 1To of RAM memory should I > test with -Xmx8g or with -Xmx785g as it's configured in the Fiji > memory > and Threads options ? > > Philippe > > > > Le 15/02/2018 à 17:02, Saalfeld, Stephan a écrit : > > > > Thanks! Have you tried other garbage collectors? > > > > ./fiji -Xmx8g -Xincgc -- > > ./fiji -Xmx8g -XX:+UseParallelGC -- > > ./fiji -Xmx8g -XX:+UseConcMarkSweepGC -- > > > > The last one is my favorite for working with BDV and lazy caches, > > but > > utilizes parallel threads, not sure what Fiji's defaults are at > > this > > time. > > > > Thanks, > > Stephan > > > > > > On Thu, 2018-02-15 at 16:50 +0100, Philippe Mailly wrote: > > > > > > Yes as you can see on the plots. > > > > > > Philippe > > > > > > > > > Le 15/02/2018 à 15:43, Saalfeld, Stephan a écrit : > > > > > > > > Prime candidates: > > > > > > > > * parallel garbage collection > > > > * other JVM > > > > > > > > Have you tried to limit the number of threads to 1 or 2 less > > > > then > > > > the > > > > maximum number of processors if the number of available > > > > processors > > > > is > > > > very large? > > > > > > > > Thanks, > > > > Stephan > > > > > > > > > > > > > > > > On Thu, 2018-02-15 at 15:25 +0100, Michael Schmid wrote: > > > > > > > > > > Hi everyone, > > > > > > > > > > after some off-list discussion and tests run by Philippe: > > > > > > > > > > The problem of unexpectedly poor performance on a Xeon 44- > > > > > core > > > > > machine > > > > > only appears in Fiji, not in plain ImageJ. > > > > > The problem is not limited to the "RankFilters" > > > > > (Process>Filters>Mean, > > > > > Median, Minimum, etc., everything that uses the "Circular > > > > > Masks" > > > > > for > > > > > the > > > > > neighborhood) but one can see parallelization problems also > > > > > in > > > > > other > > > > > functions, though not as severe. > > > > > > > > > > From all the evidence, it seems that sometimes one core or > > > > > a > > > > > few > > > > > cores > > > > > are not available for processing for rather long time (at > > > > > least > > > > > milliseconds, probably they do something else during that > > > > > period). > > > > > This > > > > > has especially bad consequences for the current RankFilters > > > > > because > > > > > they > > > > > expect all threads to work continuously and eventually the > > > > > other > > > > > threads > > > > > have to wait if one thread (core) is inactive. > > > > > (Due to optimized memory access, the RankFilters > > > > > parallelization > > > > > strategy has been very fast on machines like the Core i5 that > > > > > were > > > > > popular at the time when I developed it, but it gets poor > > > > > under > > > > > such > > > > > circumstances). > > > > > > > > > > So the question: What is different on Fiji vs. plain ImageJ, > > > > > concerning > > > > > threads? > > > > > > > > > > The problems could be explained e.g. slower switching between > > > > > threads > > > > > in > > > > > case one core has to handle several threads, or by some > > > > > background > > > > > activity that does not happen in plain ImageJ. > > > > > I suspect different java options in the Launcher of Fiji vs. > > > > > plain > > > > > ImageJ, but I know nothing about Fiji. > > > > > > > > > > > > > > > Michael > > > > > _____________________________________________________________ > > > > > ___ > > > > > > > > > > > > > > > On 13/02/2018 12:01, Philippe Mailly wrote: > > > > > > > > > > > > Hi, > > > > > > Some new tests. > > > > > > > > > > > > If I run Fiji in 32bits the median filter speed is similar > > > > > > to > > > > > > other > > > > > > computers. > > > > > > In 64bits, all 2D filters (median, mean, variance ....) on > > > > > > a > > > > > > image > > > > > > stack > > > > > > are very slow (40s) > > > > > > Same type of filters in 3D (median3D, mean3D, variance 3D > > > > > > ...) > > > > > > take > > > > > > only > > > > > > 10s > > > > > > > > > > > > Philippe > > > > > > > > > > > -- > > > > > 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 |
Re: very very very slow process (what is different in Fiji?)
|
|
Here the plots. However, the option -XX:+UseParallelGC -- doesn't work it can't create a java virtual machine ?
Philippe ----- Mail original ----- De: "Saalfeld, Stephan" <[hidden email]> À: [hidden email] Envoyé: Jeudi 15 Février 2018 17:29:03 Objet: Re: very very very slow process (what is different in Fiji?) -Xmx785g On Thu, 2018-02-15 at 17:12 +0100, Philippe Mailly wrote: > Hi Stephan, > > The computer on which I run the test have 1To of RAM memory should I > test with -Xmx8g or with -Xmx785g as it's configured in the Fiji > memory > and Threads options ? > > Philippe > > > > Le 15/02/2018 à 17:02, Saalfeld, Stephan a écrit : > > > > Thanks! Have you tried other garbage collectors? > > > > ./fiji -Xmx8g -Xincgc -- > > ./fiji -Xmx8g -XX:+UseParallelGC -- > > ./fiji -Xmx8g -XX:+UseConcMarkSweepGC -- > > > > The last one is my favorite for working with BDV and lazy caches, > > but > > utilizes parallel threads, not sure what Fiji's defaults are at > > this > > time. > > > > Thanks, > > Stephan > > > > > > On Thu, 2018-02-15 at 16:50 +0100, Philippe Mailly wrote: > > > > > > Yes as you can see on the plots. > > > > > > Philippe > > > > > > > > > Le 15/02/2018 à 15:43, Saalfeld, Stephan a écrit : > > > > > > > > Prime candidates: > > > > > > > > * parallel garbage collection > > > > * other JVM > > > > > > > > Have you tried to limit the number of threads to 1 or 2 less > > > > then > > > > the > > > > maximum number of processors if the number of available > > > > processors > > > > is > > > > very large? > > > > > > > > Thanks, > > > > Stephan > > > > > > > > > > > > > > > > On Thu, 2018-02-15 at 15:25 +0100, Michael Schmid wrote: > > > > > > > > > > Hi everyone, > > > > > > > > > > after some off-list discussion and tests run by Philippe: > > > > > > > > > > The problem of unexpectedly poor performance on a Xeon 44- > > > > > core > > > > > machine > > > > > only appears in Fiji, not in plain ImageJ. > > > > > The problem is not limited to the "RankFilters" > > > > > (Process>Filters>Mean, > > > > > Median, Minimum, etc., everything that uses the "Circular > > > > > Masks" > > > > > for > > > > > the > > > > > neighborhood) but one can see parallelization problems also > > > > > in > > > > > other > > > > > functions, though not as severe. > > > > > > > > > > From all the evidence, it seems that sometimes one core or > > > > > a > > > > > few > > > > > cores > > > > > are not available for processing for rather long time (at > > > > > least > > > > > milliseconds, probably they do something else during that > > > > > period). > > > > > This > > > > > has especially bad consequences for the current RankFilters > > > > > because > > > > > they > > > > > expect all threads to work continuously and eventually the > > > > > other > > > > > threads > > > > > have to wait if one thread (core) is inactive. > > > > > (Due to optimized memory access, the RankFilters > > > > > parallelization > > > > > strategy has been very fast on machines like the Core i5 that > > > > > were > > > > > popular at the time when I developed it, but it gets poor > > > > > under > > > > > such > > > > > circumstances). > > > > > > > > > > So the question: What is different on Fiji vs. plain ImageJ, > > > > > concerning > > > > > threads? > > > > > > > > > > The problems could be explained e.g. slower switching between > > > > > threads > > > > > in > > > > > case one core has to handle several threads, or by some > > > > > background > > > > > activity that does not happen in plain ImageJ. > > > > > I suspect different java options in the Launcher of Fiji vs. > > > > > plain > > > > > ImageJ, but I know nothing about Fiji. > > > > > > > > > > > > > > > Michael > > > > > _____________________________________________________________ > > > > > ___ > > > > > > > > > > > > > > > On 13/02/2018 12:01, Philippe Mailly wrote: > > > > > > > > > > > > Hi, > > > > > > Some new tests. > > > > > > > > > > > > If I run Fiji in 32bits the median filter speed is similar > > > > > > to > > > > > > other > > > > > > computers. > > > > > > In 64bits, all 2D filters (median, mean, variance ....) on > > > > > > a > > > > > > image > > > > > > stack > > > > > > are very slow (40s) > > > > > > Same type of filters in 3D (median3D, mean3D, variance 3D > > > > > > ...) > > > > > > take > > > > > > only > > > > > > 10s > > > > > > > > > > > > Philippe > > > > > > > > > > > -- > > > > > 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 -- Philippe Mailly PhD, Ingénieur de Recherche CNRS Plateforme d'imagerie du CIRB, CNRS UMR 7241 / INSERM U 1050 Collège de France 11 Place Marcelin Berthelot, 75005, Paris, France -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html 2DMedian timesFiji1.51u_44CPU-Xmx780g-Xincgc.tif (293K) Download Attachment 2DMedian timesFiji1.51u_44CPU-Xmx780g-XXUseConcMarkSweepGC.tif (293K) Download Attachment |
Re: very very very slow process (what is different in Fiji?)
|
|
Re: very very very slow process (what is different in Fiji?)
|
|
Hi everyone (especially Fiji experts!),
the attachment shows an example of Fiji vs. plain ImageJ parallelization performance. For this, I have already changed the RankFilters (which doe the medain) to be less sensitive to cases where one thread gets stuck, otherwise the Fiji performance with a large number of processors would be even worse. In both cases, it runs at the default priority=4. Maybe the following information provides a few more clues: - The problem is found for a Windows 10 machine (two Xeon E5-2699 v4, 2*22 cores + hyperthreading, 1 TB) - No such problem on a slightly slower Windows 7 machine with Xeon E5-2630v3 processors (max. 32 threads), 64 GB RAM. It can't be a problem of the computer or Windows 10, however, because plain ImageJ works well, the poor parallelization performance occurs only under FIJI. So again, what could be different between plain ImageJ and Fiji? (At least in theory, thread scheduling, time slices, etc. should be done by the operating system, so the Win 10 vs. Win 7 difference should affect plain ImageJ and Fiji the same way). Michael ________________________________________________________________ On 19/02/2018 16:46, Michael Schmid wrote: > Hi everyone, > > after a bit of further analysis of the Fiji vs. ImageJ performance by > Philippe (supplemented by some ideas of mine): > > Parallelization performance is sometimes very different between plain > ImageJ and Fiji (this differs a lot between different filters/functions, > and strongly depends on the size of the data set). Many times, plain > ImageJ is better, sometimes Fiji. > Performance often differs between ImageJ and Fiji by factors of five or > more! > > The garbage collector seems to make no or not much difference. It seems > that usually it does nothing - no wonder when processing half-GB image > stacks on a machine with TB memory. > Startup options in Fiji's jvm.cfg only specify 'server' mode, but also > plain ImageJ runs a 'server' JVM. So also the jvm.cfg isn't responsible > for the differences. > > While the java version is the same for both, and both is Oracle java, > there is a difference between plain ImageJ and Fiji: > The java.home property is > for ImageJ: C:\Program Files\Java\jre1.8.0_162 > for Fiji: C:\Program Files\Java\jdk1.8.0_162\jre > > Also, the library paths etc. are different (pointing to somewhere in the > respective java.home folder): > java.ext.dirs > sun.boot.library.path > java.endorsed.dirs > > > Java experts out there, do you have any idea whether this could make the > difference how Java handles multithreading performance? > (e.g. things like scheduling different threads, etc.) > Are there java options to tweak it? > > > Michael > ________________________________________________________________ > On 15/02/2018 17:02, Saalfeld, Stephan wrote: >> Thanks! Have you tried other garbage collectors? >> >> ./fiji -Xmx8g -Xincgc -- >> ./fiji -Xmx8g -XX:+UseParallelGC -- >> ./fiji -Xmx8g -XX:+UseConcMarkSweepGC -- >> >> The last one is my favorite for working with BDV and lazy caches, but >> utilizes parallel threads, not sure what Fiji's defaults are at this >> time. >> >> Thanks, >> Stephan >> >> >> On Thu, 2018-02-15 at 16:50 +0100, Philippe Mailly wrote: >>> Yes as you can see on the plots. >>> >>> Philippe >>> >>> >>> Le 15/02/2018 à 15:43, Saalfeld, Stephan a écrit : >>>> >>>> Prime candidates: >>>> >>>> * parallel garbage collection >>>> * other JVM >>>> >>>> Have you tried to limit the number of threads to 1 or 2 less then >>>> the >>>> maximum number of processors if the number of available processors >>>> is >>>> very large? >>>> >>>> Thanks, >>>> Stephan >>>> >>>> >>>> >>>> On Thu, 2018-02-15 at 15:25 +0100, Michael Schmid wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> after some off-list discussion and tests run by Philippe: >>>>> >>>>> The problem of unexpectedly poor performance on a Xeon 44-core >>>>> machine >>>>> only appears in Fiji, not in plain ImageJ. >>>>> The problem is not limited to the "RankFilters" >>>>> (Process>Filters>Mean, >>>>> Median, Minimum, etc., everything that uses the "Circular Masks" >>>>> for >>>>> the >>>>> neighborhood) but one can see parallelization problems also in >>>>> other >>>>> functions, though not as severe. >>>>> >>>>> From all the evidence, it seems that sometimes one core or a >>>>> few >>>>> cores >>>>> are not available for processing for rather long time (at least >>>>> milliseconds, probably they do something else during that >>>>> period). >>>>> This >>>>> has especially bad consequences for the current RankFilters >>>>> because >>>>> they >>>>> expect all threads to work continuously and eventually the other >>>>> threads >>>>> have to wait if one thread (core) is inactive. >>>>> (Due to optimized memory access, the RankFilters parallelization >>>>> strategy has been very fast on machines like the Core i5 that >>>>> were >>>>> popular at the time when I developed it, but it gets poor under >>>>> such >>>>> circumstances). >>>>> >>>>> So the question: What is different on Fiji vs. plain ImageJ, >>>>> concerning >>>>> threads? >>>>> >>>>> The problems could be explained e.g. slower switching between >>>>> threads >>>>> in >>>>> case one core has to handle several threads, or by some >>>>> background >>>>> activity that does not happen in plain ImageJ. >>>>> I suspect different java options in the Launcher of Fiji vs. >>>>> plain >>>>> ImageJ, but I know nothing about Fiji. >>>>> >>>>> >>>>> Michael >>>>> ________________________________________________________________ >>>>> >>>>> >>>>> On 13/02/2018 12:01, Philippe Mailly wrote: >>>>>> >>>>>> Hi, >>>>>> Some new tests. >>>>>> >>>>>> If I run Fiji in 32bits the median filter speed is similar to >>>>>> other >>>>>> computers. >>>>>> In 64bits, all 2D filters (median, mean, variance ....) on a >>>>>> image >>>>>> stack >>>>>> are very slow (40s) >>>>>> Same type of filters in 3D (median3D, mean3D, variance 3D ...) >>>>>> take >>>>>> only >>>>>> 10s >>>>>> >>>>>> Philippe >>>>>> >>>>> -- >>>>> 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 |
Re: very very very slow process (what is different in Fiji?)
|
| Free forum by Nabble | Edit this page |