History explorer questions(s)

[calan]

Is it possible to disable and/or reorder processes in the history explorer? If not, how cool would that be?    (Coming from a parametric CAD modeling background for the last 20 years, I have an uncontrollable urge to reorder and suspend processes in that window, but can't see a way to do it.  lol)

On a semi-related note... saving the history explorer as a separate process container is very powerful. But, it would be even better if when you clicked a process within a container, any associated mask would be automatically loaded as well. I burn myself all the time by relaunching a process but forgetting to set the mask that was used with it.

[Juan Conejero]

HistoryExplorer is a read-only ProcessContainer. As its name suggests, it implements the ordered list of processes applied to an image. Since it is a read-only object, you cannot modify its contained objects. It is a read-only container because it represents the sequence of actions that have been applied to produce the current state of the image. Allowing arbitrary modifications would lead to inconsistencies. Reordering a HistoryExplorer would also lead to an inconsistent state in general, since most tuples of processes are not commutative with respect to execution.

As you have discovered, you can generate a ProcessContainer from the History Explorer window, which you can modify, merge and extend as desired.

when you clicked a process within a container, any associated mask would be automatically loaded as well

That kind of interactions (of the 'do anything from any place in the UI' kind) tend to generate much more problems than solutions. Masks associated with ProcessContainer child processes are automatically applied when their parent ProcessContainer is executed.

[Niall Saunders]

Just also remember, when you look at the process sequence in the Process Container, you do at least see whether the process was applied with a mask, what image was used as the mask, and whether the mask was used in a normal or inverted state.

When I am working on an image, I save the Process History, as a Process Container, to the WrokSpace at key stages. If any process within the container relied on a mask, then I will have saved the source image, the process history used to modify the image into the mask (again as a process container), as well as the actual image mask itself.

This contiues throughout my workflow - with key images, and their associated Process Containers, being saved throughout. That way, it isn't too difficult to backtrack to any point in the workflow, and to create a 'workflow branch' that allows a different processing approach to be made.

I used to save individual process icons, but renaming these, and maintaining sequential numbering became an unmanageable issue - apart from the fact that there would be no indication whether the process should be applied through a mask or not.

Yes, Juan has made it possible to save the entire workspace (ll icons and images) as a single dataset, but I find that (for my purposes anyway) this really only has any use as a 'backup' of 'work in progress'.


Just an aside:
Something that could be more useful - if you are still monitoring this thread Juan - is the ability to save processes with 'Regions of Interest' rather than references to the likes of Previews. This is already available in the likes of Background Neutralization and ColorCalibration, but I would liked to have seen it in the likes of Crop (where the Readout Pointer can be used to select a background colour to be used when expanding an image back up to meet a certain pixel resolution - being able to specify a ROI at the edge of an image and then to have PI extract the 'mean' of that area when adding the borded just means that the Crop tool can also be 'self-encapsulating')

[Juan Conejero]

Hi Niall,

'self-encapsulating'

As you know, encapsulation is one of the main leitmotifs in the design of PixInsight (not surprising in an object-oriented pleatform), so this definitely makes sense. Interesting idea. Perhaps we could have regions of interest as standard properties of process instances, just as masks, for example. Then we would have "regional" (regionable? ) processes, just as we have maskable processes. Yes, interesting idea...