Login  Register

Re: Directional dependence of re-slicing speed

Posted by Wayne Rasband-2 on Oct 11, 2020; 3:20pm
URL: http://imagej.273.s1.nabble.com/Directional-dependence-of-re-slicing-speed-tp5023999p5024013.html

> On Oct 11, 2020, at 8:49 AM, Stein Rørvik <[hidden email]> wrote:
>
> I had a look at the source code today as found on https://raw.githubusercontent.com/imagej/imagej1/master/ij/plugin/Slicer.java
> and compiled the file as a plugin to see what effect the reading order had on my images.
>
> I tried to selectively disable the reading and writing of data per row/column, and found out that it had quite little effect; reslice left-right was equally slow compared to top-down both when returning a zero instead of a reading a pixel, and doing nothing instead of writing data to the result stack.
>
> With few possibilities left, I simply removed the fancy yellow-line-on-image-progress-update functionality, and it got _a lot_ faster, the speedup is 10-20 times.

The Re-slice command in the ImageJ 1.53f32 daily build uses an ordinary progress bar when called from a macro, which is faster on Windows but not on MacOS.

-wayne

> Here are some benchmarks; I scaled the T1 stack by various factors:
>
> [128 x 128 x 65; 16-bit] t1-head.tif scaled x0.5
> Original Reslice Top... 2.222 s
> Original Reslice Left... 6.568 s
> Modified Reslice Top... 2.06 s
> Modified Reslice Left... 2.071 s
>
> [256 x 256 x 129; 16-bit] t1-head.tif scaled x1
> Original Reslice Top... 2.693 s
> Original Reslice Left... 20.273 s
> Modified Reslice Top... 2.107 s
> Modified Reslice Left... 2.15 s
>
> [512 x 512 x 258; 16-bit] t1-head.tif scaled x2
> Original Reslice Top... 4.789 s
> Original Reslice Left... 76.842 s
> Modified Reslice Top... 2.389 s
> Modified Reslice Left... 3.176 s
>
> [1024 x 1024 x 516; 16-bit] t1-head.tif scaled x4
> Original Reslice Top... 13.28 s
> Original Reslice Left... 236.106 s
> Modified Reslice Top... 4.927 s
> Modified Reslice Left... 11.994 s
>
> [2048 x 2048 x 1032; 16-bit] t1-head.tif scaled x8
> Original Reslice Top... 44.946 s
> Original Reslice Left... 526.485 s
> Modified Reslice Top... 66.22 s
> Modified Reslice Left... 94.751 s
>
> The only change I did in the java code was this, in line 436:
>
> //if (isStack) drawLine(x1, y1, x2, y2, imp);
> IJ.showProgress(i, outputSlices);
>
> So there must be a bug in drawLine ?
> I don't understand why drawing a vertical overlay line should be slower than a horizontal?
>
> Stein
>
> -----Original Message-----
> Sent: 11. oktober 2020 05:18
> Subject: Re: Directional dependence of re-slicing speed
>
>> 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