Gregory Jefferis

Hi @Erginkayam somehow dropped this last summer, but hit it recently myself. One workaround was to convert the neuron to an `ngraph` object, but this returns all endpoints rather than...

I will commit a fix shortly.

This is not good news at all, since there must be numerous cases in the wild where we may rely on this behaviour. This includes * [mirror.default](https://github.com/jefferis/nat/blob/3362ad87bbda2584fba7b5578ed9a6cdc6bb57af/R/xform.R#L520-L549) in nat *...

it looks like a significant overhaul of registration classes may be in order, to fix this, handle #387 and allow better mixing across different registration formats including: * [`h5reg`](https://github.com/jefferis/nat.h5reg/blob/81f2b30879bc395b5c71543be392659193d062f9/R/h5reg.R#L59-L67) *...

I wonder if I should add this to the some of the updates planned for nat v2 (e.g. adding a base class for objects with 3d coordinates)

May also need to change dtype in write.amiramesh. Or accept that we have dtype which accepts a subset of type names and use header$type to set using any nrrd type...

I think that we could have different options for dtype in `write.amiramesh` and `write.nrrd`. But the option of setting fancier type values in header$type is also fine I think.

One issue to think about carefully if this is implemented is handling of default type, endian and encoding values which are carried forwards from nrrds that have been read in...

For `"XY", "YZ", "XZ"` compare with e.g. Amira Orthoslice. `ZY` has the Z and Y axes switched. `YX` and `ZX` are also possible but I never wanted them. ``` plot(Cell07PNs[[1]],PlotAxes...

Incidentally, I don't know if `nat` needs to know about anatomical coordinate systems or not (see e.g. http://www.slicer.org/slicerWiki/index.php/Coordinate_systems). We do want to keep it general i.e. not tie it to...