Re: Directional dependence of re-slicing speed
Posted by
Wayne Rasband-2 on
Oct 11, 2020; 3:18am
URL: http://imagej.273.s1.nabble.com/Directional-dependence-of-re-slicing-speed-tp5023999p5024008.html
> On Oct 7, 2020, at 8:02 AM, Phillips, Conner <
[hidden email]> wrote:
>
> 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.
It appears that re-slicing from the “left” or “right” is slower because the pixels are not read consecutively from memory. I did some testing and found that this code
for (int y=0; y<h; y++)
for (int x=0; x<w; x++)
sum += ip.get(x,y);
which reads the pixels along each line of the image consecutively, runs up to eight times faster (with 16000x16000 image) than this code
for (int x=0; x<w; x++)
for (int y=0; y<h; y++)
sum += ip.getf(x,y);
which does not read the pixels consecutively. There is little difference in speed with images up to 1000x1000 in size.
I would prefer not to implement the rotation work around because it would make re-slicing slower for stacks with smaller slices and it could introduce bugs.
-wayne
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html