Clone seems to cancel Speck Removal

[davidh]

version 22-Apr-2019 (sorry I have not managed to post it earlier - before the today' s version 27-Apr-2019)

I have created the following tree:
Top level image - Clone - Speck Removal - splitter box - three different Crop branches (portrait, landscape, portrait), other transformations.*

When I examined the crop outputs, I found that the middle one (landscape) does not show the effect of the Speck Removal step.
I went back to Speck Removal and found that now the output (or its preview) does not show the effect either, see the attachment (the first two images are from Speck Removal transformation, the other two are the crop transformations).
Re-runing Speck Removal not only did not help but now all of the crops ignored the effect of Speck Removal step.

So I skipped the previous step - Clone (using the bypass button) - and when the recalulation finished, all outputs downstream were correct (though without the Clone step effect).

Turning back the Clone step ON just re-applied its effect to outputs, but did not influence the Speck Removal any more.


* Perhaps I should also mention the order in which the tree was created as it might be important for the right order of recalculation later on:

-top level image
-Crop
-some other transformations
-cloning the first side branch from the Crop step
-cloning the second side branch from the Crop step
-inserting Clone transformation after top level image
-inserting Speck Removal transformation after the Clone step

the other steps:
-re-runing Speck Removal -> did not help
-bypassing Clone -> corrected outputs
-turning Clone ON again -> no negative effect on Speck Removal

[jsachs]

If you save a workspace script, does it still fail when you reload the script? If so, can you email me the workspace script? I am not seeing the problem here, but it may depend on some other settings or on the exact nature of the image tree you are using.

Also please be careful to distinguish when you use the term Clone between using the clone tool or cloning a side branch.

[davidh]

I have not saved the script so I have created a similar one but failed to simulate the problem. However playing with the tree I came across a behaviour that might provide a clue.

I used the following simple tree:
top level image -> Crop -> Resize -> Conditional Curve

There are no side-branches so any Clone in the following description means the Clone tool.

1. insert Clone after the top image, do some change but do not execute the step, leave the dialog open
2. insert Speck Removal after Clone -> Clone changes immediately propagates to Speck Removal output but not further
3. close Speck Removal thumbnail using x button -> the tree is recalculated and Clone changes propagates immediately downstream
4. close Clone dialog -> the thumbnail gets closed as well but the changes created by Clone are not taken back and remain in all steps downstream
5. to remove the clone changes needs re-executing the first step (Crop) but with at least a bit different setting

As the same happens when you change the order of both tools: Speck Removal -> Clone (I have not tried other tools) it seems that immediate propagation of changes from one transformation tool to the next in line is a typical behaviour of the transformation tools.

Also there is a difference when you insert a transformation and close it again without ever executing it:
When you close the transformation dialog, the thumbnail is removed from the workflow as well and the tree is NOT recalculated.
When you close the thumbnail, the transformation dialog is closed as well but the tree is recalculated and any changes are propagated downstream. This is the case of the transformation tools.

By the way, is it necessary to trigger recalculation of the tree after an inserted thumbnail was closed again before it had been executed at all?

[jsachs]

It turns out this has nothing to do with Clone as the same thing happens with any other transformation. The problem is caused by an optimization from a long time ago, namely when you cancel (or close) a transformation dialog box that was just created (as opposed to one you double-clicked on to edit), changes are not propagated to the rest of the image tree on the theory that subsequent images have not already been affected. Normally this is true, however, if you insert a second transformation before closing the first one, it inherits any changes that have already been made to the output image of the first one. At this point, canceling the first transformation should propagate changes to the rest of the image tree but it does not because of the optimization. There does not seem to be any easy way to distinguish when changes need to be propagated or not as it depends on settings for the first transformation being changed and a second transformation being added after the first after those changes have been made.

I was able to quickly make a temporary fix to force changes to propagate whenever closing or canceling a transformation dialog box which, at least for now, fixes the problem.

I don't particularly like this solution since 99% of the time this is unnecessary to propagate changes in this situation. Another possibility is to propagate changes only if the first transformation's settings have not changed which is still inefficient although less so -- this does not work so well if there is a default settings file or if the initial transformation settings don't reproduce the input image. A third possibility is to try to avoid propagating changes when the second transformation is created if the first one is still open, but that is a also tricky. So, I need to think about this for a while to decide on the best option.

[davidh]

I am not sure whether this would make it easier, but I think propagating changes of one open transformation to the next open transformation does not present any problem as long as the changes do not propagate further downstream after their source (the first open transformation) is closed.
Let the changes propagate freely to all open transformation in succession. This would be, like in my case, more likely unintentional than intentional scenario anyway. I just somehow overlooked the open clone dialog box and went on inserting another correction step.

The only problem does arise when the changes get propagated even though their source is no longer there and they cannot be removed without re-runing the precedent transformation with changed settings.

[jsachs]

That does not work since you can insert additional transformations below the second and thus propagate the changes in the first one to a whole string of downstream images.

My current thinking is to send a message to the first transformation dialog, if it is open, when inserting a new transformation after it. When receiving this message, the first transformation would then set its flag indicating that propagation of changes was necessary on Cancel or close. Currently this flag is only set when the first transformation does an Apply since this requires all the changes to be rolled back on Cancel. This still can cause unnecessary propagation if the first transformation's output image was identical to its input image, but this would still be a lot better than propagating every time.

[jsachs]

I think it is now fixed. I use the technique described in the previous post, but check if the input and output images are not identical before forcing changes to propagate.