Pat Gunn
Pat Gunn
> Also, slightly off-topic now but: > > ```python > if channel is not None: > logging.debug(m.shape) > m = m[channel].squeeze() > logging.debug(f"Movie shape: {m.shape}") > ``` > > is...
> > Also, slightly off-topic now but: > > ```python > > if channel is not None: > > logging.debug(m.shape) > > m = m[channel].squeeze() > > logging.debug(f"Movie shape: {m.shape}")...
> Hey, thanks for taking a look. I more recently made a discussion #1366 about this channel argument - instead of removing, maybe we should make it more functional? Or...
Probably worth removing the argument, now that we understand what it is.
I don't think a shorter timeout really solves anything (probably), it'd just give us a chance to spit out some kind of "I don't know what happened but things broke...
How does this approach compare to fully computing the arrays and having them reside on disk, instead lazy-loading them? Why is computing them lazily preferable?
How trivial are the computations? I get the storage benefits (and they could be pretty substantial) With lazy-loading, the data is essentially read-only when done, which is good for data...
I think I misunderstood the proposal on first read; assuming what you meant was exactly the computations above, this seems reasonable, although is there a reason to have the arrays...
Oh, that "it is not trivial to create" makes me worried. One thing I think we should aim for is making it easy for exterior code to do analysis of...