How to avoid overexposed stars ?

This is very common with narrowband imaging, as you need RGB data to get true star colors. Star exposures are usually much shorter, and while 20 minutes is often suggested as sufficient, I prefer to target around 60 minutes of integration time.

The same approach can be used with OSC cameras as well.

Jure Menart · Aug 18, 2026, 09:36 AM

This is very common with narrowband imaging, as you need RGB data to get true star colors. Star exposures are usually much shorter, and while 20 minutes is often suggested as sufficient, I prefer to target around 60 minutes of integration time.

The same approach can be used with OSC cameras as well.

OK, thanks a lot, Jure.

You write : 60 minutes of total integration time for the stars, I agree, but about individual frames exposure time, not more than 60” or different ?

Patrick

Jure Menart · Aug 18, 2026, 09:36 AM

This is very common with narrowband imaging, as you need RGB data to get true star colors. Star exposures are usually much shorter, and while 20 minutes is often suggested as sufficient, I prefer to target around 60 minutes of integration time.

The same approach can be used with OSC cameras as well.

You do not need to shoot separate RGB exposures anymore as you can color calibrate your narrowband stars with a combination of SPCC and PSCM script (Planck Star Color Mapping) from Dr. Rainer Raupach.

It does not solve the problem with overexposed stars, though.

Quando ho questo problema semplicemente aggiungo all’esposizione principale una posa più corta, solitamente 5 o 10 secondi.
Alla fine ho 2 master e faccio un HDRComposition e cosi ho tutta la dinamica completa per uno stretch perfetto.

With automation I don’t feel that shooting 60 minutes of stars is an inconvenience. But without a filter wheel I would probably make do with converting SHO in post.

When making darks for star exposure it probably worth making HDR darks too: 1,2,10 30 is a good start. Anyone worried about overexposure on stars is probably going to do HDR on particularly bright targets. I’m currently shooting NGC 7023 and it seems that not blowing out the center is a major goal.

donld · Aug 18, 2026, 03:17 PM

With automation I don’t feel that shooting 60 minutes of stars is an inconvenience. But without a filter wheel I would probably make do with converting SHO in post.

When making darks for star exposure it probably worth making HDR darks too: 1,2,10 30 is a good start. Anyone worried about overexposure on stars is probably going to do HDR on particularly bright targets. I’m currently shooting NGC 7023 and it seems that not blowing out the center is a major goal.

Thank you for these precisions.

CS

Patrick

Tony Gondola · Aug 18, 2026, 04:07 PM

Probably no need to over-complicate it. Shoot your subject with whatever sub-exposure is needed/wanted. Shoot RGB stars, 30 sec. subs should be fine for most setups. Total integration really depends on how deep you want the star field to be. Process your subject normally, remove the original stars and replace with RGB, pretty simple.

Thank you Tony, always good advices, very appreciated !

I find the most over-exposed stars with RGB imaging. Remember that saturation happens when you overflow the well-depth of a pixel. I handle this by first decreasing my exposure time for each sub. Second, I use unity sensor gain (or as close as I can get), which is when you get one photo-electron per ADU (the QE is the ratio of photoelectrons produces per incident photon) and it generally produces the largest available well depth. When the field has fairly bright stars, I use just 3 minute subs. It’s hard to avoid saturating the very brightest stars but for most of the field, nothing gets saturated. With 3-minute exposures I generally don’t worry too much about the read noise but I would if I used exposures much shorter than that. You can also crank up the sensor gain a bit but always at the expense of well depth. Just remember that the SNR of the object is determined by the total integrated time; not by how bright things look in the subs, so don’t worry if things look pretty faint in the raw frames. If you take enough data, the integrated stack will have a high SNR and you’ll have very few saturated stars.

Things change a bit when you gather NB data. Unity gain works but the read noise may overwhelm the photon noise in dark regions of the image. So, I generally lower the gain to step down the RN. Since the transmission of the NB filters is so much lower than for broadband filters, that usually doesn’t present an overflow problem due to the shallower well depth.

I’ve completely given up on using RGB stars for NB data. The PSCM script (Planck Star Color Mapping) from Rainer Raupach works extremely well and it gets rid of the need for additional broadband data for the stars. In fact, using NB data for the stars is another way to get a colorful star field that doesn’t contain as many stars, which is a good way to suppress an overwhelmingly dense star field.

John

Most newer sensors don’t have unity gain anymore. Newer sony sensors mostly have HCG mode. On my particular camera just about everyone leaves it at gain 100.

donld · Aug 19, 2026 at 04:44 PM

Most newer sensors don’t have unity gain anymore. Newer sony sensors mostly have HCG mode. On my particular camera just about everyone leaves it at gain 100.

That’s not correct. I run a Sony IMX455 sensor, which is not an old sensor and depending on the camera that it’s installed in, there are a variety of read modes available, which all include unity gain. I see from your profile that you are running the smaller version of same sensor in a ZWO ASI6200MM-Pro. The sensor itself in that camera is fully capable of unity gain. It is your camera manufacturer that limits the gain to 0.8 -e-/ADU; not the sensor. QHY Cameras on the other hand, provide 5 different read modes that gives access to a wide variety of trade offs between gain, well depth, and read noise. Still, at a gain of 0.8 e-/ADU, which is slightly more than unity gain, your ASI6200MM provides a well depth of 51k photo-electrons. That’s less than what I get out of my Moraivan camera but not by enough to matter much. At gain 100 in your camera, you are operating at the lowest possible read noise and that’s great, but you are also losing over half the well depth at about 19k e-. Operating that way works just fine, but you’ll need to use shorter exposures by at least one half to avoid overflowing the wells and saturating the stars. With such low read noise, you can go fairly short but you’ll end up with a LOT of data to process and you need to be careful about some effects due to read noise that not many folks pay attention to.

Remember that the reported RN for any sensor is only an average and it doesn’t accurately capture what happens with random telegraph noise (RTN) that occurs in CMOS sensors. RTN causes “salt and pepper noise”, which becomes a more significant problem as it becomes a significant fraction of the photon noise. So, be sure to dither often. This can also be mitigated by using longer exposures and by 2×2 median filtering your subs. It’s a “Goldilocks” story. Your exposures can’t be too long or you saturate too many stars and they shouldn’t be too short or you’ll have trouble with RTN.

John

TiffsAndAstro · Aug 19, 2026 at 06:51 PM

Is read noise even something to worry about with Imx571 family of sensors, with 60+ sec subs and likely bortle 4+ light pollution (shot noise).

( Big squared + small squared ) Square rooted is almost the same as big, so small can effectively be ignored?

Probably not. You just want to make sure that the RN is much smaller (like by a factor of around 10) than the sky noise and with 60s exposures you might be within that safety zone. (I haven’t checked for your specific camera so I’ll leave that final determination up to you.) Under a really dark sky, 60s subs might not be long enough for the noise from the signal (in the really dark regions) to swamp the read noise so your results may vary depending on your local sky conditions.

John