TransformJ Rotate or other plugin: faster calculation (multithreaded)?

[Guenter Giese]

Dear list members,

Dear Erik,

 

for arbitrary xyz rotation of whole 16bit xyz microscopic datasets (up to
100GB) we use a Xeon 32-core / 512GB RAM  compute server running Fiji 64bit
on Ubuntu Linux.

 

The TransformJ Rotate plugin by Erik Meijering does the arbitrary rotation
job (high quality interpolation), but seems to work single-threaded / quite
slow.

 

-          Is there a way to run this plugin multithreaded?

 

-          is there another plugin doing this job faster / multithreaded?

 

Best,

 

Guenter

 

 

Dr. Guenter Giese
Light Microscopy Facility Manager
Dept. of Biomedical Optics
MPI fuer Medizinische Forschung
D-69120 Heidelberg, Germany
phone  xx49 or 0 -6221-486-360  fax -325
e-mail:  <mailto:[hidden email]>
[hidden email]

 


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Erik Meijering]

Dear Guenter,

My plan is to add support for multicore processing in the next version. For the moment, while a single process is currently not multithreaded, you could still run things in parallel when batch processing many images (one thread per image).

Best regards,

Erik

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Erik,

On Fri, 15 Mar 2013, Erik Meijering wrote:

> My plan is to add support for multicore processing in the next version.
> For the moment, while a single process is currently not multithreaded,
> you could still run things in parallel when batch processing many images
> (one thread per image).

How about combining forces? ImgLib2 already has multi-threading
capabilities and it should be relatively easy to avoid duplicating work
there (ImgLib2 requires transformations -- even non-affine ones --
anyway).

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Erik,

On Sat, 16 Mar 2013, Erik Meijering wrote:

> Good point. I will consider this.

Thank you.

> But I think it will be considerably more work to rewrite my algorithms
> for another API (or even integrate them in another lib) than to add
> multithreading to them (the latter should be peanuts).

Sure, it is just a little patch. But it incurs a technical debt by
continuing to duplicate work. And worse: divergent work. Would it not be
grand if you could just use Imglib2 algorithms and ImageScience algorithms
in succession?

> Hopefully I have time to look into this starting next month (after some
> major grant deadlines).

Good luck with the deadlines, and hope to hear from you about ideas how to
combine efforts!

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html