Web App - initial ideas

I’m exploring the idea of making an ImageJ Web App for a school project.

I have a few few initial questions that would help me get my bearings.

Given that ImageJ and OMERO can be used together, is a Web App really a necessity?
Where should I start and what do you think would be the biggest challenges? Will I be working with SCIFIO and SciJava more than with ImageJ itself?

I’ve done some reading about ImageJ (imagej.net: development, architecture, this post, …) but still don’t have the grasp about the whole thing, so it would be great if you could point me in some direction.

Thank you

I think that is quite ambitious for a school project, especially over the course of a single semester.

We are planning a RESTful image server; see imagej/imagej-server#1 for some discussion. I am planning to work on this seriously later this fall. Maybe the timing is actually good—you could work on the client side javascript/browser UI, while I work on the backend? What do you think? How many hours would you have to devote to the project?

Definitely still necessary. The ImageJ-OMERO integration is nice for client- and server-side ImageJ/OMERO integration, but does not solve other use cases. For example, my primary use case for the RESTful image server is to integrate ImageJ with CellProfiler, which is written in Python, without CP needing to spin up an in-process JVM anymore. My secondary use case is to begin enabling more client-server usages of ImageJ in general, such as client-side mobile apps. A javascript UI for ImageJ would go a very long way toward this goal.

Just to clarify the difference between OMERO and an “ImageJ server”:

  • OMERO is a full-blown data management platform with many dependencies which (ideally) requires a dedicated sysadmin to install and maintain. The main idea there is that you can have a central place where your lab puts all their data. Analysis functions in OMERO are secondary—it provides a framework for them, but not a full-featured built-in analysis suite.

  • Conversely, the ImageJ server is (will be) a lightweight stack (built on Dropwizard) with no external dependencies apart from Java, which spins up and down in a matter of seconds. The main idea is to allow for non-Java programs to quickly and easily interface with the ImageJ API regardless of language, and across the network. The ImageJ server will have no support for data storage and management—you’ll still have to figure out where and how to store your images; you could combo it with something like ownCloud, but that would be a separate thing. Or you could of course combo it with OMERO, via the aforementioned ImageJ-OMERO integration. Analysis functions in ImageJ are primary—it is really trying to provide a large suite of image analysis routines, as well as an extensible framework for the community there.

There are several challenges. Primarily:

  1. On the server side, getting the details of the RESTful endpoints right
  2. On the client side, the actual work of implementing a javascript UI which utilizes those endpoints.

For (2), it will be very easy to expose all available ImageJ2 commands in some kind of menu structure/hierarchy. The tricky part is designing a nice 21st century UI that the majority of people find friendly right off the bat, while still providing the shortcuts needed by the power users to get things done efficiently. People have many different schools of thought on what makes a good UI (see e.g. ImageJFX, Icy, BioImageXD and of course the ImageJ 1.x UI).

One other point, regarding Java applets (since you linked to the forum post discussing running ImageJ as an applet): it is becoming increasingly clear that despite Oracle’s efforts, Java applets are a dying technology. Chrome has stopped supporting them. And Java Web Start is not much better. Of course, you could create a web page which launches ImageJ via Java Web Start, but honestly it would be rather crappy usability-wise, and would bring basically nothing to the table from a utility perspective. The client-server approaches I discuss above will be vastly superior, and more future-proof.

Can you tell us more about your focus in school? Is UI design relevant to your studies? Or are you more interested in the image processing side?


Thank you so much for your thorough reply.

I’m currently enrolled in a Bioinformatics masters and this will be my final project, so I’ll be working on this almost exclusively for the next 10 months.

Together with my advisor, we’ve been trying to find a trade-off between which topics to explore and the time available.
I understand how important it would be to have a working client but unfortunately UI design isn’t one of my favourite topics of development, and I am really interested in working on distributed image processing, for example I am interested in developing a methodology to load data “on demand”, i.e. allowing us to work with large datasets on clients with a limited amount of storage available.

We are very interested in collaborating with you / ImageJ community and work out something useful to you that we can focus on.

1 Like

@gfigueiro I apologize for dropping the ball on this conversation till now.

To give you a brief status update on the imagej-server project: thanks to the efforts of @lyang, it is working very well now. There is a demo command line Python client, and also a prototype web client written in javascript.

What did you end up coming up with for your project? Anything you are able to share with the ImageJ community?