how can I call the another constructor?
r = loci.formats.Memoizer(bfGetReader(), 0, 'c:\temp\bfmemo');
does not work: “No constructor ‘loci.formats.Memoizer’ with matching signature found.”
You will need to construct a
java.io.File object to call the correct constructor. Try something like
loci.formats.Memoizer(bfGetReader(), 0, java.io.File('c:\temp\bfmemo'));
- Is there a way to automatically delete those memo files?
There is no public Bio-Formats API allowing to delete the memo file. Containment of these files using a top-level directory is one option to manage the deletion of a set of memo files. Otherwise, the
Memoizer.getMemoFile(String) API will return the location of the cache file so you can also use OS level commands to manage the files once done.
- what happens if I have two readers of the same file, are they going to share the same memo file, right? Can it potentially cause any problems?
There could be a problem if two readers try to write a memo file at the same time. This could happen either if the memo file does not exist or if the cached reader is invalid with regard to the current Bio-Formats version.
If a memo file exists and is safely loaded, multiple independent threads should be able to use it concurrently. The file should be accessed in a read-only manner at initialization time only.
- I also wonder why not to have such memoizer not on the disk but in memory and automatically delete it when the dataset is not needed?
There are some functionalities for reading and writing images from in-memory sources - see https://docs.openmicroscopy.org/bio-formats/5.9.2/developers/in-memory.html. Applying a similar strategy to write the memo file to memory would be conceivable but I suspect this is not possible using the current API.
- returning back to my original post: is it possible to fix the memory leak problem in the situation without Memoizer class?
I took another look at this issue comparing a few heap dumps. It looks like the
cachedTileBuffer of the
TiffParser API is what consumes most of the heap size and eventually causing the OOM when a large number of readers are instantiated simultaneously. The content and size of this cache largely depends on the TIFF layout so more investigation will be required using one of the files generated by your script. I have recorded this investigation here.