handles ndarray type parsing for types in short notation with bytes

[gletort]

In NDArray() function, dtype str can be a short notation in bytes instead of bits (more standard). Handles that case by not dividing by 8 when it's not a standard notation.

[ctrueden]

@gletort Thanks for the detailed report on Zulip as well as this PR, and apologies for the delay in response. Your diagnosis was spot on: short-form dtypes like >u2 count bytes rather than bits, so Appose was allocating 1/8 of the needed memory.

While digging in, I decided dtype handling needed a more thorough fix across both appose-python and appose-java, so Claude and I built on your branch:

• NumPy-style short forms (u2, f4, |u1, =c8, ...) are now accepted and normalized to standard names (uint16, ...), with a fixed table of platform-independent types, so parsing behaves identically everywhere. float16 is now supported too.

• Appose arrays are always in native byte order (shared memory never crosses machines), so an explicit </> prefix is now rejected with a clear error rather than silently misinterpreted.

• We also added a new convenience for exactly your use case:

  shared = appose.NDArray.from_ndarray(img)

  It allocates the shared memory and copies the data in one step. Your big-endian image works directly: NumPy byte-swaps the values during the copy, so no
  newbyteorder conversion is needed.

One gotcha: str(img.dtype) gives '>u2' for non-native arrays, whereas img.dtype.name always gives the standard name ('uint16'). So if you construct an NDArray yourself, use dtype.name.

[gletort]

On my use case, switching the str(img.dytpe) to str(img.dtype.name) works well now, without needing anymore the newbyteorder. But I don't see the appose.NDArray.from_ndarray fonction ? It's in the shm.py file ? Maybe I messed up my pull of this branch

[ctrueden]

I don't see the appose.NDArray.from_ndarray fonction ? It's in the shm.py file ?

Ahh, I forgot to push. 🤦 Done now! I'll merge it as soon as tests pass.

[ctrueden]

OK, I lied: I decided to fix the horribly confusing naming of NDArray.ndarray() returning a NumPy array. It is now more aligned with appose-java and imglib2-appose:

---

Copy a native array into new shared memory

• appose-python: NDArray.copy_of(arr)
• imglib2-appose: ShmImg.copyOf(rai)
• appose-java: —

---

View shared memory as a native array (no copy)

• appose-python: numpy.asarray(nda)
• imglib2-appose: NDArrays.asArrayImg(nda)
• appose-java: nda.buffer()

---

Get an NDArray from a native array (view if it wraps one, otherwise copy)

• appose-python: —
• imglib2-appose: NDArrays.asNDArray(rai)
• appose-java: —