neurodata
Bug in fetching data for zoom-in cutouts.
Ostensibly http://openconnecto.me/ocp/ca/kasthuri2015_ramon_v4/synapses/hdf5/1/4478,5120/8458,9158/1041,1057/ returns an H5 file of dimensions (16, 700, 640) when its supposed to be (16, 700, 642).
@kunallillaney @wrgr
Other things to note: we replicated this on both dsp and brainviz servers (separately created, but identically named token/channel pairs). And with blosc and hdf5.
Thoughts? Stopping science and all that. :) @alexbaden
The project you are requesting data from has the base resolution as res3. In order to provide a cutout at res1, we translate that to res3 dimensions, up-sample and then trim it. There seems to be a bug when we calculate the dimensions at res3 because we don't seem to take into account the trimming effect, which is larger at a higher resolution(res1) resulting in truncated data. This will not get resolved this week. I have a bunch of stuff on my plate which is more time critical and will have to be moved to some time next week.
This can be mitigated for now by cube aligning your cutouts. The trimming only occurs when you request a cube which is not cube aligned.
If we could revisit this week, would be very helpful.
Definitely not possible to cube align for everything...we could precompute blocks on the client side and trim, but seems like not the right answer.
This is common for things like accessing bobby's data (e.g., ndpaper claims) that exist at particular locations, or cases where windows are fixed.