Overview Multiplexing

[jluethi]

The general goal of multiplexing workflows is to parse multiple acquisition cycles into the same OME-Zarr and have a flexible processing setup that allows users to process tasks by cycle, process across cycles and process individual cycles separately.

How do we run workflows across multiplexing cycles?

The main answer will be using a new parallelization level, see discussion here: #199 (comment)

Parallelization levels solve the question of how we run tasks on all cycles vs. across cycles in the same well. There are 3 questions remaining though:

1. Parameter handling for the multiplexing case: How do we specify the parameters for the different cycles

One of the core parameters that we need to handle (and which needs to generalize for multiplexing): Channel names, matching operations to channel names. See details (to be expanded) here: #211

But we’ll also need to decide how a user can set some parameters for all cycles and some varying by cycle. Details expanded her: #230

That’s important to make tasks work with multiplexing, see here for the example of what happens in cellpose task without this new approach: #227

2. Submission: How do we handle submission for all cycles & for subset of cycles in this mode?

What appears to already be working is submitting a workflow to the whole dataset (given the tasks are adapted to it and don’t require special input handling).

But sometimes, processing may fail for a single cycle only and we want to rerun just that. And in other cases, multiplexing cycles are processed as they are acquired. Thus, we’ll need to be able to submit workflows for individual cycles, not just the whole dataset, see #37

3. How do we handle reproducibility / history / status of the workflow in more complex submission scenarios?

When we submit for individual cycles, how will we handle the status of the overall workflow? (details TBD, because status question as a whole is TBD).

And how do we know what workflow with which parameters ran on which cycle if the user can change a workflow and then submit it for just a subset of the cycles (⇒ see also history discussions). Details: TBD new issue

---

Once we have multiplexing support in Fractal, there are some new tasks we’ll want to add. Core among them: image registration.

The type of image registration tasks we’ll want to add to Fractal are summarized here: #39

• 3D image-based registration: 3D Registration per FOV #40

Also, once we have multiplexing data in OME-Zarrs, do we want to support the different transformations that each OME-Zarr image can have with regard to each other?

This describes e.g. shifts between cycles or scenarios where slightly different regions have been acquired in the multiplexing cycles. For the initial implementation, I would not se this as a high priority, what we mostly want to support are acquisitions that image the same regions multiple times.

We should eventually add this (because it will be part of the 0.5 spec ), but I don’t see this as a priority and not how Fractal will likely handle many transformations (we’d rather apply it to the actual image)

See here for details: #36 (comment)

Tackling transformations would allow us to process more complex multiplexing inputs, see here for an overview: #35

---

Tl;dr: Multiplexing processing will go via parallelization levels. We need to figure out parameter handling, workflow submission & status/history questions. After this is working well, we can tackle multiplexing-specific tasks like registration, as well as (eventually) supporting things like transformations between cycles to support more complex input paths.