ASI290 mono software binning issue

hs9

After a few months I recently updated my ZWO ASI drivers. After the update when I use my ASI290 mono camera in SharpCap and select x2 binning the software simply resizes the image with no change to ADU values. Previously I used to see a jump in the ADU values with the whole histogram shifting to the right (which is the correct expected behavior). Is this a change by ZWO?

-Hiten

Sam@ZWO

Hi Hiten

we changed the binning algorithm from sum up to average

so the SNR is still improved but keep the same brightness

hs9

Thanks Sam. Is it possible to have a user selectable option whether to sum or average i.e. provide two different operations? Since formally binning is defined as a sum operation on pixels this will also help avoid confusion with users.

I find the binning operation extremely useful for real time viewing/observing. For imaging I am fine as I make the decision to bin in post processing.

riklaunim

average binning is not always desired or needed. Like methane band imaging.

Sam@ZWO

Hs9 wrote:
Thanks Sam. Is it possible to have a user selectable option whether to sum or average i.e. provide two different operations? Since formally binning is defined as a sum operation on pixels this will also help avoid confusion with users.

I find the binning operation extremely useful for real time viewing/observing. For imaging I am fine as I make the decision to bin in post processing.

This make no sense because you can adjust the gain to make image brighter

so sum up = avarage+4x gain

hs9

Sam wrote:
Hs9 wrote:Thanks Sam. Is it possible to have a user selectable option whether to sum or average i.e. provide two different operations? Since formally binning is defined as a sum operation on pixels this will also help avoid confusion with users.

I find the binning operation extremely useful for real time viewing/observing. For imaging I am fine as I make the decision to bin in post processing.

This make no sense because you can adjust the gain to make image brighter

so sum up = avarage+4x gain

Sam,

I think the problem is that these operations (e.g. very high gain) are not mathematically equivalent to binning and can cause other consequences such as calibration issues.

I am already operating at a high enough gain and going beyond it calibration becomes more challenging for me. Binning would provide the sensitivity increase that I am looking for and also the ability to change sampling i.e. arcsecond/pixel which I cannot achieve with averaging. This is also critical for hiding tracking errors or optical aberrations from very high sampling. Averaging does not address this.

Also formally binning is defined as a 'sum' operation of the pixels. You cannot average and then call it binning. It is very confusing when one vendor decides to adopt an arbitrary definition of a formally defined operation in imaging theory.

Further, averaging pixels within the frame is very different to averaging across sub exposures wrt noise reduction as you are comparing one sample to multiple samples which is critical for random noise which varies with time (and from frame to frame). Averaging pixels within the same frame does nothing in this regard as you are averaging samples across the spatial domain and not the time domain. Hence it is a very different operation.

I am quite puzzled as to why there is resistance to fixing this feature. Binning is a very standard operation and should be implemented in line with first principles of imaging. From an effort perspective it should be a very simple change to the driver or am I missing something?

Hiten

Sam@ZWO

Hi Hiten

actually, they are the same

because gain more than 300 are digital too

so all are digital processing

we changed the sum up algorithm to avarange is because the digital gain is already high

it's not possible to adjust the brightness value lower when binning at gain 0

and it's too bright when use binning at day time

easybob95

Well it is stupid to change sum to average value without asking users !

I do use bin2 for eal time video and I need sum for bin2.

If I want average, I can select hardware bin2 for imx178 camera.

It is really boring you make such changes ! I am very angry with you Sam.

You must restore very quickly sum for software bin2 at least for asi178 color camera.

Alain

hs9

Sam wrote:
Hi Hiten

actually, they are the same

because gain more than 300 are digital too

so all are digital processing

we changed the sum up algorithm to avarange is because the digital gain is already high

it's not possible to adjust the brightness value lower when binning at gain 0

and it's too bright when use binning at day time

Sam,

I don't want to use digital gain or any other workaround to mimic binning. I want binning (as do most users) and not noise reduction or averaging or any other operation.

If I want to do noise reduction I can use the appropriate filters in software. I would prefer to not be forced to do averaging when I want to do binning.

I am really puzzled as to why you don't want implement binning as binning. Binning is way of managing etendue, averaging is not.

Also I have not purchased this camera to use in the daytime. I want maximum sensitivity for Astro applications.

Hiten

chripell

Quite frankly I don't understand why so much anger. The only difference between 4*average and sum could be for rounding problems, but I think the digital numbers are already upscaled from the actual ADC dynamic range (12-14 bits) to 16, so there are spare bits that avoid loss of precision when averaging. If this holds true, simply the 2 things are mathematically equivalent, with the advantage of a better utilization of the machine word by averaging. Honestly I would always save unbinned data when possible. I think binning strictly as summation really makes sense in HW much early in the imaging pipeline, so it increases the signal in the SNR, because the noise of following stages remains constant.

This is just my 0.02 eurocent.

Sam@ZWO

chripell is correct, there is no difference actually

anyway, seems some user used to the old way

we can change it back in our next release

hs9

Thanks Sam. I would really appreciate if you could revert the driver & SDK to the standard binning operation. I welcome additional features in the SDK like averaging but please keep behavior of standard operations such as binning intact. It really helps avoid confusion and makes the cameras more user friendly.

I really enjoy using ZWO cameras (have quite a few of them!) and appreciate your contributions to our hobby.

Separately, I would like to clarify why it is helpful to have the standard binning operation.

Firstly, not everyone is post processing all the time. When I am observing live at the scope I don't have the benefit of picking my binning approach after the fact. My preference is for binning to work like binning... adding the signal from adjacent pixels to manage etendue i.e. energy per pixel, creating a brighter image.

Secondly, averaging across spatial and temporal domains is not conceptually equivalent. When you are averaging adjacent pixels in an image it is not the same as averaging to remove noise at the same spatial coordinate across multiple frames or exposures. The statistical process that occurs when averaging across frames to reduce noise and bring out the signal does not apply to spatial averaging which is a different process conceptually.

Hiten

Sam@ZWO

Hs9 wrote:
Thanks Sam. I would really appreciate if you could revert the driver & SDK to the standard binning operation. I welcome additional features in the SDK like averaging but please keep behavior of standard operations such as binning intact. It really helps avoid confusion and makes the cameras more user friendly.

I really enjoy using ZWO cameras (have quite a few of them!) and appreciate your contributions to our hobby.

Separately, I would like to clarify why it is helpful to have the standard binning operation.

Firstly, not everyone is post processing all the time. When I am observing live at the scope I don't have the benefit of picking my binning approach after the fact. My preference is for binning to work like binning... adding the signal from adjacent pixels to manage etendue i.e. energy per pixel, creating a brighter image.

Secondly, averaging across spatial and temporal domains is not conceptually equivalent. When you are averaging adjacent pixels in an image it is not the same as averaging to remove noise at the same spatial coordinate across multiple frames or exposures. The statistical process that occurs when averaging across frames to reduce noise and bring out the signal does not apply to spatial averaging which is a different process conceptually.

Hiten

thanks Hiten

hs9

Sam,

I was reading the release notes for the latest SDK and it seems the SDK is still avaraging instead of binning in the 16 bit mode. Is this correct? Not sure if I am reading it correctly .

If so, can you explain why x2 bin in 16 bit mode does not bin.

Thanks

Hiten

jagho

Hi,

I'm reading this topic and I'm little concerned, because I'm going to buy ASI290MM-C. What about bin2 with ASCOM driver (e.g. MaximDL). Is it sum (as I hope) or AVG ?

Sam@ZWO

we changed it back in our latest SDK

as the ADC is 12bit when you run at 16bit mode

after binning the data is 14bit

we put the 14bit data in the high 14bit of 16bit format

sangon

Hi Sam

Thanks for the update... Then, the new SDK also includes the change for the ASI 178MC?

The thing is that when I bin in Sharpcap (latest version with latest SDK) at RGB24 binning works ok, but in RAW16, it doesn't... In fact, the histogram is almost identical in both pictures (binned and unbinned)... with the same luminosity values compared over the same areas...

Why my 178mc doesn't sum values binning in raw16?

Thanks,

KR, Miguel

Sam@ZWO

sangon wrote:
Hi Sam

Thanks for the update... Then, the new SDK also includes the change for the ASI 178MC?

The thing is that when I bin in Sharpcap (latest version with latest SDK) at RGB24 binning works ok, but in RAW16, it doesn't... In fact, the histogram is almost identical in both pictures (binned and unbinned)... with the same luminosity values compared over the same areas...

Why my 178mc doesn't sum values binning in raw16?

Thanks,

KR, Miguel

178 has 14bit ADC, we put it at high 14bit data of 16bit

sum up just exactly 16bit

so you cannot tell from the luminosity value, but the SNR changed

gulinux

Hi, I saw that software and hardware binning are behaving differently in my ASI1600mm, with software binning being much darker. Since I'm using Linux SDK, is this because the additive algorithm has been restored only on the Windows SDK?

If so, could you restore it on the Linux version too?

Thanks,

Marco.

Sam@ZWO

the hardware binning of 1600 is different from other cameras

the brightness will increase by 4X if you choose hardware binning

you cannot see from the image if you enable software binning under RAW16

the brightness will increase by 4X too if you choose RAW8 output