The undocumented solution you need is the “fileseries” reader. Where the instructions say
FILE, you use a quoted string that looks like this instead:
The general format for the rest of the string is a list of
key=value strings separated by
|. You can supply as many fileseries arguments as you want for each of your cycles, but you should start with just the first one for now to get the stitching parameters nailed down.
Here’s what this will look like for one cycle of your data. I guessed your grid is 10x10 so you will have to change the
height. Note this all goes on one line but it may get wrapped here:
While testing, it is helpful to specify
--output-channels 0 so Ashlar only spends time assembling the mosaic image for your first (DAPI) channel.
Depending on how accurate your 20% overlap guess is, you may need to pass the
-m SHIFT argument to Ashlar with a fairly high value for SHIFT. By default Ashlar will assume that if a pair of tiles needs their relative positions corrected by more than 15 microns (i.e.
-m 15), that it’s due to noise or other problems and will fall back on a value extrapolated from other tile alignments. However there’s no reporting that tells you about this (this is also in the works…) so it’s hard to diagnose if you’re not familiar with the internals. Probably a better solution for you would be to figure out what the actual overlap is and specify that instead of 0.2. You can open two neighboring tiles in Photshop or equivalent, using additive blending mode on a sufficiently large canvas, and move them until they align. Then you can easily determine what the percent overlap is. If you get it really close, the default
-m 15 (which is 15 pixels in your case since fileseries defaults to 1 pixel = 1 micron) will probably work OK. I can help you diagnose this more once you at least get it running to completion.