Constantin Pape

> The thing is that it's actually _sub_pixel _coordinates_... Ok, I will check out the paper. But just to clarify, for now the `pixel_indices` returned always correspond to the pixel...

> they are trees in one particular domain You're right, this is only true in the narrow-minded connectomics sense :). I will implement some functions to check if a skeleton...

@jni The bug is still present on master. The issue is that the coordinate for node `3` is mistakenly calculated as `[3., 3.]` instead of `[3., 2]`. To reproduce it:...

> sorry if I sounded a bit dismissive! No worries, I was just distracted from this by other projects. Hope to work more on the skeleton related things soon. >...

Thanks for working on this @bogovicj, a few first comments from my side: > * inverse_of : [when transforms applied to images are not closed-form-invertible](https://github.com/bogovicj/ngff/wiki/Transform-List#inverse_of) > * bijection: make an...

@bogovicj Here's the work for padded string support in n5-zarr. It's very preliminary and hacky, I am sure there are more elegant ways of doing this. Note that the current...

> 1. @DragaDoncila and/or @joshmoore might want ot comment on this but my understanding is that both keys are optional (maybe RECOMMENDED) Ok, this would be good, but should be...

> One possibility is that the ongoing transformation/spaces work in #101 #84 would allow to specify metadata to register different multiscale images relative to another in the same coordinate space...

> Would this single versioning apply only to a given hierarchy level e.g. the multiscales image should have a top-level `version` that applies to `multiscales`, `omero`... or would it be...

> Agreed, @constantinpape. This was my mistake because I was thinking you "owned" latest while I was making a non-breaking change. Something that hadn't been done before. Sure, no worries....