Macro recording broken for Bio-Formats Importer

The commit 1.51u51 of #imagej1 contains a poorly documented change that breaks file path recording for #bio-formats with several file formats:

- s = s.replaceAll("\\\\", "\\\\\\\\");  // replace "\" with "\\" in Windows file paths
+ s = s.replaceAll("\\\\", "/");  // replace "\" with "/" in Windows file paths

Before version 1.51u51, opening e.g. a Metamorph file set (consisting of .nd and . stk files) using Plugins › Bio-Formats › Bio-Formats Importer would be recorded like this:

run("Bio-Formats Importer", "open=E:\\code\\fmi-basel\\faim-imagej-bio-formats-tests\\src\\test\\resources\\ch\\fmi\\benchmark_v1_2018_x64y64z5c2s4t11\\benchmark_v1_2018_x64y64z5c2s4t11.nd color_mode=Default rois_import=[ROI manager] view=Hyperstack stack_order=XYCZT series_1");

With any later version, the same command gets recorded as:

run("Bio-Formats Importer", "open=E:/code/fmi-basel/faim-imagej-bio-formats-tests/src/test/resources/ch/fmi/benchmark_v1_2018_x64y64z5c2s4t11/benchmark_v1_2018_x64y64z5c2s4t11.nd color_mode=Default rois_import=[ROI manager] view=Hyperstack stack_order=XYCZT series_1");

The problem with this line is that Bio-Formats doesn’t handle this well: when trying to run this line, you’ll get the following stack trace:

loci.formats.FormatException: STK file not found in E:\code\fmi-basel\faim-imagej-bio-formats-tests\src\test\resources\ch\fmi\benchmark_v1_2018_x64y64z5c2s4t11.
	at loci.formats.in.MetamorphReader.initFile(MetamorphReader.java:404)
	at loci.formats.FormatReader.setId(FormatReader.java:1395)
	at loci.plugins.in.ImportProcess.initializeFile(ImportProcess.java:499)
	at loci.plugins.in.ImportProcess.execute(ImportProcess.java:142)
	at loci.plugins.in.Importer.showDialogs(Importer.java:140)
	at loci.plugins.in.Importer.run(Importer.java:76)
	at loci.plugins.LociImporter.run(LociImporter.java:78)
	at ij.IJ.runUserPlugIn(IJ.java:229)
	at ij.IJ.runPlugIn(IJ.java:193)
	at ij.Executer.runCommand(Executer.java:137)
	at ij.Executer.run(Executer.java:63)
	at ij.IJ.run(IJ.java:309)
	at ij.IJ.run(IJ.java:320)
	at ij.macro.Functions.doRun(Functions.java:623)
	at ij.macro.Functions.doFunction(Functions.java:97)
	at ij.macro.Interpreter.doStatement(Interpreter.java:270)
	at ij.macro.Interpreter.doStatements(Interpreter.java:256)
	at ij.macro.Interpreter.run(Interpreter.java:152)
	at ij.macro.Interpreter.run(Interpreter.java:91)
	at ij.macro.Interpreter.run(Interpreter.java:102)
	at ij.plugin.Macro_Runner.runMacro(Macro_Runner.java:161)
	at ij.IJ.runMacro(IJ.java:148)
	at ij.IJ.runMacro(IJ.java:137)
	at net.imagej.legacy.IJ1Helper$3.call(IJ1Helper.java:1107)
	at net.imagej.legacy.IJ1Helper$3.call(IJ1Helper.java:1103)
	at net.imagej.legacy.IJ1Helper.runMacroFriendly(IJ1Helper.java:1054)
	at net.imagej.legacy.IJ1Helper.runMacro(IJ1Helper.java:1103)
	at net.imagej.legacy.plugin.IJ1MacroEngine.eval(IJ1MacroEngine.java:147)
	at org.scijava.script.ScriptModule.run(ScriptModule.java:160)
	at org.scijava.module.ModuleRunner.run(ModuleRunner.java:168)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:127)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:66)
	at org.scijava.thread.DefaultThreadService$3.call(DefaultThreadService.java:238)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

In addition to MetamorphReader, I assume there are several format readers in openmicroscopy/bioformats affected by this issue, as they all rely on File.separator being present in the input path.

/cc @Wayne @dgault @s.besson

This is probably something the BioFormats team needs to fix since “/” is a valid Windows file path separator.

Thanks @imagejan for bringing this to our attention. This change has been included for quite a while now but this is the first we have been made aware of it. The Bio-Formats code does use the java.io.File.separator which was compatible with the original recorder code. As / can be valid for a Windows file path we will look into finding a way of sanitizing the strings as part of the importer to prevent any further issues.