The Watershed (extra) effect in the Segment Editor module appeared to recompute upon a change of a segment’s colour (aka “color”), or possibly it was the segment’s Property type. This seemed to happen automatically when “Auto-update” was ticked. …Then later I couldn’t reproduce it.
While recomputation is justified when changing the ‘content’ of a segment (adding or removing voxels through Paint or Erase effects), it shouldn’t be triggered by ‘æsthetic’ changes such as change of colour or renaming.
In trying to reproduce the above issue, a different issue arose: when I changed a segment’s colour and name, the new colour was applied to the painted voxels, but the previewed regions expanded through the watershed algorithm remain at the old colour, and also the old name shows up in the Data Probe panel. The updated colour and name should be applied to the previewed regions too.
Possibly some of this might apply to the Grow from Seeds effect too (untested).
It does seem kind of similar in the Grow from Seeds effect too.
The original initialisation took dozens of seconds.
Changing the colour required some sort of recomputation for a few seconds, but maybe it’s just recomputation for the graphical display (including 3D)?
Also the colours did not update in the preview, even after clicking Update.
Updating of colours could be forced only by clicking Cancel, and then Update again.
—DIV
In the Grow from Seeds effect I am also getting a long recomputation (dozens of seconds) after adjusting the Seed locality slider value, even though Auto-update of the preview is unticked. This is a genuine recomputation of the segments, as the preview also changes noticeably.
Maybe due to this behaviour from the Segment Editor module’s documentation: “Master volume and auto-complete method will be locked after initialization”.
We could probably be do more sophisticated change analysis and perform less recomputations in response to segment changes. However, considering how infrequently users are expected to change segment colors or other properties during region growing seed painting, implementing of such optimizations would be assigned a very low priority.
I agree that there is room for improvement here, but this issue (and the others in your follow-up comments). You can submit them as feature requests on the issue tracker to keep track of them, but since they would be classified as low impact, low/medium workload tasks, most likely they would go into the backlog and only be implemented if there is specific funding attached or a volunteer chooses to implement them. So, it may be sufficient to just keep these improvement ideas here on the forum.