I've been using this utility class StitchingUtils for a while now, e.g. when I need to stitch multi-series images that are not being read correctly via Bio-Formats, or for images that are loaded into memory already in scripting workflows, to avoid writing new files and relying on a TileConfiguration.txt file.
This adds the following static methods:
computeStitching(images, positions, dimensionality, computeOverlap) returning the translation models for each tile,
as well as:
fuseTiles(images, models, dimensionality, fusionType) and
fuseTiles(images, models, dimensionality) performing the actual fusion (with blending being the default fusion method).
I've been using this utility class
StitchingUtils
for a while now, e.g. when I need to stitch multi-series images that are not being read correctly via Bio-Formats, or for images that are loaded into memory already in scripting workflows, to avoid writing new files and relying on aTileConfiguration.txt
file.This adds the following static methods:
computeStitching(images, positions, dimensionality, computeOverlap)
returning the translation models for each tile,as well as:
fuseTiles(images, models, dimensionality, fusionType)
andfuseTiles(images, models, dimensionality)
performing the actual fusion (with blending being the default fusion method).As there seems to be some community interest in having more accessible stitching API (e.g. in the discussion of https://github.com/imagej/pyimagej/issues/35), I thought it might make sense to migrate these utility methods upstream from
faim-ij2-visiview-processing
into this repository.@StephanPreibisch, @ctrueden let me know what you think.