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
It's on our plate to be able to handle tiff files. I do remember your wariness about adding support for more matrix forms beyond TSV but...
For our audience, we want to be able to say that it can be handled out of the box.
Big tiffs could get very, very, big if translated into an intermediate TSV
Getting the details of the tiling right is finicky... Now that it's done, I feel like the TSV parser itself should really just parse to a numpy array, and then do the same thing for tiffs with this: https://pypi.org/project/tifffile/
If this is going to happen, would you rather the work be done in clodius, or should there be a new clodius-imaging where it would go?
Also, just a gut check: You do feel confident that we're not getting too far into wheel reinvention here? I think there's an alternate route, where we work on the client side to handle a wider range of image tiling formats.
Would a DAG diagram of filetypes -> tiletypes -> tracktypes be useful?
The text was updated successfully, but these errors were encountered:
It's on our plate to be able to handle tiff files. I do remember your wariness about adding support for more matrix forms beyond TSV but...
If this is going to happen, would you rather the work be done in
clodius
, or should there be a newclodius-imaging
where it would go?Also, just a gut check: You do feel confident that we're not getting too far into wheel reinvention here? I think there's an alternate route, where we work on the client side to handle a wider range of image tiling formats.
Would a DAG diagram of filetypes -> tiletypes -> tracktypes be useful?
The text was updated successfully, but these errors were encountered: