Pixelmath - replacing clipped pixels

chrisvdberge

Well-known member
I'm combining Ha with RGB and in the resulting image there is one small VERY bright Ha region that now has clipped signal. The RGB however also has this region in it and I thought to replace the clipped pixels with the RGB one. However, somehow nothing happens when I use the following in PixelMath:

iif(HaRGB_R == 1, RGB_R, HaRGB_R)

I basically end up with the HaRGB image.

How can I check for clipped signal in Pixelmath to make this work?
 
Hi Chris,

Have you tried the following type of expression :

    iif (image_A >= upper_threshold, image_A, 0)

This should give you a new image based purely on those pixels that are 'above' a maximum acceptable threshold (but 'pure black' otherwise). You could also then try '== 1' instead of '>= upper_threshold'.

Conversely, you could try

    iif (image_A <= upper_threshold, image_A, 0)

This should give you a new image that has 'pure black' pixels wherever there were pixels that exceeded the 'upper_threshold'.

Next, you could try

    iif (image_A >= upper_threshold, image_B, 0)

As with the first expression, you should be able to see what you would be using to 'fill-in (from image B) the 'black pixels' that you hopefully detected using the second expression.

Now, having done things in stages, you could finally try a simple 'image addition' as follows

    image_2 + image_3

where image_2 and image_3 are the resultant images from the second and third expressions respectively.

Note that all of the above expressions need to be entered into the Red channel expression field. The Green and Blue channels should simply have the following expression
    $T
or even (if you were using global instantiation)
    image_A

Let us know how you get on.
 
excellent idea to troubleshoot and diagnose it like that! :)
I tried a few things and eventough the Readout is saying K=1.0 I'm getting NO pixels returned if I try == 0
However, I do get a bunch if I try >= 0.9, and even still 'some' at 0.9999

Any reason why this would be the case? Rounding error seems not to be the reason as the Readout will give K values in 4 decimal places...

The result of this method by the way is aweful (as kinda expected ;)) but at least I'm getting some results now. Will now try to figure out a good way to do this. (maybe create a mask of those pixels and convolute and then use it to combine the RGB with the HaRGB)
 
creating a mask based on those pixels and convoluting it to then copy in the RGB worked remarkably well.
However, is there a way (in pixelmath?) to grow the structures in the resulting mask?
 
Hi Chris (and in haste for now),

If you re-think the image as an 8-bit image, for example. This would allow you 256 discrete levels of ADU - but the range of these values can only be from 0 to 255. You can't 'get to' a value of 256, as this would require an 'extra', ninth, bit.

Well, the same goes for 'float' values (as used internally by PixInsight). Sure, we all talk about them as being from '0.000' to '1', but in fact they can never quite reach '1'.

So your experiments showed no data when you looked for pixel ADU values that equaled 1 - which would be correct. As you dropped back from 1, you started to observe the 'clipped data' that you were looking for.

I'm not in front of a PixInsight machine at the moment, so I can't remember what it is you would need to do to 'blur' your data. But, if you think purely in terms of PixelMath, you actually now have all the tools to do this yourself. Hint: Don't just make a single image from pixels detected above the 'u1' threshold. Make several images, for u1, u2, u3... then 'add these together' (not a complete solution, by the way'. Or, build a new image whose ADU values represent the difference between the original image and the upper threshold, and then scale this (by addition) such that the ADUs with the greatest difference are larger in your final image (that you will be using as a mask).

There are many ways to tackle issues like this.

Perhaps you might also want to revisit your acquisition and earlier processing phases to see if there was a sequence of steps that you performed that caused the problem in the first place - and this try an eliminate that problem 'at source'.

Good luck - and let us know how you get on.
 
Thanks again. It does make sense indeed that 1.0 isn't a value. It was just confusing that Readout does give this value ;)

As for the mask and blurring, excellent point on doing this in multiple steps. For my case however, a simple (strong) Convolution on the mask did the trick. Especially considering the fact I'm talking about a tiny area of 60x90pixels in an image of 11308x7880  ;D :eek:

Anyways... this is my result for this action now;
Replace-clipped-signal-PixelMath.jpg


And I did a write up to document this for others here http://dslr-astrophotography.com/replace-clipped-signal-image/
(with a thanks notice to you ;) you have a link you want me to include?)
 
No need to 'link to me' - a link back to the PixInsight Home Page is more than good enough.

Glad you found a solution (oh, and "nice end result", by the way  ;))
 
Back
Top