Auto Stretching wash-out for ASI294MM-P

Hi everyone,
just wondering if any ZWO ASI294MM-P owners are seein the same issue.

Ever since my first usage of the camera with SGP, the streched image has been “washed-out”, almost white. I’ve looked at all the settings and cannot find anything that would allow me to set the stretching lower than “low”.
It’s not a major issue. More of an inconvenience, as I can’t accurately assess if my exposure time is too long or not. I do use the image statistics but it would be nice to also have a visual reference.

This issue does not arise with my ASI2600MM-P or the ASI183MM-P on a different setup.

I’ve attached a picture of what the display looks like in SGP and then one with the same picture in PI.

Would very much appreciate any help that can be given.

Thank you and Clear Skies.

Update: I noticed, that this does not occur during the autofocus process, probably due to the short exposure time of 10 Sec.

I am not certain, but, while the range where data is found (over ~1000 - 1200 wells on the black side) seems normal, the shape and number of gaps seem “off”. Over a histogram range of 1200, it seems odd that you would have that many gaps in data (especially for monochrome). Here is a range over even less data than yours that presents as a smooth curve (at least over a small area of the screen like this). It is probably true that other setups that don’t exhibit this behavior show less gaps. Of note, the missing data wells seem almost as if they are uniform in nature. It is entirely possible that SGPro is picking up on those gaps and misinterpreting them for something they are not.


I have a QHY294mm-P and this is what I see. Granted different manufacturer, but the chip and bit depth are the same I believe.

Ken and pmumbower,
thank you for responding. Now I´m a little worried :smile: Is my camera really losing data or is it just not being represented in the histogram? Not sure if my histograms have ever been that smooth as your.

Would you have a clue how these data gaps come about?

Thanks for the help.

Hi Allen.

A defective camera is improbable.

The gaps are inherent when converting from the native bitness of the camera to the ASCOM 16bit standard. That conversion is an integer multiplication of the ADU values. If you use the camera in the normal 2x2 binning, you get a conversion from 14 bit to 16 bit, i.e. a multiplication by 4. Let’s suppose, the camera delivers a set of pixels having 100ADU, 101ADU, 102ADU. After conversion we get 400ADU, 404ADU and 408ADU. There will be no pixel having 401, 402 or 403 ADU ==> Gaps!

If you use the camera unbinned (unlocked) it will have only 12bit output and the necessary multiplication will be by 16 ==> huge gaps!!

Check the ASCOM settings of your camera. While you are here, update the ASCOM platform and the ZWO ASI software. What versions are you using now?

If you could upload a raw fits-file on a dropbox drive and post a link here, I could have a look.

Kind regards,

Hello Horia,
thank you very much for your contribution.

I have ASCOM 6.6, ZWO Ascom V6.5.1.8 and the ZWO ASI Camer driver V3.16 installed on a Win 10 Intel i7 PC with 16GB Memory. SGP is the latest stable version.

Here is the link to requested FIT image:

Thank you for your help.


Hi Allen

and thank you for the files. There is nothing wrong with your camera.

I loaded one of the files in PixInsight and started the HistogramTransformation. Then I zoomed in on the x-Axis, until each histogram-bin become one ADU wide. By positioning the cursor on the histogram, you can now read the number of pixels for a given ADU-value.

Given the bin 1x1 setting you used, all values in the histogram are spaced 16ADU apart, as it should be due to the conversion from 12 to 16 bits:


This is by itself not a problem, as the stacking you are certainly going to do will perfectly fill in the gaps.

When loading the image in SGP, I get the same effect at AutoStretch level = Low and way worse for Medium and High. To be honest, given the stretch algorithm SGP is using, I do not think there is a lot Ken can do. Maybe clipping just a little bit more the black level. Even PixIsight struggles somehow with that file.

Kind regards,

We are certainly open to adjusting the way we stretch images if it is problematic for an entire class of 14-bit (native) cameras. Right now, we don’t do anything special and literally use the methods present in the (very popular) aforge library. Is there a better approach that is less sensitive to these conversions?

Currently using: LevelsLinear16bpp Class

That said, having never used a 14-bit camera (except occasional DSLR usage), it’s not clear to me if the solution here is drivers and settings (because @pmumbower has the same internal hardware and does not see this?) or if this is actually something SGPro should handle better. Thoughts.

Hello Horia,
thank you so much for taking the time to check and explain. I understand now and am relieved :smile:

Best Regards,

Hi Ken,
thank you for your support.

I can live with this for now, since no one else seems to be experiencing the same.