Posted by
Stein Rørvik on
URL: http://imagej.273.s1.nabble.com/Directional-dependence-of-re-slicing-speed-tp5023999p5024011.html
I had a look at the source code today as found on
https://raw.githubusercontent.com/imagej/imagej1/master/ij/plugin/Slicer.javaand 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.
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