UPDATE FROM MABULA
I have had a very rough 2 months unfortunately health wise. I was struck 3x in a row with bacterial infections. The second infection occurred  after a routine hospital checkup and I became very sick. I had to rest and take a lot of antibiotics. Once I was recovering and restarting work 1 month ago, I again became sick. The infection was not yet gone, so even more antibiotics and rest was needed. Needless to say, it took a lot of my energy and I needed a lot of rest.
Finally, the infection is really gone and my energy is coming back step-by-step now and I have started work again. I am terribly sorry to have kept you waiting for support. I will address all outstanding questions and e-mails step-by step and will be on the forum daily from today.
APP 2.0.0-beta47 will come soon as well, a lot of work was already completed before I became very ill, so the release is also nearly ready for you. Beta47 will be much faster actually. Many workflows will be more than 2x faster, mosaics can even be 10x faster than before because registration really received a major boost... all compared to beta46. Â Before I release it, I will make sure that everything is working properly and then I will release it.
Based on what this article describes (the theoretical part seems sound),
https://siril.org/tutorials/synthetic-biases/
could the option to add a value (in ADU) instead of bias (or masterbias) to avoid adding noise to the image be included in APP?
Thanks for your attention.
Hi @anofeles,
The method as offered and discussed can be used for sure.
But... a perfectly flat bias or darkflat to calibrate flat frames (or lights) by using only an offset instead of real sensor data is something which I would only contemplate if it were impossible to create proper bias, darks or darkflats. And this is not a very difficult task I think, so why would you want to go down that route?
I would advice to simply shoot enough bias/dark/darkflats and you will get proper data calibration on pixel AND larger than 1 pixel scale (there are definite sensor noise patterns in clusters on these new CMOS sensors). The static offset simply can't offer that so it will be less good, especially on sensors that are getting of age where even the bias signal can be quite different across the whole sensor. You would be surprised what bias signal an old cmos or ccd camera can give when compared to the signal that the sensor gave when it was brand new!
In my opinion, the static offset method is just a lazy person's way to accomplish something with less precision and definitely more error-prone when compared to proper data calibration where the current state of the camera is always included, so it is a bit difficult to advice this to users even. I would not.
But..., we will try to add it as an option though at some point. It is on our ToDo list.
Mabula
Â
Â
Thanks for taking this into account.
Yes, obviously, biasing is not very time consuming (especially compared to darks or flats). It's not because of the time that can be invested in their creation but because of the noise they can introduce in the image. It would only be within the reach of the most modern CMOS sensors, of course, but it would be a way to try to avoid it.
Taken from siril's website:
"Taking a bias image must be done at the fastest possible speed, to avoid adding signal and thermal noise that would interfere with the processing. However, a bias will contain, in addition to its offset level, a certain level of noise. This is why we advise you to take as many biases as possible in order to minimize the noise in the final master. Remember that when you subtract two images, their respective noise is added. Therefore, using 20 biases introduces more noise into the final image than using 200 biases".
As said, thanks, Mabula, for taking it into consideration.
Best regards...
Â
