Author Topic: PixelMath - Rescale result not working as expected under v1.8  (Read 4134 times)

Offline Bob Andersson

  • Member
  • *
  • Posts: 67
Hi,

I've just upgraded to v1.8 RC7 (uninstalled 1.7 and installed 1.8). If I use PixelMath to perform (Img - 0.1) as a single RGB/K expression on a monochrome image "Img" then I get 0.1 subtracted from each pixel if and only if I deselect "Rescale result". If "Rescale result" is selected (default parameters 0.0 to 1.0 in use) then the pixels that should have been clipped are still there, as confirmed by the HistogramTransformation tool and/or a screen stretch.

I've confirmed this behaviour both for a 64bit floating point and a 32 bit unsigned integer version of the same image. I'm sure this wasn't how PixelMath worked under 1.7 and I imagine that this bug, if confirmed, is going to cause issues for some scripts as well.

Bob.
TEC 140 'scope, FLI ML16803 camera, ASA DDM60 Pro mount.

Offline georg.viehoever

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2132
Almost certainly the situation was the same with 1.7. As far as I know, PixelMath will not clip (i.e., if a pixel value is 0.6, and you apply $T-0.1, the value is -0.4). Rescale will later adjust all value to the range 0.0-1.0 by a linear transform ($T-min(image))/(max(image)-min(image)).

Georg
Georg (6 inch Newton, unmodified Canon EOS40D+80D, unguided EQ5 mount)

Offline Bob Andersson

  • Member
  • *
  • Posts: 67
Hi Georg,

Thanks for that but I think there may still be a problem. Consider these two scenarios:

1/ PixelMath (Img - 0.1) with "Rescale result" On doesn't clip dark pixels - as described in my opening post.

2/ PixelMath (Img - 0.1) with "Rescale result" Off followed by "Rescale RGB/K" from the main IMAGE menu does clip the dark pixels.

Simplistically I'd expect scenario 1/ to deliver the same result as scenario 2/. I'd always thought of the "Rescale result" functionality as being a way to rescale values in a range from zero to some arbitrary positive number to the range 0 to 1 (or Lower bound to Upper bound). I can see a logic to the way it works in scenario 1/ but in that case the behaviour in scenario 2/ is counter-intuitive IMHO as it implies that PixelMath has clipped negative values back up to zero as the new image is generated.

Above my pay grade, I'm afraid so I'll wait hopefully for official word on this from the team. If the PixelMath behaviour is by design and not a bug then I could certainly use an expression such as max(0, (Img - 0.1)).

Bob.

P.S. But I am pleased I finally upgraded to 1.8 whatever the verdict.  8)
TEC 140 'scope, FLI ML16803 camera, ASA DDM60 Pro mount.

Offline Carlos Milovic

  • PTeam Member
  • PixInsight Jedi Master
  • ******
  • Posts: 2172
  • Join the dark side... we have cookies
    • http://www.astrophoto.cl
Yes, this is the designed behaviour of PM. Values are treated as floating point internally, so they may be out of range, and not be clipped (either below zero and above 1.0).
Regards,

Carlos Milovic F.
--------------------------------
PixInsight Project Developer
http://www.pixinsight.com

Offline Bob Andersson

  • Member
  • *
  • Posts: 67
Hi Carlos,

Thanks for the swift reply. I stand corrected and I'm sorry to have wasted everyone's time.  :-[

Fortunately my "Repaired HSV Separation" script sets "rescale" to false for all the operations that might have been affected by my previous misunderstanding of how PixelMath's "Rescale result" works. Phew!  :D

Bob.
TEC 140 'scope, FLI ML16803 camera, ASA DDM60 Pro mount.