Skip to content

Re-introduce previously reverted raster mask release fix - #21649

Merged
TurboGit merged 1 commit into
darktable-org:masterfrom
masterpiga:raster_fix
Jul 27, 2026
Merged

Re-introduce previously reverted raster mask release fix#21649
TurboGit merged 1 commit into
darktable-org:masterfrom
masterpiga:raster_fix

Conversation

@masterpiga

@masterpiga masterpiga commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator

Commit 5fad064 in PR #21243 ("Fixes raster masks not being properly released") added _iop_prune_stale_raster_users() to pixelpipe_hb.c, which drops stale entries from a raster-mask source's raster_mask.source.users table. It decided whether a consumer was still "alive" using module-level state:

sink->raster_mask.sink.source == module && sink->enabled &&
(sink->blend_params->mask_mode & DEVELOP_MASK_RASTER)

sink->enabled and sink->blend_params track the darkroom GUI and are not maintained in the export/CLI pipeline, which caused regression test 0167 to fail. Running with -d masks -d pipe showed:

prune stale raster user   colorbalancergb   dropped 'bilat' (disabled)
no raster mask found [export] bilat  raster mask seems to be lost in module `colorbalancergb'

bilat is enabled in history, but module->enabled was FALSE in the export dev, so the prune wrongly dropped the live consumer and the raster mask vanished.

Fix

In the export pipe the authoritative enabled/blendop state lives on the piece, not the module — pixelpipe_hb.h:53: "used to disable parts of the pipe for export, independent on module itself." So I passed pipe into the prune function and judged each consumer from its node in pipe->nodes:

  • no piece in this pipe → deleted consumer, drop (pointer-only match, never dereferences a freed module);
  • otherwise consumes = sink.source == module && piece->enabled && piece->blendop_data->mask_mode & DEVELOP_MASK_RASTER.

Verification

  • FIX vs. reverted baseline: max diff 0 (bit-identical) — the corrected prune no longer alters rendering, while still pruning genuinely deleted/de-synced/disabled consumers.
  • The bad-prune build diverged from baseline by max 71 over 1.2M pixels; the residual max-4 vs the committed expected.png is pre-existing environmental noise (present on current passing master too).
  • Debug log now shows no bogus prune of bilat and no "raster mask lost".
  • 0081-mask-groups / 0150-detail-mask unaffected (prune early-returns on empty users tables).

Co-authored with Claude.

@masterpiga

Copy link
Copy Markdown
Collaborator Author

@TurboGit TIA

@masterpiga masterpiga added this to the 5.8 milestone Jul 27, 2026
@masterpiga masterpiga added bugfix pull request fixing a bug difficulty: average some changes across different parts of the code base scope: performance doing everything the same but faster scope: image processing correcting pixels labels Jul 27, 2026

@TurboGit TurboGit left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me, thanks!

@TurboGit
TurboGit merged commit cdf6e03 into darktable-org:master Jul 27, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix pull request fixing a bug difficulty: average some changes across different parts of the code base scope: image processing correcting pixels scope: performance doing everything the same but faster

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants