Bio-Formats does not recognize setMetadata("Info", string) or Property.setList(string) image info


I’m attempting to input custom metadata categories for files through my processing pipeline, e.g. the date and version of X macro used, the specific input fields, and some simple outputs I’d like to keep track of through my pipeline. The setMetadata(“Info”, string) and Property.setList(string) functions seem like a decent solution, especially since I’m able to call them easily using Property.get().

So I ran into an issue using Bio-Formats. TLDR, seems like Bio-Formats hasn’t integrated these Property Functions since they came out with 1.53a. Basically:

  1. Custom metadata & properties set using either setMetadata(“Info”, string) or Property.setList(string) are not saved if using Bio-Formats exporter. Must use saveAs(“Tiff”, title) instead.
  2. Custom metadata & properties saved using the above saveAs(“Tiff”, title) method are overwritten if opened with Bio-Formats. The properties read “No properties” and the metadata is just canned image properties like dimensions, etc.

Big picture gripe: In general, ImageJ/FIJI tends to like to drop metadata during processing. It would be great if the default was to carry the metadata forward so that images have a paper trail. It’s a bit annoying having to consciously pull the metadata from the source file and write it to the processed one, especially if that process itself ca become onerous and non-intuitive for large amounts of metadata. Carrying over an image’s dimensions properties, like pixel/voxel size and frame interval, would be really helpful for bookkeeping. Maybe it already does this, but if it does, I have no idea how to retrieve these data…

Bonus bug: I noticed that when saving an image as an .ome.tif, if there is already a file present at that path, rather than overwriting it, Bio-Formats just expands to the file size, as if it is concatenating the images. This would be cool if, like an HDF5 file, you can have subdirectories/imagesubsets within an ome.tif, but as far as I can tell this isn’t the case (e.g. the seriesCount and imageCount are unchanged, despite the increased file size).


Hi @pdd2110, thank you raising the issues and apologies for the delayed response over the holiday period. The problem with the Bio-Formats Exporter not saving all applied settings is a known bug, I have updated the existing GitHub Issue to link to this thread.

I also agree that through the exporter saving a file using an existing name should prompt the user to confirm if they wish to overwrite the existing file instead of automatically concatenating. I have also made note of this bug on the GitHub Issue.


Thank you @dgault!

No worries on the delay, hope you had a great holiday! Please let me know if there are any updates on these issues. The metadata one is more important for me.

Also, just to be clear with the saving issue, I’m fine with prompt-less overwriting (especially as prompts could complicate batch use in a macro). The issue is that when overwriting a file, the file size is increased, as if the images are being concatenated. In other words, if the original image size is [A] kb, then exporting (i.e. overwriting) the same image again yields a [2A] kb file, and generally [nA] kb for n exports. I’m not sure if this also occurs if the overwrite is a different size, e.g. original=[A] kb, exported=[B] kb, final=[A+B] kb. I’m assuming this is unintentional, especially as it could lead to storage issues if coupled with an unchecked while loop. That said, I can write an easy workaround in my own macro to check if the path is already present, and if it is, delete the file before exporting. But and having that code internally would be cleaner and avoid the issue for others.