Use the quad_info endpoint for tile_frames.

[manthey]

Now, precaching the tile frames can be done by calling the tile_frames/quad_info endpoint with cache=schedule. To match what is done in the javascript side, this endpoint needs to be called per channel with frameBase=, frameStride=, frameGroup=<IndexZ || 1>, frameGroupStride=<IndexZ / IndexC>. This is in addition to the defaults used in this project defined in src/store/index.ts around line 745.

To make this more convenient, we could add (to large_image) a special value for frameBase which would schedule all tile_frames based on this heuristic.

[arjunrajlab]

Is everything there for us to test it out? I think incorporating the defaults into large_image would make the most sense, long term.

[manthey]

Once girder/large_image#792 is merged, you can hit the GET /item/{itemId}/tiles/tile_frames/quad_info endpoint to schedule all appropriate tile_frames computation and caching given an image's item ID. Specifically, for this project, we will want to use the following parameters:

{
    'query': 'style=%7B%22min%22%3A%22min%22%2C%22max%22%3A%22max%22%2C%22palette%22%3A%5B%22%23000000%22%2C%22%23ffffff%22%5D%7D&cache=true',
    'maxTextureSize': 4096,
    'maxTextures': 32,
    'frameBase': 'c',
    'frameStride': 'c',
    'frameGroup': 'z',
    'frameGroupStride': 'auto',
    'cache': 'schedule'

The query parameter is the "auto brightness" used to make the preview cover as much dynamic range as possible. The maxTextures and maxTextureSize are values we decided work well for this project. The frame... parameters are the automation to generate separate textures by channel and then within that group z sequences together. The cache parameter says to schedule caching if it isn't already done.

[manthey]

The appropriate branch is merged in large_image and a release is currently being built. As per today's discussion, I'm merging this PR.