Direct components

Run the BigPicture submodules yourself, without the pipeline orchestration

This is a conceptual orientation, not a step-by-step guide. It is for a technically proficient reader who wants to run the individual BigPicture submodules directly — cloning and operating each one themselves — rather than through the bp-submission-pipeline’s Make targets and Docker Compose stack.

If you’d rather have the wiring done for you, use the bp-submission-pipeline path instead. If you don’t need the curation UI at all and just want to prepare and upload a dataset by hand, see Direct upload (sda-cli).

What “Direct components” means

The bp-submission-pipeline is not a separate program. It is orchestration around a set of submodules. Running the components directly means you clone and operate those same submodules yourself, providing the configuration, networking, and sequencing that the pipeline would otherwise provide.

You keep full control of how each component runs. In exchange, you take on the integration work yourself.

The four submodules

The pipeline is built from four submodules. Running components directly means operating these yourself; each has its own documentation in its repository.

Submodule	Role
slidetap	The base Slidetap application — the framework the curation UI is built on.
bigpicture-slidetap	The BigPicture-specific Slidetap extension — the curation UI you use to review and fix metadata.
bigpicture-metadata-interface	The metadata tooling — generates and manages the dataset metadata.
bp-submitter	Uploads the validated bundle to BigPicture. sda-cli is an alternative for the upload step — see Direct upload (sda-cli).

Note

Several of these are private repositories. If a link 404s, you have not yet been granted access — request it the same way you request access to the other private BigPicture resources (see Support).

Shared inputs: model.json and mappers.xlsx

Running the curation UI (bigpicture-slidetap) needs the same two reference-data files the bp-submission-pipeline uses: model.json (the attribute/observation model) and mappers.xlsx (your site’s local codes → BigPicture coded attributes). Their format and semantics — the workbook sheet structure, the mapping rules, the staining SNOMED codes — are documented under E. Reference data and apply here unchanged.

Only the placement steps there are pipeline-specific (make setup-refdata, PIPELINE_REFDATA_DIR). On this path you provide the same two files wherever your own slidetap deployment expects them.

Where to go from here

Each submodule’s own README is the source of truth for running it. Start from the repositories above, decide which components you need — the curation UI (bigpicture-slidetap) is the main thing this path gives you over Direct upload (sda-cli) — and wire them together for your environment.

Need help?

Email servicedesk.