Posted by
Stein Rørvik on
Oct 07, 2020; 10:47pm
URL: http://imagej.273.s1.nabble.com/Directional-dependence-of-re-slicing-speed-tp5023999p5024003.html
I have the same problem, and discovered the same workaround (rotating first) by accident a few weeks ago when I was testing CLIJ2 for reslicing.
You may find this thread on the image.sc forum of interest:
https://forum.image.sc/t/running-clij2-macros-from-imagej-1-5x/42832/17?u=steinrThe speed using CLIJ2 (a plugin that can run selected equivalents of ImageJ commands on the GPU) is quite impressive; here are my benchmarks from the thread:
------------------------------------------------
Stack size: 2000x2000x1000
...
Time for ImageJ Reslice Left-Right: 242.763
Time for ImageJ Reslice Top-Bottom: 16.165
...
Time for CLIJ2 (Quadro M5000M) Reslice Left-Right: 0.694
Time for CLIJ2 (Quadro M5000M) Reslice Top-Bottom: 0.08
------------------------------------------------
Also, CLIJ2 now works fine as a plugin in ImageJ 1.x using a very simple workaround, please see the first posts in the thread. CLIJ2 is also much slower when reslicing left-right compared to top-bottom, but it is already so fast that it does not matter much.
Unfortunately CLIJ2 does not work for me in most cases, as the datasets I work with are normally 2000x2000x2000 16 bit voxels and are thus too large to fit in my 8GB of GPU memory. And CLIJ2 lacks the "flip vertical" option that I always need, as my data always starts (first slice) at the physical bottom of the real-world data.
So I am also interested in a "fix" for the current ImageJ reslice left-right code. I had a look at the source code some time ago but found it too complex to see where the problem is, as the reslice code is quite advanced and has a lot of options for interpolation and skewed selections. What we are lacking is some further optimization of the code in those cases when we are just moving (transposing) data without any interpolation.
Stein
-----Original Message-----
Sent: 7. oktober 2020 14:03
Subject: Directional dependence of re-slicing speed
Greetings,
My group uses ImageJ to process TIFF optical coherence tomography data and we do a lot of re-slicing of stacks. One thing that is always a pain is that re-slicing from the right or the left takes a tremendous amount of time compared to re-slicing from the top or bottom. A colleague discovered the workaround that rotating the stack 90 degrees, slicing from the "top", and then de-rotating the stack has the exact same effect as slicing from the side at a fraction of the required time. Would it be reasonable to adapt this "workaround" into the actual re-slice function? Is there any reason why doing so might be no-go? I would generally be willing to work on such a change, but to be frank, I'm not a Java person and I have no experience with the ImageJ codebase. I would much prefer to submit the idea to an official wishlist if there is one.
Thanks for your input.
Sincerely,
Conner
--
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html