FEATURE REQUEST: increase the limit on the length of file names

[giocard]

The current limit on the length of directory and file names is 50. My experience is that these limits are easily exceeded, resulting in erroneous results without any warning.

[ctrueden]

@giocard I am not sure how closely @StephanPreibisch is monitoring this repository these days. Work has moved on to BigStitcher. Have you tried it?

[StephanPreibisch]

thanks @ctrueden ... but this sound easy to fix, where exactly is the 50 limit @giocard?

[giocard]

I had the issue when trying the grid stitching (Stitching_Grid.java), but the limit is hard coded in many places. For example, you can get a list of the calls gd.addDirectoryField, gd.addFileField, gd.addStringField where is coded with this search https://github.com/fiji/Stitching/search?q=50&unscoped_q=50 Thank you @ctrueden and @StephanPreibisch !

[StephanPreibisch]

Hi, this "50" only defines the size of the GUI, the actual filenames can be longer, so I do not believe that this causes it (except something in ImageJ changed significantly). Could you please give me a minimal example that fails? thanks @giocard

[giocard]

Hi @StephanPreibisch , you are right, the problem is unrelated to any length limit. I did further tests and it seems that the issue is actually in the header of the images: either if I change the name of the files or I just open them in Fji and save them back without any processing done, the stitching would work. My impression is that this is still a bug, because no information from the header should be used when giving the information by means of a TileConfiguration file. Attached is a minimal example reproducing the issue: files in the directory LongName are stitched incorrectly, while those in ShortName (files are only renamed) are stitched correctly. I used the command Grid/Collection stitching, specifying Positions from file as Type and Defined by TileConfiguration as Order. Thanks

StitchingDebug.zip

[imagejan]

@giocard how exactly does the issue manifest itself in the stitched result? Do you see things like the first tile repeated n times, instead of different tiles at each position?

This might be a combined problem of this plugin using BF.openImagePlus and Bio-Formats trying to be smart about multi-file datasets, as it's guessing which files belong to a single dataset and then opening the first series of the entire dataset, instead of the one in the filename you used.

See also @ctrueden's comment here:

The grid/collection stitching plugin uses the BF.openImagePlus routine to open every tile as an ij.ImagePlus. Some of the performance issues in (3) are related to this. But beyond only performance, there is likely to be an irreproducibility/correctness issue, since BF.openImagePlus will reuse the last-used user settings from the Bio-Formats Importer dialog box. In particular, if "Group files with similar names" was checked, it may still be enabled during a later stitching operation, which will have ramifications on behavior and performance. As a workaround, we should consider adding options.setGroupFiles( false ); (and maybe lock down other options similarly) within the Stitching_Grid code.

You might also want to try:

• Using Defined by image metadata (if applicable), and then using one of the .ome.tif files as "Multi series file",
• Defining your TileConfiguration.txt with the multi-series option, leaving the file name the same in every line, but adding series indices after the first semicolon (;):

# Define the number of dimensions we are working on
dim = 2
multiseries = true

# Define the image coordinates
MT_Pmr5-6nt-2nM_B-plus-75mM_MgCl_1_MMStack_9-Pos_000_000.ome.tif; 1; (0.0, 576.0)
MT_Pmr5-6nt-2nM_B-plus-75mM_MgCl_1_MMStack_9-Pos_000_000.ome.tif; 0; (0.0, 1152.0)

I didn't test this myself on your data, don't know if it helps.

[giocard]

@imagejan Thanks for the feedback and the suggestions. Indeed the result is the first tile repeated over the montage. However, I tried your suggestions and they don't work in my case: I get the first tile at its place and the rest empty. The tiles are generated under microManager, which writes some information in the header about the name of the first tile, which disorients Bio-Formats. In my example: if I consistently add one character to both file names, the stitching works; if I add one character only to the 000 tile, only the 001 is shown in the montage; if I add one character only to the 001 tile, only the 000 is shown, but at all locations. I hope this helps to clarify the issue.

[imagejan]

Hi @giocard, I tried now with your provided example images.

When I open one of the .ome.tif files using Plugins > Bio-Formats > Bio-Formats Importer, I get a Bio-Formats Series Options showing me 196 series, and only series #1 and #28 contain a thumbnail preview (since these are the only two files you provided in the sample).

Consequently, I tried the following TileConfiguration.txt containing series indices 27 and 0 which works for me:

# Define the number of dimensions we are working on
dim = 2
multiseries = true

# Define the image coordinates
MT_Pmr5-6nt-2nM_B-plus-75mM_MgCl_1_MMStack_9-Pos_000_000.ome.tif; 27; (0.0, 576.0)
MT_Pmr5-6nt-2nM_B-plus-75mM_MgCl_1_MMStack_9-Pos_000_000.ome.tif;  0; (0.0, 1152.0)

[giocard]

Hi @imagejan, thank you for the solution! Now I can generate a configuration file which can be used for the stitching. However, after stitching (option Compute overlap checked) the file TileConfiguration.registered.txt is incorrect and cannot be used later, since all the mapping is lost. Either I am still missing something, or there is some inconsistency. Also, I was expecting that, without the multiseries option, the information in the configuration file would have overriden any information in the header, but I was obviously wrong.