Scripts run from menu entry does not store parameters in History Explorer

[georg.viehoever]

Juan,

when the Canon Banding script (as delivered with 1.60) is run from its menu entry, the history explorer does not record its parameters:

Code: [Select]

var p = new Script;
with ( p )
{
   filePath = "$PXI_SRCDIR/scripts/CanonBandingReduction.js";
   md5sum = "6ca666141cfa089c1bc29627d65c828d";
   parameters = [ // id, value
   ];
}

If I run the script, create a script instance using the blue triangle, and drop this on the image, I get this in the History Explorer (which is what I expected):

Code: [Select]

var p = new Script;
with ( p )
{
   filePath = "$PXI_SRCDIR/scripts/CanonBandingReduction.js";
   md5sum = "6ca666141cfa089c1bc29627d65c828d";
   parameters = [ // id, value
      ["amount", "1"],
      ["highlightProtect", "false"],
      ["sigma", "1"],
      ["isGlobalTarget", "false"],
      ["isViewTarget", "true"],
      ["targetView", "light4"]
   ];
}

I am not sure if this is a coding error on my side, but I believe that I faithfully copied your example code...

Georg

[Juan Conejero]

When you run a script from the Script menu, it is being executed without a target image. This is because you are not "throwing" the script to an image explicitly. When you create an icon or drag an instance of the script to an image, the script runs on different contexts. The same happens with 'normal' (PCL-based) processes; however you don't notice it due to the way processes interact with the platform's GUI (modelessly). A script's interface, on the other hand, is always modal, so you expect it to do "something productive" when you launch it. However this is not necessarily true due to PI's architecture.

This is a complex topic that deserves an in-depth analysis. This is not a bug (I think) but a combination of behaviors and features derived from PI's object-oriented design, which require a good explanation. I'll think on a way to formalize the behavior that must be expected from a script as a function of its different execution contexts. Things like these don't happen with other softwares whose names begin and end with the same letter

[georg.viehoever]

Juan,

the use case where this behaviour hurts me is this:

- I use a test image to create a sequence of process steps.
- If that works, I create a process container from the image history, dragging the blue triangle from the History Explorer to the desktop
- I then create an ImageContainer, and apply it to the process container on the desktop.

Unfortunately, this container does not contain the right parameters for the script, so the result of a long long long long ImageContainer run is just wrong....

If you could find a solution fitting with the PI architecture... 

Georg

[Juan Conejero]

If you could find a solution fitting with the PI architecture...

I fully understand your frustration. The problem here is that you can't drag an instance from the script's dialog directly to an image, due to the fact that the JavaScript engine (seen as a whole including PI's interface with it) is not reentrant. So you are forced to create an icon if you want to save your parameters. The problem arises when a single icon isn't sufficient, as is your case.

The solution should be in the script's source code. I'm quite confident that a strategy can be found to store all of your processing steps as a single icon. This involves modifying your script's parameters so that they can accommodate a list of actions. This may give you some hints as to how to proceed. When I have more time (I am working hard now on an automatic updates system for PI, which is rather complex) I'll give you a hand on this.

[Carlos Milovic]

(I am working hard now on an automatic updates system for PI, which is rather complex)

Will it run with:
yum upgrade pixinsight
or
apt-get upgrade pixinsight
?
  

[Juan Conejero]

yum upgrade pixinsight
or
apt-get upgrade pixinsight

Pretty much the same, but without the command-line stuff

Seriously, this is gonna be a huge step forward, an important milestone in PI development. Right now we are completely stuck because to add a significant improvement or change I need to release a new version of the entire platform. For example, this is the reason why I can't include your modules as quickly as they should be made available.

From now on, all bug fixes, new scripts, development modules, etc, will be distributed immediately as updates. Add to this the new PCL backwards compatibility feature, and most users won't need to download a new full installation package anymore, unless they want to install PixInsight on a different machine or hard disk.

[Niall Saunders]

Hey Juan,

You really are beginning to get the hang of this software development game.

You will soon be able to turn professional

All I need now is a video tutorial showing how to configure a 'naked' PC to be able to compile PCL modules. Either that or you develop an on-line system where we just upload our source code to a PI server location, and some automated system 'instantly' compiles all the necessary OS variants and posts these on a download site, along with the creation of a topic message on the PI Forum.

Surely that shouldn't be so difficult? Any chance of seeing it by the weekend

Cheers,