Bio-formats - clij compatibility

Hey Robert (and Daniela),

I had no idea ImageJ functions could be enhanced by GPU until learning about CLIJ, and this chapter was a very helpful starting point for understanding its implementation! It seems quite simple to also incorporate this into existing workflows. Thanks so much for this!

I have a really basic question as a novice ImageJ/CLIJ macro coder, which may be better suited to be its own thread. Our group currently uses Bio-Formats to form stacks of lightsheet images in .ome.tif format, which which we then crop and analyze using ClearMap (which support patterned .tif stack inputs). From what I’ve gathered, however, it seems CLIJ doesn’t use the ome.tif format and isn’t able to directly accelerate Bio-Formats’ functions, is that correct? I’ve read a couple posts here and looked on the GitHub but wanted to also ask directly here. Again, happy to move this to a separate thread and elaborate if a workaround using CLIJ might be possible.

3 Likes

Hey @cjburnet,

that sounds like a great question / topic. Clij is made for fast image processing and I started the project because I’m drowning in lightsheet data. We process looong timelapses of developing embryos. That usually takes ages :wink:

Not sure if I understand that right. Clij is for processing, hence it doesn’t care about file-formats. Every image file format you can open in Fiji/ImageJ/Matlab/Icy/Java/[python] can be processed with clij. Bio-formats is for reading / writing images. As bio-formats can be used from ImageJ macro and clij as well, they are fully compatible to each other. But yes, clij cannot speed up bioformats because they do different things. Clij has hardly any function for reading/writing images. There is only a single operation called saveAsTif which I added for user convenience. We could basically do the same with bio-formats. What would you like such a function to do for you? :upside_down_face:

I’m not so familiar with ClearMap. Do you want to share some more details on what kind of processing you do? We do such things with our lightsheet data:
https://clij.github.io/clij2-docs/md/tribolium_morphometry/

Looking forward to learn more about your use-case!

Cheers,
Robert

1 Like

Thanks so much for the fast response!

I’ll rephrase a bit with details about our current ImageJ pipeline: we take lightsheet microscopy images of cleared brain tissue in 2 or more channels, and save each “slice” in channel_slice.ome.tif format, (e.g. “C00_xyz_Table Z0000.ome.tif”), giving us >1000 individual images of each sample, scanned in as many channels as we need. We then want to combine all the individual slices in each channel into one stack, so we import all slices in a directory using Bio-Formats Importer (using the ability to divide by channel using the filename data I mentioned above). We then use Bio-Formats Exporter to re-export two new ome.tif files: one containing autofluorescence channel scans, and one with fluorophore scans. We can then work with this individual file to crop it for ClearMap and determine which parameters we should use for the program (more on ClearMap below). The time-consuming step is definitely the Bio-Formats export of the newly stacked ome.tif files, then subsequent modification (importing, cropping, etc.).

So yes, we’d like to increase the speed of reading/writing in new files in ImageJ, which might be beyond the scope of CLIJ, but thought you might also be able to suggest an alternative processing method? Hope that makes my question a little clearer.

ClearMap has similar functionality to the CLIJ2 processing example you provided, with functions to specify spot-detection, thresholding, etc., but it allows for alignment of signal throughout the stack to a brain atlas, automating the process of figuring out where our markers of interest are found throughout an entire brain. They’ve now released ClearMap2 for detection of/localization of markers near blood vessels as well: https://github.com/ChristophKirst/ClearMap2

Let me know if you need more information. Thanks again, I really really appreciate your time helping me speed up my group’s analysis pipeline!

Hm, I’m afraid, CLIJ is not the right solution for this kind of issue. I must also admit, when deciding for the file format our microscopes save images to (we use custom microscopes with custom software) I decided against OME-TIF because it was so slow.

Simple answer: Use ImageJs tif-saver, if subsequent steps are compatible to this format. More long-term, if you ask for alternative formats/tools, you may want to have a look at zarr which is python based and thus may be better compatible with ClearMap2. It’s a tool for managing and processing images in blocks efficiently. Also N5 is definitely worth exploring.

I hope that helps. :slight_smile:

Cheers,
Robert

The fact that exporting OME-TIFF is rather slow is a well know issue and one of the reason why alternative storage formats are being discussed inside the community for while. So far there seems to be no clear “winner” but giving zarr, ome-zarr or dask arrays a try is a good idea for sure.

2 Likes

Do you by chance know why? Once identified such an issue should be solvable :smirk:

Well we discussed those issues here: Bio-Formats ome-tiff write time issue / bug? a while ago, but so far this is still the bottleneck in some workflows.

For example, on the www.apeer.com platform it is really fun to create modules based on Fiji Python Scripting, but many people complain about the time that is required to write on OME-TIFF at the end …

But I know that people are working on it …

1 Like

Performance issues are something which we have been profiling for a while now (https://trello.com/c/OimiHAQY/39-ome-common-profile-tiff-writing and https://trello.com/c/Qk6NBnPs/92-imagej-ome-tiff-writing-performance). There is not one single reason for the write speed and it will vary depending on how the API is being accessed and the use of tiling, compression etc. We (and the community) have made a number of improvements over the last few years where we have been able to identify bottlenecks, notably from version 6.0.0 onwards there should be a noticeable boost. This is however still an ongoing issue which we will continue to try and improve.

2 Likes