added support for using peak scan data in tile removal

[trautmane]

No description provided.

[Copilot]

Pull request overview

This PR adds a new “peak scan JSON”-driven mode for Multi-SEM tile/layer removal, allowing stacks to be trimmed automatically based on per-slab peak scan metadata, and refactors pipeline/CLI plumbing to carry this new configuration alongside the existing explicit per-stack removal list.

Changes:

• Introduces PeakScanData (JSON + GCS/local reader) and TileRemovalSetup (either peak-scan-driven removal and/or explicit stack list).
• Updates the Spark Multi-SEM tile removal client to accept --peakScanJson and to route execution via TileRemovalSetup.
• Updates alignment pipeline parameters to use TileRemovalSetup instead of a raw tileRemovalList.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
render-ws-spark-client/src/main/java/org/janelia/render/client/spark/pipeline/AlignmentPipelineParameters.java	Switches pipeline parameter shape from tileRemovalList to TileRemovalSetup.
render-ws-spark-client/src/main/java/org/janelia/render/client/spark/multisem/MultiSEMTileRemovalClient.java	Adds --peakScanJson and executes peak-based removal and/or explicit stack-list removal via TileRemovalSetup.
render-ws-java-client/src/main/java/org/janelia/render/client/parameter/TileRemovalSetup.java	New serializable setup object for peak-scan-driven removal and/or explicit per-stack removal.
render-ws-java-client/src/main/java/org/janelia/render/client/multisem/PeakScanData.java	New model + JSON reader for peak scan data from filesystem or Google Storage.
render-ws-java-client/src/main/java/org/janelia/render/client/multisem/MultiSEMTileRemovalClient.java	Adds post-peak scan removal capability and adjusts scan-to-z mapping behavior.

Suppressed comments (1)

render-ws-java-client/src/main/java/org/janelia/render/client/multisem/MultiSEMTileRemovalClient.java:288

• buildScanNameToZMap() now calls getTileIdsForZ() for every z in the stack, even when removeTiles() only needs to resolve a small set of requested scan names. For large stacks this can add a lot of extra web-service calls and slow removals. Consider reintroducing an early-exit path for the non-peak removal case (e.g., pass tileRemoval.buildScanNamesSet() into buildScanNameToZMap and break once all requested scan names are found), while keeping the full-scan map for peak-scan removal.

        for (final Double z : stackZValues) {

            final List<String> tileIds = dataClient.getTileIdsForZ(stack, z);

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[minnerbe]

Thanks, @trautmane! I skimmed all of it, but paid special attention to how the number is handled (z value instead of scan), which seems to be correct.