PixelMath Problem

[jeffweiss9]

This is more likely pilot error than a bug but I've had trouble using Pixel Math on a set of narrow band images SHO where the output of simple combinations such as 0.15*H+ 0.5*O
give completely saturated images as new image outputs. The attached file shows the PixelMath expression prior to execution and the resulting completely saturated image. This was PI v1.1.8-12 build 1531 12/29/2021 on my Win10 64b system, but I then installed the latest PI v1.1.9-1 version and got the identical result.
I've used this previously without difficulty but am stumped here.
Thanks.

 

[fredvanner]

The effect you are seeing in that image is not saturation, it is posterisation. It may be genuine (i.e. all pixels in the grey region have exactly the same value), but it can also happen in PI if the brightness variation in the image is too uneven to be accommodated by the default 8 bit look-up tables in the STF function. This can be remedied by using 24 bit STF look-up tables (

on the tool bar).

 

[jeffweiss9]

Thanks, Fred. The 24bit STF worked and produced what appears to be the expected image. I've been using PI for many years and am wondering why I have never before encountered this issue that required setting the STF to a 24bit lookup table.
CS/Jeff

 

[pfile]

was the image integrated with the latest PI? i find that with LN and the latest II the normalization is sometimes very different than it was before, and the range of the output data from II is sometimes "compressed" into a very narrow range of floating point values.

or is this 100% just the difference between 2 versions of pixelmath? did you use LinearFit to normalize the Ha and OIII images before pixelmath?

rob

 

[jeffweiss9]

Hi, Rob-
They were all integrated with the earlier version 1.1.8-12 in WBPP v2.4.5 and I didn't reprocess them after updating PI to 1.1.9-1, I just found the same display issues that were corrected when I went to the 24bit look-up table for STF. The original integration files do not have this problem. One thing that is different however, is that I did a very tight crop of the original integrated images to concentrate on just the Tarantula; perhaps 1/6 or less of the area of the original integrated images. I would have thought that that would have reduced the precision needed for the STF look-up table, not increased it.
I normally do use LinearFit but after the pixelmath before channel combination so these did not have it.
Jeff

 

[jeffweiss9]

Actually, I realize now why I hadn't encountered this issue before. This image was the first one I've ever done using HDRComposition to get higher dynamic range using some short exposure data along with long exposure data. So, sure enough, the images after that point in the processing suddenly had these STF display problems that I now know are fixed by the 24STF. I was just so thrown off by the severity of the distortions in the posterized output, that I thought something else had gone horribly wrong in PI.
Unfortunately, that high dynamic range shown with 24STF did not survive after stretching and the rest of the processing to the final image (attached). But I guess that is another problem.
Jeff

 

[pfile]

ok - HDRComposition outputs 64-bit images by default and most times 64-bit images need 24-bit CLUTs

pretty nice image nonetheless!

rob

 

[jeffweiss9]

Thanks, Rob-
CS/Jeff