Login  Register

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