Clarify dimension order in the specs

[jkh1]

There is some confusion about what the specs say about image dimension order. It's been understood either to be arbitrary as defined in the metadata or fixed at t,c,z,y,x. Now I'm told that the specs should read first t, then c, then arbitrary space dimensions order which is indeed what careful reading of the specs would lead to.
I would suggest to amend the sentence:
"All image arrays must be up to 5-dimensional with the axis of type time before type channel, before spatial axes."
to make it clear it's independent from the t,c,z,y,x example.
maybe something like:
"All image arrays must be up to 5-dimensional with the axis of type time before type channel, before spatial axes which can be in arbitrary order".
Also make it clearer in the multiscale metadata section, in particular the following sentence:
"If there are three spatial axes where two correspond to the image plane ("yx") and images are stacked along the other (anisotropic) axis ("z"), the spatial axes SHOULD be ordered as "zyx"."
should also mention that in the case of two spatial dimensions, order is arbitrary or should/must be "yx".
Alternatively, since so far all examples I've seen use t,c,z,y,x, maybe the specs should simply fix the spatial dimensions order to z,y,x.

[will-moore]

My understanding is that if there are 2 dimensions then they SHOULD be yx, which I see is not explicitly stated in the spec.
This could be stated more clearly after the "If there are three spatial axes..." sentence.

Therefore I don't think that we should add "...which can be in arbitrary order" to describe the spatial axes in the t,c,z,y,x example.
Does that make sense?

[jkh1]

Yes so I think this is equivalent to saying the order SHOULD be t,c,z,y,x. In this case it should also say either that any dimension is optional or there MUST be at least two spatial dimensions (i.e. can we store just one dimension only e.g. or any two e.g. t,x though we can debate whether this is still an image?)

[clbarnes]

To me, formatting this as a table would be much simpler:

Axes must be, in this order:

Required	Type	Conventional name	Notes
No	"time"	t
No	"channel" or custom	c
No	"space"	z	SHOULD be the anisotropic/ stack axis if present
Yes	"space"	y
Yes	"space"	x

[joshmoore]

@clbarnes, could certainly work. Are you interested in giving this a shot for the imminent 0.5 version?