cornerstone: large file handling?

[kousu]

An image <10MB is reasonable to load

but some files, especially large 3D scans, take a noticeable amount of time to download, lag out people's browsers, and often aren't even worth the wait (at least until #26):

Can we do anything about this?

[kousu]

We can:

• render the previews server-side
• try to use HTTP ranges

Server-side previews are complicated. They mean adding a slew of extra HTTP routes and NIfTI parsing code to the backend and a complicated front-end dance to work with them. So I don't like that idea.

HTTP Ranges are nice, but it doesn't seem that Gitea supports them:

p115628@joplin:/tmp/spine-generic-single$ curl -I https://data.dev.neuropoly.org/neuropoly/spine-generic-single/media/branch/master/sub-perform/anat/sub-perform_T1w.nii.gz 2>&1 | grep Accept-Ranges
p115628@joplin:/tmp/spine-generic-single$ 

but I think maybe this is the right place to patch it in?

https://github.com/neuropoly/gitea/blob/243af58365634c44b125f095c313d2a0fae431a4/routers/common/repo.go#L108-L115

A Range header isn't that hard to support, it just requires adding a 'Seek()'; now, a problem is that the code is set up with io.Readers; we could try to retrofit it to say a ReadSeeker, or do the dumb thing and just scan forwards until we hit the requested range, which is possible because there's no need to scan backwards.

And then we'd probably have to patch Cornerstone to understand Range Headers and partial files. Which might be much harder. But if we got it working then you should be able to quickly load a slice of a 3D image, and lazily download on demand further slices as you scroll through the image. There's still a complicated frontend dance here, but it's based on a standard protocol (range headers) instead of making something up as we go.