vlaiv

I also see them as very handy little mounts that do both EQ and AZ and can track with simple motor. They do look decent enough to be recommended as a star tracker for someone wanting to do a bit DSLR+lens astrophotography - like cheaper version of star adventurer. It seems that AZ-EQ avant is no longer available even as bundle?

Difference is exceptionally small between these two, but there is difference - and it is far stranger than I expected to be honest: This is difference of the two images stretched to insanity You can see that there is some small difference in signal in the central galaxy - that can be down to flat correction not being 100% correct, but I'm really puzzled by these lines in the image. If both images are processed completely the same except for bias removed from flats - then these have to do with flats and I'm really puzzled by look of that pattern. As if it is warped / stretched somehow. Not nearly what I would expect from regular grid pattern of pixels. I think I also see amp glow in top right part (ImageJ loaded images vertically inverted in comparison to your presentation above). Here is above image smaller and vertically inverted to match it Well, this does serve to show that there is a difference, and in this particular case difference is very small (would not be shown in final image by any stretch) - but do bare in mind that with much more integration time - people tend to push their data stronger and even small imperfections start to show as these won't go away with number of stacked subs - they are fixed signal in nature. By the way - I love this strange pattern in the image and can't even begin to fathom what it could be.

I'd be interested only in two final linear fits - one with synthetic bias and one with flat darks (I assume this is luminance only) for inspection. Thanks

Here is same thing again with DSLR (Canon 750d): 15 bias subs in total - used 14 to create master bias and remaining one to measure StdDev and then to calibrate out fixed pattern noise. Again - stddev is smaller (and it would be smaller still had I used more subs).

Actually it is CMOS sensor - one of "early models" - Aptina MT9M034 (found also in ASI120mc). I do believe there is always this fixed pattern component present - it maybe less noticeable in some newer models, but it is always there.

Not sure what is happening - but whenever you attach a crop - it is always very small and not zoomed in

For some reason - that does not look like 100% zoom - it looks more like 100% zoom? Here is what I get when zooming in to 400% on one of subs you attached above: That is quite a bit of difference in zoom level.

Here is above "experiment" that I conducted on some old data that I found. Have a session from 2015 where I have bunch of nice bias files with camera that will show this effect nicely. First row is single bias and its standard deviation. Second row is that same bias with median value of 204 removed - of course nothing changes in terms of noise when you remove constant value. Third row is original bias sub "calibrated" with master bias. Noise is now lower. This is counterintuitive if we know that mathematical operations like addition and subtraction add noise rather than remove it. How can it then be lower? Bias data consists out of two components - bias signal and read noise. If we assume bias signal is flat / constant - like removing constant value from our bias sub - we will make a mistake of not removing "detail" in bias signal - all the variations of bias signal itself. From data and image point of view - this is "noise" - although it is not random in nature - it is unwanted signal that we don't want polluting our data / image. Here is what master bias looks like for this camera: all those vertical lines are in fact unwanted signal / variation that shows up as StdDev in above measurement - and you don't want it in your image. Proper calibration will remove it, while using synthetic bias - won't. In any case - I think I have proved my point with numerous examples. Regular / proper calibration with dark flats - is guaranteed to work (if we have well behaved camera that can be calibrated), while using synthetic bias / flats and other - is not guaranteed to work. It might work in your particular case with your equipment - but it is wrong to conclude that it is proper / better way to do things.

Light leak can cause both under and over correction - depending when it happens. It can happen during taking of darks, or maybe during taking of flats or perhaps during taking of lights. Since first step is lights - darks, depending which one of them has extra signal - it can be either case of having extra positive signal before flat correction or extra "negative" signal before flat correction. One leads to over correction and other to under correction (like flats haven't been fully applied). Btw - flats divide rather than subtract

Yes, that was from center - just to make sure there are no edge aberration issues.

If you want to do high resolution work - it would be good to add x2 barlow, but for starters - you can use it as you have it. Using ROI will give you much faster download speeds.

Even if there is no published chart for IMX571 that goes up to 1000 - we can sort of guess from other OSC sensors made by Sony. IMX462 is really exception in its sensitivity, but we can look at others and they all seem to have some sensitivity above 700nm We can also look at sensitivity of mono version and do some extrapolation (again by comparing other model OSC vs mono graphs).

Yes, that is very high. I've blown up a bit image so it can be seen easily - these stars are in fact elongated by pixel or two in horizontal. Given that your pixel scale is ~2.3"/px, that sort of matches <7" p2p periodic error claimed by iOptron. This mount can be used at this sampling rate without guiding (and stars won't be perfect but close) - but someone doing a bit higher resolution work won't think the same.

That profile looks like clipped, so be careful - use stars that are not saturated in their cores (less bright ones) for FWHM measurement.

I'd use following approach: Highest F/ratio that you should use is F/15 so don't go over that if you don't have to. Faster is fine, but slower won't bring any additional detail. Look into ROI and in particular - look at the specs for your scope. Loose any correctors you usually use for AP - these tend to correct some aberrations but sometimes soften up telescope at planetary "scales" (they trade some on axis sharpness and PSF sharpness in general for good correction over larger field). Calculate diffraction limited field for your scope and compare it to the size of the moon given your focal length. You might be able to fit whole moon in single frame - or maybe you'll have to do mosaics to get full lunar disk. In any case - you should look into ROI that will work given your scope. Using ROI will speed up download time. Use higher gain - one that minimizes read noise - this is important for planetary stacking. Shoot very short exposures to freeze the seeing - like 2-3ms on the moon (5-6ms max, but moon is bright and you'll probably won't need that long exposures) - don't look at histogram - except if you start saturating / clipping in white. Maybe try SharpCap software - as it is somewhat specialized for planetary imaging. Use filter - like Green filter you otherwise use for imaging. Alternatives are OIII or Ha - narrowband filters if you have those. Selecting smaller bandwidth helps with refractor optics to select part of spectrum with best correction (that is green for example) - minimizes atmospheric blur and seeing impacts less longer wavelengths (this is why Ha tends to be good as it is longer wavelength than most in spectrum). For rest - look up some tutorials, but in essence: - you image a ser video (or sequence of fits) - use PIPP to calibrate those and export as a ser video again - use AS!3 to stack that video - In the end sharpen using wavelets in Registax and further process in app or your choice. - If creating a mosaic - look into one of these - Microsoft ICE (no longer available for download from Microsoft site, but people kept installers and shared them online so it can be found), iMerge - small utility to merge mosaics, ImageJ has several plugins for "stitching" of images and so on ...

I don't want to hijack the thread, but title is rather convenient for what I'm about to ask. Is there a way to tell Siril not to mess with ADU values when stacking? I don't want them to be scaled to 0-1 or 0-65535 range, I want them to be kept as they are.

Try cropping first before you wipe background to remove edge stacking artifacts. Yes, last image is big improvement, but I do wonder why there is issue with calibration.

@barbulo had similar issue, don't know if it is solved now, but this is what I suggested. In above dialog - Aperture Photometry Settings - there is More options button on the bottom. This takes you to another screen where you can select FWHM measure to be included: As far as alt-click goes - you should get profile for a single star looking like this: In top part it says FWHM in pixels (in this case since image is not plate solved and I did not enter plate scale factor). I don't think it approximates anything - it does Gaussian fitting and calculates FWHM (and other parameters). Above radii are essential part of photometry process. You need to tell how much of signal is considered star in the image - first radius / first aperture You also need to tell software how to calculate background - this is where second and third radius come in - anything between second and third radius will be considered "Sky" And yes, you need to set those sensibly for photometry calculations to work.

You can check FWHM of the stack as well as roundness of the stars. Roundness of the stars coupled with sampling rate (arc seconds per pixel) will show to some extent periodic error drift over duration of exposure. Total FWHM will show what was the seeing like. Poor seeing can mask star elongation, and if stars have high FWHM - we can't know if it is down to seeing (missing guiding info since you did not guide) or mount precision.

What is average FWHM, star eccentricity and number of frames that did not make it into the stack?

Wonder why is that?

TS has a range of these as well, including 65mm, 80mm and 100mm https://www.teleskop-express.de/shop/product_info.php/info/p8489_TS-Optics-Optics-Spotting-Scope-BW65Z--16-48x65-mm---1-25--interchangeable-eyepieces.html

I think you don't and that is why simple test will show what is really going on instead of us going back and forth telling the other they are wrong.

If you are so confident - why don't you do a test? And indeed, it is signal processing basics - do your bias files have 0 stddev to begin with?

I just played around with things. I used three controls: 1. Adjusted gamma using levels to 2.2 (move middle slider to the left until number underneath it says 2.2) 2. Changed color temperature to make it less yellow 3. I increased saturation insanely Not sure in which order I did all of that - it might even be in order I listed them