WBPP Multi Scope Stacker

The MultiScopeStacker is a specialized WBPP builder for multi-scope or mixed-resolution data sets.

Its purpose is simple: if two or more POST light groups share the same POST keyword identity, or if they all have no POST keywords at all, they should be treated as one logical stack even when WBPP would normally keep them split because of differing frame sizes.

Unlike the No Code Pipeline Builder, this script does not use a ProcessContainer-based automation layer. It modifies the WBPP pipeline directly.

Standard WBPP grouping can separate otherwise compatible POST groups when image dimensions differ. In a multi-scope workflow, that is often not what the user wants.

If those groups are meant to land on the same registration target and the same final stack, splitting them only by resolution creates extra groups, duplicate downstream work, and in some cases invalid empty donor groups after manual regrouping.

MultiScopeStacker addresses that by merging eligible POST groups before the downstream measurement and registration stages begin.

The script builds a regrouping key for active POST light groups that are not combined RGB groups.

The key keeps these properties distinct:

• imageType
• filter
• binning
• exposureTime
• isCFA
• associatedRGBchannel
• the complete POST keyword set

The important design decision is that frame size is intentionally not part of that regrouping key.

That means:

• groups with the same POST keyword identity are merged even if their resolutions differ
• groups with different POST keyword identities remain separate
• groups that have no POST keywords at all are also allowed to merge with each other

When two POST groups resolve to the same regrouping key:

• the first matching group becomes the keeper group
• all FileItem objects from later matching groups are moved into the keeper
• exposure totals are updated on the keeper group
• automatic fast-integration mode is re-evaluated for the enlarged keeper group
• donor groups are marked inactive and purgeable
• donor groups are removed from the real WBPP groups manager

Removing the donor groups from the groups manager is important because it prevents empty zero-frame POST groups from surviving into later validation or integration steps.

The regrouping is applied immediately after WBPP builds the POST groups and before the rest of the normal POST pipeline is queued.

In practice, the merged POST groups are then used by the standard WBPP operations that follow:

• reference-frame data preparation
• measurements
• frame selection, when enabled
• bad-frame rejection
• reference-frame selection
• registration
• local-normalization reference selection
• local normalization
• image integration or fast integration
• drizzle integration
• auto-crop
• RGB recombination
• plate solving

This timing is what makes the script useful: the merged groups share the same downstream registration target selection and the same final stack path instead of behaving like separate islands.

After regrouping, the script continues by scheduling normal WBPP operations. It does not replace registration, integration, drizzle, local normalization, or plate solving with custom implementations.

The only behavioral change is the earlier regrouping of compatible POST groups, plus a small WBPP utility patch that preserves already-known drizzle and local-normalization sidecar references when target frame tables are generated.

The core assumption behind MultiScopeStacker is that differing source resolutions are not a problem when those frames are going to be registered onto the same target anyway.

By regrouping before measurement and registration, the script lets WBPP analyze and align the full merged set as one logical group. That is the main reason the regrouping must happen early and not after registration or integration.

• combining data from two telescopes that used the same filter and the same POST tags but produced different image dimensions
• merging equivalent light groups across nights or rigs when POST keywords were deliberately used to define the intended stack identity
• preventing duplicated registration and integration paths for data that should become one final master

• The regrouping only affects active POST light groups that are not combined RGB groups.
• Groups with different filters, binning, exposure time, CFA state, RGB channel identity, or POST keyword identity are intentionally kept separate.
• This script is a direct WBPP builder and does not include the ProcessContainer-based custom-step system from No Code Pipeline Builder.
• The script assumes that resolution-only POST splits are safe to collapse for the intended workflow. If the POST tags do not represent the true intended stack identity, regrouping can merge data that should have remained separate.