Support Int8, Int16, and Int32 textures

[manzt]

Fixes #370 more robustly..

The primary change in this PR is that we don't cast any TypedArrays unless there is no WebGL2 support. In addition, all of the handling of webgl2 vs webgl1 is isolated to just before creating a texture. This changes the previous behavior where both ImageLayer and MultiscaleImageLayer checked for WebGL2, now it's done in once place: dataToTexture.

The main weirdness seems to be that the text is black on the example image. @ilan-gold, I'm not sure if you know why this is the case.

[manzt]

Update: FWIW, I think this actually is the right behavior. This is the same image in napari:

[ilan-gold]

@manzt It's good that we agree with Napari. If you look at the picker tool in Avivator over those points, they are negative one, which causes the shader to render black simply because the output there is either less than 0 for the auto-slider values (which are 1 for each channel) or 0 if you move the slider to the min value of the domain (-1). But in theory, the sliders should be able to go from -127 -> 127 for this image (and they would be able to in Vitessce because we have the "Full" option). So we could have an image like this:

Note the "Blue" slider value which is -114

[ilan-gold]

Looks good. Let's add that min option to DTYPE_VALUES so this works nicely with Vitessce's "full" option. Thanks!

[manzt]

@ilan-gold I added a JSDoc @deprecated tag to DTYPE_VALUES. This will add a strikethrough to uses of DTYPE_VALUES, DTYPE_VALUES, and offer a message that references my comment. (It will also show a strikethrough when referenced within Viv's source, but this happens in one place and the warning is intended for end users).

[ilan-gold]

Ok! Thanks!

[oeway]

@manzt Will you update it in vizarr too?

[manzt]

@oeway, yes when I get the chance. Hopefully this week, now that we've made a release.

[will-moore]

Just noticed with https://github.com/hms-dbmi/vizarr/pull/136/files that DTYPE_VALUES is still being used in vizarr (and linked here).