You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We first determine pixel coordinates for image stitching, then calculate back physical coordinates for the ROI tables. We can instead go directly from the stage position data to the ROI tables (only requiring the shape of a single image once to be converted to physical coordinates).
Also, the montage functions currently violate the single-responsibility principle as they mix pixel stitching/blending with ROI table creation. Separating this will be important to simplify code maintenance, and e.g. for fully supporting dask arrays in the future (see #42).
The way ROI tables are currently computed is far too convoluted:
https://github.com/fmi-faim/faim-hcs/blob/6a1cd2b9d56037f84f523050c99fb347ec009222/src/faim_hcs/MetaSeriesUtils.py#L175-L186
We first determine pixel coordinates for image stitching, then calculate back physical coordinates for the ROI tables. We can instead go directly from the stage position data to the ROI tables (only requiring the shape of a single image once to be converted to physical coordinates).
Also, the montage functions currently violate the single-responsibility principle as they mix pixel stitching/blending with ROI table creation. Separating this will be important to simplify code maintenance, and e.g. for fully supporting dask arrays in the future (see #42).
/cc @tibuch @jluethi
The text was updated successfully, but these errors were encountered: