Cmos sensors and ROI

[Thalestris24]

Hi

I was wondering how the ROI function works with cmos sensors. Does it just select a row and column from the pixel grid i.e. no software binning? Does the function allow you to save subs using the roi dimensions or is it just for on-screen display? I'm comparing the imx183 (colour) and the 178 (colour) eg asi183mc-pro and asi178mc-cool. The 183 seems, ostensibly, to be a slightly better sensor than the 178 but I think it natively produces ~39Mb subs ? which sound a bit unwieldy (though storage is cheap!). I believe the 183 also allows software binning - is there any disadvantage to that? Any thoughts?

Thanks
Louise

[vlaiv]

ROI with CMOS sensors works in terms of download - it is determined on sensor as region of pixels to be read and downloaded.

It is exactly the same thing as doing crop in software except that it happens on sensor which has two important implications - download time is reduced because less data is transferred over USB link - helps with frame rate, and needed storage is reduced - less data transferred - less storage space (other data is effectively discarded on chip and never reaches computer).

No binning is involved with ROI function.

Any sensor "allows" for software binning. It is function of data processing rather than sensor, and you can select what type of "processing" you want to do to bin data. There are actually different ways to bin data in software. One is regular additive binning, then there is adaptive binning - where contribution of each pixel is varied depending on some factors (like SNR, or read noise or whatever). There is also option for "sift" binning - not sure if that is proper name - I came up with that and named it so - method very similar to drizzle integration, but works in opposite direction - instead of increasing resolution at expense of SNR, it lowers sampling rate to recover SNR but without side effects or simple additive binning (pixel blur).

Only drawback of software binning (regular one - or additive) in comparison to hardware binning is level of read noise. With hardware binning "summation" process is done on physical level prior to read and there is "one" read noise afterwards added. With software binning, because pixels are already read out of sensor prior to binning - each has its own read noise already added, so overall result of binning is "two" doses of read noise per binned pixel (in case of 2x2 bin). CMOS sensors due to their architecture are not able to do real hardware binning - each pixel is separate "unit" with AMP and A/D stages. On CCD, AMP and A/D stages are located on separate silicon and electrons are "marshaled" there in readout. In this process they can be "bunched" up together to do hardware binning.

[Thalestris24]

8 minutes ago, vlaiv said:

ROI with CMOS sensors works in terms of download - it is determined on sensor as region of pixels to be read and downloaded.

It is exactly the same thing as doing crop in software except that it happens on sensor which has two important implications - download time is reduced because less data is transferred over USB link - helps with frame rate, and needed storage is reduced - less data transferred - less storage space (other data is effectively discarded on chip and never reaches computer).

No binning is involved with ROI function.

Any sensor "allows" for software binning. It is function of data processing rather than sensor, and you can select what type of "processing" you want to do to bin data. There are actually different ways to bin data in software. One is regular additive binning, then there is adaptive binning - where contribution of each pixel is varied depending on some factors (like SNR, or read noise or whatever). There is also option for "sift" binning - not sure if that is proper name - I came up with that and named it so - method very similar to drizzle integration, but works in opposite direction - instead of increasing resolution at expense of SNR, it lowers sampling rate to recover SNR but without side effects or simple additive binning (pixel blur).

Only drawback of software binning (regular one - or additive) in comparison to hardware binning is level of read noise. With hardware binning "summation" process is done on physical level prior to read and there is "one" read noise afterwards added. With software binning, because pixels are already read out of sensor prior to binning - each has its own read noise already added, so overall result of binning is "two" doses of read noise per binned pixel (in case of 2x2 bin). CMOS sensors due to their architecture are not able to do real hardware binning - each pixel is separate "unit" with AMP and A/D stages. On CCD, AMP and A/D stages are located on separate silicon and electrons are "marshaled" there in readout. In this process they can be "bunched" up together to do hardware binning.

Ok, thanks Vlaiv. So ROI will let me (if I wanted to) save smaller subs i.e. I could treat a 183 as if it were a 178 for saving images? And/or use a 183 with reduced ROI for video/eaa?

Louise

[vlaiv]

Yes, if you look at specs for ASI cameras on their website (which is out of function at the moment ), they quote FPS in terms of resolution - by selecting smaller ROI you can achieve higher fps.

I know that with SharpCap and FireCapture you can select certain ROI and work with it, but don't know if ASCOM capture software will let you do the same (I suppose so but never tried).

For EAA I would personally use different approach with ASI183. Because very large number of pixels, best idea in my view is to download full frames and work with them. This gives you flexibility to bin or crop (effectively ROI). Vast majority of monitors and display devices do not support such high pixel count and often you will be watching at EAA image "scaled" down to fit display. It is better from SNR standpoint to bin data instead of just scaling it down. Again having that many pixels will let you "zoom" on region of interest and still have "native" pixels - so you can zoom to certain level (either smaller bin factor or native 1:1) and pan around the target.

ASI183 is better choice than ASI178 for most purposes, and it is certainly better bang for your buck - at 1/3 price increase you will get almost x4 sensor area with same pixel size - even if sensitivity was the same (and I think ASI183 has an edge there). Only advantage ASI178 has over 183 is planetary imaging one - able to achieve higher fps, for example at ROI 640x480 and 10bit ADC, 178 is quoted at 253fps while 183 is quoted at 170fps.

[Thalestris24]

5 minutes ago, vlaiv said:

Yes, if you look at specs for ASI cameras on their website (which is out of function at the moment ), they quote FPS in terms of resolution - by selecting smaller ROI you can achieve higher fps.

I know that with SharpCap and FireCapture you can select certain ROI and work with it, but don't know if ASCOM capture software will let you do the same (I suppose so but never tried).

For EAA I would personally use different approach with ASI183. Because very large number of pixels, best idea in my view is to download full frames and work with them. This gives you flexibility to bin or crop (effectively ROI). Vast majority of monitors and display devices do not support such high pixel count and often you will be watching at EAA image "scaled" down to fit display. It is better from SNR standpoint to bin data instead of just scaling it down. Again having that many pixels will let you "zoom" on region of interest and still have "native" pixels - so you can zoom to certain level (either smaller bin factor or native 1:1) and pan around the target.

ASI183 is better choice than ASI178 for most purposes, and it is certainly better bang for your buck - at 1/3 price increase you will get almost x4 sensor area with same pixel size - even if sensitivity was the same (and I think ASI183 has an edge there). Only advantage ASI178 has over 183 is planetary imaging one - able to achieve higher fps, for example at ROI 640x480 and 10bit ADC, 178 is quoted at 253fps while 183 is quoted at 170fps.

Yeah, I did try looking on the ZW web site - as you say, not working properly at the moment. I also tried downloading the qhy183 manual but got warned off with a 'dangerous website' warning. These Chinese companies don't seem to look after their own web security...

Yeah, the 183 does seem better value in terms of pixels and may be more sensitive (product info says 85% QE but it says that for the mono version also... ). I've used the ROI function with my Atik for focussing so I knew ROI could be useful for eaa - useful with a big resolution chip.  I just wasn't sure if I could use it to take subs (and calibration frames). If it can, indeed, do that, it would be useful

Thanks

Louise