C11 HD Hyperstar or reducer?

[ollypenrice]

17 minutes ago, Xplode said:

You would be amazed at the low noise the IMX455 sensor has, i've compared the KAF 16200 sensor and the IMX455 sensor and the read noise is so low that images get deeper in a shorter time.
The downside is some stars have haloes, but the stars on the KAF 16200 isn't perfect either.

This is the point. I can't argue with the speed and resolution of the CMOS cameras but the numbers don't tell the whole story.

Olly

[wimvb]

4 hours ago, Wiu-Wiu said:

Interesting point in investing in a new camera, but ZWO just doesn't seem to have that kind of pixel size cameras (I'm fond of the asiair so I want it to be compatible, and a cooled camera is a must)

My ASI174MM-COOL has 5.86 um pixels and a small chip (1900 x 1200 pixels). Paired with a moderately sized scope (1000 - 1600 mm), it hits the sweet spot as a galaxy hunter. Nowadays, ZWO concentrate on large(r) sensors. If you don't want the large files asdociated with these, you can set ROI while imaging. This is like cropping, but without the large files raw data.

2 hours ago, DaveS said:

 

I was seeing this on the FLO site

And assumed that it applied to the mono version. Are ZWO selling porkies?

What I don't like about ccd is the long download times when doing alignment or focusing. In all fairness, this wouldn't be an issue during data capture. 

[DaveS]

3 hours ago, Xplode said:

I would say it's kinda a grey area around the binning of these sensors.
Like mentioned earlier it's meant for color cameras so it bins several R, G, B pixels together.

There's also the thing with the ZWO Ascom driver only supporting software binning, for hardware binning the software has to connect in native mode like what Sharpcap and other planetary imaging softwares can do.
I haven't really tested the hardware binning on the ASI6200 mono camera i have access to.

One last (!) question then I'll let the thread back on track. Am I understanding correctly that if I want to bin, eg the whole frame, then I have to download the full size, 124 MB files and downsample after stacking? Or is there a more efficient way.

Sorry to hijack the thread.

[ollypenrice]

1 hour ago, wimvb said:

My ASI174MM-COOL has 5.86 um pixels and a small chip (1900 x 1200 pixels). Paired with a moderately sized scope (1000 - 1600 mm), it hits the sweet spot as a galaxy hunter. Nowadays, ZWO concentrate on large(r) sensors. If you don't want the large files asdociated with these, you can set ROI while imaging. This is like cropping, but without the large files raw data.

What I don't like about ccd is the long download times when doing alignment or focusing. In all fairness, this wouldn't be an issue during data capture. 

I focus manually so I select a small box around the focus star and get an almost instantaneous download.

Olly (Yes, I'm a dinosaur and, quite probably, a brontosaurus even then!)

[wimvb]

47 minutes ago, ollypenrice said:

I focus manually so I select a small box around the focus star and get an almost instantaneous download.

Focus measurements for a reflector are a little trickier than for a refractor. Software can have trouble interpreting the doughnut profile. Ekos, which I use, at times just measures a bright area on the defocused star and returns sub arcsecond fwhm/hfr. Full frame focus measurements are generally more reliable. Such is astro life. 

[ollypenrice]

1 hour ago, wimvb said:

Focus measurements for a reflector are a little trickier than for a refractor. Software can have trouble interpreting the doughnut profile. Ekos, which I use, at times just measures a bright area on the defocused star and returns sub arcsecond fwhm/hfr. Full frame focus measurements are generally more reliable. Such is astro life. 

That's good information because we never got any sense out of Full Half Radius (I think it was) on single stars using Nebulosity for capture with an ODK14 reflector. We reverted to Bahtinov Mask. I never knew why the equivalent of FWHM didn't work since I've always used it with refractors. Maybe this is why.

Olly

[Xplode]

6 hours ago, DaveS said:

One last (!) question then I'll let the thread back on track. Am I understanding correctly that if I want to bin, eg the whole frame, then I have to download the full size, 124 MB files and downsample after stacking? Or is there a more efficient way.

Sorry to hijack the thread.

If you want to bin "the right way" that's how you need to do it.
You can of course downsample the image before stacking, but i bet the image would end up better if downsampling after stacking/processing.

[DaveS]

Thanks Ole.

Gonna need a bigger drive :).

[wimvb]

12 hours ago, ollypenrice said:

Quite so, but the impressive size of their optics is easier to see from down here than the equally impressive size of their pixels!

😁lly

 

Quite so. When @gorann and I processed images from the Liverpool telescope, we only needed few subs to get good data. This is due to the combination of a large, albeit slow by amateur standards, mirror (2 m, f/10) with large pixels (15 micrometers, but binned to 30 um). At 20 m focal length, the pixelscale was 0.3"/pixel.

[Rodd]

On 23/04/2020 at 08:35, Xplode said:

Software binning is kinda pointless, it's better to downscale after stacking the image.

This is simply not true.  The results of software binning are essentially identicle to those of hardware binning.  If you doubt this, ask the member Vlaiv to explain it.....I used to doubt too.  But I have seen the results first hand.  One thing, if you use Pixinsight, or another software that has a screen stretch function that is not a permanent stretch until you make it one, then the effects of software binning can only be seen if a new screen stretch is applied to the image.  If you have a stack--say the red stack--screen stretched on the screen and you bin it 2x2, the image will get smaller but won't change otherwise.  However, if you remove the screen stretch and then reaply a new screen stretch, you will immediately see that the bin2 version is brighter and fainter extensions are visible.  The image does get smaller--but the FOV remains the same.  If your bin2 stack has a resolution below what seeing allowed, then you won't lose any resolution by binning.  If you are shooting with the C11 at .4 arcsec/pix and seeing was around 2 arcsec, you could bin 4x4 and still not lose descernable detail.   But it will be like multiplying your integration time by a factor of.....allot!!!!   16x?   not sure.  But I don't like binning past 3.  If you post a bin 2 image on this forum--full resolution is still bigger than normal vieiwing.  I think that is true for Bin 23 as well, but there is no much of a size increase.  After 3, there is no size increase.  Buts that is personal preference (probably bias)

[gorann]

On 23/04/2020 at 18:12, DaveS said:

One last (!) question then I'll let the thread back on track. Am I understanding correctly that if I want to bin, eg the whole frame, then I have to download the full size, 124 MB files and downsample after stacking? Or is there a more efficient way.

Sorry to hijack the thread.

You can tell the sofware running the CMOS camera to bin (e.g.2x2) and it will save smaller files. I do not do that since hard drives are cheap (on average I image 50 - 100 nights a year with two or more scopes with APS-C cameras each night and it still takes me 2 years to fill a 5 Tb harddrive that costs about 200 GBP). I guess I do not like the feeling of loosing data, even if I do know that it may be empty data and I may as well save binned data. Binned data is also faster to stack and process. But if I save it all then I have different choices of how to bin it, some better that other (Vlaiv tried to explain it once). What I do is usually to downsample the final processed image to a degree where I see no loss of resolution. I guess that is also a form of binning.