Things crash on negative data out of DrizzleIntegration

const

New member
Jun 11, 2020
3
0
Ask me if you never get negative values in integrated images and I will upload some shots from my superdark site :)
So, my process is simple:
  1. WBPP calibrate only using darks, flats, and flat darks.
  2. StarAlignment.
  3. ImageIntegration with Noise weighting and Linear Fit or ESD rejection with default parameters. Discard the resulting image.
  4. DrizzleIntegration. Scale 1, Drop shrink 1, Enable CFA drizzle, all other defaults.
  5. STF AutoStretch resulting image — boom!
    Code:
    PixInsight 1.8.8-5 - Critical Signal BacktraceReceived signal 11 (SIGSEGV)
    Module: /opt/PixInsight/bin/PixInsight(+0x16d1f41) [0x564cec18ef41]
    ================================================================================
    6: /lib64/libpthread.so.0(+0x13070) [0x7ffb706b0070]
    5: void pi::RenderThreadBase::Render<pcl::FloatPixelTraits>(pcl::GenericImage<pcl::FloatPixelTraits> const*)(+0x215f [0x564ceb15feaf])
    4: pi::RenderThread<pcl::FloatPixelTraits, pcl::FloatPixelTraits>::run()(+0x53 [0x564ceb552f73])
    3: /opt/PixInsight/bin/lib/libQt5Core.so.5(+0xc75b2) [0x7ffb672ae5b2]
    2: /lib64/libpthread.so.0(+0x7f77) [0x7ffb706a4f77]
    1: /lib64/libc.so.6(clone+0x3f) [0x7ffb66433f8f](+0x3f [0x7ffb66433f8f])
    ================================================================================
    terminate called after throwing an instance of 'pcl::EUnixSegmentationViolation'
    Received signal 6
    #0 0x7ffb6ade4fae base::debug::StackTrace::StackTrace()
    #1 0x7ffb6ade3e83 base::debug::(anonymous namespace)::StackDumpSignalHandler()
    #2 0x7ffb6ade4f16 base::debug::(anonymous namespace)::StackDumpSignalHandler()
    #3 0x7ffb706b0070 <unknown>
    #4 0x7ffb663726c1 gsignal
    #5 0x7ffb6635c53b abort
    #6 0x7ffb6670c87e <unknown>
    #7 0x7ffb66718486 <unknown>
    #8 0x7ffb667184f1 std::terminate()
    #9 0x7ffb672754a9 qTerminate()
    #10 0x7ffb67276ef2 _ZN14QThreadPrivate5startEPv.cold
    #11 0x7ffb706a4f77 start_thread
    #12 0x7ffb66433f8f clone
    r8: 0000000000000000 r9: 00007ffa777fdac0 r10: 0000000000000008 r11: 0000000000000246
    r12: 00007ffad4005b90 r13: 00007ffd5afbb5ef r14: 00007ffa777fe700 r15: 00007ffa777fde80
    di: 0000000000000002 si: 00007ffa777fdac0 bp: 0000564cec3a0140 bx: 00007ffa777fe700
    dx: 0000000000000000 ax: 0000000000000000 cx: 00007ffb663726c1 sp: 00007ffa777fdac0
    ip: 00007ffb663726c1 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000004
    trp: 000000000000000e msk: 0000000000000000 cr2: 0000564df787664e
    [end of stack trace]
    Calling _exit(1). Core file will not be generated.
Statistics shows (unclipped) minimum values in some channels are negative, while other metrics are positive. I can Rescale the image to bring the minima to zero. Or I can simply save the image and reopen it. I guess, negative points are effectively clipped then, or somehow else killed.
ImageIntegration sometimes rescales or truncates the output when the original range extends to the negative space. I guess, DrizzleIntegration is not as careful.

How is it even possible to get negative values when all inputs are strictly non-negative? What is the right workaround for master light, rescale or truncate?
 

Juan Conejero

PTeam Member
Sep 2, 2004
7,555
96
56
Valencia, Spain
pixinsight.com
This is now fixed in the upcoming version 1.8.8-6, where DrizzleIntegration cannot generate negative output pixel values, just as ImageIntegration does. Thank you for the bug report.

How is it even possible to get negative values when all inputs are strictly non-negative?
Because of normalization. The additive with scaling normalization is as follows:

v' = (v - m)*s0/s + m0

where v is an input pixel value, v' is the normalized value, m is the location estimate (median) of the image, s is its scale estimate (e.g., MAD), m0 is the location of the reference image, and s0 is the scale of the reference image.

Note that the above equation can give v' < 0 if s0 < s and/or m0 < m. So it basically depends on the frame selected as reference and on the properties of all input frames. For example, if the reference image is weaker than most of the integrated frames, a negative result may happen. However, this should never happen with correctly calibrated data sets under normal conditions.

What is the right workaround for master light, rescale or truncate?
It depends. For integration of light frames, usually rescaling is the best option because it preserves all of the integrated data in the result. However, if additive components are not admissible (e.g., integration of master flat frames), or if the integrated image has to be compared with other images using a common range of data values, so a global change applied to all pixels is not possible, truncation is the only option. In the latest versions of ImageIntegration (and now DrizzleIntegration too), additive components are always avoided when possible, i.e. they are only applied when the integrated result has negative values and the truncate on out-of-range option is not selected.
 

const

New member
Jun 11, 2020
3
0
Glad to know it is already fixed. And thanks for the explanation! One less mystery.