Hmm, worth thinking about if should be in inputs too. I'm not mad about having it there, necessarily?

Also, can we have this target main and then rebase the cp_plus_stardist branch after? We want to get back into the habit of small PRs to main, rather than mega-PRs, if we can. TY!

Agree on aiming for smaller PRs to main going forward!
For this one though, my branch depends on files that only exist in cp_plus_stardist, so switching it to main would bring in that whole branch’s history. I’d suggest merging this into cp_plus_stardist first, then we can rebase and start doing smaller PRs to main from there.

Hmm, worth thinking about if should be in inputs too. I'm not mad about having it there, necessarily?

Might be! I can may-be think of a case where an algorithm could take both “raw images” and “mask images” as inputs, both .tif. Schema says type: image, format: tif for both, but without unique_string we can’t automatically tell them apart if they’re in the same folder.

Other than also implementing it in inputs, anything else left needed to convert from draft to ready?

I need to test this passing a folder of images (for all algorithms) & inputs that's all

It's not ready for review yet - I am trying to resolve rebase conflcits

Great, Single and multiple output handling works correctly for algorithms whose Docker images contain an importable Python module, but fails for algorithms like classical_segmentation, where the entry point is a standalone script

Is it failing for a particular interface(s)? Feel free to add more details if you want help chasing it down.

Nope, Now everything works fine across all interfaces, but the output mount path must be /data/output - otherwise, it fails.

Why?
In original cp-plugin (take RunCellpose), all inputs and outputs live under a single shared mount - /data. The module reads from /data/img so there’s no conflict because everything exists inside the same top-level directory.

In Bilayers, we take a slightly different approach - each output can go to a user-defined path (e.g. /bilayers/output, /bilayers/models, etc.). That’s fine in general, and it means multiple directories might be mounted.

However, if the user sets both input and output to the same container path (for example, --save_dir /bilayers/input_images), Docker ends up getting two mounts for the same location:

docker run \
  -v /host/input_images:/bilayers/input_images \
  -v /host/output_images:/bilayers/input_images \
  ...

When this happens, the second mount overrides the first one, so the input files become invisible inside the container.

Now, if we mount only unique folders (to avoid duplicate mounts), the container only sees what’s explicitly mounted - for eg.

docker run \
  -v /host/input_images:/bilayers/input_images \
   ....

In this case, only /bilayers/input_images exists inside the container.
So, if the algorithm tries to write outputs to a different path (say /host/input_images), that path isn’t mounted to the host at all - meaning any files written there stay inside the container and are lost when it exits
If we only mount one unique input folder, the plugin can’t “see” or persist outputs because the output path simply doesn’t exist on the host

P.S.: I've the draft-code that fails at this point for mounting (haven't pushed)

But otherwise, help me break the current plugin just at save_dir in any algo define path as /data/output

Sorry, I don't follow one small point here- why isn't the conclusion "save_dir can't be the input directory", rather than "save_dir must be one and only one thing"?

Well, algorithms may allow to write in the same directory as input (eg. cellpose does) - to advocate that case

Okay, works fine now - when we give unique input & output directories!

Failed for Instanseg this time, (before commit e88849d), it was generating some outputs for the same set of images. But the failure is mostly related to the algorithm not plugin

Error Message : 
Attempted file (/bilayers/input_images/DNA.tif) load with reader: ... failed with error: No module named 'xmlschema'
NotImplementedError: Got 3D input, but bilinear mode needs 4D input

Outputs aren’t written to the default mounted folder because, like standard cp plugins, this module only produces data in memory - saving them to disk is handled separately via the SaveImages module if the user chooses.