Speaking as a volunteer who has taught both CCD courses as part of CHOICE: I think it is time for those who are experienced CMOS photometrists to start sharing informed information among themselves about “best practices” for using CMOS cameras for photometry. Perhaps Headquarters knows who these individuals are and can call for a committee of the willing to share information.
A manual or at least a “facts sheet” should be generated with very specific protocols directly related to CMOS photometry similar to those the information now existing for CCD and DSLR sensors. It should be authoritative regarding the kinds of CMOS cameras that are suitable (mono, obviously: pixel size, minimum bit depth, etc.), specifics on topics such as gain setting, well depth and etc., calibration and other topics that might set CMOS cameras apart from CCD cameras. Having Googled the topic, I know there is a lot of information out there, but how much of it is informed? Not knowing much, if anything, about critical use of CMOS cameras for photometry, I cannot judge.
With this information AAVSO can either (1) contemplate a separate CHOICE course for CMOS photometry (restricted to suitable CMOS cameras) or (2) give the CHOICE CCD instructors the tools to help any CMOS photometrist to get through the CCD courses.
This call for action is somewhat self-serving. I was not able to provide the kind of advice to a recent CMOS-camera participant in CCDI that I would have liked to provide, simply because I don’t use a CMOS camera.
IMO NABG CCD cameras are optimal for photometry at our level. But I know that ABG CCD, DSLR, and CMOS cameras have been demonstrated to be effective photometry cameras. We cover NABG and ABG CCDs in the CCD manual, we have a DSLR manual. It's time for a CMOS manual or at least an appendix to the CCD manual covering whatever differences there are between CCD and CMOS cameras.
Ed Wiley (WEY)
Indeed ZWO discontinued their ASI 178 cooled model, but you can still get what I guess is essentially the same thing as "Alccd-QHY 178cool" from the Astrolumina brand, and perhaps from other vendors as well.
CS
HBE
That is a shame about the ASI178MM cooled version being discontinued. I was weighing my options and thinking about selling my 183 and buying the 178 cooled.
I do have the ASI178MM-uncooled for planetary imaging. Now, there are four M4 threaded holes in the back of some of the uncooled ZWO cameras including the 178. There was a video online on how to mount a Pelter cooler on it but there wasn't anything about percise thermal controls that was mentioned. The ZWO camera software has temperature control where it will maintain the same temperature.
Well as I wrote, you can still buy a cooled IMX178 based camera from Astrolumina. The DIY cooling solution is perhaps a bit problematic wrt. fogging of the window due to condensation. Cooled cameras have desiccant plugs for that, but the uncooled and DIY-modded cams don't have that. But we are digressing a bit here I guess.
CS
HBE
Dear Ed,
I am very new to photometry and in fact not knowing any better plunged head first into obtaining differential photometry light curves of SS Cygni recently using a CMOS camera (QHY 174M). I have enclosed my results as an attachment to this message. My technique is far from conventional at this point. I am using a Star Analyzer 200 on my 12-inch LX-200 for simultaneous observations of spectroscopy and photometry. I know it may be hard to correlate the photometric values to a standard, but the light curve itself is informative and can give clues about where changes in the spectra may have ocurred. This aside however, I do believe there will be more people like me using these cameras for photometry in the conventional sence, and a resource to help us learn the ropes would be very appreciated.
In addition to a post #48 ( https://www.aavso.org/comment/66914#comment-66914 ): I've done additional tests of ASI120MM-S: another photometric run against XX Cygni (https://the-sky-above-us.blogspot.com/2019/10/using-zwo-asi120mm-s-planetary-camera.html) and linearity test (plus measurements of other characteristics of the camera: https://the-sky-above-us.blogspot.com/2019/10/measuring-of-characteristics-of-zwo.html). XX Cyg photometry shows good light curve. The linearity test shows that the camera is very linear (see attached pictures), however, some features were found at low ADU level very similar to those mentioned by Mark Blackford for Canon EOS 600D (https://www.aavso.org/comment/47248#comment-47248) and by Christian Buil for cooled ZWO ASI1600MM camera (http://www.astrosurf.com/buil/CMOSvsCCD/index.html). Buil thinks that that behavior is caused by imperfect timing for very short exposures he used. I think it is not an exposure timing problem rather some features of the CMOS sensor itself (auto-adjusting dark level?).
This is a side-by-side comparison between the Orion Starshoot G4 Monochrome 16-bit CCD camera and the ZWO ASI183MM-Pro 12-bit camera with 4x4 binning, which, according to some of the comments on this thread gives an equivalent dynamic range of 16-bits. I wanted to use this on some variable stars or a standard field but I'm still waiting for my Astrodon V-filter for that.
So, tell me what you think.
I think that binning makes sense only if the star's image is spread over binned pixels more or less uniformly. I would rather avoid binning, instead, I would work with unbinned images to better control a degree of defocusing. Moderate defocus allows us to measure the signal from many pixels which increases the virtual dynamic range.
My experience so far with the ZWO ASI1600MM through a 120mm f/7.5 refractor suggests that optimising the degree of defocus may give better results than binning. I don't have enough data yet for proper analysis but interim results show that minimal defocus gives me better precision than more aggressive defocus. For brighter stars it is of course easier to end up with saturated pixels. Getting the right balance between exposure duration and degree of defocus appears to be the key, with the aim of achieving ADUs as close as possible to the upper end of the linear response range of the sensor. This is how I achieved my best precision, as in the results with RS Gru and its check star In my first post on this camera.
Roy
I also think that it is important to choose proper gain. For unity gain (Gain120, see https://astronomy-imaging-camera.com/product/asi183mm-mono) you can collect no more than 4095 electrons per pixel (for 12-bit camera). This will lead to a bigger statistical error (caused by the limited number of electrons). I think it is worth to set the gain to bigger values (say, 2 or 3 e/ADU) to better consume full well capacity (using longer exposures). It depends on a target and observing conditions, of course.
Someone mentioned that a camera should have 2 extra bits for noise.
https://www.aavso.org/comment/66769#comment-66769
If that's so and binning with a CMOS can be used to produce virtual 14-bit images with a 12-bit camera, then would it not be prudence to both crank up the Gain to 120 *and* set the camera to 2x2 binning, especially for the ASI183 since the pixels are pretty small even for a CMOS. At 2.4µm, that would be 0.67 arc-seconds per pixels with my scope (FL=731mm). With a FWHM of 4, that would mean FWHM would be 5.9 pixels. So, a 2x2 binning for the ASI183 would mean the FWHM would be 2.95 pixels and a little bit of defocusing wouldn't hurt either.
BTW: what did you think about the comparison between the ASI183 and Starshoot G4? I know taking pretty pictures isn't quite the same but there is some overlap. Also, I could any advice on doing comparison for photometry purposes. Finally, I recently scored an SBIG ST-7E NABG camera off Astromart.com for $20, and I would like to do a comparison between the three.
I did another photometric try with ASI120MM-S on 30 Oct: a target was TT Ari (interesting cataclysmic star). Telescope: 150/750 Newtonian (SkyWatcher). Images were processed in IRIS (calibration) and measured in AstroImageJ. No binning, gain 2e/ADU, exposure 25s. As for me, the photometry looks good (data were loaded to AAVSO database):
https://www.aavso.org/lcg/plot?auid=000-BBD-461&starname=TT%20ARI&lastdays=200&start=2458787.25&stop=2458787.5&obscode=PMAK&obscode_symbol=4&obstotals=yes&calendar=JD&forcetics=&pointsize=1&width=800&height=450&mag1=10.6&mag2=11&mean=&vmean=&grid=on&uWV0pt=on
I also attached a light curve for a check star.
I tried submitting my ASI183 FIT file to VPHOT but it wouldn't accept it because the wording in the FIT header for the exposure time was different from the acceptable wording (EXPOINUS for ZWO camera). That and the exposure time was given in µs. (60 second exposure is written as 60000000 us for 60 million microseconds). How were you able to get yours submitted to AAVSO?
I do not use VPHOT. I use IRIS for calibration, AstroImageJ for plate solving (with local astrometry.net server -- see https://adgsoftware.com/ansvr/) and measurements, Excel table for final calculations (with special VBA macro to export to AAVSO format). However I plan to use VPHOT in the future.
Probably you are using ASICAP (it writes exposure this strange way)? Try SharpCap, it creates normal header (however DATE-OBS corresponds to the end of an exposure, be aware of this!)
Just for the record and as a heads-up for people using SharpCap:
Following a discussion with the author of SharpCap, the software now writes an estimation of the exposure *start* time (rather than the time the frame was received by SharpCap) into the DATE-OBS header field (at least for ZWO ASI cameras like the one I use, that do not have GPS etc to timestamp the frames in-camera), like this:
DATE-OBS= '2019-12-05T02:53:26.5663177' / System Clock:Est. Frame Start
SWCREATE= 'SharpCap' / v3.2.6137.0, 32 bit
If in doubt, look at the comment field of the fits header, it was and is always correct in describing how to read the time. Here is what it used to be :
DATE-OBS= '2019-10-31T00:59:38.8267762' / System Clock:Frame Received
SWCREATE= 'SharpCap' / v3.2.6086.0, 32 bit
The new behaviour is much more in line with expectations of popular photometry software, but if you explicitly compensated for the previous, rather unexpected behaviour, you will want to skip that step after the update of SharpCap.
Cheers
HB
Thank you for pointing this! I'm still using an old version. I's good to know about this unexpected change...
.
It has been suggested that binning can improve the characteristics of the CMOS sensor, changing it's characteristics from 12 bit ADC to something more like 16 bits.
I've tried 2x2 and 3x3 binning with the ASI1600MM. There is no improvement in precision.
Roy
Actually, binning will work only if starlight is more or less equally spread over binned pixels. This assumes some defocus. Now I think that it would be better to avoid binning, instead work with original non-binned images, which allows better control of defocus. There is no matter in which stage signals from different pixels are summarized: during image capture or at a stage of postprocessing (in case of CMOS sensors). All we need is a moderate defocus. An alternative way: stacking several images. I.e. stack of 4 images has virtual 14-bit digitalisation (assuming initial images are 12-bit)
Indeed. After all, aperture photometry is nothing but binning: for every star that is measured, you add pixels and put them into just two bins (the pixels from the inner aperture go into the "starlight bin" and the pixels from the outer anulus go into the "background light bin" and with those you do the math for the photometry). Binning some pixels up front won't help, it's a matter of (A+B)+(C+D)=A+B+C+D.
I think the most useful application of binning in CMOS sensors with restricted bit-width of the ADC is in a thought experiment :-), only to convince yourself that it's pretty much the same whether you have bigger pixels that are then digitized at 16 bit or (say) smaller pixels that together cover the same area as the bigger comparison pixel and individually need fever bits to represent, provided there is even defocus across those smaller pixels and the readout noise is small.
I would say, that there is another very important benefit of binning as well - the storage control one. I have a ASI183MM here, every single frame unbinned is 40 MB... Usually I'd take at least 5 measurements per filter (I have 5 of them), so 1 GB of raw data per one data point per star which I really have to archive.
I really would like to observe bright stars, in that case I have to use very short exposures but stack many (sometimes hundreds of them) to beat scincillation.... At the same time live stacking could do as well.
Best wishes
Tõnis
ASICAP let's the user set the region of interest. If field of view is not an issue, the region of interest can be set in such a way that only a portion of the total CMOS sensor is recording data this keeping from filling a hard drive with unneeded data without binning (though, for pointing the scope, the full 5496x3672 can be used).
Sorry double post
Do you have actual data from ZWO ASI cameras that defocussed, binned images give greater precision than defocussed, unbanned images? The tests in which I could not improve precision with binning were conducted on defocussed images.
Roy
That is, "unbinned".
No. As Bikeman has already noted, there is no matter how to sum up pixel values.
Since I asked for any actual photometic data on binned defocussed images, it's only fair that I attach my own test results.
Stacking images has been mentioned. But my observing involves time series photometry through the night. It would be very tedious to stack groups of images. Rolling averages would achieve the same thing (at the expense of lowering the magnitude values at the peaks of the light curves, and raising them at the troughs), but also rather tedious. Therefore, for me achieving the best precision for photometry on each image is the goal.
Roy
ZWO just came out with the ASI6200MM, a 16-bit, full-frame monochrome CMOS camera.
https://astronomy-imaging-camera.com/product/asi6200mm-pro-mono
At Gain 0, the ASI6200MM has a dynamic range over 83 dB (FWC: 51,000 -e; read noise: 3.5 -e) or nearly 14 stops.
Hello! Just curious if the CMOS cameras have adjustable gain with binning? Some cameras and companies allow the gain to be adjusted in their cameras while other cameras/companies have fixed gain.
If the gain does not change, I believe that the same number of electrons in 1x1 would be spread over the total binned pixels. So, for 2x2 binning, each pixel would only be able to handle 1/4 the electrons as it would have with 1x1.
For example, (for round nunbers) with a gain of 2 e-/ADU and 100,000 e- full well, the system would have 50,000 ADUs. With 2x2 binning, with a gain unchanged of 2 e-/ADU, the output would still be 50,000 ADU for the single large binned pixels, so the 100,000 e- are spread over all 4 pixels, essentially decreasing the dynamic range but preventing oversampling so that the image would more closely match the Nyquist theorem.
If the gain is adjustable, then lowering the gain to 0.5 would allow each pixel to continue to have a full well of 100,000 e-, essentailly inceasing the full well of the 2x2 binning to 400,000 - increasing the dynamic range while more closely matching the Nyquist theorem.
I may not have gotten the interaction of gain and binning correct, and I would love to hear from others about it. I am far from an expert, and I'm trying to evaluate the benefit of binning/gain vs. larger pixels of cameras to match telescope focal length (taking into account cost, etc.)
There are other factors besides gain to take into account with binning, too. And Arne has discussed them in some of his post and videos. Thank you and best regards.
Mike
Gentlemen:
My original post was a call for action in producing either a CMOS manual for photometry, or a 'fact sheet" or a CHOICE class, or all of the above.
May I suggest that general discussion of COMS cameras for photometry might get more attention if a specific topic "CMOS Cameras for Photometry" was placed on the forum.
I have found much of the discussion very informative, my motivation in dedicating a forum with a more informative title is that more of our colleagues may see be drawn to it rather than the forum with my original title.
CMOS is the wave of the future, I do hope someone will take up the challenge of producing the documents that will alow others to make the transition.
Ed