ome / bioformats

Bio-Formats is a Java library for reading and writing data in life sciences image file formats. It is developed by the Open Microscopy Environment. Bio-Formats is released under the GNU General Public License (GPL); commercial licenses are available from Glencoe Software.
https://www.openmicroscopy.org/bio-formats
GNU General Public License v2.0
378 stars 241 forks source link

Bfconvert Timestamp Pattern %A Fails in Windows Command Environment #3631

Open amrosado opened 3 years ago

amrosado commented 3 years ago

If I run bfconvert with the following command:

bfconvert 20201023_DNAForceProbe.mvd2 output_tiff_%%A_%%n_%%s.tiff

I receive the following output:

VolocityReader initializing 20201023_DNAForceProbe.mvd2
[Volocity Library] -> output_tiff_%A_%n_%s.tiff [Tagged Image File Format]
Exception in thread "main" java.io.FileNotFoundException: output_tiff_2020-11-05T15:56:40_antiCD3 CD8_0.tiff (The filename, directory name, or volume label syntax is incorrect)
        at java.base/java.io.RandomAccessFile.open0(Native Method)
        at java.base/java.io.RandomAccessFile.open(RandomAccessFile.java:347)
        at java.base/java.io.RandomAccessFile.<init>(RandomAccessFile.java:261)
        at java.base/java.io.RandomAccessFile.<init>(RandomAccessFile.java:216)
        at loci.common.NIOFileHandle.<init>(NIOFileHandle.java:130)
        at loci.common.NIOFileHandle.<init>(NIOFileHandle.java:151)
        at loci.common.NIOFileHandle.<init>(NIOFileHandle.java:165)
        at loci.common.Location.getHandle(Location.java:522)
        at loci.common.Location.getHandle(Location.java:462)
        at loci.common.Location.getHandle(Location.java:443)
        at loci.common.RandomAccessOutputStream.<init>(RandomAccessOutputStream.java:66)
        at loci.formats.FormatWriter.createOutputStream(FormatWriter.java:566)
        at loci.formats.FormatWriter.setId(FormatWriter.java:401)
        at loci.formats.out.TiffWriter.setId(TiffWriter.java:163)
        at loci.formats.ImageWriter.setId(ImageWriter.java:463)
        at loci.formats.tools.ImageConverter.testConvert(ImageConverter.java:693)
        at loci.formats.tools.ImageConverter.main(ImageConverter.java:1095)

I do not get the same error if I don't use the %A pattern to put the series timestamp into the output filename. I believe the problem might be related to how the colon (:) is interpreted in the path.

sbesson commented 3 years ago

Hi @amrosado, thanks for reporting this. Similarly to https://github.com/ome/bioformats/issues/3629, I assume Windows is the environment?

If so, I certainly understand how : is problematic as it is an invalid character for a Windows filename. Unfortunately, the usage of colons comes from the IDRO 8601 standard.

I see two options:

In addition to the above, what is the rationale for encoding the acquisition time in the output file name as opposed to using a richer file format like OME-TIFF and store the information in the associated metadata?

amrosado commented 3 years ago

I think using a richer file format like OME-TIFF and having all the associated metadata would work best. I'll spend some time looking through the XML output I have from my library file to find all the information in metadata I need for my analysis. If I can help make a fix preventing windows users from losing a potentially useful feature, I think this problem might originate from the loci.common.Location class. Specifically how that calling the absoluteFilePath might need a toString method.

sbesson commented 3 years ago

I think using a richer file format like OME-TIFF and having all the associated metadata would work best. I'll spend some time looking through the XML output I have from my library file to find all the information in metadata I need for my analysis.

If you want to export as OME-TIFF, the main change is really to use one of the extensions of the format as the output file e.g.

bfconvert 20201023_DNAForceProbe.mvd2 output_%%n_%%s.ome.tiff

If I can help make a fix preventing windows users from losing a potentially useful feature, I think this problem might originate from the loci.common.Location class

Thanks. For reference, the Location class is maintained in the ome-common-java component. Feel free to open a RFE or directly a contribution against this repository.