new module: cellpheno/nis

[Chrisa142857]

Closes #11311

Description

cellpheno/nis runs whole-brain 3D nuclei instance segmentation on a single lightsheet
microscopy tile: a 2D U-Net per slice, 2D→3D flow conversion, flow-following to
obtain instances per depth-chunk, and GNN gap-stitching across chunks. It wraps
the C++/LibTorch CellPheno NIS executable from
https://github.com/Chrisa142857/Lightsheet_microscopy_image_3D_nuclei_instance_segmentation.

This is a GPU, container-only module (no Conda package), following the
established parabricks/* and numorph/3dunet pattern: a single vendor container,
no environment.yml, an in-script guard that errors under -profile conda/mamba,
label 'process_gpu', and versions via the topic: versions + eval mechanism.

PR checklist

• This comment contains a description of changes (with reason).
• If you've added a new tool - followed the module conventions in the contribution docs.
• If necessary, include test data in your PR.
• Remove all TODO statements.
• Broadcast software version numbers to topic: versions.
• Follow the naming conventions.
• Follow the input/output options guidelines.
• Add a resource label (process_high + process_gpu).
• Use BioConda and BioContainers if possible.
• Ensure the test works with Docker / Singularity:
  • nf-core modules test cellpheno/nis --profile docker
  • nf-core modules test cellpheno/nis --profile singularity
  • nf-core modules test cellpheno/nis --profile conda

Notes for reviewers

• No conda support is intentional and matches parabricks/*.
• process_gpu emits a non-standard-label warning (as it does for every GPU
  module); paired with process_high.
• Versions come from eval("cat /usr/local/share/cellpheno-nis/VERSION") because the binary
  has no --version; the Dockerfile writes that file from the same ARG as the
  image tag to keep them in lockstep.
• Container hosting: the image is published at
  quay.io/wzq10101/cellpheno-nis:1.0.0 (my personal Quay namespace — I'm a new
  nf-core member and don't have quay.io/nf-core push access yet). nf-core modules lint is clean (42 passed, 0 failed) under the default quay.io registry. Happy to
  have the team re-host it under quay.io/nf-core/cellpheno-nis during review — I'll
  update the container line to match.

[mashehu]

do you have the dockerfile for this image?
If so, please add it here and request nf-core to upload to their registry, similar to how numorhp did it https://github.com/nf-core/modules/blob/master/modules/nf-core/numorph/3dunet/main.nf

[mashehu]

for modules that don't support conda, please add them to the .github/skip_nf_test.json file

[Chrisa142857]

Thanks @mashehu! Addressed both points:

• Dockerfile + registry: added a self-contained Dockerfile (plus a README.md) to the module that clones and builds the C++/LibTorch/CUDA NIS binary from source — following the numorph/3dunet pattern — and pointed the container at quay.io/nf-core/cellpheno-nis:1.0.0. Could you trigger the nf-core build/upload to quay.io/nf-core? I built and validated the image locally (it's currently mirrored at quay.io/wzq10101/cellpheno-nis:1.0.0 for reference).
• Conda: added modules/nf-core/cellpheno/nis to .github/skip_nf_test.json (the module is GPU/container-only and has no conda package, same as parabricks/*).

[Chrisa142857]

Status after the latest push:

• ✅ nf-core lint modules (cellpheno/nis) passes (default quay.io registry)
• ✅ conda matrix passes now that the module is in skip_nf_test.json
• ❌ The GPU Test jobs fail on missing test data, not on the module:

  ERROR ~ No such file or directory:
  https://raw.githubusercontent.com/nf-core/test-datasets/.../imaging/segmentation/cellpheno_nis/tile
  

The gpu-tagged test references a tile + TorchScript models in nf-core/test-datasets
that aren't there yet. This is a planned follow-up (it's the unchecked "include test
data" box): contribute a small real tile to nf-core/test-datasets, host the .pt
weights on Zenodo (the numorph/3dunet precedent), and regenerate the snapshot on a GPU
runner. The stub test (CPU) passes and is snapshotted.

Happy to coordinate the test-datasets + Zenodo follow-up, or open the module without the
live GPU test for now (as discussed for vendor GPU modules). Let me know which you prefer.

[Chrisa142857]

Update — the test-data follow-up is now complete, so this should be ready for another look:

• Tile: cellpheno/nis: add test tile + models test-datasets#2136 is approved (single ~700 KB real P4 crop). Once it's merged the gpu-tagged test can resolve the tile.
• Models: the TorchScript weights are hosted on Zenodo — 10.5281/zenodo.21284682 (https://zenodo.org/records/21284682/files/cellpheno_nis_models.zip), following the numorph/3dunet precedent. The test now fetches them from there (they're too big for test-datasets).
• Device-agnostic models: I fixed the binary to map_location the flow/GNN modules onto whatever --device is passed, so a single model set runs on any GPU index (cuda:0/1/2/…), not just cuda:0.
• Wider CUDA compat: the module Dockerfile now builds against CUDA 12.1 / LibTorch 2.5.1+cu121 (was 12.8/cu128) — no custom .cu kernels, so LibTorch's fat binary still covers sm_50..sm_90, and this lowers the driver floor to ≥530.

Recap of your two earlier asks, both done: added the self-contained Dockerfile (numorph pattern) and added the module to .github/skip_nf_test.json for conda.

Could you please, when you have a moment: (1) merge test-datasets#2136, and (2) trigger the nf-core build/upload of the Dockerfile to quay.io/nf-core/cellpheno-nis:1.0.0? I don't have push access to the quay.io/nf-core org (it's mirrored at quay.io/wzq10101/cellpheno-nis:1.0.0 for reference). Then the GPU test should pass on a runner. Thanks!

[mashehu]

since you are the author of the upstream software, could you not make a release and publish it on bioconda? Just building from main is not good practice for reproducibility

[Chrisa142857]

Good point on reproducibility — agreed, building from main was wrong. I've done two things:

1. Cut a tagged release v1.0.0 of the upstream software and pinned the Dockerfile to it (NIS_SOURCE_REF=v1.0.0, commit 5420a1c) instead of main, so the image is now reproducible.

2. On bioconda: happy to pursue it. One caveat to flag — NIS is a C++/LibTorch/CUDA GPU executable (not a Python package), so a recipe has to compile against conda's libtorch/opencv/CUDA and the auto-built BioContainer is a GPU image. This is the same situation as the numorph/3dunet example you linked, which ships a pinned release + vendor container rather than a conda package. I'll work up a bioconda recipe and, if it's accepted, switch the module's container to the resulting biocontainer.

Would you be OK merging with the pinned-release container now (reproducible via v1.0.0), and I migrate the container line to the biocontainer once the bioconda recipe lands? That unblocks the module while the conda packaging goes through review. If you'd rather hold the module until bioconda is merged, that's fine too — just let me know your preference.

[Chrisa142857]

Bioconda recipe submitted: bioconda/bioconda-recipes#67064. It builds the C++/LibTorch/CUDA binary against conda's libtorch/libopencv (pinned to the v1.0.1 release). If it's accepted I'll switch the module's container to the resulting BioContainer; in the meantime the Dockerfile is pinned to v1.0.1 so the current image is reproducible.