vlaiv

Yes, that is correct (although CMOS are not designed for short exposure - but rather allow for short exposure, due to their low read noise) - but that has nothing to do with what I've said. It has to do with brightness of the target - which has some flux - or some photons per second. If target has say 0.5e/s flux (we here convert to electrons and assume known QE of sensor) - in 30s exposure it will accumulate 15e, while in 300s it will accumulate 150e. These are absolute numbers per exposure and they change based on what exposure length you use - regardless of CMOS vs CCD thing. If you take bunch of subs with about 15e of signal and stack those using average method - well, average of bunch of 15e will be 15e. Resulting stack will have that absolute value. Similarly - bunch of subs with 150e averaged will produce stack with 150s signal. Although both stacks produce same image (same SNR) - they will differ in absolute value. Shorter exposures will simply produce smaller values. And if you have very short exposure and very small values - 16bit integer format will produce rounding errors. Simple as that.

Total exposure is important as far as SNR goes. As far as absolute values go - single exposure time is important. You average single exposures (most of the time), when stacking - and hence resulting stack will have same absolute signal values as single exposure. If you decide to stack using sum method (in that case - no fancy weighted methods nor sigma rejection) - you will get same absolute values regardless of exposure length - for same total duration.

If you run PI script - then it is very likely that it converts to 16 bit for StarNet and then converts back to 32bit - in the process rounding happens so error is introduced regardless of data being 32bit in the end.

Don't know about StarXTerminator - but this happens to me: (this is with version x2 of starnet - not sure why it still says StarNet++ for GUI). Readme also emphasizes this: StarNet++ v2.0.2 Finally! -> As before: Only TIF files with 16bit per channel are supported. <- -> Yes, AVX is still needed. Sorry! <- -> If the previous version did not work - this won't either. <- -> TO BE USED FOR ASTRO IMAGE PROCESSING ONLY <- -> Have fun! <-

I'm not a fan of using 16bit format in any stage of image processing (apart from acquisition). This is more pronounced these days with progress in CMOS arena. CMOS sensors have lower read noise and thus drive ever shorter exposures. It is not uncommon for people to use 10-20 times shorter exposures with CMOS then it was common with CCD cameras. This means that signal levels are much lower - for same brightness of target, x20 shorter exposure will result in x20 lower signal value. Take for example instance where you have faint signal in 10 minute exposure - say 250e. Same signal in 30s exposures will be x20 times lower or 12.5e on average. Problem with 16bit image format is that you can't record 12.5e - you can either record 12e or 13e and you introduced 0.5e just by virtue of using 16bit format. 32bit float point does not have this limitation. It can record numbers with much greater precision - and any introduced error is minimal (easily swamped by noise). Short exposures "cram" all the signal into lower part of 0-16bit range, and although signal is fine grained after stacking - it will get rounded up and unnecessary errors will be introduced. This leads to "posterization" of faint parts of image on short exposures. One way how to avoid this happening with StarNet V2 and still use linear data would be to linearly stretch your data - setting white point to just above brightest target parts. This will clip the stars, but we don't really care as stars will be removed. We just need starless version (we can later subtract starless version from full version to get unclipped stars with some math).

It looks like it is necessary. I tried running Starnet v2 on 32bit image and it complained and refused to work.

But still uses only 16bit data format?

Pixel size is not important, or rather, small pixels can be used on long focal length. You can reuse the same camera on 1300mm of FL as long as you bin your pixels to get adequate sampling rate. I use 3.8um ASI1600 camera on 1600mm FL. Sometimes I can use bin x2 - for 1"/px but most time I'll bin x3 for 1.5"/px. I bin in software after capturing, when I asses FWHM of the capture (binning in software also allows for more flexibility than binning in firmware of camera). Do be careful - binning with CMOS sensors does not keep the same read noise, so above calculation (or measurement) for exposure length is always performed at native resolution. This might be an issue for you as higher native resolution of the system - longer subs are needed to swamp the read noise. This is because with higher resolution - LP signal is also spread over more pixels and each pixel gets less LP signal and thus has lower LP noise (read noise per pixel remains the same).

I just ran some basic calculations and it will actually take about an hour of exposure in those conditions to swamp the read noise x3 If you really want shorter exposures - look at CMOS sensors with very low read noise.

You have very dark sky and very high read noise - optimum exposure length is 10+ minutes for you.

Say you have multiple scopes that share filter wheel and camera, or perhaps you have 5 position filter wheel that you use for both LRGB and narrowband imaging and need to change filters from time to time.

Because you use permanent setup. Much more likely if you take your setup apart after every session.

Rrrreally good version? R stands for version with belt fitted out of the box, but why did they decide for R moniker is beyond me.

That is the best solution - having proper markings on rotator (does not have to be automatic). That way, even after plate solve - one can easily rotate correct amount to match needed angle, but that all adds $$$ to setup.

Having standard orientation of sensor allows for markers on camera / ota for quick alignment. 0/90 can also be easily aligned without plate solving - with drift exposures (drift is in RA direction and bright star that drifts in exposure will leave a line - if that line is either horizontal or vertical in frame - you are aligned).

Yes. It is best to Find/Frame/Focus the target and then move scope to meridian / dec 0 to calibrate just before starting imaging run.

Here is interesting comparison: http://www.astrosurf.com/buil/filters/curves.htm Note this graph: Astronomik UHC is combined with IR cut filter (this is important for imaging, but not for visual as we are not sensitive to light about 700nm anyway).

Well, best course of action is to actually digitize those graphs given in images and then put results in say spreadsheet, multiply values and produce resulting graph. You can use online tool like this to read graph values and save as CSV or similar: https://automeris.io/WebPlotDigitizer/ It is possible to do crude assessment of what resulting transmission will be over range of frequencies. It is important to note that usually two things happen - first, resulting peak transmission is the same or (more often) reduced. It can never be increased. Similarly - width of filter pass bands is the same or (more often) reduced. It can never be widened by stacking. For this brief analysis of stack of two filters - we can divide resulting filter in two regions. Region around 500nm (OIII zone) and Region around 656nm - Ha zone. CLS filter is simply wider around OIII as it starts around 450nm and finishes at ~520nm, while UHC goes from 480nm to 510nm. Both filters have peak transmission around 95% in this range. Stack will simply behave as narrower of the two - like UHC filter with peak transmission around 90% (0.95 * 0.95 = 0.9025). As far as OIII zone is concerned - stack performs little worse than UHC alone Then there is Ha zone - here both filters start at 640nm - but UHC does not finish after Ha signal - it continues. CLS does drop off just before 700nm and that is a good thing because it removes all wavelengths above that. Again - peak transmission will be smaller then either of filters - at about 90% Overall stack behaves like UHC filter with IR cut off applied and somewhat lower transmission. Similar effect can be obtained by stacking UHC with regular IR/CUT filter, or even better - Astronomik L3.

Blow bulb, but really you want to take flats as flats sort out issues with dust (and other things like uneven sensor response if there is any).

Given that you have spacing issues - dust is most likely on field flattener rather than on sensor or IR cut filter.

Yes, it is dust - but rather far away from sensor. Closer dust is to sensor "more concentrated" shadow is, and opposite happens when dust is further away - fainter and larger shadow becomes.

Mono is faster, but your example can't be used to demonstrate that. You can't show that mono is faster by using OSC camera only. What you have demonstrated is that removal of LP increases SNR even if it decreases signal somewhat - that is the point of using certain filters. With filters - it is pretty simple. You multiply transmission graphs. It goes like this - for each wavelength, you check out transmission in both (or multiple) filter graphs and read of percentage passed. Use percentage in 0-1 range (so not 80% but 0.8) and multiply. If there is even single filter with 0% transmission - whole stack will block that wavelength as X * Y * Z * 0 = 0, no matter what X, Y and Z are ... Back on topic mono vs color. Color is faster in other aspects. We must first define what "fast" means. If we define fast to be something like time taken to reach target SNR given certain parameters (sampling rate, aperture, scope type, etc - pretty much everything except OSC vs Mono) then Mono is always going to be faster. In fact, besides being faster - it is much more flexible. But, there is other type of speed that we need to consider. Imagine someone not having a permanent setup - and most amateur astronomers don't in fact have permanent setup. This means that per imaging session for LRGB you need to include 4x focusing, 4x flats. If flats happen to be of different exposure - that also means 4x flat darks If one is not very versed in all of that - above can amount to maybe additional hour or so of "not imaging" during imaging time. Over the course of whole evening in wintertime, or several evenings - that can be compensated by speed of Mono system (time to target SNR kind of speed), but if one is imaging for only 1-2 hours, well - half of that is going to go on focusing and flats and all of that after filter change. Automated filter wheel improves this speed (not all people have it so less people will see mono as faster) Automated focuser will improve this speed (not all people have it so again less people is likely to see mono as faster) Not all have flat panels, ... It is easy to see why people think OSC is faster. One more thing - comparing two same sensor cameras in Mono and OSC version is comparing apples and oranges - and often people don't see / understand that. What you want to do when comparing data from OSC / Mono same sensor is either: Use super pixel mode to debayer OSC and bin Mono x2 (to get the same sampling rate) or Use regular debayering and bin Mono x2 and then scale it up by x2 to again get the same format of data. It simple fact that OSC samples at half the frequency of Mono and this needs to be addressed when comparing data. It also means that if Mono is properly sampled, OSC will be less sharp for same sensor (nothing to do with antialias filters on DSLR - this is true for dedicated astro cameras as well).

I think that 5.4kg quote is whole package with included eyepieces, 45 degree diagonal for terrestrial and that case that all comes in. Scope itself is less than 2Kg as far as I was able to find online. (check out Vixen A62SS and Orion StarBlast 62mm - same scopes from Long Perng as the one I linked and both quoted at ~1.5Kg / 3.1lbs=

This seems to be the issue. Once you blow up things and clip them - bringing those down wont restore dynamics in those areas due to clipping.

Maybe go with this instead? https://www.teleskop-express.de/shop/product_info.php/language/en/info/p14791_Tecnosky-AC-62-520--Refraktor---optischer-Tubus.html I'm inclined that it will give better views and will certainly allow form wider field without vignetting.