SQM waarde meten met je camera

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #24412

    han.k
    Participant
    posts: 85

    Vandaag een nieuwe mogelijkheid toegevoegd aan ASTAP development versie 0.9.476: “Meten van de SQM waarde”. Dus de hemel lichtvervuiling in magnitudes per vierkante arcsec. Het is een kleine aanvulling op de bestaande routine om de stermagnitudes te meten. De werking is als volgt:

    • Laad een opname
    • Optioneel:  calibreren met dark en flat in stack menu optie “calibration only”.
    • Astrometric (plate) solve.
    • Gebruik tool menu “Magnitude measured annotation”

     

    De detecteerde sterren worden vergeleken met de database. Daaruit wordt de relatie sterflux/magnitude bepaald. Daarop wordt de magnitude van elke detecteerde ster aangegeven.  Het nieuwtje is dat ook eenvoudig de hemelachtergrond gemeten kan worden. Het best na een dark/flat calibratie van een enkele opname maar zonder gaat ook redelijk goed. De SQM wordt onder aangegeven.

     

    Zijn er gebruikers die dit eens willen testen met hun opnames?

    Han

    Webpage: http://www.hnsky.org/astap.htm

    ASTAP Windows versie:  http://www.hnsky.org/astap_setup.exe

    ASTAP Linux versie:  http://www.hnsky.org/astap_amd64.deb

    • 3 people like this.
    #24413

    InFINNity Deck
    Participant
    posts: 378

    Hoi Han,

    zojuist getest met een lum-opname van 17 december jl. van C/2020 M3 Atlas en die komt (zowel met als zonder darks/flats) op een SQM van 17.0 mag./arc sec2. De omstandigheden waren met opkomende bewolking sub-optimaal. De lum-opname van 18 december komt op 19.0 mag./arc sec2, maar ook op die dag werd de opname door bewolking ingekort. Een opname van 8 augustus van Sharpless 155 en vdB 155 tijdens een goede heldere nacht komt op 20.0 mag./arc sec2.

    Volgens LightPollution Map zou het hier 19.77 mag./arc sec2 moeten zijn. Ik heb geen SQM meter om mee te vergelijken.

    Wat me opvalt dat de drie resultaten allemaal op hele mag./arc sec2 afgerond zijn, terwijl er wel één decimaal gegeven wordt.

    Nicolàs

    #24414

    han.k
    Participant
    posts: 85

    Hallo Nicolàs,

    Bedankt voor de feedback. Ja een foutjes gemaakt met het afronden. Inmiddels versie 0.9.476a geupload (zelfde link). Deze laat correct een decimaal achter de komma zien.

    In principe moet dit heel nauwkeurig werken. De database magnitudes kloppen meestal binnen 0.1 magnitude met de gemeten ster-magnitudes   Dat moet dit ook kloppen voor de waarden van de beeldachtergrond als de dark er vanaf getrokken is.

    Daarnaast heb ik ook geprobeerd het hemelsignaal te heconstrueren van de achtergrondruis. In principe is de hemelruis dominant en gelijk aan de wortel van het signaal.  Dus het hemelsignaal (flux) zou gelijk moeten zijn aan de ruis in het kwadraat. Echter met mijn cmos camera ASI1600 is de achtergrond ruis twee keer zo groot als verwacht. Zelfs na correctie met dark en flat. Daar heb ik nog geen goede verklaring voor.

    Han

     

     

    • 1 person likes this.
    #24415

    han.k
    Participant
    posts: 85

    Ik zie het zelfde in dit beeld van ATIK:

    https://www.atik-cameras.com/wp-content/uploads/2016/12/shot-noise-1-e1481806613359.png

    Waarde is 43248    de ruis zou dan zijn sqrt(43248) is 208

    De standaard deviatie is 417.

    #24416

    han.k
    Participant
    posts: 85

    Dat moet de 2×2 binning zijn. De output word na binning niet 4 keer hoger.  Dan moet het mogelijk zijn om de SQM te bepalen zonder dark…..

    Later:

    Nee dat klopt niet. Bij bin 1×1 meet ik vier keer zoveel noise dan de shot noise berekening sqrt(signal) aangeeft. De achtergrondruis lijkt invloed te hebben van pixelongelijkheid ofwel  PRNU (photo-response non-uniformity) noise.  Maar als ik twee lights vanmekaar aftrek om PRNU te elimineren dat lijkt dat toch niet te helpen. Waarschijnlijk onstaat de fout doordat ik niet in electrons reken. Voor mijn 12 bit camera wordt voor elke 16 ADU een electron gemeten. Als je het signaal omzet in elektrons en dan de ruis uitrekent  dan komt er een factor 4 verschil uit. Daar moet ik nog eens nader na kijken.

    Han

    #24418

    han.k
    Participant
    posts: 85

    De methode werkt nu zowel voor de opnameachtergrondwaarde als de ruiswaarde van de achtergrond. In het begin zat ik even fout met de ruisberekening maar nu lijkt het te kloppen. Er wordt een SQM berekend voor 12 bit (ASI1600) en 16 bit cameras. Versie 0.9.477. Terugkoppeling  van testresultaten wordt gewaardeerd.

    Han

     

    #24422

    InFINNity Deck
    Participant
    posts: 378

    Hoi Han,

    zojuist ASTAP 0.9.479 geïnstalleerd en Sharpless 155 er nog eens doorheen gehaald. Nu krijg ik inderdaad één decimaal te zien. De SQM uit background data is 19.6 magn/sqr(“), uit de 12bit ruis 19.4magn/sqr(“). Ik zie dat ik ook een camera pedestal kan opgeven, maar moet dat in 12bit of 16bit? En wat is de beste manier de pedestal te bepalen?

    Nicolàs

    #24424

    han.k
    Participant
    posts: 85

    Hello Nicolàs,

    De pedestal is alleen nodig voor de eerste meting gebaseerd op de gemiddelde achtergrondwaarde.  Je kan eenvoudig een bias of dark nemen en daar de gemiddelde waarde van af lezen met ASTAP. Deze waarde is vast. Bij mijn ASI 1600 is het 300. ASTAP geeft de pixel waarde aan in de status bar tusen twee []. Je kan ook het popup menu gebruiken om het statistisch gemiddelde/mean van de opname te bepalen.

    Het twee en derde getal zijn gebaseerd op de ruis van de achtergrond. De ruis komt bij moderne camera voornamelijk van de shot noise van het inkomende licht. De ruis is dan de wortel van het aantal elektrons. De pedestal waarde heeft daar geen invloed op. Echter bij een sterk signaal wordt de ruis relatief steeds minder en gaat de pixel ongelijkheid meespelen of zelfs overheersen. De praktijk moet gaan bewijzen of methode nauwkeurig is voor alle camera. Voor de meting gebaseerd op ruis is het belangrijk dat de achtergrond overheerst dus wat langere belichting als 50 seconden of meer zijn nodig.

    Zodra het helder is ga ik tijdens de schemering metingen doen en vergelijken met mijn Unihedron SQM-L meter.

    Klopt de gerapporteerde waarde 19.6 met deze kaart?:

    Han

    https://www.lightpollutionmap.info/#zoom=6.88&lat=52.2900&lon=7.1229&layers=0BTFFFFFFFFFFFFFFFF

    overlay “World map 2015”, the zenith sky brightness scale goes down to SQM<17.5

    #24425

    InFINNity Deck
    Participant
    posts: 378

    Hoi Han,

    dank voor de uitleg.

    Ja, zoals ik hierboven reeds meldde, is de waarde volgens Light Pollution Map bij ons 19.77 magn/sqr(“), dus dat klopt aardig. Uiteraard is het maar een momentopname, veel is afhankelijk van de transparantie en van de toestand in de wereld (toen COVID19 goed losbrak, gingen om ons heen veel kassen uit, dus dat scheelde weer…).

    Nicolàs

    #24427

    han.k
    Participant
    posts: 85

    Deze avond kon een veldtest van de SQM routine doen. Helaas met een beperkt aantal metingen doordat er steeds wolken voorbij kwamen. Bovendien stond de Maan aan de hemel. Maar het resultaat is gewoon goed:

    Belichtingstijd van 0.5 seconde in het begin to 30 seconden aan het einde. Camera was een ASI1600MM Cool in bin 2×2.

    Han

    • 1 person likes this.
    #24428

    InFINNity Deck
    Participant
    posts: 378

    Hoi Han,

    dat is opmerkelijk goed! ASTAP lijkt iets terughoudender te zijn, maar de verschillen zijn denk ik verwaarloosbaar klein. Ben eigenlijk wel benieuwd hoe andere camera’s presteren wat dit betreft en of er verschil zit tussen CMOS en CCD.

    Mooi hoor! 🙂

    Nicolàs

    #24429

    han.k
    Participant
    posts: 85

    Hallo Nicolàs,

    De omstandigheden waren slecht door regelmatig voorbijkomende wolken, dus afwijkingen kunnen ook door sluierwolken ontstaan zijn.

    Door de calibratie met de Gaia sterren database verwacht ik dat het resultaat  zo goed is als de Unihedron SQM meter. Zolang de CMOS of CCD sensor linear is, dan is de sterflux/(2.51^magnitude) verhouding constant. De sterren flux meting is natuurlijk kritisch maar deze werkt goed. Outliers en verzadigde sterren worden verwijderd. Grootste probleem is waarschijnlijk de signaalafval in de hoeken/randen van het beeld. Maar dat kan je compenseren met een flat. Dat heb ik nog niet gedaan en is misschien ook niet nodig door het middelen.

    Veroudering/vervuiling  van de optiek zal bij de ASTAP meting geen invloed hebben, bij de Unihedron meter wel. De ASTAP ijking wordt bij elke meting gedaan door vergelijken met de sterrendatabase.

    Han

    Later, er is een ding wat ik nog niet heb meegenomen, dat is de altitude. Bij lagere altitude dan zenith worden de sterren zwakker.  Zo misschien was het toeval dat de waarden zo gelijk zijn. Waarschijnlijk is het beter om over de relatieve SQM te praten.

    Extinction becomes significant when altitudes are lower than about 45 degrees. At sea level, zenith extinction is 0.28 magnitudes, and at an altitude of 45degrees it’s 0.40 magnitudes

    • This reply was modified 1 month, 1 week ago by  han.k.
    • 1 person likes this.
    #24432

    han.k
    Participant
    posts: 85

    Voor de record: Vandaag nog even meer verdiept in extinction. De reden dat de Unihedron en ASTAP waarden zo gelijk zijn is dat Unihedron calibratie circa 0.35 magnitudes gecorriseerd is. Dit is gelijk aan de extinction in het Zenith.

    http://www.lightpollution.it/download/sqmreport.pdf

    The different zero point is likely due to the fact that the relation has been obtained with outside-the-atmosphere magnitudes V’ and B’. As an example, assuming an extinction of 0.35 mag in V and 0.15 mag in B and replacing V’=V-0.35 and B’=B-0.15, where V and B are the apparent magnitude below the atmosphere, we obtain SQM−V= 0.2(B−V)−0.31 in agreement with my previous results. The zero point of the current SQM calibration made by Unihedron gives SQM≈V’ for stars with B’=V’, above the atmosphere, and consequently the below-the-atmosphere SQM-V correction factor for the alpha Lyrae spectrum come out different from zero. Fig.18 shows that for alpha Lyr is SQM-V=-0.35 mag arcsec−2.

    • 1 person likes this.
Viewing 13 posts - 1 through 13 (of 13 total)

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