Posted by
Curtis Rueden-2 on
Oct 08, 2020; 12:21am
URL: http://imagej.273.s1.nabble.com/Directional-dependence-of-re-slicing-speed-tp5023999p5024004.html
Hi,
Using ImgLib2, you can quickly create resliced views of your data. For
example, here is a Groovy script that pops up a left-right sliced view of
an image stack:
#@ Img img
#@ UIService ui
import net.imglib2.view.Views
v = Views.permute(img, 1, 2) // XYZ -> XZY
v = Views.permute(v, 0, 2) // XZY -> YZX
ui.show(v)
With a 1500x1500x500 8-bit ramp on my system, the Left Reslice operation
took 30 seconds, whereas popping up the view as a virtual stack took <2
seconds. If your workflow is compatible with virtual stacks, this might
save you some time and memory.
If you need a non-virtual image, you can then create a new ImagePlus, wrap
it to ImgLib2, and copy the view into the new image, which takes ~15
seconds on my system. Here is a Groovy script:
#@ Img img
#@output result
import net.imglib2.view.Views
import net.imglib2.util.ImgUtil
import net.imglib2.img.ImagePlusAdapter
v = Views.permute(img, 1, 2) // XYZ -> XZY
v = Views.permute(v, 0, 2) // XZY -> YZX
int w = v.dimension(0)
int h = v.dimension(1)
int d = v.dimension(2)
result = ij.IJ.createImage("resliced", w, h, d, 8)
dest = ImagePlusAdapter.wrap(result)
ImgUtil.copy(v, dest)
Regards,
Curtis
--
Curtis Rueden
Software architect, LOCI/Eliceiri lab -
https://loci.wisc.edu/softwareImageJ2 lead, Fiji maintainer -
https://imagej.net/User:RuedenHave you tried the Image.sc Forum?
https://forum.image.sc/On Wed, Oct 7, 2020 at 5:50 PM Stein Rørvik <
[hidden email]> wrote:
> I have the same problem, and discovered the same workaround (rotating
> first) by accident a few weeks ago when I was testing CLIJ2 for reslicing.
>
> You may find this thread on the image.sc forum of interest:
>
>
https://forum.image.sc/t/running-clij2-macros-from-imagej-1-5x/42832/17?u=steinr>
> The speed using CLIJ2 (a plugin that can run selected equivalents of
> ImageJ commands on the GPU) is quite impressive; here are my benchmarks
> from the thread:
> ------------------------------------------------
> Stack size: 2000x2000x1000
> ...
> Time for ImageJ Reslice Left-Right: 242.763
> Time for ImageJ Reslice Top-Bottom: 16.165
> ...
> Time for CLIJ2 (Quadro M5000M) Reslice Left-Right: 0.694
> Time for CLIJ2 (Quadro M5000M) Reslice Top-Bottom: 0.08
> ------------------------------------------------
> Also, CLIJ2 now works fine as a plugin in ImageJ 1.x using a very simple
> workaround, please see the first posts in the thread. CLIJ2 is also much
> slower when reslicing left-right compared to top-bottom, but it is already
> so fast that it does not matter much.
>
> Unfortunately CLIJ2 does not work for me in most cases, as the datasets I
> work with are normally 2000x2000x2000 16 bit voxels and are thus too large
> to fit in my 8GB of GPU memory. And CLIJ2 lacks the "flip vertical" option
> that I always need, as my data always starts (first slice) at the physical
> bottom of the real-world data.
>
> So I am also interested in a "fix" for the current ImageJ reslice
> left-right code. I had a look at the source code some time ago but found it
> too complex to see where the problem is, as the reslice code is quite
> advanced and has a lot of options for interpolation and skewed selections.
> What we are lacking is some further optimization of the code in those cases
> when we are just moving (transposing) data without any interpolation.
>
> Stein
>
> -----Original Message-----
> Sent: 7. oktober 2020 14:03
> Subject: Directional dependence of re-slicing speed
>
> 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.
>
> Thanks for your input.
>
> Sincerely,
> Conner
>
>
> --
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html