http://imagej.273.s1.nabble.com/Directional-dependence-of-re-slicing-speed-tp5023999p5024017.html
> Thanks, works as advertised.
> You write ".. which is faster on Windows but not on MacOS”
MacOS does not have the slow transparent line drawing problem.
> Do you mean that it is still slow on MacOS, or that it was already fast on MacOS, so this is a Windows only problem?
> For those who are used to using the "/" shortcut at the numeric keypad for reslice, this little wrapper macro in StartupMacros.ijm should do the trick, to get the faster behaviour also when using the GUI:
The 1.53f34 daily build always uses the standard progress bar on Windows.
> macro "Reslice [n/]" {
> run("Reslice [/]...", "");
> }
>
> I looked closer at the code and found that the problem is due to the transparency of the color:
> g.setColor(new Color(1f, 1f, 0f, 0.4f));
> If we replace this with a solid yellow
> g.setColor(new Color(1f, 1f, 0f, 1f));
> the yellow line progress runs as fast as without the lines, but of course covering the image.
>
> Apparently the mechanism used to render this transparency gets slower and slower the more pixels are covered, and that this slowness increases much more in the vertical than in the horizontal direction.
> Shortening the length of the transparent line also speeds up the reslice.
>
> Anyway, the solution in 1.53f32 works fine for me, since it is macro execution time that matters, and it is easy to wrap for use in the GUI.
>
> Stein
>
> -----Original Message-----
> Sent: 11. oktober 2020 17:21
> Subject: Re: Directional dependence of re-slicing speed
>
>> 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