Just to chime in, agree with both @Konrad Rokicki and @Jeremy Muhlich. Ome-tiff / tiff is likely not the perfect solution going forward, as files get very large, transferring data therefore becomes a bottleneck and in terms of nextflow pipelines, copying all this data might also be inefficient. That being said, I also think that currently many providers do use ome.tiff with pyramid and tiled storage as their standard data output and thus building the pipelines for the current generation of technologies with the current generation of tools (that mostly work with tiff) is likely the short term way to go. I am keen to see where and how fast the field will move to common data standards. We are big fans of spatialdata, since its co-developed here in Heidelberg, but from my perspective, it’s currently still changing a bit too much day-to-day to build long-term tools on it. Hopefully this will improve in the coming months!

Just a small notion here. We are currently looking to still do 2 major changes in SpatialData after which it should be in a quite stable state. 1. A refactor in the transformations which would also support stitching. 2. Add support for multiple tables. Currently only 1 AnnData table is supported but we observe that this is too limiting.

How rich is the transformation model? We are finding that performing barrel-distortion correction yields a non-trivial accuracy boost in stitching and registration. The model for that correction is very much non-affine and probably best modeled as a general vector field.

Is this already implemented in Ashlar? As to for your question, indeed at the moment what we support in SpatialData is up to / including affine transformations. With this we are ahead of OME-NGFF which at the moment supports scale and translation. There has been talk in the OME-NGFF community of also supporting vector fields. Trying to find the discussion, but can't seem to find it at the moment. I will get back to you on this.

Ashlar has an undocumented/hidden 1-parameter barrel correction model, but it doesn't infer the parameter. The user has to compute it externally and pass the value explicitly. This is tricky, which is why I left it hidden for now. Even though the model is 1-parameter, it ends up building a vector field under the hood to actually perform the transformation. A more accurate correction approach would be to image a calibration slide with a grid and use that to compute the vector field directly. The correction is indeed applied per tile, and it applies the same correction to every tile in a scan (as it should be purely a function of the optical train).

@Jeremy Muhlich is the cross-fading applied to every channel and is there a side effect of creating any artifacts at the borders? i'm wondering how this might affect FISH images which are quite sparse, tight puncta. as a result detection is pretty sensitive to translation etc.

Yes, every channel.