Conversation
…ata (#86) * extend to zyx `total_translation` values with backwards compatibility * Multiwell coordinates to .yaml * minor cleanup * minor refactor * cleanup * use dicts over lists * cosmetics * clean up docs
* Fix output time indices in concatenation (#90) * fix output time indices * revert diff noise * maint: update click test pallets/click#1489 * cleanup imports * clean unused stitching functions * low-RAM, parallelizable, blended proof of concept * formatting bugs * unused argument * standardize inputs * add verbose option * refactor preparing for parallelization * parallelize with submitit * bump ram * fix bug * support blending exponent CLI option * ram bump * move flipping and rotating to `estimate-stitch` * simplify `StitchSettings` and keep all flipping in coordinate space * save to `float16` * delete local SLURM_* environment variables to prepare for nested submissions * fix z chunking bug * saves correct z positions based on both available z stages * cleaner indexing * cleaner comments and variable names * enable additional parameters * depend on stitching branch * add --optimize option * set smaler saving chunks * enable pcc optimization * `estime_stitch` docs * stitch documentation * delete `cli/__init__.py` * read actual tile_size * test extract stage positions * simplify extract stage positions --------- Co-authored-by: Ziwen Liu <67518483+ziw-liu@users.noreply.github.com> Co-authored-by: Jennifer Doherty <jennifer.doherty@gpu-e-5.clusternet>
…they're done with it
|
@talonchandler I'll leave the review of this PR to you. Please change it to a draft PR if it's still under active development |
|
@talonchandler I think the functionality of tiling should belong to |
|
I'm completely open to moving One question about the HDF5 Virtual Dataset you linked: does it support overlapped tiling? (an essential feature for the tile, optimize, stitch strategy we're planning) Is there something specific about the implementation you trialled here that you think you can improve upon? |
|
I want to take that idea presented in HDF5 and apply it to this specific use case. I think if we can virtually concatenate our TCZYX datasets into a unified "big Zarr store" an entire grid of fovs can be sliced and interacted with through a single coordinate system. HDF5 virtual datasets don't support overlapping datasets due to their more general use case, but we can implement that ourselves. Basically I'm thinking if we can have a tiled / stitched grid of TCZYX fovs that behaves as one gigantic Zarr store, it would simplify a lot of downstream applications. I've tried this out a bit with I do think I need to workshop some of the more intricate details a bit more though. |
3 participants
Added tiling (please excuse the nasty commit history)