Fiji and Elastix : opinions and advice about using a client / server solution?

Hello!

So I’ve been working on this project for a while now:

In it, I need to call elastix 5.0.1 (GitHub - SuperElastix/elastix: Official elastix repository) for automated registration. Elastix has to be installed as an executable binary on the user computer before the fiji plugin can work + it requires some minimal configuration. ( like in this wrapper by @Christian_Tischer : GitHub - embl-cba/elastixWrapper )

On Mac OS, I had a lot of trouble making the elastix binary work (an extra library is difficult to link, and in fact I couldn’t suceed on some computer). Also on some Mac, a security warning appears preventing Java from executing external binary (which is understandable). On some linux distributions, some libraries are too old and elastix simply cannot run.

So I was thinking : why not offering the possibility to execute the registration task on a server ? Then you can centralize the burden of the server installation at your IT department - or maybe it’s possible to provide a fully public registration server if the load is not too high. Then many users can use the same registration server, and the install just requires to set the server address, (ease of installation + more security for the client computer). I did some initial test and it seems to work.

I’m not familiar at all with client / server stuff, so I’d like to hear from knowledgeable people. Is this a good idea ? Are there some obvious pitfalls that I’m not aware of ?

Nico

@Christian_Tischer @bogovicj @imagejan

2 Likes

You are aware of it, but I guess that’s the main issue: uploading big images to the server :slight_smile:

In general, maybe you could try contacting the CellPose developers, they should have some experience http://www.cellpose.org/

2 Likes

Right! My idea was to do handle tiny images (limited to a few Mb per image) only, and reject bigger images. In fact for my use case all images are 2D and with pixels dimension 320x240. That’s why it’s well suited for “remote computing”. But I think it can still be useful by bigger images: you register a downsampled version of your image and apply the transform to the full resolution image - performing the heavy computing on the client side only.

1 Like

Really cool @NicoKiaru , thanks for showing this off!

How complicated was it to set up the server? Do you think a moderately tech-savvy person get it done within a day?

John

What about a container-based solution?

Do you think a moderately tech-savvy person get it done within a day?

Setting up the server is like setting up bigdataserver (BigDataServer - ImageJ) - I use the same repo for http communication (jetty). Setting up the server is complicated if you want to make it public and secure, I guess. But I tried on amazon web services, and it was easy enough, but it’s expensive…

Sure, what is that :sweat:? But then the server runs on the client ? Is it easy to install ?

If the problem is distribution of elastix binaries, you could instead distribute it as a container. On macOS, this would require that the user install Docker desktop app (or Singularity desktop app if you go with singularity).

Ok! My main goal is the following: activating the plugin update site is the only thing required to test it - no extra install step. Then, only when you’re happy with the plugin and want more performance, you’ll have the possibility to install elastix locally (or with a Docker).

Also, here I’m just thinking out loud, but I’d like to mention this idea and get some feedback: if the user agree, the registration server (a global one or the one of your institution) could keep in memory some result from registration requests. In theory, keeping some computation results could be used in order to improve the plugin and the registration parameters “a posteriori”. Do you think it’s a good or terrible idea ? Maybe yes on some condition, or never ever ?

Nicolas

I don’t know enough about the process but questions I would ask first: is caching computation worth the data management effort? How often is this going to be useful and to what extent (e.g. what’s the gain in speed and/or accuracy)?

Part of the registration is manual, in order to reach a good first guess. This is the part I’d like to facilitate by gathering which task fails and which suceeds. Essentially, the goal is to find a fast way of knowing if it’s worth executing an ‘heavy’ registration task. The data to keep is small because I’m working on strongly downsampled images (~ 100ko per image).

Beyond the gain in accuracy and use, the part I’m worried about is related to the users. Do you think it would be ok to collect data as an opt-in option, and then stating clearly the goal to the user?

I think offering it as an opt-in option to users is fine.