vlaiv

19 minutes ago, AweSIM said:

I'll try this next. I'm pretty sure I haven't installed the ascom driver and only installed the core zwo driver from its website 

I think this solves the problem. You need to use ASCOM driver to do your captures.

Once you install that driver, you will have option in SGP to choose ASCOM driver and there you will be able to set gain and offset.

13 minutes ago, AweSIM said:

1. I have no idea how to control the WB of this camera. I haven't changed anything in its driver, and honestly, I haven't even seen any GUI for the driver that lets you control anything about the camera. Just that there was a driver available from ZWO site and I downloaded and installed it and that's it. I'll dig around on the internet about how to control its WB and fix it there. I'll report back when I've figured it out.

This part got me worried as well. I could not find any reference of WB in ASCOM drivers online. In fact, I found one discussion on ZWO user forum that talks about WB settings - and there Sam stated clearly that ASCOM drivers don't have this setting.

I can think of only one possibility for changed White Balance. Have you used SharpCap by any chance at any point? I suspect that there might be issue between native and ASCOM drivers for this camera model. In native drivers you can set WB and it is set to something like 50/100 and 90/100. I remember that later is for blue, and former is perhaps for red channel, but I'm not 100% sure on that one. Next thing that I read in the same post on ZWO forum is that once you set those WB values - they will not change.

Maybe if you set WB values in native driver and ASCOM driver somehow works with native driver to produce images - it is quite possible that ASCOM results are impacted by native driver and remembered WB settings.

This is of course just a theory - maybe even a bit far fetched - but that is only explanation I can offer on this.

Above is taken from internet - it shows sharpcap with ASI294 camera and relevant controls have been marked with arrow.

21 minutes ago, AweSIM said:

4. Can you tell me how you inspected the values inside these FIT files? How can I check that none of the values inside my bias frames are not negative and adjust the offset accordingly?

You can't check for negative values - as you'll never get negative values out of camera. You can only conclude that there is histogram clipping to the left - by examining pixel ADU values and looking at the histogram.

Here are values for subs you posted:

1) Gain 1 offset 0

It has 0 as min - this is very strange. I think it is again consequence of that white balance thing (I have no other explanation for it). All other ASI cameras that I've seen behave like this - if they have less than 16 bit ADC - all ADU pixel values that come from camera will be multiplied with either 4 or 16 - depends if camera is 14bit or 12bit. This is because 12/14bit values are stored within 16bit word in MSB (most significant bit) with LSBs being 0. That makes number values - multiplied by 4 (2^2 for 14bit camera) or 16 (2^4 for 12bit camera). I have never seen 0 as ADU value.

On my ASI178 which is 14bit - lowest number I've seen is 4. On my ASI1600 which is 12bit - lowest number I've seen is 16.

In any case - histogram shows that there is clipping to the left and this combination of offset and gain is not good.

2) Offset 10 and Gain 1:

This clearly shows that histogram is separated from left side and minimum number is 476. Next to it is max number - which is odd number - 1533. You can't have odd numbers if every value is multiplied with 4. Again this shows that values have been altered from default format.

Now important bit - I can't tell if histogram is ok or not as it has been white balanced. I suspect it is ok - but look how far right is peak for blue. It is not that far right because it has that much offset - it is that far right because it has been multiplied with some value - white balanced. What if it was too left before multiplication.

Offset 64 is way too high for this camera - no need to go that high. Offset 10 is quite ok.

Use Gain 120 and offset 10 and I think you will be ok.

Big question remains - have you used SharpCap and if maybe WB settings were changed from that software?

Here is synthetic luminance from wiped channels in 1/4, 1/2, 1/4 ratio, stretched beyond breaking point - just to show that there is residual vignetting:

Cropped and a bit touched up:

It's actually quite decent

23 minutes ago, CaptainShiznit said:

Again being my first attempt I just saved from DSS the default 16bit. What would be the better format between 32bit TIF/FITS and -interger/-rational?

Use 32bit float point. I prefer the use of Fits format as it is standard format for astronomy images, but many people prefer tif because it is easier to work with - most software for image processing will open that but not fits.

Gimp opens both. Do note that older versions of Photoshop can't work with 32bit data and you need 16bit data, and Gimp prior to 2.10 is limited to 8bit data only.

25 minutes ago, CaptainShiznit said:

found the flats a bit tricky as it was my first attempt at calibration frames. I put a baby's muslin cloth folded once over the scope and secured with an elastic band then pointed at my laptop screen with a white browser page open. Camera was in Av mode. Do you have any suggestions for a better method?

Wim gave better advice than I could because I don't work with DSLRs, but in case your flat calibration does not work - it could be due to darks rather than flats.

I would suggest that you use bias as master flat dark, use bias and darks and turn on dark optimization in DSS and then try calibration like that. While still not perfect, I think that would be the best way to calibrate your data.

4 minutes ago, Dustspeakers said:

Hi Vlaiv,

I'm also having issues with calibration frames (flats in my case) but I was interested in your comment above in trying to understand the whole calibration process. I have an ASI1600MM-Pro and I do see that raising the offset does shift the histogram from the LHS towards the RHS. For example on Bias, for Gain 200/Offset 10, I get a 'bell curve' of ADUs values between 0.78 - 12; for Gain 200/Offset 20, values between 6 - 18; for Gain 200/Offset 40, values between 19 and 29. So if I've understood you, if I shoot Darks (and Lights) with the latter value this is the correct way to proceed. I've just done a 300s Dark and it looks as I would expect with even random noise. So far so good (I think). But what is the action of increasing the offset to move the histogram to the right actually doing to benefit the images. Can you illuminate, so to speak.

Thanks

Steve

Thing with cameras is that they can't produce negative values. One would think that because we are counting photons, we don't need negative values, and in perfect world that would be the case, but since there is read noise present, and read noise is gaussian type noise centered on 0 - meaning it can have negative values, subs that don't contain light can end up being negative due to noise (actual pixel value can't be negative, but pixel + noise can be negative).

Since camera can't produce those negative values, only positive, we need to make sure numbers that we read off from camera contain all the information - we do that by adding the offset. So if pixel values for example are in range of -10 to +10 (actually zero because there is no light, but read noise is such that it produces noisy values between -10 and +10) - we can say - let's add 20 to each pixel value and then we will have all the values to be positive -in range +10 to +30. We have all the same information if we later subtract that 20 - we will get our negative values.

Now if you imagine following - row of numbers -1,0,1,1,-1,-1,0,1 .... random equal spread of -1, 0 and 1 values and you decide to take average of that. Average value will be 0.

Let's now do the same, except this time do the "clipping" - we throw away all negative values and replace them with 0. Now we have 0,0,1,0,1,0,0,1,1 .... sequence. We take average of that value and it is no longer 0 - it must be higher than zero. Act of clipping changed some things - it changed our noise distribution and changed our mean value.

If clipping occurs when one is doing darks - it can happen (and most likely it will happen) that no clipping will occur when one is doing lights. There is Sky level (light pollution) that will create real offset and all those negative values will end up as positive values.

Since darks are clipped but lights are not - they no longer match and that leads to issues with calibration (and it even affects flat calibration) but also due to changed noise statistics - stacking is less effective in removing noise (stacking works when you have mix of poisson and gaussian distributions, or each one individually, but it will not work as good on clipped data).

This is why it is important to set offset properly - and you determine how to set offset properly by examining bias subs. If all pixel values are above lowest value - you are safe. There is exception to this rule - if you have "cold" pixels that don't have much bias signal in them and are always very low in value - but hopefully you will have no or very few of those (recently I've seen example of ASI1600 camera that has 12 cold pixels - it created confusion with above "make all pixels higher" rule).

What sort of issues with flat calibration do you have?

Ok, here are my findings:

1. There is no light leak so you are ok with that.

What I suspect is going on with bayer pattern in the darks / bias subs is some sort of white balance in drivers. I'm not familiar with drivers of this particular camera, but if you turned on automatic white balance in drivers - you might want to turn that off.

I'm suspecting AWB because this camera is 14bit ADC camera - that means that all values in recorded raw sub should be divisible by 4 (16 bit total, 14 bit used - remaining two bits set to 0 - same as number being multiplied by 4). It is not case with your bias and dark files - there are odd values as well as even. This can happen only if values have been changed once they were read out of the camera - for example AWB process in drivers could explain that. AWB could also explain bayer patter. Since there is some offset to pixel value (pixels in bias are not 0, but rather positive value roughly equal for each pixel) - multiplying that with different factors for each color will create different values. Even values in bayer matrix show this could be so - since strongest is blue then red and green is the weakest. If you look at ASI294mc QE curves - it is other way around - green is strongest, red is second and blue is the weakest - which means that they have to be multiplied with certain factors to "even out" giving strengths of pixels in bias/dark that we see.

In any case - I would recommend turning off auto white balance in drivers. With that turned on, I can't judge if offset of 10 is good value because I can't see actual read out values of pixels but only WB corrected values.

Another thing - AWB should not mess up your calibration and everything should work fine.

2. Your subs indeed work fine. Here is comparison on one sub between proper calibration and raw sub without calibration:

This is the same sub - left has been calibrated by (ligth - avg_dark) / (avg_flat - avg_flat_dark) while right one is without calibration. Both subs were binned x8 to get enough SNR to show features of the image. As you can see - you get pretty decent sub with calibration - no vignetting and it looks clean in comparison to raw sub.

As you see - another confirmation that above is probably AWB, as that is not going to affect calibration, and indeed calibration works fine.

3. I would just recommend you in the future to use Gain 120, to turn off AWB and check if offset has good value - and continue taking nice images

HTH

Nice data, I believe there could be more in there - maybe if you post 32bit tif?

In any case - here is Gimp 2.10 quick processing:

I'm not sure that flat fielding worked as it should - there is still vignetting in that image. But on the bright side - Running man is visible as well and I think it can be pulled out with a bit more effort and 32bit tif version.

It's rather late over here so I'll be brief for now, but I'll take a closer look tomorrow in the morning.

If you are seeing bayer pattern in both bias and darks - it could be that you have a light leak.

It might seem to you that capping off camera and being in dark room is going to solve light leak problem, but you need to understand that your camera has only AR coated window and that you don't have any UV/IR cut filter on it. In fact here is what transmission of your anti reflexive cover window on camera looks like:

It will pass all wavelengths in IR part of spectrum (700nm and above). Another important thing to remember is that plastic is often transparent to IR wavelengths. So just putting plastic cover on your camera and being in dark room might not be enough to prevent IR leak - especially if you have heat sources near camera.

Best way to be sure you don't have any light or IR leak is to do following: put plastic cover on and then place camera "face down" on wooden table, or better yet - use aluminum foil to make additional layer on top of plastic cover (wrap camera in aluminum foil). I use first approach with wooden table, but some people do it like this:

I'll have a look at your subs tomorrow to see if I can figure out anything from them.

Btw, for ASI294 I would use gain 120 - as that puts camera into low read noise domain, and I would raise offset until I get very nice histogram separation from the left side on my bias subs. Not sure what that should be with ASI294, but with my ASI1600 I use offset of 64.

One way of doing it is to set gain that you are going to use, and then set offset at particular value - for example offset 10 that you already used. Then shoot a bunch of bias subs and see if there are pixels that are too low in value - something like 4ADU or similar and if histogram is well away from left side. If you find that it's not the case - raise offset and repeat. Once you find value that you are happy with - then prepare your darks with those settings (temp, gain, offset and wanted duration) and use same settings when you go out and gather actual data - lights.

Don't use bias in calibration though - it is not needed - darks contain both dark signal and bias signal so they alone will calibrate rights properly (also some CMOS sensors have issues with bias, and until you check your camera for bias issues - it's best to avoid using it in calibration).

47 minutes ago, pez_espada said:

That would mean that a 6" F8 refractor and 6"F8 Newtonian are expected to perform around the same, I guess. To pickup just an example of the top of my head..

If they have same central obstruction, which is not the case, if they have same transmission, which is not the case, if they have same F/ratio, which is here the case, if they have same surface quality and correction - strehl ratio - which might or might not be the case and are affected the same by atmoshpere - then aperture rules .

I support the notion that aperture rules, and I'm quite familiar with the idea that newtonians and other mirrored systems in general have slightly lower light grasp then their aperture would suggest - like we shown above - that depends on quality of coatings and size of central obstruction.

For what is worth, 6" F/8 Newtonian is going to blow away 6" F/8 refractor of the same price class in almost every aspect. It will also be outclassed in almost every aspect by high quality ED/APO 6" F/8 scope, but on the other hand - if you pay that much for a mirror and general construction of newtonian - gap to ED/APO closes real fast (never going to be equal, but very close).

Just now, pez_espada said:

I see this in the practice indeed but how's that from the theoretical point of view? What about the "aperture is King"  tenet in astronomy then?

That is short version of that saying. Longer and proper version of that saying goes like this: Aperture is King everything other being equal

36 minutes ago, pez_espada said:

For an 8" @ F5 to have a fully illuminated field one is looking more to 30-32% of CO, i.e a secondary of 60-63mm.

Ah sorry - my bad, I meant F/6 - that one has about 26% CO (I've got one - dob mounted 8" F/6), but you are right larger secondary is required for F/5, and even larger for imaging OTA.

6 minutes ago, Tommohawk said:

OK. Currently for NB I use Gain 300 offset 50 (but will switch to 64) and do 300s subs. Sky here is approx class 4 Bortle. So maybe gain 139 and keep with 300s subs? 

Also, whilst I'm busy picking your brain, what's your thoughts on the USB setting? 

Could you check one of your NB subs for background sky levels - that should tell us what the deal is. Easiest way is to run stats on selection without any nebulosity and check for median value (that will deal with any stars in selection).

I believe I have USB setting at 64 as well. I changed it to be the same as offset - simply because I did not notice any difference in my setup when changing that and I did not want to go very high with it.

5 minutes ago, pez_espada said:

So all that said I can confirm that a reflector to be a le to compete with a refractor, the former has to be at least 27-30% larger in apertura. 

The myth becomes truth. 

Might be so for small apertures, but as aperture gets larger - differences get smaller.

For example - we have seen that 130mm is equivalent to 112mm of clear aperture, so that is reduction of about 13.8% by diameter.

If you do the same with for example 8" F/5 newtonian, you will get different result. It has 26% CO, so math will be sqrt((101^2 - (101*0.26)^2) * pi * 0.91^2 / pi) *2 =  ~183.5mm of clear aperture. That is difference of 9% by diameter,

Indeed - here is quick calculation:

102mm vs 130mm

102mm at about 98.5% transmission will be equal to 51^2 * pi * 0.985 = 8048.71mm2

130mm with 32% Central obstruction and 91% reflectivity on two mirrors will be equal to (65^2 - (65 * 0.32)^2) * pi * 0.91^2 = 9866mm2

Still larger and therefore more light gathering, but not 3cm larger in diameter, more like only 1cm larger as 9866mm2 is equal to about 112 - 113mm of clear aperture (sqrt(9866 / pi) * 2).

Add to this that F/5 scope has much tighter critical focus zone - harder to obtain proper focus, especially if scope has single speed 1.25" focuser that is not very precise, and the fact that larger aperture will suffer more from seeing effect and also that strehl numbers of two scopes can differ considerably. If 5.1" newton is mass produced it will probably have system sthrel of about 0.8 and F/11 refractor will probably have over 0.9.

Put everything together and you get result that you have.

12 minutes ago, Tommohawk said:

he author is very switched on so its hard to believe he's "got it wrong" but maybe as you say it's not primarily for DSO work and has some adaptations which aren't ideal.

It's not really down to sharpcap as a piece of software. It works well for what it was originally intended. It has more to do with the fact that ZWO has two different drivers and we can't be sure if those drivers talk to the camera in the same way (set same settings). Native drivers and ASCOM drivers. Facts are that:

1. ASCOM drivers take much more to download than native drivers. Native drivers can achieve 15+ FPS on full frame, but for me ASCOM download lasts almost a full second (so 1fps or less).

2. We see that subs coming from native drivers and ASCOM drivers are in some way different - mean ADU level does not behave as one would expect if things were "simple". We simply can't avoid conclusion that somehow these two drivers behave differently

On numerous occasions I've seen people having issues with SharpCap and native drivers when trying to do DSO imaging / long exposure. I can't tell if that happens with SharpCap and Ascom drivers and whether multitude of options in SharpCap (like brightness / contrast / white balance / whatnot) is simply confusing people and that is why they are getting issues.

For that reason alone I recommend people to stay away from DSO / long exposure imaging with SharpCap. Otherwise I think it is really good piece of software and I recommend it for planetary and EEVA use.
 

19 minutes ago, Tommohawk said:

I did wonder if perhaps there was a light leak on the shorter sub. I have a metal lens cap + metal foil but because I'm just tinkering I don't have a dark hood/dark room as I normally would for darks.

On next session, when you do full set of subs (flats, darks, flat darks and lights) - maybe post one of each so we can try to see if everything is in order and if there is some possible light leak. There is set of "sanity checks" that one can do on the data (histogram clipping, mean adu levels, simple calibration on single frame and looking for irregularities) to determine if everything seems to be in order.

20 minutes ago, Tommohawk said:

BTW am I right in thinking you also keep with unity gain (139) for narrowband too? I've always had passable results with 300 gain, but maybe I should change.

Only benefit that gain of 300 vs gain of 139 will have is lower read noise - ~1.2e vs ~1.7e. That is not major difference. In fact that is only ~x1.42 higher read noise on unity gain. Only impact of read noise is on many short vs few longer subs. Since no one is doing single exposure images and we all stack - it will be the matter of using certain exposure length.

Rule is simple - use exposure length at which other noise source becomes dominant over read noise. Let's say that Sky/LP noise becomes dominant at 1 minute and read noise of 1.2e. What sort of exposure do you need to get the same result from 1.7e read noise? We've seen that difference is x1.4 and LP noise raises like square root of LP signal which raises linearly with time. This means that you need x2 longer exposure (because sqrt(2) = ~1.41 = 1.7/1.2). You only need to use 2 minute exposures at unity gain and you will get the same result. Using minute and a half will get you like 90% there and not 50% - again it is the story of diminishing returns like sub duration in general - after a certain point, gains from going with longer subs are just too small.

I don't mind imaging at gain 139 for NB - just use longer exposure.

@Tommohawk

Here is what I think about it all:

On 25/01/2020 at 19:24, Tommohawk said:

So whatever I do with the brightness setting, when doing darks the min value indicated below is only 16. I've tried setting the brightness in Sharpcap, or the offset in NINA to the maximum which is 100, and still this value is only 16. So whats that all about? 

My position on using sharpcap to do DSO AP is quite clear - don't do it. Use Nina or maybe SIPS or SGP lite - these are all free to use and work well (in fact I did not try Nina, and I stopped using SIPS once I ran into trouble with large files - it mistook my ASI1600 mono subs for color of different size - maybe it was early drivers or maybe it was that particular version of SIPS which is now updated. In any case I use SGPro now, but I think any of listed should be better than SharpCap).

I'm not saying that SharpCap is not good - I'm just saying it should be used for other purposes - like planetary imaging and EEVA / live stacking.

Here is example why it's not best option:

We have two dark subs taken with same settings except for exposure length. First is one minute and second is 0.64s. But look at Mean value. There simply is no way that one minute exposure has lower mean value than 0.64s one, and certainly not by 50%. It is obvious that camera is working in different regime for these two subs. SharpCap is probably putting camera into mode for fast readout and that changes the way camera works (maybe producing offset issues, or offset instability or whatever).

On 25/01/2020 at 19:24, Tommohawk said:

Edit: I tried this initially with gain set at 300 which I normally use for narrowband, and the min value wont go over 16 no matter what the offset. BUT just tried it with Gain at 139, and then the min value is 432, with offset 100. However this is dependent on exposure length - with gain 139 and offset set to 100, I need minimum 8 seconds exposure to get the Min value to exceed 16.

I still think you should do Gain 139 / Offset 64 for your subs. Indeed this sub has 12 pixels with value of 16, but histogram is well separated from right side:

Here is same sub from my ASI1600 (also 1 minute exposure, gain 139 and offset 64):

Very similar looking graph. Only difference is that mine has min value of 224 while your has min value 16.

It could be that your camera has few "cold" pixels. Those pixels have really low value and you need to really pump your gain to raise their value enough. Since you only have 12 of them (according ImageJ and histogram):

I don't think you should worry too much about them. Dithering will sort this even if these are dead pixels (and I don't thin they are dead pixel, just cold, since this other sub shows that they indeed can hold value larger than "zero" / base value).

1 minute ago, AndyThilo said:

Can I use WBPP? Do I just load them in with the flats? Or put them in as bias?

I'm not familiar with particular PI scripts, so we should really wait for someone to answer that one.

Flat darks should be "darks for flats" - master flat dark created by stacking and then subtracted from flats prior to their stacking (same workflow as with regular subs where you subtract regular darks).

Just now, AndyThilo said:

Yeah I’ll try in the morning. Do I need dark flats?, I took them but not sure if I should use them?

Yes, use a set of matching flat darks always.

1 minute ago, AndyThilo said:

The above was without flats. I’ll try with my flats tomorrow. I’ll see how they look with flats, if ok then I’ll order the filters from Gerd.

you can try the old flats with these new darks once you have time for it. It'll cost you nothing except a bit of processing time - you don't need to retake them.

1 minute ago, AndyThilo said:

Conclusion, thank you @vlaiv, I will be deleting my whole dark library and making new ones :). And I really can't see how flats would improve this?

Good to see that there was only light leak in the darks and that proper darks took care of everything.

You now know that your flats are working properly. Only real issue with that flat panel is that it does not produce much red part of spectrum and your red histogram peak is quite low. It will not cause too much issues - but take more to compensate for this. Also, your color balance will be really thrown off if you don't normalize your flats prior to doing calibration with them.

Just now, AndyThilo said:

Well I’m truly lost 😂

Don't be. Here is quick guide:

1. You've probably taken another set of darks? If not - do it, but take every precaution not to have light leak. Take camera off the scope, use camera cover and aluminum foil - place camera "face down" on desk and do darks.

As far as I can see deltaT is about 35C so you need to do this somewhere where you don't have heating (shed perhaps or basement or ....) as you need ambient temperature to be below 15C.

Compare that with the darks you have already taken - see if you get same gradient / mean ADU level.

2. Try calibrating data that you now have with existing flats (these seem ok) and new darks - just to see if it will work (I sort of doubt it - if there were a light leak, it affected both darks and lights) - if it does work properly - problem solved, if not - it is sign of light leak. This means that you need to examine your setup and change some things.

Light leak will usually come thru extension tubes, or adapters, or filter wheels or OAG. It can be diagnosed by using strong flash light and shooting short darks - which torch shining at different pieces of equipment. Highest mean ADU will tell you where likely leak is. 

9 minutes ago, Physopto said:

I might try a figure closer to that next time out. I am at The Galloway Star Camp next month. So a few more hours spent trying out different levels would not come amiss.

 

Simplest way to test if flats of different histogram peak level are working as they should is to do flat / flat calibration.

You take set at some peak values like 33% (to be reference value), 50%, 75%, 80%, 90% - do couple of each, and do couple of flat darks for each exposure. Create master flats and then divide master flats with each other (33%/50%, 33%/80%, etc) - you should get uniform gray sub (with noise obviously but it should not have any vignetting nor dust shadows evident).

4 minutes ago, Physopto said:

Hi Vlaiv

Yes I can see your argument. I always use around 50% FWD for my CCD (QSI 683), ( what QSI recommended I believe). So I aim for around the 25,000e ish. It is a long time since I did any maths/statistics on shot and thermal noise. So I just aim for what seems to work. I would guess it may be different for the various makes of CCD depending on how they work. Things have changed greatly in the last 25 years or so since I did my first degree.

All I was pointing out is where carastro may have seen or gotten the 33% figure from. I use Maxim DL but have never tried their auto routine so far. I get too little time to waste messing about with experimenting. I beleive in" if it ain't broke, then don't fix it!"

Derek

I figured that you just quoted potential source of 33% statement. On the other hand, I just wanted to point out that not all things should be taken as accurate / set in stone without running logic checks first.

This does not mean that there is no something else that will indeed make 33% recommendation better option for some CCDs out there that I've not taken into account. From what I've seen - figure of 80% works and it works well (I use it) - and logic behind taking flats supports it.

It is certainly worth combining the data in a proper way.

Unfortunately it is a bit complicated topic and DSS does not have option to combine data in such way.

Just combining them as if they were same SNR subs can result in improvement but can also result in worse data. Actual result depends on how different SNR is between the subs, and to make matters worse - there is no single SNR value per sub - each pixel in fact has its own SNR value.

There are couple of things that you can do to address this issue:

1. Stack better subs to one stack and then stack all subs to other stack - inspect stacks to determine which one is better looking - and use that one.

2. If you have license of PixInsight - use that as it has weighted average stacking (not ideal, but better than equal weights stacking)

3. Make two stacks - one of good subs and one of poor subs and then try different weighted combining of those two stacks (simple image arithmetic - 0.8 * good + 0.2 * bad - or other weights, and select combination of weights that gives you best result).

4. Use algorithm specifically designed to handle such cases. Have a look at this thread first:

And if you are up to it - I can make you a small tutorial on how to use ImageJ and plugin that I wrote to stack your data with that algorithm.

In fact, I was wrong in my previous post - I did the math incorrectly.

I used percentages instead of actual numbers (figured it will be easier to understand) - but I should not have done so. SNR involves quadratic relationship (noise is square root of signal) and linearity is not preserved - hence percentages will not match actual numbers. I'll just quickly redo calculation with real numbers to show that this issue is even less than percentages would suggest.

Let's again take 15k FW. 80% of that is 12000e. Noise / one sigma is square root of that - ~109.55 and we have 3000e until saturation (15000-12000 = 3000e). This means that we in fact have 3000/109.55 = 27.38 sigma. Probability that any single pixel will saturate is not 1% but closer to following statement: "Universe is simply not old enough for this event to ever have happened so far given it's probability and all cameras in the world"

In fact, even if you go for 95% histogram peak, you are unlikely to saturate with real sensor - it is still more than 6 sigma event.