Need help or advice ? Come to the Icy club ! - Every other Thursday morning from 9h30 to 12h30 - Francois Jacob Building - Main hall - Pasteur

User reviews

5 star
4 star
3 star
2 star
1 star
average rating: 5

Please log-in to post a review
06 Jul 2016 17:41
This has fantastic capabilities to create tailored analysis sequences. Many thanks!
18 Jun 2015 19:56
Very useful and powerful plugin that let scientist making programming without knowing anything to informatics language. Perhaps a zoom/navigation capability could help when creating large protocol.
Many thanks for that
18 Jan 2015 18:17
It is wonderful to have the ability to draw a graphical design for you image processing.
Bertrand Vernay
25 Jun 2014 10:57
Very nice tool. A must have. A pan tool (space bar activated) will be useful especially when working on a small size display. Thanks
Fabrice de Chaumont
11 Feb 2014 15:46
The most didactic plugin of Icy ! Super-easy to use, no error possible while linking blocks. Must be tried !
Thibault Lagache
08 Nov 2013 12:28
graphical programming is the future of reproducible research! very nice plugin
13 Apr 2013 22:07
Just Awesome! Really great to chain several actions and so nice to be able to loop protocols to get batch analysis. It saves so much time. And on top of that it's really visual.
Yoann Le Montagner
13 Mar 2013 14:50
Thomas Provoost
05 Mar 2013 10:31
A must have in Icy.


by Alexandre Dufour

Design your own quantification protocol, visually. No programming required! Protocols can be shared and re-used straight from the Icy website.

Publication Id
See technical details
View complete changelog


Protocols is a graphical environment that enables anyone to prototype and design image processing and quantification protocols graphically, without any prior knowledge in programming.

More than just words, let's start with an introductory (although slightly outdated) video:


How to design a protocol

  • Adds blocks to your protocol, either by right-clicking inside the workspace and navigating the various categories, or by using the keyword-based search using the left-hand side panel. Each block represents an elementary image processing or quantification task. Ideally, all plugins in Icy should have their block counterpart. If you notice a plugin that is not available as a block, you are very welcome to submit a comment on the page of the plugin you wish to use and ask for it.
  • Link blocks together by dragging arrows (on the edge of each block) from block to block. By doing so, the blocks will automatically communicate and transfer their results between one another and run sequentially.

A protocol and all its parameters may at any time be saved (in XML format), and submitted to the Icy website for immediate sharing and/or perma-linking in a scientific publication. Any protocol published online may be downloaded and installed in a seamless manner (all required plug-ins are automatically installed). Any user can hence re-run a given protocol using the original parameters, and further edit the pipeline by adjusting parameters or adding and removing blocks.

Available protocols

If you don't feel confident enough to start from scratch, don't worry, a number of protocols already exist and are freely available on the Icy website. Click here to access this list.

Processing many files at once

In addition to bringing powerful programming abilities to non-expert users, one of the major benefits of Protocols is the ability to run a given protocol on a large number of images automatically (a process many users refer to as "batch mode"). 

Creating batches with protocols is as simple as building the protocol itself. Let's start with a simple protocol that runs on the current (active, or focused) sequence, computes statistics on the ROI in the sequence and save these statistics to a workbook on disk:

(missing image)

In order to batch process an entire folder, we basically need to run the entire protocol multiple times, replacing the "active sequence" from the first block each file of the folder. To do so, click on the "embed" icon in the Protocols interface (the one to the left of the "Play" button). When clicked, a menu appears and offers a number of options to perform loops and batch processing. Then, click on "sequence file batch", which basically says "embed the current protocol inside a batch to process a folder of sequence files". The intial protocol now appears embeded within a larger, enclosing block with a few parameters defining the batch parameters:

(missing image)

As can be seen from the screenshot above, one of the batch parameter is the folder to process. To the right of this parameter is an arrow that will read and provide, one after the other, all of the sequences available inside the specified folder, ready to be processed by the inner blocks. The last step is thus to make the final link from this arrow to the entry point of our embeded protocol, here replacing the "active sequence" of the first "inner" block:

(missing image)

Note that the batch parameters will change depending on the type of batch requested. In the current example, the "sequence file batch" block will automatically list all available sequence files in the specified folder (discarding non-image data) and read them from disk before passing them to the inner blocks. But it is also possible to run other types of batch processes, for instance on a list of files (images or not), a series of files from a multi-series dataset (e.g. lif, mvd2), etc.

That's (almost) it! When clicking on the "Play" button, the enclosing block will read the first image, run the inner protocol, then move on to the second image of the folder, run the protocol again, and so forth. Why is "almost" it? Well, we are missing one small (but important) adjustment. The last block that saves the statistics to a workbook on disk is currently set to write the workbook anew for every new file, which is not so useful in a batch context. All we need is to change the "if file exists" option from "overwrite" to "merge sheets, excluding first row" (excluding the first row will exlude the header row from the statistics table from the second run onwards, because we don't need a new header row everytime a new image is processed).

Command-line support

For the most tech-savvy, protocols can also be run from the command-line, again in a very straightforward manner. The key point here is being able to pass arguments from the command-line to the various input blocks of the protocol. To do so, let's start with a minimal protocol that reads a sequence from a disk file, and saves it to another file on disk. Here we will add a new "input" block (accessible by right-clicking in the workspace and going to the "read" subsection). Go ahead and add a "File" input block:

Right-click > Read...

This file parameter can naturally be set via the graphical interface, but we need to give it an ID such that it can be set from the command-line. To set the ID, click on the block's menu (the upper-left-hand icon), and set the ID to, say, "input1":

Input block menu > ID

Let's repeat the operation again by adding another "File" input block, and setting its ID to "output1":

Input block menu > ID

Let's finalize the protocol by renaming and linking these blocks to the other ones:

Rename and link blocks

And our protocol is ready. Here comes the magic spell: -hl -x plugins.adufour.protocols.Protocols protocol=/my/great.protocol input1=/my/inputFile output1=/my/outputFile

Let's briefly analyse this line:

  • is the Icy startup command (NB: replace by icy.exe on windows; you can also generically use "java -jar icy.jar" instead)
  • "-hl" is short for "headless", which means icy will run on the command line and no graphical interface will appear
  • "-x" tells icy to run a specific plugin at startup (this plugin is "Protocols", as you might have guessed)
  • "protocol=..." indicates the path to the protocol file to run
  • "input1=..." and "output1=..." are used to pass all the necessary parameters to the protocol, using the IDs specified above.

 That's it. You can now run Icy with your favorite protocol on any Java-friendly machine (desktop, server, cluster, smart fridge, etc.)


Contributors to this project include:

  • Ludovic Laborde (copy/pasting, dis-embedding, search bar, block renaming)
  • Stephane Dallongeville (for stress-testing, troubleshooting and continous support, one update at a time)
  • All of the happy (and patient) alpha/beta/gamma testers and feature requesters out there!