Apply OME coordinate transformations

[manzt]

Cherry picked changed from #242. There was a pretty substantial refactor of state to make it more consistent and type safe.

[will-moore]

@manzt I just tried this with https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0101A/13457537.zarr which has xyz translations and I don't see anything in the viewer (all black).
When I zoom really far out, I eventually managed to find a tiny image but it vanished when I tried zooming in.

I'm guessing that the Z translation moves the image out of the visible plane and that moving the Z slider doesn't help as its not really 3D viewing?

[manzt]

I see, I just swapped in your implementation for coordinateTransformationsToMatrix and it seems to be working. I haven't had the time to look and sort out why, I'm happy to accept a PR that improves how we build the matrix, now that we have an isolated function that performs this translation and the rest of the wiring is all lined up. Sorry for suggesting to remove the changes from #259 so quickly.

export function coordinateTransformationsToMatrix(multiscales: Array<Ome.Multiscale>): Matrix4 {
  let matrix = new Matrix4().identity();
  let scaleX = undefined;
  let scaleY = undefined;
  let dx = undefined;
  let dy = undefined;
  const coordinateTransformations = multiscales[0].datasets[0]?.coordinateTransformations;
  if (coordinateTransformations !== undefined) {
    for (const transform of coordinateTransformations) {
      if (transform.type === "scale" && transform.scale !== undefined) {
        scaleX = transform.scale.at(-1);
        scaleY = transform.scale.at(-2);
      }
      if (transform.type === "translation" && transform.translation !== undefined) {
        dx = transform.translation.at(-1);
        dy = transform.translation.at(-2);
      }
    }
  }
  // Deck.gl translate happens BEFORE scale (opposite of OME-Zarr)
  if (dx !== undefined && dy !== undefined) {
    // NB: we don't handle the Z translation
    matrix.translate([dx, dy, 0]);
  }
  if (scaleX !== undefined && scaleY !== undefined) {
    // NB: we don't handle the Z scale
    matrix.scale([scaleX, scaleY, 1]);
  }
  return matrix;
}

[will-moore]

My implementation was a bit naive in that it simply ignored any Z values for scale and transformation. So it "worked" with translating X and Y in my example.
I don't know if vizarr can really support the concept of Z scale/translation? I kinda assumed it behaves like a 2D viewer that moves through Z in the same way as through T (like OMERO viewers!). Each Image in vizarr has it's own Z and T sliders so they can move in their own Z/T space and not a "shared" Z/T space (so it's almost meaningless to scale them differently in Z)?
Whereas viv/Avivator is actually a 3D viewer?