You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
axis naming is a hard issue. it's a necessary evil. There are obvious conventions out there (e.g. XYZCT) but extensions are always needed (e.g. P position, G grid, row/col etc...). Ultimately useq-schema should only care about mapping an arbitrary string to an iterable of coordinates for that dimension. This is mostly what MDASequence does, albeit with hard-coded assumptions about the dimensions for now, so as to make it easy to accomplish the vast majority of use cases. The underlying code still just treats it as an iterable (mostly arbitrary) axes. but more could be done
axis naming is a hard issue. it's a necessary evil. There are obvious conventions out there (e.g. XYZCT) but extensions are always needed (e.g. P position, G grid, row/col etc...). Ultimately useq-schema should only care about mapping an arbitrary string to an iterable of coordinates for that dimension. This is mostly what
MDASequence
does, albeit with hard-coded assumptions about the dimensions for now, so as to make it easy to accomplish the vast majority of use cases. The underlying code still just treats it as an iterable (mostly arbitrary) axes. but more could be doneSequence[str]
notstr
#138MDASequence
is essentially a subclass of that more general pattern, with "known" axes PGZCTThe text was updated successfully, but these errors were encountered: