Open amrosado opened 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:
%A
on Windows systems:
by e.g._
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?
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.
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.
If I run bfconvert with the following command:
I receive the following output:
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.