Ruis in de CMOS cameras, metingen en berekeningen

Viewing 15 posts - 16 through 30 (of 31 total)
  • Author
    Posts
  • #21049

    InFINNity Deck
    Participant
    posts: 50

    Hoi Han,

    ik heb de volgende proef gedaan:

    Integratie 1:
    – 10 x Lum van 120 seconden geladen
    – MD van 25 subs geladen (dit zou bij de rule of five te weinig zijn)
    – Median integratie met MAD Winsor clip, kappa 3.0, 1 iteratie, weights: star shape

    Integratie 2:
    – 10 x Lum van 120 seconden geladen (dezelfde als hierboven uiteraard)
    – MD van 500 subs geladen (dit zou bij de rule of five te veel zijn)
    – Median integratie met MAD Winsor clip, kappa 3.0, 1 iteratie, weights: star shape

    De gegevens uit de fits headers van de integraties:

    MD25 integratie
    HDU1 – NOISE-1 = ‘ 1.6006E-03 ‘ / noise level of channel 1
    HDU1 – SNR-1 = ‘ 1.0147E+00 ‘ / Signal to Noise Ratio of channel 1
    HDU1 – medNR-1 = ‘ 2.7650E+00 ‘ / median noise reduction, channel 1
    HDU1 – medENR-1= ‘ 1.0119E+00 ‘ / effective median noise reduction, channel 1
    HDU1 – refNR-1 = ‘ 2.7633E+00 ‘ / reference noise reduction, channel 1
    HDU1 – refENR-1= ‘ 1.0067E+00 ‘ / effective reference noise reduction, channel 1 Integrate met 500-sub MD:

    MD500 integratie:
    HDU1 – NOISE-1 = ‘ 1.6003E-03 ‘ / noise level of channel 1
    HDU1 – SNR-1 = ‘ 1.0146E+00 ‘ / Signal to Noise Ratio of channel 1
    HDU1 – medNR-1 = ‘ 2.7655E+00 ‘ / median noise reduction, channel 1
    HDU1 – medENR-1= ‘ 1.0116E+00 ‘ / effective median noise reduction, channel 1
    HDU1 – refNR-1 = ‘ 2.7638E+00 ‘ / reference noise reduction, channel 1
    HDU1 – refENR-1= ‘ 1.0065E+00 ‘ / effective reference noise reduction, channel 1

    Verschil:
    HDU1 – NOISE-1 = 0.02%
    HDU1 – SNR-1 = 0.01%
    HDU1 – medNR-1 = -0.02%
    HDU1 – medENR-1= 0.03%
    HDU1 – refNR-1 = -0.02%
    HDU1 – refENR-1= 0.02%

    [EDIT]
    Het aardige is, dat wanneer ik in APP alle subs verwijder het het proces opnieuw start (ik had aanvankelijk alleen de MD25 verwijderd en vervangen door de MD500), dan krijg ik iets andere verschillen:

    HDU1 – NOISE-1 = -0.02%
    HDU1 – SNR-1 = 0.02%
    HDU1 – medNR-1 = 0.10%
    HDU1 – medENR-1= 0.07%
    HDU1 – refNR-1 = 0.13%
    HDU1 – refENR-1= 0.11%
    [/EDIT]

    De MD25 header info laat dus de ruisniveaus zien, gebruik makend van de 25-sub Master Dark, die andere met de 500-sub Master Dark. Het verschil laat de procentuele verschillen zien, welke dus in alle gevallen ruim kleiner zijn dan 1 promille. [EDIT]Na opnieuw starten van de integratie lopen de verschillen iets op, tot net iets meer dan 1 promille.[/EDIT]

    Dat de verschillen klein zijn, blijkt wel uit onderstaande crop, welke ik 5x vergroot heb.

    Nicolàs

    • This reply was modified 3 weeks, 5 days ago by  InFINNity Deck. Reason: Tweede MD500 integratie toegevoegd
    #21053

    han.k
    Participant
    posts: 40

    Mooi, dat geeft in iedergeval aan dat bij een niet perfecte hemel de dark ruis minder relevant is to.v skyglow ruis en de de rule of 5 niet nodig is.  Ik zit nog te puzzelen met de math maar de noise van een master dark kan je omschrijven als:

    • This reply was modified 3 weeks, 5 days ago by  han.k.
    #21071

    Theunissen
    Keymaster
    posts: 1016

    Het topic is op verzoek afgesplitst.

    #21072

    han.k
    Participant
    posts: 40

    Van de APP ruisgetallen kan ik nog steeds niet maken. Er zit ook geen vaste verhouding met de ruisgetallen die ik meet. Nog even naar MaximDL geken en die meet de ruis het zelfde als in ASTAP.

    De ruis kan je omzetten in elektron. Bijvoorbeeld voor de ASI1600 heb ik het volgende uitgerekend:

    ASI1600MM-Cool, Gain 139, Bin x 1, -25 degrees Celsius

    Standard deviation of average 50 bias minus one bias 26,5 ADU
    gain setting 139 ==> e-/ADU 1,0
    Extra gain 12 bit naar 16 bit is 2^4=>16    16,00
    Read noise or Standard deviation is dan  26,5/16=> 1,67 electron

    Met de dark ruis & read noise moet de skyglow ruis te bereken  zijn en kan de invloed van elke factor bepaald worden.

    #21075

    han.k
    Participant
    posts: 40

    Hier mijn getallen gebaseerd op mijn ASI1600 opnames:

    Readout noise:

    • ASI1600, Gain 139, Binx2, -25 degrees Celsius
    • Standaard deviatie van een average master bias (50x) minus een enkele bias opname is 13  ADU
    • e-/ADU is  1/16  door de 12 bit naar 16 bit omzetting.
    • Read noise or Standard deviation 13/16 => 0,82 electron  Dit is precies de helft van bin 1×1 ofwel 1,62/sqrt(4) electron.

     

    Dark noise:

    • ASI1600, Gain 139, Binx2, -15 degrees Celsius
    • 1xDark-DarkMaster 200 sec,   noise in het resultaat  is ~16 ADU  dit is een combinatie van ReadNoise en DarkNoise
    • Noise^2 =ReadNoise^2+DarkNoise^2
    • 16^2 =13^2+DarkNoise^2  => DarkNoise is 9 ADU or  (9/16)/200 elektron/seconde

     

    Skyglow in in een H-alpha 7nm opname

    • ASI1600, Gain 139, Binx2, -15 degrees Celsius
    • 1xLight – DarkMaster (200 sec exposure),  het resulterende signaal is 211 ADU en de noise in dit signaal ~38 ADU gemeten. Dit is een combinatie van SkyNoise+ReadNoise+DarkNoise.
    • Noise^2 =SkyNoise^2+ ReadNoise^2+DarkNoise^2
    • 38^2 =SkyNoise^2+16^2  => sky Noise is 34 ADU or  (34/16)/200 elektron/seconde. Een deel van deze 34 ADU is ShotNoise ofwel de wortel van het signaal sqrt(211)5=15 ADU en PRNL noise.

     

    Skyglow in een enkele luminance (280 nm breed) opname, SQM  waarde hemel ongeveer 20

    • ASI1600, Gain 139, Binx2, -15 degrees Celsius
    • 1xLight – DarkMaster (200 sec),  het resulterende signaal is 6800 ADU,  de noise in dit signaal ~168 ADU gemeten. Dit is een combinatie van SkyNoise+ReadNoise+DarkNoise
    • Noise^2 =SkyNoise^2+ ReadNoise^2+DarkNoise^2
    • 168^2 =SkyNoise^2+16^2  => SkyNoise  is 167 ADU or  (167/16)/200 elektron/seconde.
    • Een deel van deze 167 ADU is ShotNoise ofwel de wortel van het signaal sqrt(6800)=82 ADU en PRNL noise.

     

    Wat duidelijk is dat de SkyGlow noise de meeste ruis veroorzaakt. Zonder filter is de SkyGlow  voor mijn locatie al bijna 167/9  keer groter dan de DarkNoise. Bij gebruik van een H-alpha filter is SkyGlow 34/9 keer groter dan de DarkNoise.

    Je kan ook zien dat de Skyglow rechtevenredig afneemt met de filter bandbreedte. 280/7nm ~ 6800/211.

    Han

    • This reply was modified 3 weeks, 3 days ago by  Theunissen.
    #21080

    InFINNity Deck
    Participant
    posts: 50

    Mooi Han, dat is een flinke rekenklus geweest. Het is duidelijk welke rol skyglow in onze opnames speelt.

    Ik heb zojuist naar de invloed van darks en dithering gekeken. Daartoe heb ik vier integraties gemaakt:
    – 40 ongeditherde Ha opnames van 120s, bias, BPM, geen MD, geen flat
    – 40 geditherde Ha opnames van 120s, bias, BPM, geen MD, geen flat
    – 40 ongeditherde Ha opnames van 120s, bias, BPM, MD, geen flat
    – 40 geditherde Ha opnames van 120s, bias, BPM, MD, geen flat

    De data staat on-line: http://www.dehilster.info/docs/M101.zip (laat even weten als je ze hebt).

    In onderstaande tabellen staan de resultaten.
    De eerste tabel toont de waarden uit de FITS metadata, zoals geproduceerd door APP.
    De tweede tabel toont de verschillen, waarbij de ongeditherde integratie waarop geen darks zijn toegepast, diende als referentie.

    Wat duidelijk is, is dat dithering de noise flink naar beneden brengt, maar dat de S/N verhouding meer verbeterd indien niet geditherd wordt. Wat verder opvalt, dat bij het niet gebruiken van darks alleen de noise verbeterd, de rest wordt slechter.

    [EDIT]
    Uiteraard zijn darks nog wel nodig om de amp-glow kwijt te raken! Ik heb nog een animated gif bijgesloten om de verschillen tussen de bovenstaande methoden te tonen.
    [/EDIT]

    Nicolàs

    • This reply was modified 3 weeks, 4 days ago by  InFINNity Deck. Reason: Animated gof toegevoegd
    #21087

    han.k
    Participant
    posts: 40

    Hallo Nicolàs,

    Mooi overzicht, maar ik nog steeds moeite met de APP ruisgetallen. Kan je in de APP documentatie een beschrijving hiervan vinden?

    Hier heb ik als test een stack van 45 x 200 seconden  H-alpha opnames gemaakt. Dit zijn dus ruisarme opnames. Zonder een masterdark is het ruisgetal ~6.8 ADU lokaal (donker stukje hemel) and met toepassen van een masterdark ~5.8 ADU. Dus zonder toepassen van de masterdark een 17% slechter ruisgetal. Dat is ook logisch want met de master dark hef je DSNU noise op.

    Dat je het tegenovergestelde (en kleine variaties) meet is dus vreemd.

    Han

     

    #21088

    han.k
    Participant
    posts: 40

    Als extra test heb ik Nebulosity (demo installation) gedownload. Hiermij kan je net als met ASTAP lokaal de ruis meten met de muis cursor (optie Pixel Stats). De meetwaarden StDev komen overeen met ASTAP.

    Han

    #21089

    Haverkamp
    Participant
    posts: 648

    Hoi allen,

    Ik zie toevallig dit topic over ruis en dat Han problemen heeft met de ruis meet waardes in APP, dus bij deze even een snelle reactie op deze koningsdag ;-).

    @han-k , @infinnitydeck

    ” De unit ‘ NOISE = ‘ 1,41E-04’ / MRS gaussian noise estimate of channel’ ken ik niet. De noise wordt normaal RMS, the square root of the mean square bepaald. “

    Ik adviseer je om eens goed in de astronomische literatuur te duiken, je stelling dat ruis wordt bepaald met RMS, the square root of mean square is incorrect. En ik denk dat je de square root of the variance bedoeld?

    Dat is enkel een maat van dispersie/scale: the square root van de variance is de standaard deviatie van een normaal/guass verdeling. Het vertelt je hoe de data is verdeeld ten opzichte van de centrale waarde van een gauss verdeling. Het zegt in principe niks over de ruis zelfs, al kan de ruis in bepaalde gevallen in de buurt komen van deze waarde.

    Je suggestie is zeker geen goede manier om robuust ruis te meten. Je kan wel de ruismeting benaderen mits de data over de sensor compleet vlak is (wat bij een asi1600 zeker niet het geval is). Scale/dispersie en ruis zijn gecorreleerd maar het zijn toch echt compleet ander zaken.

    MRS noise – Multi-Resolution Support Noise , in de professionele astronomie is dat de manier om ruis te bepalen, want het is voor als nog de meest robuuste manier gebleken. Ruis goed meten en MRS noise implementeren is daadwerkelijk geen triviale zaak en veel lastiger dan de RMS, square root of variance uitrekeken, dat is een simpele rekensom… MRS noise is een hele andere zaak.

    Bij deze het beroemde artikel over MRS ruis bepaling zoals dat in 1998 is gepubliceerd en tot de dag van vandaag door de professionele astronomie wordt gebruikt:

    http://adsabs.harvard.edu/abs/1998PASP..110..193S

    Ik zal proberen om morgen het hele draadje te lezen om te kijken of ik wat meer kan verhelderen, okee?

    Wat in deze wel belangrijk is, is dat de asi1600 12bits is, maar de data wordt als 16bit opgeslagen.

    Dus je moet de ruis waardes eigenlijk door 2^4 = 16 delen, om te weten wat de sensor eigenlijk echt heeft gemeten 😉

    Mabula

    • This reply was modified 3 weeks, 4 days ago by  Haverkamp.
    #21091

    InFINNity Deck
    Participant
    posts: 50

    Hoi Han,

    Je schreef

    “Mooi overzicht, maar ik nog steeds moeite met de APP ruisgetallen. Kan je in de APP documentatie een beschrijving hiervan vinden?”

    ik vrees dat dit niet in de handleiding gedocumenteerd is. Ik zie wel op het APP forum dat de voor de MRS (Multi-Resolution Support) gaussian noise naar een artikel van Jean‐Luc Starck en Fionn Murtagh verwezen wordt. Erover schrijft Mabula:

    “Simply said, a simple noise calculation (using easier to implement methods) will estimate the noise with a precision of about 10% only. That is not very precise.

    The MRS gaussian noise, if implemented correctly, will have a precision of only 1%. So the error in the estimate is only 1% of the found value. That’s 10 times better than those simpler methods.

    Even more simply said, the MRS gaussian noise metric is probably the most precise noise metric available.”

    Over de andere berekeningen kan ik zo snel niets vinden, zal een post plaatsen op het APP-forum.

    Nicolàs

    #21092

    InFINNity Deck
    Participant
    posts: 50

    Hoi Mabula,

    dank voor je reactie. Ik was al aan het zoeken en schrijven terwijl jij je post deed, die had ik dus nog niet gezien toen ik mijn vorige verstuurde. Als je commentaar zou willen geven op ons draadje, dan zou ik dat zeer waarderen! Mocht je data nodig hebben, dan hoor ik dat graag.

    groeten,

    Nicolàs

    #21093

    han.k
    Participant
    posts: 40

    Haverkamp,

    Bedankt voor je input. De link naar MRS artikel werkt niet. ik zal verder zoeken maar er lijkt weinig van te vinden.

    Ik bereken de standaarddeviatie van de pixel waarden ( dat is het zelfde als de RMSD van de mean). De noise waarden in the APP fits header lijken weing verband te hebben met de standaarddeviatie, maar misschien wordt dat duidelijk bij het artikel  over MRS.

    Han

    #21094

    Haverkamp
    Participant
    posts: 648

    Hoi Han en Nicolàs,

    Nogmaal de link naar het artikel (excuses, die eerste link is niet goed gegaan), standaard deviatie is echt niet goed om de ruis te bepalen over de hele sensor. Sterker, ruis zal altijd lager liggen dan de standaard deviatie… Het artikel maakt hoop ik veel duidelijk 😉

    Beroemd artikel, googlen levert direct hits op:

    Automatic Noise Estimation from the Multiresolution Support, Starck, Jean-Luc; Murtagh, Fionn

    Automatic Noise Estimation from the Multiresolution Support

    Heel veel algortimes die de professionals gebruiken maken gebruik van de Multi-Resolution techniek.

    MRS kan onderscheid maken tussen ruis op verschillen resoluties/schalen, MRS noise in APP is standaard de ruis op vier schalen, 1 pixel, 2 pixel, 4, 8 pixel schaal opgeteld. De data moet worden geconvuleerd met specifieke kernels om die schalen te kunnen onderscheiden… en daaruit een goede ruis waarde vinden is vervolgens nog steed niet triviaal. Sterker je zult eerst moeten testen met kusntmatige ruis op verschillende schalen om het algoritme te kunnen implementeren uberhaupt. Het artikel geeft je daar wel een hint over 😉

    Mabula

    • This reply was modified 3 weeks, 4 days ago by  Haverkamp.
    #21098

    han.k
    Participant
    posts: 40

    Hallo Mabula,

    >> Ik zie wel op het APP forum dat de voor de MRS (Multi-Resolution Support) gaussian noise naar een artikel van Jean‐Luc Starck en Fionn >>Murtagh verwezen wordt. Erover schrijft Mabula

    Dit artikel heb ik doorgelezen.

    1)  Klopt het dat MRS methode als eerste de deepsky objecten markeert en van de resterende achtergrond zowel de skyglow als de sensor readout  noise kan meten?

    2) Indien ja, dan moet een van de MRS waarden van  een dark gelijkwaardig zijn aan de standaarddeviatie waarde van de dark?

    Zelf kijk ik voor ruis bepaling in sommige routines naar het pixelwaarden histogram (pixelwaarden vs aantal pixels met deze). De histogram spreiding onder de hoogste piek (van de achtergrond) is een goede maat voor de ruis. Wavelets toepassen zoals voor MRS is een brug te ver.

    Han

    Later, ik zie al een nieuwe link om door te lezen. 🙂

    >>Standaard deviatie is echt niet goed om de ruis te bepalen over de hele sensor. Sterker, ruis zal altijd lager liggen dan de standaard deviatie… Het artikel maakt hoop ik veel duidelijk

    3) Deze stelling is me nog niet duidelijk. De standaarddeviatie in pixel waarden is er omdat die gemeten wordt en moet ergens door veroorzaakt worden. Ga je er vanuit dat de ruis niet Gaussian is? De standaarddeviatie meet ik a) van een dark of b) van een opname maar dan lokaal gemeten voor een donker stukje hemel. Ik neem aan dat de homogene skyglow shot noise veroorzaakt met een Poissonverdeling maar dat deze goed benaderbaar is met een normaalverdeling, dus meetbaar als standaarddeviatie.  Als de MRS een lagere ruis aangeeft welk fenomeen veroorzaakt de hogere standaarddeviatie en waarom is dit geen ruis?

     

    • This reply was modified 3 weeks, 3 days ago by  Theunissen.
    #21158

    han.k
    Participant
    posts: 40

    Hallo Mabula,

    Om een en ander nog eens te testen heb ik APP geinstalleerd en de test nog eens gedaan met de darks van Nicolàs.

    Met APP een masterdark van 20 x dark, MD20 gemaakt. De sigma wordt door APP gerapporteerd als 5,13E-4= 33,6/65535. ASTAP, Nebulosity en MaximDL rapporteren rond de 18. Dit is bijna een factor 2 lager.

    Daarna de volgende bewerking gedaan, een enkele Dark – MD20 + 1000, dus de masterdark MD20 van een enkele dark afgetrokken en een offset van 1000 toegevoegd om e.a. positief te houden. Dit geeft door de ander programmas een gemeten sigma van 31. Dit kan je omrekenen naar de verwachte ruis voor de MD20 door te delen met de wortel van 20. De uitkomst 6,9 (D3) lijkt redelijk te kloppen met noise gerapporteerd in APP als 9,5/65535.

    De grootste afwijking voor deze test is de door APP gerapporteerde sigma ofwel standaarddeviatie. Waar gaat het fout? Of is de sigma in APP master dark gerapporteerd, de sigma van een enkele dark (standard deviation channel)?

    Han

    • This reply was modified 3 weeks, 3 days ago by  Theunissen.
Viewing 15 posts - 16 through 30 (of 31 total)

You need to log in or to reply to this topic.