This is a RESTful image server backed by ImageJ.
To provide easy-to-use and highly reusable image processing functionalities is a central goal of ImageJ. As a result, the components of ImageJ are modular, to make them easily accessible from other Java programs. However, for programs written in other languages besides Java, the interaction becomes complicated. In order to mitigate this problem, this RESTful image server is offered as a universal interfacing layer.
See the Rationale page of this repository's wiki for a longer discussion of cross-language integration and interoperability.
This is currently only a prototype! Testing needed!
The server can run with a graphical display, or in headless mode.
- With a graphical display, remote commands can affect the ImageJ graphical user interface (GUI). E.g., images can be displayed to the user.
- In headless mode, there is no GUI. E.g., in a cluster computing environment, each node can have its own local ImageJ Server instance.
There are several ways to invoke the server:
If ImageJ is already running
- Use Plugins › Utilities › Start Server to make ImageJ start listening for remote commands.
- Use Plugins › Utilities › Stop Server to shut down the server. The local ImageJ will continue running.
You must enable the Server update site first.
Launch via jgo
The jgo launcher makes it easy to launch the ImageJ Server. No need to explicitly clone the repository or download any JARs.
After installing jgo, add the following stanza to your ~/.jgorc
file:
[repositories]
imagej.public = https://maven.imagej.net/content/groups/public
Then invoke the server with a graphical display as follows:
jgo net.imagej:imagej-server
Or in headless mode:
jgo -Djava.awt.headless=true net.imagej:imagej-server
Launch from CLI via Maven
Clone this repository. Then start the server from the CLI in headless mode:
mvn -Pexec
Launch from IDE
Clone this repository, import the project, then run the class
net.imagej.server.Main
. The server will launch in headless mode.
Launch via the ImageJ Launcher
Enable the Server update site.
Then launch ImageJ with a graphical display:
./ImageJ --server
Or in headless mode:
./ImageJ --server --headless
See also the ImageJ Launcher documentation.
Including additional plugins
If you want to make additional ImageJ plugins (e.g. plugins from Fiji) available remotely, you can include the additional components on the runtime classpath.
One easy way is via the jgo
-based launch mechanism with the +
syntax.
For example:
jgo sc.fiji:fiji+net.imagej:image-server
Another way is make your own Maven project depending on
net.imagej:imagej-server
and other things, with a main
entry point
that invokes net.imagej.server.Main.main(String[])
.
The pyimagej module includes a Python wrapper for the web API.
A collection of sample API calls to imagej-server using Postman.
Installation
- Check that you have got Node.js and npm installed (instructions).
- Open a command prompt, navigate to
clients\webNew
and runnpm install
. This will install all required Node.js packages.
Compilation and execution (development)
- Open a command prompt, navigate to
clients\webNew
and runnpm start
. - Open a web browser and navigate to
localhost:4200
.
- GET /modules
Returns a list of modules. By default, imagej-server exposes its API at localhost:8080
, which will be used throughout this documentation.
$ curl localhost:8080/modules
- GET /modules/{id}
Returns detailed information of a module specified by {id}
. Notice that {id}
could contain special characters such as dollar sign ($
), which needs to be escaped when using cURL
.
$ curl localhost:8080/modules/'command:net.imagej.ops.math.PrimitiveMath$IntegerAdd'
- POST /modules/{id}?process={process}
Executes a module with with JSON inputs. Use the module details to determine the correct input keys. The optional query parameter process
determines if the execution should be pre/post processed.
$ curl -XPOST -H "Content-Type: application/json" -d '{"a":1,"b":3}' \
> localhost:8080/modules/'command:net.imagej.ops.math.PrimitiveMath$IntegerAdd'?process=false
{"result":4}
- GET /objects
Lists all object IDs available on imagej-server.
$ curl localhost:8080/objects
- GET /objects/{id}
Shows the information of an object.
$ curl localhost:8080/objects/object:1234567890abcdef
{"class":"net.imagej.DefaultDataset","created_at":"Sun Jan 01 00:00:00 CST 2017"}
- DELETE /objects/{id}
Delete one object from imagej-server.
$ curl -XDELETE localhost:8080/objects/object:1234567890abcdef
- POST /objects/upload?[type={type}]
Uploads a file to server. A 16-bit lowercase alphanumeric ID prefixed with object:
will be returned as a JSON string. The ID can be used in module execution to represent the file. Currently only supports uploading images and tables in text. An optional query parameter type
could be provided as hint to file type. If it is empty, filename would be used for guessing.
$ curl -F "file=@src/test/resources/imgs/about4.tif" localhost:8080/objects/upload
{"id":"object:0123456789abcdef"}
- GET /objects/{id}/{format}?[&key={value}]...
Download an object in some specific format from the server. Optional query parameters will be used for configuration depending on the type of the object.
$ curl localhost:8080/objects/object:0123456789abcdef/png
- DELETE /admin/stop
Stop the imagej-server gracefully without shutting down the imagej runtime.
curl -XDELETE localhost:8080/admin/stop
- DefaultObjectService effectively prevents garbage collection of all objects produced during the lifetime of this imagej-server instance, which could lead to serious memory issues. The timestamped object ID could be used to determine if an object should "expire" on a regular basis or when memory runs low.
- Ops that need to be initialized are not working when run as module. See the HACK in
ModulesResource
- The converters from
Number
toNumericType
could be refined and considered moving to other projects such as SciJava. - It might be a good idea for the client to provide optional language-neutral type information for module execution, so that we can support more complex data structures without too much guessing. This would also solve the problem of nested special object (i.e.
List<Integer>
could not be converted intoList<IntType>
even with converter betweenInteger
andIntType
). - What test framework should be used?
- Might need to add logging/debug info
- The module information should be improved. The inputs outputs names are not very informative.
- The current design of setting inputs/getting outputs could easily break if those names are changed. Should we just assume they will never change, or should those libraries (i.e. Ops) also take care of all the client implementation?