Automatic recomputation of analysis (1-to-0) can produce unwanted results

[StefanoPierini-Codra]

Summary

DataLab currently automatically recomputes analysis operations (the
"1-to-0" features such as statistics, FWHM, centroid, peak/contour/blob
detection, etc.) whenever the underlying object changes — e.g. after a ROI
modification, a data transformation, or an object-property edit.

This automatic behavior can surprise the user, silently overwrite results,
and in some cases produce unwanted or misleading results. I propose to
disable the automatic recomputation of analysis features and instead let the
user trigger it explicitly, by extending the existing manual "Recompute"
action (which today only handles 1-to-1 processing) so that it also
recomputes 1-to-0 analysis features.

Current behavior

Analysis results are recomputed automatically by
BaseProcessor.auto_recompute_analysis()
(datalab/gui/processor/base.py), which is called from several places, notably:

• after ROI creation / modification / deletion,
• after in-place data transformations (recompute_1_to_1),
• after object-property changes (datalab/gui/panel/base.py).

Meanwhile, the manual "Recompute" action
(SignalPanel/ImagePanel.recompute_processing, wired in
datalab/gui/actionhandler.py) only considers objects whose stored parameters
match the 1-to-1 pattern; 1-to-0 analysis features are explicitly filtered
out and are never recomputed on demand.

Problems with the current automatic behavior

• Unexpected side effects: changing a ROI or an object property silently
  re-runs an analysis and replaces its previous result, without the user asking
  for it.
• Potentially wrong or meaningless results: after certain edits, the stored
  analysis parameters may no longer be appropriate for the modified data, so the
  auto-recomputed result can be incorrect or misleading.
• Loss of user control: there is no obvious way for the user to decide
  when an analysis should be refreshed.

Proposed behavior

1. Remove the automatic recomputation of 1-to-0 analysis
   features. Editing ROIs, data, or object properties would no longer implicitly
   re-run analyses; existing results are simply left as-is (and may be flagged
   as potentially outdated).
2. Extend the existing manual "Recompute" action so that, in addition to
   1-to-1 processing, it also recomputes 1-to-0 analysis features for the
   selected objects. The user thus refreshes analysis results explicitly, at a
   moment of their choosing, through the same familiar command.

Rationale

• Recomputation becomes predictable and explicit: results change only when
  the user asks for it.
• Avoids silently overwriting analysis results with potentially invalid ones.
• Consolidates all recomputation behind a single, well-known manual action,
  simplifying the mental model.

Affected repository

• DataLab (DataLab-Platform/DataLab): recompute action, auto-recompute call
  sites, tests, and documentation.

[StefanoPierini-Codra]

What was done

• Disabled automatic recomputation of 1-to-0 analysis features after ROI edits, data updates, and property changes.
• Kept existing analysis results unchanged until the user explicitly requests a refresh.
• Extended the manual Recompute action so it now refreshes:
  • 1-to-1 processing results
  • 1-to-0 analysis results
• Renamed panel method from recompute_processing to recompute_selected to reflect the new scope.
• Updated action wiring/tooltips and internal references accordingly.
• Updated tests to match the new manual recompute behavior.
• Updated user documentation (signal/image Edit menu) and release notes.
• Added/updated French translations for new UI strings.

[StefanoPierini-Codra]

In case the user decided to stop the recompute, 1-to-0 computation was continued. I fixed this, manual recompute now stops cleanly if the 1-to-1 reprocessing phase is canceled or interrupted. In that case, DataLab no longer continues with 1-to-0 analysis recomputation, and analysis is refreshed only for objects whose 1-to-1 recompute actually completed successfully.

[StefanoPierini-Codra]

The new name recompute_selected could break some existing code. @ThomasMalletCodra do you want me to keep the old name as a deprecated alias for a while?

[StefanoPierini-Codra]

While working on the fix for #322 (profile "Reset selection"), an unrelated pre-existing bug was found on develop.

Bug

When recomputing several selected objects at once via the manual "Recompute" action, the code read the processing parameters from the shared Processing-tab editor (ObjectProp.processing_param_editor). In the multi-object loop that editor lagged behind the object being recomputed (it is only rebuilt through the asynchronous selection-changed signal). As a result, one object could be recomputed with another object's parameters, and its stored metadata got overwritten.

Resolution

This branch already fixes the bug incidentally: the recompute logic was refactored so the multi-object loop calls processor.recompute_processing(obj) without a parameter override, making each object fall back to its own stored parameters. The editor's dataset is now only used in the genuine interactive single-object "Apply" path.

Regression test

Added profile_recompute_multiobject_app_test.py: it extracts two profiles of different shapes (horizontal 51 pts, vertical 201 pts) from the same image, selects both, applies a known offset to the source, and calls recompute_selected(). It asserts each profile keeps its own shape, values (data + offset) and stored parameters. This fails if one profile's parameters leak into the other.

[StefanoPierini-Codra]

The new name recompute_selected could break some existing code. @ThomasMalletCodra do you want me to keep the old name as a deprecated alias for a while?

The choice has been made to not do that: the possibility that a user is using this in his script is remote. I edited the release notes to clearly explain the name change.

[ThomasMalletCodra]

fixed and merged :

• 02b7abe
• e53f245