Split repo into five focused artifacts

[stefanhahmann]

Motivation

The current monorepo bundles everything — imglib2 model, Fiji/BDV integration, backend I/O (N5, zarr-java), and UI — into a single artifact. This makes it impossible for non-Fiji Java tools (QuPath, Icy, custom pipelines) to depend on just the OME-Zarr reading logic without pulling in the full Fiji stack. It also forces Fiji plugin authors to take both backends even if they only need one.

Proposed artifacts and dependency hierarchy

                      ome-zarr-imglib2  (API, no backend)
                     /        |        \
          ome-zarr-n5   ome-zarr-zarr-java   ome-zarr-fiji  (API, no backend)
                     \        |        /
                       ome-zarr-fiji-ui

Both ome-zarr-imglib2 and ome-zarr-fiji are API-only artifacts (analogous to slf4j-api): they define interfaces and integration layers but ship no backend. Neither is useful in isolation — a backend must be present on the classpath. The backends (ome-zarr-n5, ome-zarr-zarr-java) pull in ome-zarr-imglib2 as a transitive dependency, so downstream consumers rarely need to declare it directly.

ome-zarr-imglib2 (API, no backend)

• No dependencies on Fiji, ImageJ, BDV, N5, or zarr-java
• Conatins: Pyramidal interface
• Contains: PyramidalContents class (backend-agnostic methods only: numChannels, numTimepoints, numResolutionLevels, getType, getName, getOmeroProperties), OME-Zarr metadata model, imglib2 types, coordinate transforms, channel/timepoint metadata
• Contains: PyramidBackend interface
• Perhaps with a new asImg() method
• Non-Fiji developers (QuPath, Icy, …) should depend on ome-zarr-n5 or ome-zarr-zarr-java directly; they get ome-zarr-imglib2 transitively

ome-zarr-n5

• Depends on ome-zarr-imglib2 + N5-universe
• Provides a concrete N5-backed implementation of PyramidBackend
• Fully usable standalone for non-Fiji developers — adding this artifact gives complete OME-Zarr reading capability with no Fiji dependency

ome-zarr-zarr-java

• Depends on ome-zarr-imglib2 + zarr-java
• Same as above, backed by zarr-java instead

ome-zarr-fiji (API, no backend)

• Depends on ome-zarr-imglib2 only — no backend dependency
• Provides PyramidalBdv, PyramidalDataset, PyramidalPreprocessor, PyramidalService
• Not useful standalone — consumers must also depend on ome-zarr-n5 or ome-zarr-zarr-java
• A Fiji developer who wants N5 declares ome-zarr-fiji + ome-zarr-n5; one who wants zarr-java declares ome-zarr-fiji + ome-zarr-zarr-java.

ome-zarr-fiji-ui

• Depends on ome-zarr-fiji + ome-zarr-n5 + ome-zarr-zarr-java
• Contains all UI/UX logic: DnDHandlerPlugin, ZarrOpenActions, DnDActionChooser dialog, OpenInBDVCommand, OpenResolutionLevelCommand, ClipboardUtils, ScriptUtils
• The artifact end users install into Fiji; supports both backends

Summary: who depends on what

Consumer	Dependencies
Non-Fiji developer (QuPath, Icy, …)	ome-zarr-n5 or ome-zarr-zarr-java both pull in ome-zarr-imglib2 transitively
Fiji plugin author (N5 backend)	ome-zarr-fiji + ome-zarr-n5
Fiji plugin author (zarr-java backend)	ome-zarr-fiji + ome-zarr-zarr-java
End user installing into Fiji	ome-zarr-fiji-ui (pulls in everything)

Preparation for splitting repo:

1. Clean up the Pyramidal5DImageData interface boundary

(from issue "Key design decision" + tpietzsch comments)

• Define the backend-agnostic subset that will live in ome-zarr-imglib2: numChannels, numTimepoints, numResolutionLevels, getType, getName, getOmeroProperties
• Add a new asImg()
• Move Fiji/BDV-typed methods off the interface — asPyramidalDataset(), asPyramidalDataset(int), voxelDimensions(), and (currently on the impl) asDataset(), asImagePlus(), asSources(), asImgPlus()
• Add generics to the load method rather than the PyramidBackend interface - <T...> PyramidContents load(URI inputURI)
• Allow a PyramidBackend to be instantiated independently of the URI it reads

2. Clean up PyramidContents

(from tpietzsch comment "On the interface boundary")

• For the fields numChannels / numTimepoints / numDimensions — add javadoc; either drop the fields in favor of final methods, or provide a default that derives them from resolution level 0
• Reduce overspecification — derive dimensions from the full-resolution CachedCellImg instead of storing them
• Resolve channelAxisIndex vs zAxisPresent/timeAxisPresent inconsistency (and overlap with AxisCalibration) — remove, or make them methods consistently for all axis types
• Remove mpicbg.spim.data.sequence.VoxelDimensions — AxisCalibration already carries this information
• Document the source/target coordinate systems for transforms

3. Separate the volatile (V) type from the imglib2 layer

(from tpietzsch + stefanhahmann comments)

• Drop the V generic from PyramidContents → PyramidContents (and from PyramidBackend)
• Remove the volatileImgs field (and volatileType) from PyramidContents — these belong in the future Fiji layer
• Do the VolatileViews wrapping in the Fiji layer; have the Fiji layer expose V (used only for BDV display)
• Audit current Volatile/VolatileViews usage in Pyramidal5DImageDataImpl, PyramidalBdv, and both backends so the wrapping has a clear new home

4. Resolve the in-code TODOs

• Pyramidal.java:46 — decide the fate of the "may be removed" delegating defaults (numChannels, numTimepoints, getOmeroProperties, voxelDimensions); align with the new backend-agnostic subset
• PyramidalDataset.java:62 — move preferredMaxWidth handling out of the Pyramidal5DImageData level (e.g. into the opening Command), since it's a UI/opening concern
• OpenResolutionLevelCommand.java:101 — allow PyramidalDataset to be constructed from (context, pyramidContents, level) without a Pyramidal5DImageData, decoupling the dataset from the backend impl

5. Layer/dependency hygiene within the current monorepo

(prep so packages map cleanly onto future artifacts)

• Verify no class in the future ome-zarr-imglib2 set references Fiji/ImageJ/BDV/N5/zarr-java types (the interface + metadata model + transforms)
• Confirm both backends (backend/n5, backend/zarrjava) carry no Fiji dependencies
• Update BackendBenchmark to compare N5 vs zarr-java loading times (validates backends stay independently usable)

Tasks for the actuall splitting into artefacts

• Decide whether this is a Maven multi-module repo or separate repos
• Identify which current classes belong in each artifact
• Ensure ome-zarr-imglib2 compiles with no Fiji/BDV/N5/zarr-java deps
• Ensure ome-zarr-n5 and ome-zarr-zarr-java compile with no Fiji deps
• Update CI, release, and versioning accordingly

[tpietzsch]

On the interface boundary of ome-zarr-imglib2:

• PyramidContents has numChannels, numTimepoints, numDimensions. What is the relation between those? (Maybe add javadoc while discussing this)
  • Either remove these fields from the class and instead make it final methods
  • Provide default implementation, which uses resolution level 0 for these dimensions
• The interface is a bit overspecified. Rather fetch the dimensions from a CachedCellImgs of the full resolution.
• channelAxisIndex vs zAxisPresent, timeAxisPresent is inconsistent. Also seems duplicate information with AxisCalibration? Index vs. isPresent for different axes types is not good.
  • Either remove at all or it should at least be methods and if it be there, it should be there for all dimensions.
• Don't use mpicbg.spim.data.sequence.VoxelDimensions. Remove it, since AxisCalibration is doing the intended job.
• What are source/target coordinate systems for transforms? - Add javadoc for this.
  • Remove the field transformation from PyramidContents
  • Use now only translation and scaling

[tpietzsch]

No generics on the interface, instead on the load method.

public interface PyramidBackend {
	<T extends NativeType<T> & RealType<T>, V extends Volatile<T> & NativeType<V> & RealType<V>>
	PyramidContents<T, V> load(URI inputURI);
}

Support the use case that a PyramidBackend can be instantiated independently of the URI that it should read from.

• I would not expose the V type on PyramidContents. This is only relevant for showing in BDV. I would do the VolatileViews wrapping in the ome-zarr-fiji layer.

Without V generic:

public interface PyramidBackend {
	<T extends NativeType<T> & RealType<T>>
	PyramidContents<T> load(URI inputURI);
}

[stefanhahmann]

This field does not need to be in the imglib2 layer, but only in the fiji layer.

private RandomAccessibleInterval< V >[] volatileImgs;

The FIJI layer may then expose the V

[stefanhahmann]

Try to have an updated BackendBenchmark to compare loading times.

[stefanhahmann]

[stefanhahmann]

ClipboardActions
ZarrOpeningSettings
ZarrOpenBehavior
ClipboardUtils
ScriptUtils
ZarrUtils

• Should go to fiji-ui

BdvUtils
ZarrOpenActions

• Should go to fiji layer
• ZarrOpenActions needs to be split into two classes (one for fiji-uiand one fiji)