PixInsight 1.8.8-9 Released

Juan, re the new image rotate, can you rotate unclipped within PixelMath? If so, can you show me a math example?
 
Juan, re the new image rotate, can you rotate unclipped within PixelMath? If so, can you show me a math example?

Unclipped rotations are not available in PixelMath, but if you need them, I can implement a new function very easily and release an update.
 
Unclipped rotations are not available in PixelMath, but if you need them, I can implement a new function very easily and release an update.


That would be very helpful. Also, would it be possible to use Pixelmath to say, close an image down by name? i am working on some process container stuff where I am creating a lot of reference images and it would be nice if I had the ability to close images down by name that I no longer need; either through pixelmath or a process icon where I had the ability to store an image name. I figured pixelmath via code command would be simple to do. Let me know, thanks!!
 
That would be very helpful

Count on it implemented and released in a few days.

would it be possible to use Pixelmath to say, close an image down by name?

That functionality is out of the scope of the PixelMath language.

or a process icon where I had the ability to store an image name

We could have a new process to close images. Instead of a single image, it could close a set of images by their identifiers using wildcards (such as "Image*"), or even regular expressions (such as "Image[0-9]+"). The process could also have a parameter to close images unconditionally, that is, without asking for confirmation. Such process would be very easy to implement. I'll try to implement it as soon as possible. Good suggestion!
 
Count on it implemented and released in a few days.



That functionality is out of the scope of the PixelMath language.



We could have a new process to close images. Instead of a single image, it could close a set of images by their identifiers using wildcards (such as "Image*"), or even regular expressions (such as "Image[0-9]+"). The process could also have a parameter to close images unconditionally, that is, without asking for confirmation. Such process would be very easy to implement. I'll try to implement it as soon as possible. Good suggestion!

Juan, that would be FANTASTIC!!!! Thank you very much!
 
Count on it implemented and released in a few days.



That functionality is out of the scope of the PixelMath language.



We could have a new process to close images. Instead of a single image, it could close a set of images by their identifiers using wildcards (such as "Image*"), or even regular expressions (such as "Image[0-9]+"). The process could also have a parameter to close images unconditionally, that is, without asking for confirmation. Such process would be very easy to implement. I'll try to implement it as soon as possible. Good suggestion!

@Juan Conejero if you do this, can you look into either shading or iconifying windows too, and have the ability to set the icon or shaded position? i was working on AutoIntegrate.js and apparently from PJSR the only thing you can do is iconify a window, and in order to force the icon location you have to save the window position, then set the window position such that the center of the window is where you want the icon, then iconize the window and restore the old window position. it seems like internally you do keep the icon position separately from the window position but from PJSR there's no way to access the icon position or set it.

rob
 
Count on it implemented and released in a few days.



That functionality is out of the scope of the PixelMath language.



We could have a new process to close images. Instead of a single image, it could close a set of images by their identifiers using wildcards (such as "Image*"), or even regular expressions (such as "Image[0-9]+"). The process could also have a parameter to close images unconditionally, that is, without asking for confirmation. Such process would be very easy to implement. I'll try to implement it as soon as possible. Good suggestion!


Juan, sorry to ask this but was wondering since you are working on pixelmath, could you add this feature as this would be another big help: So, because you already have "Replace Target Image" option, but could you add another option called "Replace Image ID" so that we could use math to replace an image already available? You can use the existing Image ID box to enter in the image name for the image you want to update Seems like an easy add. Please let me know. thanks buddy!
 
Hello Juan,

I tried the atan2 with the new release but was a little surprised that the calculation time seemed to be longer than what seems a more complex calculation, see 2 examples of old and new, all applied to the same image (I use it multiple times in my script, hence my focus on speed).

PixelMath: Processing view: theta
Solved 1 invariant subexpression(s).
Executing PixelMath expression:
sign(west)^2*atan(south/west)+0.5*(1-sign(west))*(1+sign(south)-sign(south)^2)*pi()
channel #0: done
72.080 ms

2nd example
sign(west)^2*atan(south/west)+0.5*(1-sign(west))*(1+sign(south)-sign(south)^2)*pi()
channel #0: done
70.469 ms

PixelMath: Processing view: theta
Solved 1 invariant subexpression(s).
Executed 1 image generator(s), 29.841 MiB
Executing PixelMath expression:
combine(south, west, op_atan2())
channel #0: done
140.014 ms

2nd example
combine(south, west, op_atan2())
channel #0: done
145.658 ms

Not a major issue, was just wondering if this was your expectation, or maybe I'm not using it correctly.

All image generators incur a performance penalty, since the time required to generate an image has to be added to the time required to access the generated image by interpreting an image reference during expression execution. Besides this, the op_atan2() operation works in 64-bit floating point format internally. However, the difference that you are observing, which I can reproduce on our machines in a similar way (your complex expression runs about twice faster), is difficult to explain in this case. I am investigating it and suspecting that this has to do with code optimizations. What is clear from this comparison is that my implementation of PixelMath's interpreter/compiler isn't too bad :)

At any rate, you can speed up PixelMath execution using generators if you enable its internal cache by setting the PixelMath.cacheGeneratedImages property to true from a script. For example:

JavaScript:
var P = new PixelMath;
P.expression = "combine( south, west, op_atan2() )";
P.useSingleExpression = true;
P.cacheGeneratedImages = true;

When the cache is enabled, subsequent executions with the same expression and source images are very fast because nothing has to be generated. To clear the cache, execute an instance with the PixelMath.clearImageCacheAndExit property set to true. Of course, this may or may not be applicable to your specific case. Thank you for the insight.
 
Juan, that would be FANTASTIC!!!! Thank you very much!

The unclipped rotation is now implemented in PixelMath (as a new urotate() generator). However, it may not be what you expect:

urotate.jpg


The problem is that, because of the way PixelMath works, the unclipped rotated image has to be smaller than the original one (except for rotations by 0/180 degress). This happens because PixelMath implements a pixel-by-pixel execution, so every generated image has to have exactly the same dimensions as the target image. Contrarily, the JavaScript and C++ implementations of unclipped rotations generate a larger unclipped/rotated image.
 
@Juan Conejero if you do this, can you look into either shading or iconifying windows too, and have the ability to set the icon or shaded position? i was working on AutoIntegrate.js and apparently from PJSR the only thing you can do is iconify a window, and in order to force the icon location you have to save the window position, then set the window position such that the center of the window is where you want the icon, then iconize the window and restore the old window position. it seems like internally you do keep the icon position separately from the window position but from PJSR there's no way to access the icon position or set it.

rob

Hi Rob,

In version 1.8.9 of PixInsight we'll have a new Workspace JavaScript object, which will provide access to the entire functionality of PixInsight workspaces, including image windows, image icons, process icons, etc. Basically, the Workspace object will allow you to manage all workspaces in a completely automated way, including the possibility to define the geometries of all elements and create/destroy workspaces. This will fill this important gap in our JavaScript engine.
 
The unclipped rotation is now implemented in PixelMath (as a new urotate() generator). However, it may not be what you expect:

View attachment 12096

The problem is that, because of the way PixelMath works, the unclipped rotated image has to be smaller than the original one (except for rotations by 0/180 degress). This happens because PixelMath implements a pixel-by-pixel execution, so every generated image has to have exactly the same dimensions as the target image. Contrarily, the JavaScript and C++ implementations of unclipped rotations generate a larger unclipped/rotated image.
Juan, can you get it to work rotated 90 degrees with no black areas? I tried running this "urotate" code but I get errors.
 
Last edited:
Count on it implemented and released in a few days.



That functionality is out of the scope of the PixelMath language.



We could have a new process to close images. Instead of a single image, it could close a set of images by their identifiers using wildcards (such as "Image*"), or even regular expressions (such as "Image[0-9]+"). The process could also have a parameter to close images unconditionally, that is, without asking for confirmation. Such process would be very easy to implement. I'll try to implement it as soon as possible. Good suggestion!

Juan, any update on when this feature will be implemented?
 
I am preparing a new 1.8.8-10 version, which I plan on releasing next week. For this reason I am not releasing any updates for 1.8.8-9 (because there are no urgent ones, of course). So I ask for a bit of patience here.
 
I am preparing a new 1.8.8-10 version, which I plan on releasing next week. For this reason I am not releasing any updates for 1.8.8-9 (because there are no urgent ones, of course). So I ask for a bit of patience here.

Awesome news, thanks Juan!
 
To quote the OP:

"... on all platforms."

I think it's a bit disingenuous to continue to count FreeBSD as one of the supported platforms for PixInsight. There hasn't been a release for it in some time now (yes, I am aware of the technical issues), but you cannot possibly even use the last released PixInsight on FreeBSD currently (the list of dependencies is massive and very out of date). Is there a version which works on the currently supported FreeBSD release i.e. 12.2-RELEASE or 13.0-RELEASE? At this point, I would settle for the current FreeBSD version of PixInsight (without all of the new features) for FreeBSD 13.0-RELEASE so that it is at least possible to run PixInsight and use it.

There are many other proprietary programs I use on FreeBSD which use Qt. The last released version of one of them is from 2012, and it loads and works the same now on a recent version (13.0-RELEASE) of FreeBSD. To accomplish this, it has bundled the dependency tree (all shared libraries) which it uses, paying special note to those of Qt. I would be very grateful if the current, old, FreeBSD release could be packaged like this, so it's at least possible to run the PixInsight and use it. If this is not possible, I think that FreeBSD support should be dropped entirely, or that PixInsight should state that it is only supported on older versions of FreeBSD those especially old versions of Qt which are several versions behind, because otherwise it is false advertising.
 
I apologize if this has already been asked. Will uninstalling the old version and reinstalling the new require reinstalling third party scripts (like the EZ Processing Suite) or special processes (like from Adam Block Studios)?
 
yes it will require reinstalling 3rd party scripts and of note, the https certificate for the EZ script repository has expired, so the https:// URL for the EZ repo will not work. at least one user reported that http://darkarchon.internet-box.ch:8888/ (no s and different port) still works, but of course that's an unsecure connection to the server.

rob
 
Juan, in pixelmath is it possible to skip the pixelmath process if a criteria hasn't been meet, say an "iif" command where an "iif" value hasn't meet a threshold, to stop the pixelmath process? example: iif($T<1,$T,end) where "end" will kill the pixelmath process? I am creating custom star mask routines in a process container but would like the ability to stop it early if the first pixelmath code wasn't met. I figured it would be easier if a kill command in pixelmath could be implemented.

Regards,
Bill
 
I am preparing a new 1.8.8-10 version, which I plan on releasing next week. For this reason I am not releasing any updates for 1.8.8-9 (because there are no urgent ones, of course). So I ask for a bit of patience here.
Just wondering when 1.8.8-10 will be released your note from 9/22 said next week that is 2 weeks ago. Just a note I can wait
 
Unfortunately, some of the important new features and changes that we are implementing are requiring much more development and testing time than what we anticipated. So the new version will be delayed about one more week, perhaps more. Patience, the wait will be worthwhile.
 
Back
Top