Siril Pixelmath

Hi to all, I am learning Siril pixelmath mostly by learning about Pixinsight pixelmath.
I wish to thank the devs for this functionality as I am committed to growing with Siril on its journey.
I have noted that at this time functionality lacks logical operators like iif, or, etc & look forward to future updates.
I do wish to make a contribution to the group that appears to be undocumented.
The power of inverted pixels is supported at this time. For example consider this possible creation of a green channel from Ha & Oiii : (where tilde = (1 - something,) an inverted pixel.)
The forum will not produce a times sign ( shift 8 ) so I used x in place of.
f: (Ha x Oiii)^~(Ha x Oiii)
SynG: f x Ha + ~f x Oiii
In this case you can create a new image from the “f” line and save it as a new image called This is like storing a subroutine or a function that can be called into the second line after it is added as a variable in pixelmath. It uses inverted pixels to create a unique channel based on the pixel values found in each of Ha & Oiii channels.
I’m still looking for a good expression to represent a synthetic SHO version from duo narrowband data. Ideas?


PixelMath introduced in Siril 1.0.0 is quite basic.
We are currently working on a better version, but we need to be patient ;).

Thanks for your kind comments.


1 Like

New Siril version is available, with a PixelMath greatly improved.

1 Like

This is fantastic! Thanks to all the dev who make this possible. Siril just keeps getting better!
My only feature request would be for a median function to simplify calcs like “R+factor*(newHa-med(newHa))” This is part of a common work flow for adding Ha data to galaxy arms etc.
My regards!

1 Like

For now you can computer the median with the siril stats. It is just an extra step.

1 Like

One problem I still have with the pixelmath in Siril-latest is that of aligning the inputs. The RGB compositor has the ability to align the images used for each colour albeit it cannot rotate them, but once you’ve loaded the various input images into the pixelmath tool there isn’t a way of aligning them. So for example I have stacks of Ha, OIII and SII data on an object but they aren’t perfectly aligned and rotated, I can’t combine them with pixelmath as the resulting image will be full of misalignment artefacts.
Siril has the capability to register, align and crop images - it does this for subs prior to stacking obviously. It would be wonderful if this capability could somehow be added to the pixelmath tool - pick say Ha as the reference, register all the other images and crop to the common area. I did try taking my different filter stacks, creating a sequence and registering them to achieve this but for some reason it didn’t work properly.

This is a common request, we will hopefully do it in a near-future version.
Renaming your files (or symbolic linking them) to a new sequence and running registration on it should still work.

As the name of the tool says this is just math of pixels.
I don’t believe that other software providing such a feature allow us to align the images in same time because this is not the goal.

Maybe we would add some math in the rgb compositing (this is what Vincent is talking about), but Pixel Math is not dedicated to other things that doing math with pixels in my opinion.

That’s fine, I was only drawing the comparison with the RGB tool, but the fact is that what one wants as the input files for pixel math is aligned stacked images, and although Siril provides a good alignment process for aligning subs within a sequence to be stacked it doesn’t generalise that capability very well. I know you can make the stacks into a sequence and register them but then say you had stacks named Ha, Oiii and Sii you lose those names and have to figure out which one of the images in the registered sequence is Ha, which is Oii etc. A more general interface to the registration process that could do a better job of preserving the names of the input files so you could then feed those into pixel math and know what you were dealing with would be great (and you could also feed the result into RGB compositor instead if you preferred, thus the other alignment code in RGB compositor would become redundant and could be got rid of).

That’s true but the type of filter is kept in the FITS keywords and Pixelmath recognizes it.

Oh! Yes I’m embarrassed to say I hadn’t noticed that, or at least I probably had but didn’t make a connection. So I’ve been renaming files from my stack sequences for no real need! :face_with_hand_over_mouth:

No problem, everything is explained here: Siril - Discovering PixelMath