We obtained a Perkin Elmer Opereta CLS mid 2017 to address medium-high throughput live imaging needs.
The system is fully integrated with its software and some work was needed to extract the images for use in ImageJ
{F9254550, size=full}
== Parameters ==
===Select your directory with your exported images ===
This is the directory where the Harmony Software extracted the tif files and .xml file, for example `D:/MyData/images/`
===Select directory to save images===
Directory to save the new images, if set to `default`, it will resave into the same fodler as above, in a folder called `output`
===Resize Factor===
An integer larger than 1, that defines the downsampling factor, in case you just want to check the data, it can make processing a lot faster
===Export file(s) as===
Defines whether to fuse the fields of a well together or to export each field as a separate image
===Only Process Selected Wells===
Opens a GUI to select which well(s) to export
===X Y W H of box to extract===
Defines a string representing a rectangle with
X= top left corner x coordinate, in pixels
Y = top left corner y coordinate, in pixels
W = rectangle width in pixels
H = rectangle height in pixels
===Project Z Slices===
If the datasets have slices, this allows for the exporter to project them
===Z Projection Method", choices={"Max Intensity", "Sum Slices", "Average Intensity", "Standard Deviation", "Median"}) z_project_method
===Export Sub Fields", value=false) is_do_fields
===Fields(s) to Export", value="") fields_for_export_str
===Export Sub Channels", value=false) is_do_channels
===Channel(s) to Export", value="") channels_for_export_str
===Export Sub Slices", value=false) is_do_slices
===Slice(s) to Export", value="") slices_for_export_str
===Export Sub Timepoint", value=false) is_do_timepoints
===Timepoint(s) to Export", value="") timepoints_for_export_str
= Installation =
The easiest way is to use [[ https://c4science.ch/w/bioimaging_and_optics_platform_biop/image-processing/imagej_tools/update-site/ | BIOP update site ]]
Alternatively, you can download the `.groovy` script from our GIT repository.
rOPERETTAIMPORT
and add it to your `plugins > Scripts` folder or simply open it and run it directly in Fiji
== Dependencies ==
We make use of [[http://www.gpars.org/ | GPARS: A Concurrency & Parallelism Framework]] to take advantage of the maximum possible performance of our workstations.
But for that we need to make sure that the following libraries are located in the `jars` folder of Fiji/ImageJ
- `groovy-xml.jar` - Contains the XML parsing library we use to read the Operetta Metadata
- `groovy-swing.jar` - Contains what is needed to create a GUI to select the wells to process
- `gpars.jar` - Is the concurrency framework that allows us to have fun with parallel loops
- `jsr166y.jar` - Is the java library that GPARS depends on
{F4056414}
{F4070847}
{F4056415}
{F4056413}
NOTE: We provide them here for convenience. If you want to make sure you have the latest versions, you can [[ http://groovy-lang.org/download.html | download and unzip Groovy ]] (Just get the binaries) and grab the 4 files from the `lib` folder.
= Use =
Upon saving a series of images using the Export button
{F4055744, size=full}
We obtain a folder like so
{F4055762, size=full}
This inside the `Images` folder, we have all the wells, fields, channels, slices and timepoints as individual **compressed** tiffs
More importantly we have a `Index.idx.xml` that contains all the information on the acquisition
When you run the script, simply provide the location of the `Images` folder and the downsample factor you want (if any)
= Rationale Behind the Script =
== Missing Images ==
One major issue is that images that for whatever reason could not be acquired would not appear, so simple imports into ImageJ was not possible.
We needed a way to parse the data in order to know the real dimensions of the dataset that was acquired. This way we can create a clean hyperstack where missing images are at their correct locations
== Compressed Tiffs ==
The exported output contains tiffs that are lzip-compressed. For ImageJ, this means that there is a strong overhead to unzip the file before having access to its pixel data (150ms vs 10ms for opening an uncompressed tiff of the same dimensions). This prompted us to parallelize the opening of each series to maximize hard drive and processor bandwidth.
== Stitching ==
Users wanted to be able to view the stitched versions of their multiple fields in ImageJ, so this script assembles the images based on the stage coordinates given by the Operetta. As of yet, there is no smart stitching or computation done.
= Known Issues =
== Too many threads are being called ==
We are using a multi threaded approach to process as many wells in parallel. within each of these threads, we call upon more threads to handle each timepoint separately. This way, we can both make use of all the RAM (Wells in parallel) and the CPU to read the tiffs (Timepoints in parallel)
However, this creates more threads than it should. An issue was filed under https://github.com/GPars/GPars/issues/55
This is no problem per se, but your PC will be very slow until it finishes... Get in touch with the BIOP if you encounter issues.
Best
Oli