Bio-Formats ome-tiff write time issue / bug?

Usage & Issues
, , , , ,
#1

ome tiff export is super slow:
Example with an (empty) simple empty hyperstack, 5 channels 16 bits, 1000x1000 , 300 time points (about 3GB in tif).

Tiff writing with Fiji: 10 sec
Tiff writing from Fiji Bio-Formats exporter or Icy (save as Tiff, using Bio-Formats by default): more than 2 minutes (I was not patient enough to let it finish).

Do you have any idea how to fix that in Bio-Formats (super useful otherwise, thanks for developing and maintaining btw)? could all software propose an alternate saving otherwise (in icy it is the only export format in tif available for now)?
Kind regards,
Perrine

1 Like
Make tags obligatory, and introduce tag hierarchy?
Use bf-convert with multiple threading?
\(•ᴗ•)/ QuPath scripting (#1): Using CluPath to save smoothed image regions
#2

I also noticed that that writing OME-TIFF recently got super slow, so that I was running into a timeout. I do not remember the exact numbers but it was several minutes for MB-sized image.
I noticed that when writing images from inside a Fiji Docker container while testing a new module for the APEER platform.
Any hints what could be the reason would be really helpful.

#3

These times do appear to be longer than expected so thank you for raising this as a concern. The Bio-Formats team has been carrying out some tests on this today and we have been able to reproduce these sort of times using similar dimensions. My initial view is that this is a performance issue rather than a bug and it is not specific to the FIJI plugin. We have also begun to look into profiling the tiff writing process in order to better understand what the bottlenecks are and how they can be improved going forward. This is something that we will have to further investigate going forward.

David Gault

3 Likes
#4

Hi David,

thanks for the update. Let me know if I can help with more info etc.

Sebi

#5

Hi David,

are there any updates on this because I emcountered that issue today again. Basically I did run into a timeout when using BioFormats Export to write a file.

If it is supposed to be fixed, then which version of BioFormats should I use?

Sebi

#6

We are still trying to profile this better and we are hoping to prioritise work to make improvements to this shortly. There is some ongoing discussion on https://trello.com/c/OimiHAQY/39-ome-common-profile-tiff-writing which you can follow. This will be further updated with the latest findings over the next few weeks.

#7

Thx for the update.

Sebi

#8

Thanks for the link.

#9

I too have been using BioFormats from my own Java application to read/write OME-TIF files and the performance can be very slow. Whilst on my Mac with internal SSD the performance is acceptable, the moment I switch to using a slower target (network disk for example) the performance really plummets.

I have some more tests to try, but I suspect that during the write process calls to ImageWritter::saveBytes might be opening/writing/closing the file each time which perhaps may defeat some file system caching?

One thing I will look to test is whether writing to a temporary file on the local filesystem and then block moving this into the final destination improves matters for a network drive.

I’d sure be interested to hear if there has been progress with this issue.

– Michael Ellis

1 Like
#10

Dear all,

sorry for the long delay in answering and thanks everyone for all the hindsights. The link given by @dgault in Bio-Formats ome-tiff write time issue / bug? contains references to some writing performance improvements change that have been recently proposed by ourselves and contributors.

Although these changes have given us substantial writing improvements in our recent testing use cases, largely using the Bio-Formats command line tools, it does not address the speed of writing OME-TIFF using the ImageJ plugin in the conditions described above.

We believe the issue discussed in this thread is specific to the usage of the writing API in the ImageJ plugin. As we have now completed a large portion of our work on pyramidal OME-TIFF (watch https://blog.openmicroscopy.org/ for more information), tackling this performance issue is now part of our outstanding and immediate priorities.

For developers, you can track the latest progress on the dedicated reference card - https://trello.com/c/Qk6NBnPs/92-imagej-ome-tiff-writing-performance. Once we have a fix ready to test by the community, we would propose to enable development milestones of Bio-Formats 6 via the development Bio-Formats update site.

Best,
SĂ©bastien, David, Melissa & Josh

#11

Are there any real news because from checking the progress an Trello I do not really know, what is going on.

We use the BioFormats OME-TIFF writer on APEER (www.apeer.com) inside docker containers and run sometime into the issue that or Kubernetes system (where the workflow engine runs) sometimes “kills” a running container because it thinks “it is dead”.

But if fact writing the OME-TIFF to the outputs is still running (slowly …). Do you have a rough idea, when this issue might be solved so that we can update our modules?

#12

Hi @sebi06,

we are currently on the process to freeze our specification and API frozen for Bio-Formats 6. Current expectation is to have Bio-Formats 6.0.0 released in February including some improvements for writing OME-TIFFs.

Following up on my Bio-Formats ome-tiff write time issue / bug?, we have encountered issues which prevented us from pushing the Bio-Formats 6 development milestones to the Bio-Formats development update site. Addressing these blockers if currently high on our priority list and we hope to have the first release candidate of Bio-Formats 6 available via this update site.

If you are downloading Bio-Formats independently of Fiji within a Docker container, you could also try to the latest development milestone.

2 Likes
Bio-formats - clij compatibility
#13

Thanks a lot for the update.

Sebi

#14

Hi all,

are there any news on this issue? I am currently hitting this bug rather hard in ImageJ (latest Fiji-release) - I am trying to write an OME-TIFF (ca. 1500x1500 px, 3ch, 54 z-layers, 8bit, JPEG compression) to a SSD and it’s only writing around 0.4 MB/sec. :frowning:

Simon

#15

Hi @skalteis

I also have not heard anything from this issue for a long time, but I can confirm what writing OME-TIFF is still very slow and still a bottleneck on our APEER platform.

Any tips on how to make it faster are welcome.

Compressing z-stacks
#16

What is important for us in trying to understand these performance issues is to understand exactly what times are being compared, what process is being used, what type of data is being written etc. @sebi06 and @skalteis, are you both using the Bio-Formats Exporter command from the Bio-Formats plugin?

As part of our work on next gen file formats we are currently looking at further benchmarking that will also include the current performance of OME-TIFF. So those results may be useful in understanding where the bottlenecks are for various image types and formats.

For those using the Java API directly it may be worth looking at bioformats2raw and raw2ometiff from Glencoe Software which is a much more performant implementation than say the Exporter plugin in FIJI due to processing in parallel. Though part of this will also be due to assumptions being made about the data, whereas the Exporter plugin for example provides a more general purpose solution that deals with all possibilities.

#17

Hi @dgault

I use jython scripts where the relevant code snippet is

class ExportTools:

    @staticmethod
    def bfexporter(imp, savepath, useLOCI=True):

        if useLOCI:

            paramstring = "outfile=[" + savepath + "] windowless=true compression=Uncompressed saveROI=false"
            plugin = LociExporter()
            plugin.arg = paramstring
            exporter = Exporter(plugin, imp)
            exporter.run()

        # save as OME-TIFF using BioFormats library using the IJ.run method
        if not useLOCI:

            # 2019-04-25: This does not seem to work in headless anymore
            paramstring = "save=[" + savepath + "] compression=Uncompressed"
            IJ.run(imp, "Bio-Formats Exporter", paramstring)

        return paramstring

So basically the normal BioFomats exporter with the useLOCI=True option, because the other stopped working a while ago anyway (should remove it). Based on my observation this is what take quite a while. Nevertheless it gives the correct results.

#18

Additionally I can also confirm that the other tools mentioned above work significantly faster. For this reason we also use them to convert larger CZI slides into pyramidal OME-TIFFs using this script here:

#19

Thanks Sebi, thats very helpful. Having the exact Exporter call thats being used will allow us to benchmark that specific function to try to isolate any bottlenecks.

1 Like
#20

Hi @dgault

I have also just run into this issue - I have some very large (10-40 Gb) z-stacks lifs that I would like to compress, and someone recommended that I do so using ome.tiffs. I tried it on a test image (6580 x 3787 px, 2 colors, 10 z planes, 475 Mb) by using Save as → OME-TIFF in FIJI, then using the file type .ome.tf2, and choosing JPEG2000 compression, and it’s taken 20 mins so far to reach just over half way. Saving as a regular tiff would take about 1 second on my computer.

Thanks for your work on this. Any help would be appreciated.
Ryan