Refactor classes

[gselzer]

This draft PR aims to reorganize this library, such that we can more easily accomplish the following goals:

• Discover all of the functionality available
• Compare function A with function B

I was motivated to submit this PR because:

1. There are many operations with subtle differences, which are not easily findable to the untrained eye. As an example, if you just want to convert your Img<T> to an ImagePlus, you have:
   • ImageJFunctions.wrap(RandomAccessibleInterval<T> img) and its many friends
   • ImgToVirtualStack.wrap(ImgPlus<?> imgPlus) and its many friends
   • ArrayImgToVirtualStack.wrap(ImgPlus<?> imgPlus) and similar functions for PlanarImg and CellImg.
2. We are writing a new library, meaning it is the perfect time for a large-scale refactoring

The goal of this PR is to reorganize all functionality by purpose, while also making it clearer in future PRs which functionality should be migrated out to other libraries (e.g. imagej-legacy) and to reorganize for natural packages when this library eventually becomes modularized. The work isn't quite done yet, but it is ready for initial opinions. Specifically, I still want to decide about:

• ArrayImgToVirtualStack, CellImgToVirtualStack, PlanarImgToVirtualStack - ideally, these could be encapsulated within a single function somewhere (ImgPlusToImagePlus?), to avoid case logic like this
• ImagePlusImgs feels like it could be top-level.

Happy to hear opinions from @ctrueden and @tpietzsch

[imagesc-bot]

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/fiji-friends-weekly-dev-update-thread/103718/71

[odinsbane]

Great! I have started moving from ImagePlus to imglib2 classes. So this is very relevant to me.
I hope we don't see something along these lines. https://xkcd.com/927/

• I am using List<Source<?>> and List<ImagePlus> to represent multichannel 3D time series.
• The 3D spatial aspects found in the imagej calibration are the most important to me.

I have some tests written, and Ill gladly adapt to a more unified library. Especially if it means there is better agreement on how the Calibration relates to imglib2 associated values.

MeshImageStack2 is an imglib2 version of a class that was originally built on an ImagePlus. So this class converts List<Source<?>> to ImagePlus.

This class SaveImageToZarr is going the other direction and changing an ImagePlus to an RandomAccesssibleInterval to be saved with the N5 library.

[gselzer]

I hope we don't see something along these lines. https://xkcd.com/927/

Yeah...it's unfortunate that this project is necessary in the first place, but at least it gives us an opportunity to clean - imglib/imglib2-ij#37 gives some rationale if you hadn't seen it.

The best thing we can do is file PRs wherever imglib2-ij was used (I started that, but then I got annoyed with the public API, hence this PR 😅), and there will of course be natural pressure/complusion to switch to this library when maintainers bump their Java version.

[odinsbane]

I am not completely familiar with all of the imglib2, imagej nuances.

When should I start using this? It seems like it it will be targeting the java 21 version of fiji?

[gselzer]

When should I start using this? It seems like it it will be targeting the java 21 version of fiji?

It is not yet ready for usage as there is no available release, but yeah, our plan is to target the Java 21 version of Fiji. At that point, I'd advise using imglib2-ij for Java 8 projects, and this library for Java 11+.

[gselzer]

• ArrayImgToVirtualStack, CellImgToVirtualStack, PlanarImgToVirtualStack - ideally, these could be encapsulated within a single function somewhere (ImgPlusToImagePlus?), to avoid case logic like this

Current thoughts are that this should not be exposed due to the dependency on ImgPlus, which we are talking about removing from this library (see #4) - will remove in a separate PR though, along with the rest of the ImageJ2 imports.

• ImagePlusImgs feels like it could be top-level.

Have removed any exposure of this class (using PlanarImg instead) from top-level API, although we can always expose it later if needed. Would rather keep it private and make public later than make it public from the beginning and be unable to go back.