Thanks a lot for the pointers! I’m trying to gauge what requirements/functionality of a module(s) would be most useful for the community, I can imagine many pipelines dealing with bioimage data might find it useful to have modules for efficient I/O and parallel processing tasks, based on OME standards. Perhaps a poll might be a good idea.

This polly is closed. @Luis Kuhn has a polly for you!

Hi All! I'm planning on attending the SBI2 conference this year. Any other Nextflow microscopy/imaging pipeline enthusiasts attending and want to plan a get together?

Hi folks! I wanted to flag the event message from @Luis Kuhn over in #C01G2VA2ZSP - may be of interest to many of you!

Chatting with folks at #C07TKBP3WNA and they suggested that I share the poster I presented at SBI2 earlier this year. It features some of great work and pipelines by folks in the community here.

Hi fellow microscopy friends! @Krešimir Beštak and I are preparing release 1.1.0 for #C05AJBTJXDY. If anyone has time to do a review of our

dev -> main

PR, that would be appreciated 😊 ! https://github.com/nf-core/molkart/pull/105

https://github.com/MIC-DKFZ/nnInteractive Python backend for nnInteractive: Redefining 3D Promptable Segmentation - https://arxiv.org/abs/2503.08373

hi does someone know if there is a

zarr

structure in the

test-dataset

repo?

dear microscopy people, I've made a nf-core compatible

subworkflow

which uses several modules for tiled segmentation. which can be found here: https://github.com/BioinfoTongLI/modules/blob/develop/subworkflows/sanger/tiled_segmentation/main.nf I wonder what is best practice to built the subworkflow from

nextflow

perspective. Is it better to

include all modules into one subworkflow

as it currently is OR construct

one subworkflow per method

? i.e. 4 subworkflows in total in my case? PS:Please ignore the module names etc. I will push them to the main stream soon to make sure all is in

nf-core

By the way folks! We've recently started work on an nf-core pipeline for #C08P26ZAZM4. It's very early development, but we're making progress on it as part of #C08P1EATPCM at the Nextflow Summit Boston. If anyone else is working on cellpainting analysis feel free to jump into our channel and introduce yourself; additional collaborators are definitely welcome!

Job opportunity specially for people with experience of #C051C6071S4 pipelines here.

We would appreciate a review on https://github.com/nf-core/modules/pull/8749 -- @Alex wrote this new module for for the bioformats

showinf

tool for extracting OME-XML from supported image file formats (including proprietary vendor formats supported by bioformats). It's initially intended for the #C047HKB4RPC pipeline but we think other microscopy pipelines will benefit too.

Excited to announce we've submitted the PR for core team review of the first nf-core release of #C047HKB4RPC ! If anyone wants to take a look and make any suggestions, the PR is here: https://github.com/nf-core/mcmicro/pull/120

Hello there! Help needed! I have a very general question: what is the best way to deal with out-of-memory (OOM) image processing/analysis? These days, I believe a lot of Nextflow users are also working with spatial genomics data, which can get out of either RAM or GPU-RAM memory pretty easily. I know Janelia (@Konrad Rokicki @Cristian Goina ) has a very promising solution which runs cellpose as a subworkflow with 3 steps: 1. spin-up dask/spark cluster 2. pass the server address to cellpose wrapper which distribute each chunk to each worker and then merge the data 3. shutdown the cluster This is a great solution but if we'd like to extend this template to other segmentation methods, the amount of work can be daunting. Since a new wrapper will be needed for each methods. Thus, I am wondering is there a solution that scales and doesn't lead to the overhead of using dask/spark?

@Florian Wuennemann On the topic of the cellpose 4 module update: It was noted in that PR that the container does not include the model weights. I've found this to be a big hassle in the past for cellpose (and mesmer)! It adds extra time to EVERY cellpose run for every sample in every pipeline run as the model weights aren't cached. People with network-restricted clusters will also be impacted as their compute nodes can't reach out to download the weights. Dynamic weights fetching also adds an extra point of failure, and this one has broken our GitHub Actions test runners multiple times when huggingface responds with a server error. When I created the separate mccellpose module (memory-efficient tile-by-tile processing) I built a container that does include the weights. I think cellpose 4 only has the one model now so one doesn't need to worry about different models as before, so the only concern is that the weights may be updated if the authors re-train.

Is there a better solution? Should we treat model weights like a reference genome in the bioinformatics world and arrange to always pass it as an explicit module input, moving the responsibility for downloading and caching the weights into the pipeline?

Are the weights different to the model here? We do have the model as a path input that let's you provide a custom model or simply refer to a pretrained model

cpsam

So simply predownloading the model and providing it would fix your issue wouldn't it? Except of course if the weights are different to the model

Yes, I am using "weights" and "model" more or less interchangeably, but cellpose 3 did have what they referred to as different "models" which had semantic differences in terms of what they expected as inputs (cyto, cyto2, cyto3, nuclei, etc.) but I think they may have released updated weights for each of those over time. That process might be irrelevant with cpsam though? Not totally sure.

I'll need to check whether passing the downloaded cpsam weights file as the argument to

pretrained_model

will do the right thing.

But this is a bigger issue for imaging pipelines so I wanted to raise the issue here to see if others had experience with the issue or thoughts on a community best practice

I just searched this slack and didn't find much else on the topic. Here's one very recent thread discussing whether to include model weights in a container (I added my little call to action) : https://nfcore.slack.com/archives/C09H6NYHR9T/p1773322464627599

The old cyto/nuclei/etc. weights files were ~25 MB each. The cpsam weights file is 1.2 GB!

Mesmer, should anyone want to use it, is at 200 MB across a few separate files

We’ve started to play with the idea of Claude Code running Nextflow modules in dynamic workflows (as opposite to static DAG-based pipelines). This might be especially relevant for microscopy image analysis, if we can define well-specified objectives. Maybe even loosely defined objectives evaluated by vision-language models (VLMs) could work. The idea would be to automate getting to a reasonable processed output, then a human can take over and tune each step further if necessary. One issue with using nf-core modules for this is that module parameters are typically not specified at the module level. Rather there are pipeline parameters (

nextflow_schema.json

) which are mapped/injected into modules in pipeline-level configs. Some modules specify a documentation link (e.g. https://github.com/nf-core/modules/blob/master/modules/nf-core/admixture/meta.yml) that the agent could read. But this link can be anything and it’s not clear how easy it would be to have an agent ingest this cleanly. Another idea might be to add a

README.md

(or

AGENT.md

?) into each module that describes not only the CLI parameters, but how to run the module and what to expect from it. I was curious if anyone else is looking into this, or has any thoughts along these lines. @Tatiana Woller @Tong LI @Cristian Goina @Phil Ewels

@Kobe Lavaerts @Nicolas Vannieuwkerke what is your opinion?

Hey, I was doing investigation on a tool called MONAI using Gemini's Deep Research tool. I was pointed here that you might be potentially interested in it docs.google.com/document/d/1H0jhd0whoQN…/edit?usp=sharing

Hi all, I’m trying to understand how Nextflow should handle Zarr/SpatialData. Zarr allows large datasets to be updated in-place without rewriting the whole object, but my understanding is that Nextflow stages inputs and expects processes to produce new outputs, making persistent in-place updates difficult. Is that correct? Are there any Nextflow pipelines or recommended patterns for updating Zarr stores in place? Sorry if this has already been discussed elsewhere!