/params/ directory. Most of the input parameters are derived from your module specification file we will discuss below. An example for a
WFE_INPUT_JSONstring would look something like this at runtime:
JSON_Read.jsscript contains one short function
readJSONthe whole script works as follow:
callargument will be the json key we are calling to get the associated value
variablethat contains the path to the WFE json file
getArgument()function will catch the paramter we supply when calling this script from our main ImageJ Macro
setting.[the json key you want to querry]in this case the key
WFEOUTPUTnow contains the value i.e. tha path where you should store the output json file for your module.
CallLog.classif you want to make changes you need to generate the class file yourself from the
generate_stack.ijm. We will go through it block by block, you can either copy paste it from each section into one complete *.ijm file or copy and paste the code snippet given below.
BATCHMODEvariable to conveniently trigger ImageJ to batchmode (i.e. this prevents most UI outputs)
/params/WFE_input_params.jsoninside of the if block we make sure if the files exists and stop the macro of we can't access the file
INPUTFILESand then using the ImageJ macro function to execute a script i.e. the
runMacrocommand. In our case we use
runMacro(JSON_READER, "settings.input_files");i.e. executing the
JSON_Read.jsand using the argument _settings.input_files. Remember we stored the
_WFE_input_params.jsonin the settings variable so all keys can now be accessed by the "." syntax.
main()macro function we extract the path of the input files from the file list. We need to do this because we want to access the folder where all input files are stored. During the execution of a workflow the WFE puts all the files into a specific folder for the particular step. By reading the first file of the input list (i.e
settings.input_files) we have the path and using two ImageJ string functions (
substring) we extract the input path.
currentTimeis defined later but gives you the system time for the log. Batchmode is set to true in the if-statement
_run("Close All");is an ImageJ macro function that closes all remaining open windows
eval("script", "System.exit(0);");forces ImageJ to quit. This method give better results then the equivalent
run("Quit");. Using _run("Quit"); in the virtual framebuffer environment produces a Java error.
savingStack(). Both are simple functions called from the
main()part of the macro.
importData()we output some log text, then use an if/else block to use one of the json parameters from the module specification to decide whether we supply the Image Sequence with some additional parameters or not
run("Image Sequence...")to open all files in the input directory
savingStack()then uses the same logic to save the resulting image stack as tiff.
jsonOut()function is containing the block of statements that writes the required output specifications of your module
json_out.txtfile and fill it with the required output specifications in JSON format since ImageJ macros cannot directly output json we print the syntax manually
json_out.txtfile and rename it according the the WFE specification. Remember the variable
WFEOUTPUTcontains the parameter for this file as dictated by the
WFE_output_params_filekey from the WFE json file we read out in the beginning of the macro.
currentTime()is not strictly necessary and was taken from ImageJ Macro repository it is used to translate the system time into user readable format and use it during the log outputs. It is not strictly necessary and just used for convenience.
Dockerfilefor this ImageJ module. In this file we specify what the container for our module should include.
FROMcommand and specifying the container image. Here we are using a container we already build based on a Linux image, adding Java and ImageJ
RUNcommands that will execute linux command in the Docker container to add additional software packages we need for the Xvfb environment
COPYwe then add all additional files we need into the Docker container here these are all files discussed during the tutorial. The logic similar to the standard
cpcommand where you need to supply the local file and the location where it should be copied to. Here, you can also add your plugins, e.g. to use the additional ImageJ plugin "Extended Depth of Field", you need to download the plugin package from the home page of the plugin, unzip it, place the folder in the module folder and add this line to the
COPY ./EDF /Fiji.app/plugins/EDF.
VOLUMEcommand we specify the additional directories that are going to be mounted later by the for exposing files to and from the container. This is WFE convention and will always be the same
ENTRYPOINTfor the Docker container. The entrypoint is the command executed during the start of the container. Here we execute a shell script once the container starts
ENTRYPOINTparameter. On our example we execute a shell script
start.shthat contains the following command below. In essence we start ImageJ with the argument to run our macro script In addition we start the virtual frame environment so that ImageJ can output potential graphical elements into the virtual screen.
module_specification.jsonfile. The filename is WFE convention. Without this file the platform will not generate you module. Below is the JSON for this module:
module_specification.jsonconsists of two part the
specblock and the
uiblock. You will recognize that the parameters in the
specpart are the same we saw in the initial workflow engine file (
WFE_INPUT_JSON.json) at the beginning of this tutorial. The reason is that the WFE takes your module specification. If a workflow runs this information is used to send the input parameters you specified to your module so it is up to you which parameters your module accepts, how they are called and which types they are.
spec: Here you define the input parameters that your module accepts and also generates. You need to define the key:values according to the json syntax.
input_filesand give it the type
list[files]. This means the module can accept a list of filenames and the WFE will send the path to all files generated by the previous module with the variable.
stringand also supply a default parameter. If no other information is send during workflow execution the
prefixwill contain the string "no-filter".
inputsyou also need to tell the WFE what type of outputs your module generates. Here we have only one output i.e. the Tiff stack the module produces So here
outputsonly contains one key
RESULTSDATA, as type we again use
ui: This blocks defines the UI of your module display on the platform. If you don't want or need any options to change parameters manually by the user you can leave this block empty. However here we want the user to be able to select a certain filter string to e.g. only open png files generated by the previous module and also choose a custom name for the output stack, so we define two UI elements for the parameters above like so:
prefix). Since it is the first element in the UI the
indexis 0. Next we define the
label. This is the text displayed in the UI for this element. With
widget: we define the UI element for the user input. In this case a simple textbox.
WFE_INPUT_JSON.jsonfile similar to what the WFE on the platform would send. Copy this file to
C:\Test\params\, like so:
--rm: will remove intermediary containers after a successful build
-t: specifies the name of your container
.: tells docker to look for a file name
Dockerfileand use it to build the container accordingly.
Dockerfile. Once the build completed you can use the following command to display all local available docker containers.
-v: this parameter tells docker to use a local folder and map it to a path inside the docker container. Here we are making three
\paramsjust like you would expect on the platform.
C:\Test\outputin this example.