New Avivator

[ilan-gold]

For #398 this is the next issue on the list for #415. It contains all of the features in the list on #415

Change List

• Arbitrary slicers implemented via spherical coordinates
• More compact styling
• Robust on-load callbacks to give deterministic behavior
• Improved z-slicer experience via arrow key selection and better on-load callbacks as well as making ImageLayer capable of cancelling requests when it finalizes its state
• Unify all rendering to happen in "physical coordinates" (so this is a resolution of 3D Viv Core #409 (comment)). I can't see a good reason to use the pixel coordinates since we have to scale volumes anyway to make them render properly i.e if you wanted to overlay something, you would have to use physical coordinates anyway, but it's possible I am wrong in this inclination. I opened an issue in image.sc about this: https://forum.image.sc/t/ome-roi-coordinate-system/51781. Previously, downsampled resolutions rendered in a space defined by their literal pixel sizes but now those pixels are scaled up by the layer to what the full volume would be (just like an image pyramid). This was an oversight on my part, but while implementing the plane-clipping/resetting the camera, it became apparent that this would be necessary for consistency of those implementations with an external applicatoin.
• Translation/fixed axis-of-rotation of the camera.

Checklist

• Update JSdoc types if there is any API change.
• Make sure Avivator works as expected with your change.

[ilan-gold]

The reason for splitting this is that scale encodes the pixel-based scaling of the volume while resolution is for "scaling up" to the volume's full resolution dimensions. We can't make one matrix unfortunately because scale is used on the fragment shader (and pre-multiplying resolution would make that problematic).

[ilan-gold]

This was a bug :(

[manzt]

Minor notes on some API choices. Nice work!

[manzt]

Similar to the comment in the other PR, is it possible to remove the "multi" variants of these settings. It would be easier to use them in a modular manner. In addition, currently we need to wait for all the "channel" stats before updating any of the UI. Why not fire off all these changes asynchronously? Update each domain & slider independently, whenvever the data comes back.

[ilan-gold]

Similar to the comment in the other PR, is it possible to remove the "multi" variants of these settings.

You mean the multiple channel version? Sure I can just use the single channel version and remove the other.

In addition, currently we need to wait for all the "channel" stats before updating any of the UI. Why not fire off all these changes asynchronously? Update each domain & slider independently, whenvever the data comes back.

The idea here is that the channel stats come back much much quicker than the actual data often times for 3d volumes so we only want the sliders change once the 3d volume is loaded and ready for rendering. Otherwise you get a sort of flashing effect where the sliders change but the actual data has not.

[manzt]

Possible to hoist this up into a function? hard for me to see what's going on. Not sure what r is.

function formatter(label) 
  const isRadius  = label === 'r'; // useful variable name
  return (value) => {
    const val = truncateDecimalNumber(isRadius ? : v / Math.PI, 4);
    ... 
  }
}

//... 

valueLabelFormat={formatter(label)}

[manzt]

Why not use an object?

setClippingPlaneSettings(0, { radius, phi, theta });

[manzt]

Another example of where getting stats independently would allow the UI to update on demand rather than waiting for each channel before any UI update.

[manzt]

why not https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed?

[ilan-gold]

I think the issue is its behavior on non-floats, like

Number.parseFloat(1234).toFixed(6)
"1234.000000"

[ilan-gold]

Maybe there's another way of doing this?