Gregory Jefferis

My next thought was to provide a specialised `xform.neuron` method and to have that intercept the case when `reg` is a function (see 2993a4b2291c8cadda295eeef85db53de3e71e43). That sort of works, but fails...

Adding further specialised logic to [`xform.neuron`](https://github.com/jefferis/nat/blob/2993a4b2291c8cadda295eeef85db53de3e71e43/R/xform.R#L135-L149) to handle `reglist` type registrations by peeking inside them feels very inelegant.

Perhaps one could add `xformneuron.reglist` and have that sort out the logic applying transforms. But that's actually pretty close to what I just mentioned and would largely duplicate `xformpoints.reglist`.

Maybe we need a different class of transform that signals that it can be applied to Nx4 points and will scale diameters accordingly. But that still implies that we need...

Something like: ``` r #' @param x A neuronlist whose names will be registered as canonical identifiers for these neurons. #' @param moreids A named character vector that maps additional...

Of course register still seems like a less than ideal name for the generic given how much image registration we do ...

> Looks good to me. Perhaps deposit as an alternative to register? I wonder if deposit has the suggestion of putting the neurons into a location rather than telling someone...

The main change besides adding the `register/deposit` function would be to update `plot3d.character` to use it. Possibly there should be a separate function that fetches neurons by identifier.

May be because rds files do not contain reglist objects.

some work already on feature/im3d-sub branch but does not handle bounding boxes for singleton dimensions properly ``` `[.im3d`