"Sequential images" breaks if the sequence reaches over 99 images

[afb269b0e9]

Hey,
I'm using the plugin to stitch with the "Sequential Images" function to stitch sequences of metallographic micrographs at high magnifications. I'm making those by using the manual x-y function of the sample stage. I am using FIJI on Windows 10 20H2 64-bit with an AMD Ryzen 3600 and 32GB of RAM, if this makes a difference.

I encounter the issue, that the stitching breaks as soon as the numbering on the image has 3 digits, where the plugin starts to sort the images >100 in between the rest of the files, e.g. 10, 100, 101, 102, 103,..., 11, 110, 111, 112,..., 20, 200, 201,... (See TileConfiguration.txt ). If I delete every image above filename99.tif the whole image is stitching perfectly. Without deleting the images with the numbering >99 the parts of the image are stitched perfectly with breaks caused by the jumps in-between the sequences. Modifying the Frame Range to 20 did not improve the reliability consistent enough to use it as a work around. Using the "unknown sequence" is not viable at this point as the time needed gets horrendous even on my reasonably fast PC.

It does not matter how the filename is formatted, or if I remove the filename entirely. I tried to add a leading zero, multiple leading zeros, adding a leading 99 to all files above 100 to make them last in the sorting, renaming the files into their alphabetical equivalent (aa.tif, ab.tif, ac.tif,...), removing the filename and all of these things get ignored by Fiji/the plugin. Especially the alphabetic renaming of the files mangles the sequence completely/does not even start. I checked that Fiji is not sorting the files by creation time or other attributes and these do not influence the sorting.

In the other modes of the plugin there is a mask to input the filename-formatting , which if this would be implemented in the "Sequential images"-function may fix the problem, since I have the feeling that the sorting algorithm is looking only at 2 digits, while ignoring leading zeros, instead of the whole number. I would be really happy if this could be fixed.

Greetings,
Stefan B.

PS.: I tried a cursory look at BigStitcher, but I can not find the setting that supports a simple sequence of RGB-.tif-images like the old plugin does or a tutorial on how to use BigStitcher in such a way.

[imagejan]

The files will remain in the order that the operating system is serving them, since that is what dir.list() returns:

Stitching/src/main/java/plugin/Stitching_Grid.java

Line 1204 in f151a53

final String[] imageFiles = dir.list();

I agree that an option to sort them would be useful, in particular because some file systems do not apply alpha-numeric sorting by default, and the order can get pretty random in these cases.

@afb269b0e9 as a workaround, you should be able to pad your filenames with zeros, such that they all contain three digits, no? As they currently are in your TileConfiguration.txt, they are inconsistently named, because the single digits are zero-padded to two digits, but the padding is not compatible with >100 files, when it would need to pad to three digits.

Alternatively, edit the TileConfiguration.txt manually.