Share:
Notifications
Clear all

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.

[Solved] Calibrating data with a Sony BSI IMX183 C/M sensor - ASI183, Altair Hypercam 183, QHY183 - removing the severe Amp-Glow patterns

10 Posts
3 Users
7 Reactions
13.4 K Views
(@rcfmitch)
Neutron Star
Joined: 8 years ago
Posts: 74
Topic starter  

the New Sony Hypercam BSI IMX183 C/M star burst doesn't seem be subtracting with 40 darks ,

and I'm too new to guess why.

Im going to try a few more runs and show the results. Doing BPMap also did not seem to solve this.

MD ISO gain 800.0 exp 180.0s 40subs Altair Astro Camera ASCOM Driver 5440x3648 WC 3 3.0 avg StIMX183M
BPM1
Sony BSI IMX 183

 

EDIT by Mabula:

CHECK this post with the solution:

https://www.astropixelprocessor.com/community/main-forum/sony-hypercam-bsi-imx183-c-m-star-burst-not-subtracting/#post-4533


This topic was modified 8 years ago 2 times by Mabula-Admin

   
artem reacted
ReplyQuote
(@rafiosso)
Molecular Cloud
Joined: 8 years ago
Posts: 4
 

What precisely camera is it? Altair Hypercam? Or something else?



   
ReplyQuote
(@rcfmitch)
Neutron Star
Joined: 8 years ago
Posts: 74
Topic starter  

Yes, the Altair Astro 183M  hypercam . 🙂



   
ReplyQuote
(@rafiosso)
Molecular Cloud
Joined: 8 years ago
Posts: 4
 
Posted by: rcfmitch

Yes, the Altair Astro 183M  hypercam . 🙂

Well, in that case You don't have precise temperature control built into the camera. AFAIK Altair hypercam has only a cooler, not a precise controlled peltier (like ZWO, QHY) and that is why You cannot get rid of thermal pattern, as temperature changes during photosession.



   
ReplyQuote
(@rcfmitch)
Neutron Star
Joined: 8 years ago
Posts: 74
Topic starter  

 

 

Actually that statement is incorrect , ( get rid of thermal patterns) i can completely remove the Starburst in Pixinsight and DSS4.1.1. and Nebulosity 4.

the problem at this point is the way APP interprets the darks and flats as it calibrates the light frame.

thank you for your input , 🙂   Mabula will have a look at this when he has a minute..  

 

Micth 


This post was modified 8 years ago by rcfmitch

   
ReplyQuote
(@rafiosso)
Molecular Cloud
Joined: 8 years ago
Posts: 4
 
Posted by: rcfmitch

 

Actually that statement is incorrect , ( get rid of thermal patterns) i can completely remove the Starburst in Pixinsight and DSS4.1.1. and Nebulosity 4.

the problem at this point is the way APP interprets the darks and flats as it calibrates the light frame.

thank you for your input , 🙂   Mabula will have a look at this when he has a minute..  

 

Micth 

Oh, glad to see there's a solution for thermal patterns, i suspected the temperature control to be "guilty" 😉



   
rcfmitch reacted
ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 9 years ago
Posts: 5379
 

Hi Mitch @rcfmitch, @rafiosso, @vincent-mod,

Thank you Mitch for sending me a dataset shot with the Altair Astro Camera which has the Sony Hypercam BSI IMX183 sensor.

APP can calibrate this data correctly, using the Adaptive Data Pedestal in 2) Calibrate.

To be clear, APP will do this better (at least with the data that I have for testing) than other applications due to this Adaptive Pedestal.

Please have a look at the release notes of APP 1.062, this example shows the issue with an asi183mm-c camera which has the same sensor.:

https://www.astropixelprocessor.com/community/release-information/astro-pixel-processor-1-062-ready-for-download/

  • Improved, data calibration of severe Amp Glow, amp glow does not behave linearly so it's always important to not use dark scaling if your sensor has significant amp glow. You need to create darks of the same offset, gain/ISO, temperature and exposure time as your lights, to properly deal with amp glow. Now, in cases of strong amp glow, it can happen that the glow is so strong when compared to the real photon signal and noise in our data that a large part of these pixels will be calibrated to zero if we subtract a suitable dark frame. This will happen in each frame for different pixels and that will have a cumulative effect in image integration. The statistics of the pixelstacks will actually be skewed to the upside still showing residual amp glow in some cases. In 2) Calibrate, there is now a new option that will adaptively solve this for data were this happens. It's called Adaptive Data Pedestal. If you enable this, it will prevent severe clipping on the black point in calibration, and will therefore prevent skewed pixel statistics in image integration. It's an adaptive algorithm, so it takes a little bit more time in calibration. A case were you probably need to enable this is strong Amp Glow with camera's like the ZWO ASI183. For most camera's and datasets, this setting will have no effect, but in cases where severe black clipping in calibration does occur, for whatever reason, this setting will prevent it and will ensure precise calibration and no-skewed statistics in image integration.
Adaptive Data Pedestal

Example of an integration of ZWO ASI183mm-c Oxygen-III data provided by Warren Landis @orangemaze, with and without the setting enabled in calibration:

APP 1062 ampglow fix
APP 1061 ampglow asi183

In this case, the amp glow is not calibrated out with the Adaptive Data Pedestal disabled, because the amp glow simply overpowers the real OIII data on the location of the amp-glow. By enabling the Adaptive Data Pedestal, the amp glow is properly calibrated.

I received a nice Hydrogen-Alpha data set from Mitch of IC405. Details are:

60x180sec lights

40x180sec darks to calibrate the lights

50x flats to calibrate the lights

60x bias to calibrate the flats. (not used for the light frame calibration)

To see the extreme amp-glow problem of this sensor, this is the stretched MasterDark:

MD ISO gain 1000.0 exp 180.0s 40subs Altair Astro Camera ASCOM Driver 5440x3648 NR avg St

You can see the extreme amp-glow on the right side of the sensor, and a little bit in both bottom corners of the sensor.

These are the results with and without the Adaptive Data Pedestal enabled in calibration, off course, highly stretched to show the data calibration performance in an integration of 60x180 seconds Hydrogen-Alpha frames (3 hours total exposure time):

Without Adaptive Data Pedestal:

Without AdaptiveDataPedestal
Integration without AdaptiveDataPedestal

With the Adaptive Data Pedestal enabled, where is the Amp-Glow ?? 😉 :

With AdaptiveDataPedestal
Integration with AdaptiveDataPedestal

Direct comparison:

Without With AdaptiveDataPedestal

 

What happens without the Adaptive Data Pedestal: the residual amp-glow that you see in the integration without the adaptive data pedestal enabled, is the result of skewed data integration (to the upside) due to black clipping of the light frames after the subtraction of the MasterDark. This means that the provided lights are not sufficiently illuminated for this sensor. This sounds strange perhaps for such a BSI cmos sensor, but the illumination really is not enough to have the light/photon signal overcome the severe amp-glow on the right side of the sensor. The Amp-Glow signal is so strong, that after subtracting a masterdark from the light frames, a lot of pixels are still black clipped... The Hydrogen-Alpha signal (in this case) is too weak to overcome the Amp-Glow. This has a degrading effect on the data, once properly calibrated with the Adaptive Data Pedestal enabled, the image data will always have worse noise characteristics in the areas where the Amp-Glow resides on the sensor. 

The Adaptive Data Pedestal is an adaptive algorithm that will prevent the black clipping of pixels after masterdark subtraction and therefore the integration results are no longer skewed to the upside, thus properly removing the amp-glow signal if the provided darks are of  the same temperature, same exposure and same gain + offsett as the light frames.


This post was modified 8 years ago 2 times by Mabula-Admin

   
ReplyQuote
(@rafiosso)
Molecular Cloud
Joined: 8 years ago
Posts: 4
 

Wow, that is impressive!

Thank You Mabula for lots of effort and clear explanation!!!



   
Mabula-Admin reacted
ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 9 years ago
Posts: 5379
 
Posted by: rafiosso

Wow, that is impressive!

Thank You Mabula for lots of effort and clear explanation!!!

You're most welcome @rafiosso ;-(



   
ReplyQuote
(@rcfmitch)
Neutron Star
Joined: 8 years ago
Posts: 74
Topic starter  

I agree , WOW , thank you for making a program that will allow us to push the envelope on this new Sony BSI chip without fear of horrible amp glow and damaged data sets. 

More data and images to come in the coming weeks processed with APP.

 

Thanks again Mabula H.



   
Mabula-Admin reacted
ReplyQuote
Share: