vlaiv

Was there ever such thing as astrophotography in simple terms? (or is it just me ) Depends on how you want to use it for mono purposes. I'll give you some examples: 1. You want to use color camera for "mono" purposes - size of pixel is the least of your concerns 2. Say you want to use it for Ha - then only red is really sensitive in Ha. In terms of resolution - pixel size will be effective 4.8um (it will be able to resolve as if pixel is 4.8um large), but as far as sensitivity goes - pixel is still 2.4um in size 3. Maybe you want to use it for OIII - things get complicated here as both green and blue pixels are sensitive in this wavelength - but to a different degree. 4. You want to bin your data 2x2 to actually get mono image (there are better ways to do this) - pixel size as far as both sampling and sensitivity go - will be 4.8um but effective QE will smaller than any of individual components. 5. You want to use some sort of duo band filter that captures both Ha and OIII at the same time - things get progressively complex here - so no easy way to describe what is going on. In the end - I'd like to point out that with OSC - pixel size is never really that pixel size (unless you do bayer drizzle)

Yes, there is specific reason for those numbers, but it is probably completely unimportant I'm computer programmer by trade, and powers of two are easily divisible using fixed point math - no surprises. Much like it is very easy to divide something with say 1000 in decimal system - you just "move" decimal dot three places - note that 1000 is 10^3 - so is with binary operations. Numbers written in binary form "don't loose precision" (this really depends on how are they recorded) when divided by power of two. Take for example division by 3 in decimal system. Every third number is nicely divisible - but other two take on "infinite" form - say 34.33333333..... or 12.666666 (depending on remainder when dividing with 3). These numbers can't be precisely written with finite number of digits - you need to round them up - and rounding up introduces error. There you go - if you use power of 2 subs - you are guaranteed not to introduce rounding error when dividing result - taking average. In reality - this hardly makes any difference - especially if you start doing sigma clip to avoid hot pixels or cosmic rays - those pixels that have outliers will be divided with different number anyway, but due to way my brain is used to working - I instinctively go for these number of subs. I often joke that I have "binary OCD"

We don't have to exaggerate stretching either. We can split stretching into two distinct parts / two purposes. Purpose one would be to truthfully represent the image. This is required by standards and our display devices. sRGB standard incorporates gamma stretch of roughly 2.2 (technically a bit different but very close to this value). We perceive images made in daylight by our cameras because data linearity, sRGB gamma, response of our display devices (if properly calibrated) - are all matched. Linear data coming in from camera can't be directly displayed as image in our browsers because it is not adjusted in the way it is required by standard (or it can but it won't match reality). You can show even very faint data using only this level of stretch. Here is above image / luminance data - without any "special" stretching. Only things done to image are black and white point and standard sRGB gamma (properly encoded in sRGB). This does not mean we can't show faint detail in the image. Here is same thing done to the same image - but made to show fainter detail: But here we have to sacrifice the core - we have effectively "over exposed" image. When we have much larger dynamic range than our device is capable of showing (or for that matter - our eyesight is capable of viewing at the same time) - we need to compress this dynamic range in order to fit both highlights and shadows in the same image. This is the second type of stretch - compressing dynamic range into dynamic range our device is capable of showing. But we don't need to do it. We can do what nature does - if you look at bright torch next to computer screen - you won't be able to see what is on computer screen. There is limit to range of intensities we can observe at any given time (and it is about 1000:1 for human vision - you might think that is more than 256 levels - but remember gamma is there for a reason it compresses very bright and stretched very faint so it effectively encodes what our vision can perceive). There is also fundamental difference between stretching and saturation. Stretching is changing exposure on a pixel level - exposing different pixels to different amount. By doing this you alter amount of received light but you don't change its nature. Changing saturation is changing type of light that you recorded - not only its intensity.

Actually with some CCDs - long flats are mandatory If flat has mechanical shutter - then using short flats can record shutter motion and create gradient due to shutter motion (CCD will be still exposing while shutter is closing).

I think that internet is to blame - everyone expects / are used to - too processed / too saturated images and regular images look uninteresting because of that.

Oh, this is so depressing Whenever I make true color processing - it just does not look attractive What do you prefer in the image, true color rendition or uber saturated version

Depending on exposure length - I aim for at least 64 darks I go for 256 flats and flat darks, but my flat panel is very strong and I don't have issues with very short flat exposures - my flat exposures are like few milliseconds each, so it does not take long to shoot 256 of them (take more time to download subs with ASCOM driver in SGP than anything else - my flats usually take about 10 or so minutes).

Here you go - above attached stack of bias subs - very small standard deviation and rather "normal" looking stretched image. (You managed to get your old account back? Do you have two accounts now?)

I usually use more (significantly more), but that really depends. Every additional sub lowers noise you inject back in in the image. I just measured your masters and found something interesting: Dark has one (or more) hot pixels that are not showing in flats. max pixel value is almost double that of flat. First thing to check is if you used exact same parameters for flats and flat darks? (temperature, offset, gain, exposure length?). Second would be type of stacking used for both: What type of stacking did you use for both? I would recommend sigma reject stacking for both to remove any cosmic ray hits or anomalous hot pixels.

Yes it works as expected. Here is explanation for calculation. I subtracted two darks under following premise: flat_dark is very short and is taken with same settings as dark. This means that it contains almost no dark current signal, but does contain bias signal. Subtracting the two leaves only dark signal that accumulated over 120s. We average values of subs, divide it with 16 as 12bit camera data is padded with four zeros when written as 16 bit format (equivalent of multiplying with 16 - same as 123 written as 12300 is same as multiplying with 100 - only former was done in binary) and subtract the two. Then we divide result with 120s to get dark current per second at 0C - in your case this turned out to be ~0.05e/s Value that I've found for dark current of ASI1600 online is 0.006e/s at -20C. At lower temperature dark current is smaller, so how do we convert this value to 0C dark current to compare to what your dark shows? It turns out that there is a rule - each N degrees C increase in temperature dark current value doubles - this is called dark current doubling temperature and for most sensors it is somewhere around 6C This simply means that at -20C - dark current is 0.006e/s -14C - dark current is double of above so 0.012e/s -8C - dark current is double of above so 0.024e/s -2C - dark current is double of above so 0.048e/s -2C is close enough to 0C and you have 0.05e/s versus 0.048e/s - that is within measurement error, so I don't really think you have significant light leak with darks. On the other hand if you have light leak on your setup for flats and lights - that will also skew flat calibration. Any signal that is present - that did not come from objective lens of telescope and thus is subject to vignetting / dust / etc - that is not removed will mess up flat calibration. This includes wrong offset, improper dark removal, light leak - anything that changes pixel values. Pixel values are expected to be with certain ratio - say you have 1000e of signal and you have 100% and 80% illumination (center and edge) - you will measure 1000e and 800e respective. 1000/1.0 and 800/0.8 = 1000, 1000 - nice flat background equal everywhere. Try adding some offset to either flat or lights - for example, light leak when shooting lights - say you have additional 100e that illuminates sensor Now you have 1100 / 1.0 and 900 / 0.8 = 1100, 1125 - suddenly you have over correction as corner is brighter then center Maybe you have light leak in flats? Now flats will have higher values then they should 1000 / 1.1, 800 / 0.9 = ~909.091, ~888.889 Huh, now you have under correction - center is still brighter than corners. You have over correction - which means that lights are "stronger" than they should be, or flats are "weaker" than they should be. Stronger lights means light leak when shooting lights Weaker flats can mean stronger flat darks (as you remove them so if they are larger - result will be smaller in value) - which means light leak when shooting flat darks. In any case - you should look to minimize light leak if possible in order to get flat calibration to work properly.

ImageJ automatically sets display range after operation on the image. Flat dark has some level of noise, some hot pixels and so does flat. These are single files not masters so it is not averaged out. When you perform operation image will contain large range of values and if you set "stretch" from min to max - it will look mostly grey and flat, but if you adjust contrast/brightness (these don't change pixel values in ImageJ - they are not real stretching but rather "screen transfer functions") - you will still get proper image. note distinct three peaks in histogram - this is normal for raw color image that contains all three color pixels and has not been debayered (each peak is one color).

I would choose ones that work. You can always try flat/flat calibration to see if you have proper set of flats. Take one set of flats at certain exposure level - say 30-40% histogram peak, and other set at twice exposure length 60-80% histogram peak (no need to be precise about it as long as you don't have clipping and have different exposures). If two calibrate out properly - you have good flats (meaning you divide one master with other and you get perfectly flat noisy image).

ImageJ/Fiji Btw, there is quite a bit of issue with flats. Not sure what it is. Here are stats for dark and flat dark So these are actually x16 lower because of 16bit padding. That is ~59.9e and ~53.95, so about 6e of dark current. Let see if we can match that to dark current data for ASI1600 Dark current is about 0.006e-/s at -20C You have 6e over 120s so that is 0.05e/s and that is at 0C? Doubling temperature is about 6C If we start at -20 - we have three times to double until we get 0C (-20 + 6C +6C+6C = -2C) 0.006 * 8 = 0.048e/s That sort of matches ok. I don't think there is light leak in darks. How about flats? Or lights? Is there any chance you have a light leak there? What is your setup like?

What for? For capture I use SGP. For calibration / stacking / preprocessing - mostly Fiji/ImageJ, Siril (this is new, it can align / interpolate with Lanczos) and Gimp for post processing.

Ok, so here is procedure with ImageJ. First - you will need debayer / demosaic algorithm. I'll include one simple plugin at the end that you can use. 1. Open each of: - light - flat - dark - flat dark and on each of them perform: Image / Type / 32-bit This will convert each to 32bit float point so that we don't loose any precision. 2. Subtract master dark from light by using Process / Image calculator Select light as image 1, select operation to subtract and select master dark as image2. Make sure you have 32bit result and you can create new window (otherwise image2 is subtracted from image1 "in place" - changing image1 - you can't undo that). 3. Do the same with master flat and master flat dark - subtract master flat dark from master flat 4. rename new images by right click / rename or F2 to light and flat 5. close others 6. You need to debayer both flat and light and extract only green channel. For this you can use supplied plugin. Select bayer pattern, select replication and green component. Do this to both images. This will create new images 7. Select central part of flat image where there is no vignetting and do Analyze / Measure: note average value: Now remove selection and to Process / Math / Divide to flat and divide with said value - in above case 13257.092 8. in the end produce final image by Process / image calculator -> divide light green with flat green: 9. Divide resulting image by 4 to get true values rather than scaled to 16 bit value (Process / math / divide with 4) 10. Make selection and measure In this particular case we measured background value to be ~77.3 (Mean value is ~78, median is ~77.3) Here are plugins: Debayer_Image.class This is .class file that you can save to your Fiji/ImageJ Plugin folder (open Astro sub folder and place it there). Be waned - above is "executable" and you should not trust executables posted online unless they are coming from trusty source. I no longer have source, otherwise I would post that also for you to compile yourself in case you wanted to. You can also install one of other published "official" ImageJ/Fiji plugins for debayering and use that.

That bit is wrong. I'm writing another post to show the steps.

I guess for two minutes and 0C that is ok. Stack them and apply them to see what sort of result you will get.

Almost ok Master bias is here not needed - as you pointed it out, master dark and master flat dark are all that are needed, so these seem to be good but light is not. Can you upload just single raw sub as it came from the camera? This one has been debayered, converted to 32bit floating point format and scaled.

In order for flats to work properly, both lights and flats must contain only light signal - offset and dark current must be removed from both (that is why we take darks and flat darks). If we don't remove either of those two properly - flat correction will fail as it will "operate" on or by signal that is not subject to vignetting.

Issue with noisy master dark could be due to histogram clipping to the left due to too low offset. See how it is "glued" to the left? No nice bell shaped curve for that dark. This is histogram of flat dark Much better looking.

This could be issue. Try doing one more set of darks (luckily they can be done at this time as well) - but this time setting all parameters the same. Yes, just checked fits headers - dark is at offset 0. Better redo those at offset 56 as well.

Well, something is wrong with the files and no wonder you are getting very strange calibration results. First off - do you have cooled camera? Is it ASI1600MM-Pro or regular ASI1600MM without cooling? I'm asking because your master dark is very very noisy. Much noisier than one would expect from cooled camera. left is your dark stack (not sure how many subs you stacked, but it does not matter) - right is only one dark sub from my cooled ASI1600. Both are stretched to the point amp glow is starting to show. Your stack is much more noisy. Second - I'm not sure what software are you using to capture and process data, but you have very odd dark flat there. I measured both your master dark and master flat dark and here are the results: First - it is very odd that mean value of master dark of 120s, cooled or not be that much lower than master flat dark as master flat dark is much lower in exposure time. Second - column StdDev is confirming my assumption on not having cooled camera - noise is so much worse in master dark than in master flat dark - and that can be only due to thermal noise in those 120 seconds. With cooling, there is some difference, but difference is small - not x17 more noise. Third very strange thing is that master flat dark has much higher min value than master dark. In fact - that low minimum value in stack suggests that offset is not good for camera. In the end I conclude two things: 1. You don't have set point temperature / cooled camera so it is very hard to get matching darks 2. You probably shot master flat darks at very different settings to darks, or you have light leak In any case - this is the cause of failed flat calibration.

Hopefully 32bit rational should be the same as 32bit floating point (although strictly speaking, rational numbers can be stored as both float and fixed point).

No, it just means that max value of the flat is set to 1. You take your master flat - find max value and divide whole flat with that max value (that is simple approach, more precise approach would be to select central region of flat without vignetting - find mean or median value and divide with that). Could you actually put up those files and I'll walk you thru how to do it? I use ImageJ - it is open source, cross platform software for scientific imaging. Works great with fits and has loads of plugins. Sub that you attached is saved as 32bit integer and contains negative values. You really want to use 32bit floating point and you don't want to scale any pixel values (except for flat)

To be honest, I expected rural landscape and more rustic setup, but this really makes sense - lunch break + parking lot + break in the clouds = excellent image. I guess it even provides shade for laptop inside.