Ed,
Let me know if you still think there's a bug in the fitsviewer stretching, and if so, please post somewhere an image I can download and read into a fitsviewer, and instructions on what I should do to replicate the problem.
Sorry if things aren't clear. Here's how I intended it:
The button on the far left turns on and off stretching. If you have it off, the image is displayed linear, as captured.
All the other buttons are then disabled until you turn it back on.
The button on the far right (magic wand) sets the image back onto the default stretch setting.
If the image is already on the default stretch setting (as it is initially), the button is disabled, as it would do nothing.
The sliders in the middle control the shadow, midtone and clipping parameters.
You can move them, left or right, and as you move them, a real-time (but low resolution, for compute reasons) preview of the stretch is shown.
When you let go of the slider, the setting is kept, but the button returns to the middle of its range so that you can make further adjustments--there is very little screen space.
You can tell the setting is kept as the number shown should not change after you release the button. Think of these as "relative" sliders.
Also, when you let go of the slider, you also get the full-resolution image, instead of the real-time approximation.
Further, now that you've changed a parameter, the magic wand activates, allowing you to return to the default stretch.
Stretching should work on a monochrome or RGB image. If an RGB image is not debayered, it is treated as monochrome (and you can see the bayer pattern if you zoom in).
The stretch scheme, and defaults used, is what's described in the PixInsight documentation:
See section 8.5.6 of
pixinsight.com/doc/docs/XISF-1.0-spec/XISF-1.0-spec.html
though without the "expansions" described there.
Hy
PS I would think an RPI4 could auto-debayer just fine, though I don't have an RGB astro camera.
If you are auto-computing HFR, though, you should consider the "quick HFR" option.