Todos before sharing with the outside world

[bethac07]

Exciting that this is already stuff on our horizon!

• [x] We need a bilayers logo :) My original ideas were around things to do with phospholipid bilayers, but we can always say "Beth, your ideas are overly-literal garbage, stop it"
• [ ] Adding a short description of the bilayers project to each UI
• [ ] Adding DOIs/descriptions of the wrapper to each UI
• [ ] Adding DOIs/descriptions of the wrapped app to each config, and then code to each UI to display it
• [ ] Add wrapped app licensing info to each config, and then code to each UI to display it
• [x] #48
  • [ ] Bioimage analyst level documentation - how do I add a software container with a tool I think is cool into this?
    • [ ] We probably want a blank/dummy spec - do we want it in this repo, another repo?
    • [ ] How do I dockerize a tool I like - link to Suganya's blog post, any other tutorials we like (but we need not probably write anything from scratch here)
  • [ ] Softeng level documentation - how do I design a new UI, and/or run my own version of this?
  • [ ] Tool user documentation - how do I use each interface?

[rajavishah]

• [ ] Adding DOIs/descriptions of the wrapper to each UI
• [ ] Adding DOIs/descriptions of the wrapped app to each config, and then code to each UI to display it

1. Does the description looks good?
2. Do we need to add any other DOIs?

[rajavishah]

• [ ] Adding a short description of the bilayers project to each UI

Let me know, if you have some cool description in mind

[bethac07]

RE: DOIs - It's hard to know what this is from without the code being pushed, but in my head, I think we want to break these up - like, the Gradio DOI + text will be part of the Gradio interface generation code, the Jupyter DOI + text would be part of the Jupyter interface generation code, and then part of the config file is the DOI link for that tool, does that make sense?

RE: Bilayers description - I don't, feel free to take a pass. Don't stress too much though about the exact description text for that or anything else, presumably the image analysts will give feedback here, and I can too once stuff is pushed. Easier to do once everything is visible in context!

Nice work :)

[rajavishah]

RE: DOIs - It's hard to know what this is from without the code being pushed, but in my head, I think we want to break these up - like, the Gradio DOI + text will be part of the Gradio interface generation code, the Jupyter DOI + text would be part of the Jupyter interface generation code, and then part of the config file is the DOI link for that tool, does that make sense?

That's fair, it would be easy to navigate to look at the code and answer those questions. I have some more things to fix on my end. I will push the code soon. These both are some cosmetic things to fix, so no worries! Thanks

[bethac07]

• [ ] Another thing, eventually - we don't need it for any of the interfaces we are currently making, but one of our visions for this was also that the specification would include a list of expected outputs and their kinds, which will help for more advanced interfaces (CellProfiler plugins, for example) or also just help adoption with non-bilayers users because if nothing else, it now serves as a way for other people doing other stuff to just understand what a given container makes. It's one of my major grievances with bioimage.io :-D

[gnodar01]

a list of expected outputs and their kinds

We'd want that on the input side as well, no?

[bethac07]

We'd want that on the input side as well, no?

Yes, but I think our inputs currently cover that, as well as I can understand - right now though we've been very vague about outputs other than where they go

[gnodar01]

Ah, I might be way, way over-thinking things. Maybe mention of "grievances with bioimage.io" triggered the much-larger problem space there to pollute what we're doing here.

Here's what I have in my head:

We have a parameters section (formerly inputs section) which describe the types for each CLI flag. Some of those parameters are specific to the input data, like the tag --dir, which specifies the "Input Image Directory", having a type of Files, with file_count of "multiple".

There are also parameters which are specific to the output data, like the tag --save-tif which specifies whether or not to save segmentations as TIF files, implicitly having a type of Boolean with no value.

Then there's an outputs section, which specifies things like where things go, and allow us to construct a UI element that lets you retrieve it by having type Files.

We want to extend the outputs section to allow us to describe the outputs, beyond just being of type Files sitting in location /path/to/out_dir.

In CellPose we kind of, sort of have that via some of the flags in the parameters section, e.g. these flags: --save_[png | tif | flows | outlines | ncolor | txt]. But that is just because CellPose in particular has lots of nice cli options like that, and it is not in general true of other algorithms.

So we want to have descriptions of outputs which let us do a similar thing, more generically. It would let us specify things like (very, very roughly):

- name: mask_outputs
  pattern: "mask_[0-9]+\.tif"
  description: "Segmentations masks"
- name: flow_outputs
  pattern: "flow_[0-9]+\.tif"
  description: "gradient flows"
- name: "Numpy outputs"
   pattern: ".*_seg\.npy"
   description: "the stuff here: https://cellpose.readthedocs.io/en/latest/outputs.html#seg-npy-output"

Do we think we would want to mirror that on the input side? Beyond parameters specific to inputs, would we want to have a section dedicated to inputs that lets us describe them in a manner akin to how we may want to describe outputs? For instance describe that our inputs are of the pattern ".+[0-9]+\.tif" or at least of the ext type .tif or .npy, and that they are binary masks, or label masks, or 2d arrays, or...

The general idea being that--if we're using bilayers specs in pipeline contexts like CellProfiler, or even general workflow trees as in Galaxy--describing inputs is just as important as describing outputs (or at least it's not unimportant).

[bethac07]

Do we think we would want to mirror that on the input side? Beyond parameters specific to inputs, would we want to have a section dedicated to inputs that lets us describe them in a manner akin to how we may want to describe outputs? For instance describe that our inputs are of the pattern ".+[0-9]+.tif" or at least of the ext type .tif or .npy, and that they are binary masks, or label masks, or 2d arrays, or...

Yes, I think we do, though you're right that currently with Cellpose as our alpha-testing-algorithm, we've now mixed that in with a lot of other stuff. So I think potentially keeping an inputs section, but having it have only parameters related to specifying mandatory inputs, and then moving all the OTHER things in our spec into a section called parameters, seems a reasonable minimally-perturbative way to move forward. What do folks think?

If we go that route, the devil will a tiiiiiny bit be in the details - is something like the --chan or --chan2 flags (which specify which channel of the input images to use) an input or a parameter? So another options is to have a brand new section called specification or something like that which has subsections for input and output that describe the types of inputs, but I worry that then just becomes a repeat of the non-optional parameters

The general idea being that--if we're using bilayers specs in pipeline contexts like CellProfiler, or even general workflow trees as in Galaxy--describing inputs is just as important as describing outputs (or at least it's not unimportant).

👍