Link structures converted from Java -> Python

[mpinkert]

Currently, only structures converted from Python to Java are linked. E.g., modifying a dataset that came from a numpy array will also change the numpy array.

The converse is not true. Creating a Python object from a Java object will make a new Python object that is not linked to the Java object.

Changing this would require a different interface to the JVM, as this is a limitation of pyjnius (currently).

This would be a nice-to-have feature.

[hinerm]

Is this still true in Jpype..?

[ctrueden]

Still true in JPype. To go the other way requires a substantial amount of coding, to wrap a Java-side ImgLib2 image into a "numpy-array-like" structure, which could work in many Python scenarios via duck typing.

(I don't think it's true that a different interface than pyjnius would have been needed... but either way, would need Python-side wrapper structures, in an analogous way to how we have Java-side ImgLib2 wrapper structures around memory pointers of numpy arrays.)

To be more precise: there are actually four cases:

1. Wrapping a numpy block of memory to ImgLib2. (currently supported)
2. Wrapping any numpy-like object, which may not be a block of memory, to ImgLib2. (not supported yet)
3. Wrapping a Java-side block of memory allocated off-heap (e.g. via ByteBuffer.allocateDirect) to Python. (not supported yet; analogous to (1) but in the Java-to-Python direction).
4. Wrapping any Java-side ImgLib2 object, which is very likely not a block of memory, to Python. (not supported yet)

There may also be further case logic and/or restrictions with any of the above, depending on whether Java was started as a subprocess from Python, or vice versa.

So this issue could really be about (3), or (4), or both. And we don't have an issue currently for (2). I do think (1) and (4) are the most pragmatically useful things, but (2) and (3) are potentially also useful in some cases.

[hanslovsky]

(3) should be possible already, albeit I don't think there is a convenience method for that. Things may have changed since I was last involved with imglyb (it was still pyjnius back then), but there is/was a way to generate ImgLib2 ArrayImgs backed by native memory and you can then simply pass that pointer into a numpy array.

I have wrapped a numpy-like object into a cached cell img (2). I don't remember what exactly the object was but as long as the individual cells can be mapped to native memory, this shouldn't be too much of a challenge. It is a different story for completely arbitrary objects, though.

(4) may be challenging. When I toyed around with JNI, I found it to be terribly slow, so interaction between Java and C/Python at a per-voxel level may not work. One example that might pose a challenge is in-place addition of a wrapped ImgLib2 object into a native numpy array, e.g.

native_numpy_array += wrapped_imglib2_object

This may be simple if the += can be overwritten in the new class that represents the wrapped object. Then, the native_numpy_array could be temporarily wrapped as imglib2 and the += could be implemented with Java only.

[ctrueden]

Since (1) is done, and (4) is effectively now done thanks to @JImplementationFor providing arraylike API access to JPype-wrapped Dataset, Img, RandomAccessibleInterval, etc., let's close this. @gselzer and I filed #202 and #203 to cover the remaining cases discussed above, which are not urgent to implement.