Combining images with Pixel maths

[Jules]

Hi

I am trying to combine the two images displayed to make the OIII data envelope the Ha shock front, if I add them in pixel maths then I loose the surrounding Ha data.

I have tried a mask on the OIII then added it to the Ha in pixel maths that was a non starter.

Anybody any ideas please?

Julian

[RBA]

Are you trying to keep the image monochrome? If so, you could try a LinearFit on the OIII image, then a Max(img1,img2) in PixelMath.
Might not be the most elegant and elaborated solution but it's a start. Depending on how much you want the OIII data to show, after the linearfit you may want to push it a bit more before doing the Max operation

If you're trying to build a color image, then there are several ways to attack it, and others probably have better suggestions than what I could come up with (I haven't done much narrowband color stuff)....

[Jules]

Are you trying to keep the image monochrome? If so, you could try a LinearFit on the OIII image, then a Max(img1,img2) in PixelMath.
Might not be the most elegant and elaborated solution but it's a start. Depending on how much you want the OIII data to show, after the linearfit you may want to push it a bit more before doing the Max operation

If you're trying to build a color image, then there are several ways to attack it, and others probably have better suggestions than what I could come up with (I haven't done much narrowband color stuff)....

Hi, Thanks for taking the time and getting back. I actually want my cake and eat it. I would like to make a monochrome Ha/OIII and then try a bi-colour version.

Julian

[GB_10D]

Hi Julian,

A simple ADD operation will not do much good ( as you can tell already), you have to use the MAX operator:
MAX(image1, w*image2), w ... weight factor to balance both images.
The MAX operation will take the brighter pixel in given position in the two images and places it in the resulting image.
It is the equivalent operation to 'Lighten' in Photoshop.

Best regards,
Gerhard

[Jules]

Hi Julian,

A simple ADD operation will not do much good ( as you can tell already), you have to use the MAX operator:
MAX(image1, w*image2), w ... weight factor to balance both images.
The MAX operation will take the brighter pixel in given position in the two images and places it in the resulting image.
It is the equivalent operation to 'Lighten' in Photoshop.

Best regards,
Gerhard

Gerhard

That is really interesting. I will give it a go, thanks for your time.

Regards

Julian

[RBA]

When using Max(i1, w*i2) you'd need to be careful that the * operation does not bring some values in i2 out of range prior to the Max operation. Actually I don't know if leaving "rescale" checked would take care of that. I'm guessing that, although the final result would be within range, it might bring some values in i2 out of range during the intermediate * operation, hence resulting in a value of 1 for the final result. Maybe Juan can clarify.

It might be safer either do a linearfit on i2 first, as I suggested (actually I don't know if LinearFit might also bring values out of range!) and then, if you like (though not required) do the * operation on i2 separately (what I meant by "push it a bit more" in my earlier post - sorry I wasn't more specific) with "rescale" checked, prior to the Max operation.

The good thing of using LinearFit is that it takes the guesswork out of the equation.

[Jules]

When using Max(i1, w*i2) you'd need to be careful that the * operation does not bring some values in i2 out of range prior to the Max operation. Actually I don't know if leaving "rescale" checked would take care of that. I'm guessing that, although the final result would be within range, it might bring some values in i2 out of range during the intermediate * operation, hence resulting in a value of 1 for the final result. Maybe Juan can clarify.

It might be safer either do a linearfit on i2 first, as I suggested (actually I don't know if LinearFit might also bring values out of range!) and then, if you like (though not required) do the * operation on i2 separately (what I meant by "push it a bit more" in my earlier post - sorry I wasn't more specific) with "rescale" checked, prior to the Max operation.

The good thing of using LinearFit is that it takes the guesswork out of the equation.

Hi

Thanks for the reply. If I understand Linear fit correctly, because you specify a reference image then you are forcing the target image to have the same linear brightness response as the reference image?

I will have to see if Harry has a tutorial.

I want to merge the two images but I do not want to loose any of the Ha.

Regards

Julian

[GB_10D]

When using Max(i1, w*i2) you'd need to be careful that the * operation does not bring some values in i2 out of range prior to the Max operation. Actually I don't know if leaving "rescale" checked would take care of that. I'm guessing that, although the final result would be within range, it might bring some values in i2 out of range during the intermediate * operation, hence resulting in a value of 1 for the final result. Maybe Juan can clarify.

The beauty of floating point operations ( as used in PI) is the absence ( well, almost) of 'out of range' values during intermediate calculations.
And to be really on the save side, the weight factor can always be smaller than 1.

Best regards,
Gerhard

[Jules]

Hi

I have been experimenting with the max operator in Pixel maths and IMO it has worked pretty well. Have a look for yourselves.

The OIII shows up quite well around the shock front.

Thank you all for your help.

[RBA]

The beauty of floating point operations ( as used in PI) is the absence ( well, almost) of 'out of range' values during intermediate calculations.

I don´t think the floating point format has anything to do with this but if I´m incorrect please say so.
All pixel values in an image in PI are within the real [0,1] range. If your weight is, say, 2, and a pixel value is 0.7, the result will be 1.4, which is out of the 0-1 range.

If you use a value less than 1 as the weight, you´d be decreasing the final pixel values for that image, which probably isn´t what you want.

The key is having the "rescale" option enabled.

Makes sense?

[Juan Conejero]

As long as you have the "Rescale result" option enabled, PixelMath will preserve the whole set of values (to within roundoff error) that your PixelMath expressions have generated, irrespective of whether the final result exceeds from [0,1].

The beauty of floating point operations (as used in PI) is the absence ( well, almost) of 'out of range' values during intermediate calculations.

That's correct. Unconstrained intermediate calculations is one of the main advantages of floating point data. PixelMath performs all of its intermediate calculations (as most PI tools do) in 64-bit floating point format. Then it uses either 32-bit or 64-bit floating point images (selectable with the 'Use 64-bit working images' option) to store the result. Finally, if strictly necessary, the output is converted to an integer format (for example, if you are applying PM to an integer image this is unavoidable).

When using Max(i1, w*i2) you'd need to be careful that the * operation does not bring some values in i2 out of range prior to the Max operation.

You don't have to worry about that with PixelMath. This tool doesn't impose any restriction on intermediate pixel values; you can use the whole range of 64-bit IEEE 754. PixelMath only constrains the output to [0,1] as its very final step (and if you use PM from a script, you can prevent this final step completely).

[RBA]

The beauty of floating point operations (as used in PI) is the absence ( well, almost) of 'out of range' values during intermediate calculations.

That's correct. Unconstrained intermediate calculations is one of the main advantages of floating point data. PixelMath performs all of its intermediate calculations (as most PI tools do) in 64-bit floating point format. Then it uses either 32-bit or 64-bit floating point images (selectable with the 'Use 64-bit working images' option) to store the result. Finally, if strictly necessary, the output is converted to an integer format (for example, if you are applying PM to an integer image this is unavoidable).

When using Max(i1, w*i2) you'd need to be careful that the * operation does not bring some values in i2 out of range prior to the Max operation.

You don't have to worry about that with PixelMath. This tool doesn't impose any restriction on intermediate pixel values; you can use the whole range of 64-bit IEEE 754. PixelMath only constrains the output to [0,1] as its very final step (and if you use PM from a script, you can prevent this final step completely).

I know that Juan. By "out of range" I don´t mean the value is lost/truncated, but that then, when doing Max(i1, w*i2) the value of i1 will remain within 0-1, but not so the values of i2 (during the intermediate operations), so when ultimately the final result is rescaled (we assume "rescale" is enabled), all resulting values from Max will be rescaled according to the highest value in i2... (correct?) This MIGHT be what the operator wants, but it doesn´t make sense to me in the problem at hand, where we want both images more or les "fitted" then do the Max between them.

If we do the weighting thing on i2 separately before the Max operation using "rescale" (or better yet, a LinearFit), we´d end up with nice values between 0 and 1 for i2, and then, the Max operation between 1 and 2 would be more "balanced"... In this case, "rescale" isn´t even necessary for the Max operation.

Does this make sense?

[Juan Conejero]

It does make sense. However, keep in mind that since we are working with floating point all the time, the importance of these 'issues' gets minimized in a natural way, in most cases. For example, if we were working with 16 bits internally, then these considerations would actually be the problems to solve. Fortunately, we have overcome that in PixInsight long time ago

Max(i1, w*i2)

I released the LinearFit tool precisely because it is a nice way to compatibilize images, in the statistical sense. This has lots of applications. For example, one of them is as a preparatory step for LRGBCombination, where we can achieve a 'perfect' adaptation between lightness and chroma, with excellent results. If the above expression is being applied because i1 and i2 are not compatible (for a given purpose, which is unimportant for this discussion), then you are absolutely right: i1 and i2 should be made mutually compatible before the task in question. If the above expression is necessary as part of a specific image processing task (for example, because i2 requires to be scaled linearly in order to be compared with i1 to make some decision), then it is perfectly valid. It depends

[RBA]

It does make sense. However, keep in mind that since we are working with floating point all the time, the importance of these 'issues' gets minimized in a natural way, in most cases. For example, if we were working with 16 bits internally, then these considerations would actually be the problems to solve. Fortunately, we have overcome that in PixInsight long time ago

The important thing is to know what you're doing and why. In this particular problem, using Max(i1, w*i2) may not do what you want, being LinearFit what, at least I, would use instead, and as I see it, the fact that internal operations are done in floating point is irrelevant. Or better said, it's not irrelevant, but we're already assuming internal operations are being done in floating point (as you say, if they were done in int16, *that* would be a more serious problem).