Crashing when applying 24-bit Auto-STF after Drizzle

[naavis]

Hi!

I'm able to crash PixInsight after running the DrizzleIntegration process. After running the process, I close the weighting image, then auto-STF the result file by pressing Ctrl+A and then enabe the 24-bit lookup table for STF by pressing the button on the toolbar. Then PI crashes. I'm running Windows 8.1 64-bit. Also, saturated parts of the images (some stars and galaxy cores) turn black in the drizzled image.

[Juan Conejero]

Hi,

I can't reproduce this problem. Could you upload the drizzled image somewhere, so I can try to understand why this happens?

saturated parts of the images (some stars and galaxy cores) turn black in the drizzled image.

That happens when "clip high range" is enabled in ImageIntegration. When a saturated pixel gets rejected in all input frames, drizzle sets it to zero in the final image. This does not happen with ImageIntegration because this tool sets 100% rejected pixels to the median value of the stack. However, DrizzleIntegration cannot do that because it integrates one image at a time and hence does not have all the data available at once.

If you disable the clip high range option, there should be no black pixels due to rejection.

[naavis]

I sent you a link to the images via private message.

If Pixel Rejection is completely disabled both in ImageIntegration and DrizzleIntegration, I'm also getting those black cores after drizzling.

[naavis]

Oh, I sent you the original images. I can also send the drizzled version ASAP.

[naavis]

The plot thickens. I attached a screenshot of what the drizzled image looks like with pixel rejection disabled. Now, if I save the image and open it again, the black striping near the saturated areas is gone. The drizzled image can be found here: https://dl.dropboxusercontent.com/u/17224129/m51_drizzled.fit

Also, if I save and reopen the image before applying auto-STF and the 24-bit LUT, PixInsight does not crash. It only crashes if I try doing the 24-bit STF when those stripes are visible, right after drizzling.

[Carlos Milovic]

Could you check the pixel values at those locations? Are they in the normalized range? Are there any negative, greater than 1.0 or NaN values?

[naavis]

Could you check the pixel values at those locations? Are they in the normalized range? Are there any negative, greater than 1.0 or NaN values?

The values are slightly above 1. There are values such as 1.003, 1.0001, 1.005 etc. If I save and reopen the file, the same pixels are only around 0.92.

[Juan Conejero]

This is a bug in the DrizzleIntegration process: of course there should be no pixels with values larger than one. I can reproduce it with the data that naavis has kindly uploaded for me, so I'm working to find and fix the problem right now.

In the meanwhile, a workaround is applying PixelMath with default parameters and $T as the RGB/K expression. This will truncate all values to [0,1].

Sorry for the inconvenience.

[Juan Conejero]

Update: the bug is now fixed. I'll release an update as soon as possible. Thank you for your help.

[naavis]

Awesome, thanks!

[Igor]

Hello Juan,

I can reproduce the same issue and crashing the last release of PixInsight with an image with pixel values slightly below 0. Negative values are not an issue with ImageIntegration which rescales the final image I guess.

Regards

Igor