Offset

[gerard van den braak]

Offset
Het begrip ‘Offset’ kent naar mijn weten twee betekenissen.
1. Een verplaatsing van het brandpunt in mm omdat het brandpunt , door combinatie(s) met andere lenzen, voor of achter het brandpunt van de lens gekomen is. Een ander term voor backfocus.
2. Het toevoegen van een grondlading, een pedestal aan een ccd in ADU’s.
Offset voorkomt de er negatieve waarden worden uitgelezen. Als een pixel bijvoorbeeld 10 fotonen ontvangt en de masterdark wordt er van afgetrokken kan er een negatieve waarden ontstaan die door de ruis veroorzaakt is.

Willen Jan zei tijdens de starparty dat hij de offset nog eens moet berekenen. Dat verbaasde me en nam me voor hem daar naar te vragen. Als hij de offset zoals onder punt 1 bedoelde kan ik me voorstellen dat je wat moet rekenen aan opvulringen tussen focusseer en camera. Maar als je dat eenmaal goed hebt doet de autofocus het werk verder. Hij heeft toen een mooie, scherpe opname gemaakt, wat was dan het probleem om tot een berekening over te gaan?

Tim geeft in de toelichting van zijn foto’s de gebruikte offset. Bij de ene foto is dat 25, bij de andere 100. Het kan niet missen dat het hier ‘Offset 2’ betreft. Dit kan ik eerlijk gezegd niet volgen. Hij gebruikte steeds dezelfde camera en dezelfde telescoop en de fabrikant van de camera geeft in de documentatie aan wat de offset moet zijn.
Waarom dat toch de offset veranderen?

[Astrovirus]

Hoi Gerard,

Wat jij onder offset #1 benoemd zou ik geen offset, maar backfocus noemen, want inderdaad bijvoorbeeld filters tussen een reducer/corrector kunnen inderdaad lengte aan de lichtweg toevoegen die invloed hebben op je backfocus.

Ik gebruik inderdaad het begrip offset #2 bij mijn opnames en het klopt dat ik met verschillende offsets heb gewerkt de laatste tijd. Dat ik de offset heb moeten veranderen bevreemde mij inderdaad ook, want ook ik was altijd in de veronderstelling dat in principe de offset 1x ingesteld moet worden en dat je hem zo laag mogelijk kiest, maar wel zo, dat inderdaad er nooit negatieve waarden ontstaan als de sensor uitgelezen wordt. Voor mijn OSC RGB opnamen was een offset van 25 altijd prima, dit gaf bij mijn belichtingen altijd een mooi losliggend histogram aan de linker zijde, met goed dynamisch bereik.

Echter toen ik vorige maand mijn Ha-filter in de optische trein bijplaatste (en deze zit in dit geval voor de comacorrector en heeft dus geen invloed op de backfocus tussen de camera en de corrector), zag ik toch een behoorlijke clipping van het histogram aan de linkerzijde, zelfs als ik de belichting naar het maximale van de camera opschroefde. Na een discussie hierover op de AF Discord ben ik dus met de offset gaan spelen en kwam met een Ha filter uiteindelijk uit op een offset van 150, waarbij ik weer een mooi losliggend histogram heb en de belichtingen ook weer in veel ordelijke lengtes kwamen te liggen (3-5 min/sub).

Een echte verklaring hiervoor heb ik niet, waarom ik met en zonder Ha filter dus verschillende offsets moet gebruiken, maar mogelijk dat hier het gebruik van een OSC camera en een smalband filter invloed op elkaar hebben. Mijn idee hierbij is dat maar 1/4 (de rode pixels) van mijn sensor echt gevoelig is voor het doorgelaten Ha licht en dat mogelijk 1/2 (de groene pixels) een lagere efficiëntie hebben, terwijl opnieuw 1/4 (de blauwe pixels) een zeer lage efficiëntie hebben voor het doorgelaten licht. ALs ik met een offset van 25 werk is die misschien wel goed voor de rode pixels, maar aangezien groen en blauw een veel lager SNR hebben moet de offset voor de hele sensor dus misschien wel veel hoger ingesteld worden. Geen idee of dit correct, laat staan een zinvolle redenatie is, feit is dat het zo wel werkt voor mijn camera.

In het verlengde hiervan, ben ik momenteel bezig om te kijken wat voor invloed een offset van 150 heeft, bij het schieten van OSC RGB data. Eerste indruk is dat het inderdaad minder dynamisch bereik geeft (logisch), aangezien het histogram verder naar rechts opschuift. Vooralsnog niet zover dat het overbelichting suggereert, maar daar kom ik waarschijnlijk pas achter als ik de set RGB data ga processen.

[Astrovirus]

Overigens moet je wel voor elke gekozen gain waarde wel een eigen offset kiezen. M.a.w. offset is wel gain afhankelijk.

[gerard van den braak]

Een OSC heeft een 3-4 maal lagere resolutie dan een monochrome camera. Als je er dan een H-alfa filter voor zet wordt het licht opvangen wel heel moeilijk. Groen en blauw laat het niet door en slechts 7nm van het rood.
Wil je dan toch voldoende fotonen vangen moet er erg lang belicht worden om het histogram los te krijgen van de linker zijde.
Ik kan me voorstellen dat als je de offset maar voldoende verhoogt het histogram uiteindelijk los komt. Je voegt immers lading toe aan de pixels. Maar dat is nepsignaal! Je krijgt niet meer informatie door.

De Gain is een versterkingsfactor die de lading van de pixel met de ‘gainfactor’ verhoogd. Het zal het zwakste signaal zover omhoog brengen dat het beter zichtbaar en te bewerken wordt. Maar ook hier krijg je niet meer informatie.

De offset verhoogt de verticale positie van het signaal, de gain de amplitude.
Er is dus geen relatie tussen offset en gain!
Een OSC is dus eigenlijk niet geschikt voor gebruik met filters. Doe je dat toch, dan ben je aangewezen op heldere objecten of héél lang belichten.

[Astrovirus]

Ik ben het in hoofdlijnen helemaal met je eens Gerard, maar zou het toch wel wat willen nuanceren.

Ik heb namelijk zelf altijd wat moeite met de nogal zwart-wit aanname dat een OSC camera per definitie een 3-4x lagere resolutie heeft als een gelijke mono camera met identieke sensor. Mede door deze veronderstelling wordt nog wel eens geadviseerd om dan smalband data te schieten in 2x2 bin om de GB pixels teniet te doen. Maar ik heb altijd het gevoel dat men hierin voorbij gaat aan de softwarematige interpolatie van de data bij bijvoorbeeld het debayerproces. Nu moet ik meteen toegeven dat ik nooit metingen gedaan heb met gelijke mono en kleurensensoren en mij puur baseer op mijn eigen ervaringen met een Canon 350Da en mijn huidige OSC en altijd prima SNR weet te behalen als ik Ha opnames maak. Je hebt overigens wel gelijk dat het Groene en Blauwe kanaal vrijwel geen ifo bevatten bij een OSC en Ha filter, van daar ook dat ik in de processing alleen werk met het Rode kanaal. Zie onderstaand voorbeeld van de ruwe stack waarvan de 3 geextraheerde kanalen een exact gelijke stretch hebben gehad.

Ha RGB verdeling.png (288.88 KiB) 1385 keer bekeken

Wel zal er uiteraard een verschil in gevoeligheid zijn tussen een mono en een OSC, maar ik denk dat dat net zo goed opgaat als je gelijke sensoren OSC en mono de strijd aan laat gaan op een breedband foto (OSC en LRGB opname). Dat is nu eenmaal de afweging in mono schieten en dus heel veel tijd moeten steken in alle losse kanalen, of sneller OSC binnenhalen, waarbij je ook weer langer totaal moet belichten om zwakke details/structuren zichtbaar te maken. Netto hebben we misschien dan net zoveel totale integratietijd nodig per object.

Als ik nu naar mijn Ha data kijk van de afgelopen periode valt het echt wel mee hoeveel het verhogen van de offset mij aan dynamisch bereik heeft gekost, terwijl bij lagere offset er duidelijk zichtbare clipping plaats vind aan de donkere (linker) zijde van het histogram. En ik denk dat mijn Ha platen duidelijk laten zien dat je met normale subframe belichtingen van 3-5 minuten en een totale integratietijd van 4-5 uur prima Ha opnames kan maken met een OSC. En er zit ook echt wel zwak spul in die opnames, gezien de zwakke Ha wolken aan de buitenranden van M16. Zelfs de soap bubble, die voornamelijk OIII straalt, is in mijn Ha stack van NGC6888 zwak zichtbaar, wat mijns inziens toch aantoont dat het met de gevoeligheid van deze OSC wel meevalt.

Soap bubble Ha NGC6888.png (455.28 KiB) 1385 keer bekeken

Voor wat betreft mijn opmerking over de relatie tussen gain en offset. Er zal misschien geen directe relatie zijn, maar als je al het signaal vermenigvuldigd door een hogere gain te gebruiken, dan zal je mogelijk beter af zijn bij een lagere offset, omdat je anders aan 2 kanten het dynamisch bereik aan het inperken bent. Wat ik dus bedoelde te zeggen is dat het verstandig is om voor iedere gain setting je optimale offset te (her)bepalen. Nu geef ik wel meteen ruiterlijk toe dat ik aangaande deze factoren meer een praktisch iemand ben, dan dat ik de theorie helemaal probeer te doorgronden, het is ten slotte een hobby en ik ben in het dagelijks werk al genoeg met precieze wetenschap bezig.

Ik denk dus dat het schieten van smalband data met een OSC helemaal nog niet ze slecht gaat. Het blijft natuurlijk wel achter bij een mono camera, maar is zo slecht nog niet.

Wel een interessante discussie overigens dit allemaal hoor.

[Han]

Echter toen ik vorige maand mijn Ha-filter in de optische trein bijplaatste (en deze zit in dit geval voor de comacorrector en heeft dus geen invloed op de backfocus tussen de camera en de corrector), zag ik toch een behoorlijke clipping van het histogram aan de linkerzijde, zelfs als ik de belichting naar het maximale van de camera opschroefde. Na een discussie hierover op de AF Discord ben ik dus met de offset gaan spelen en kwam met een Ha filter uiteindelijk uit op een offset van 150, waarbij ik weer een mooi losliggend histogram heb en de belichtingen ook weer in veel ordelijke lengtes kwamen te liggen (3-5 min/sub).

Dat is vreemd. De pedestal, ofwel basiswaarde in het Nederlands is normaal een vaste waarde. Daar bovenop komt de lekwaarde van de pixels en de hemelachtergrond. Welk waarde hebben je darks? Deze darks moeten een normale histogram laten zien zonder clipping onder nul.

By QHY and ASI is deze pedestal niet in te stellen en is ook niet nodig.

Ik heb ook een aantal H-alpha opnames gemaakt met mijn QHY8 OSC camera. Dat werkt best goed. Wel is het zaak alleen de rode pixels uit de raw te extraheren. Dat geeft dan beelden met een 1/4 van de normale hoeveelheid pixels.

Han

[gerard van den braak]

Wel een interessante discussie overigens dit allemaal hoor.

Juist daar ging het me om. Zo komen we tot meer inzicht en draaien we met wat meer kennis aan de knoppen.
Je foto's vind ik prachtig, dat was niet de insteek. En wat betreft de spikes; ik vind het altijd jammer dat mijn Takahashi die niet geeft. Een draadje spannen gaat me echter te ver.

[Astrovirus]

En wat betreft de spikes; ik vind het altijd jammer dat mijn Takahashi die niet geeft. Een draadje spannen gaat me echter te ver.

Dat is ook precies waarom dit zo'n mooie product is van Skywatcher betaalbaar, meer widefield dan ik heb met de 200P, snel en SPIKES!

[Astrovirus]

Ik heb ook een aantal H-alpha opnames gemaakt met mijn QHY8 OSC camera. Dat werkt best goed. Wel is het zaak alleen de rode pixels uit de raw te extraheren. Dat geeft dan beelden met een 1/4 van de normale hoeveelheid pixels.

En dit doe ik dus niet, ik stack gewoon de hele set als een OSC opname en daarna extraheer ik het rode kanaal om als monochrome opname mee verder te gaan. Die heeft gewoon de normale resolutie van de sensor en ik heb niet het idee dat dit de kwaliteit verminderd. Maar ik weet dat er vaak geadviseerd wordt om in 2x2 bin te schieten, zodat d iedere pixel eigenlijk alleen maar de rode zijn (groen en blauw zijn leeg). Op deze manier kan ik veel makkelijker een HaRGB combinatie maken, aangezien beide gelijke volle resolutie hebben.

[Astrovirus]

Dat is vreemd. De pedestal, ofwel basiswaarde in het Nederlands is normaal een vaste waarde. Daar bovenop komt de lekwaarde van de pixels en de hemelachtergrond. Welk waarde hebben je darks? Deze darks moeten een normale histogram laten zien zonder clipping onder nul.

Dat is inderdaad zo, mijn normale darks hebben denk ik een gem ADU van 300-400. Maar in N.I.N.A zie ik met het Ha filter echt clipping aan de linkerzijde van het histogram met het Ha filter in de optische trein. Ook flats via de flatwizzard gaan niet zomaar goed. Als ik een RGB flat maak op 50% ADU, dan doet NINA prima de belichting zo instellen dat de gem ADU inderdaad rond de 30.000-32.000 ligt, met een vrij breed histogram waarin 2 pieken te zien zijn (als ik het me goed herinner). Bij Ha flats op dezelfde manier schiet NINA enorm door in de belichtingen en krijg ik een histogram met veel lagere pieken. Ik ben toen eens zelf hadmatig met de belichting gaan spelen en zag toen de bij korte belichtingen het histogram lijkt op die van RGB. Als ik dan de tijd vergroot, dan zie ik een piek los komen die uiteindelijk aan de rechterkant verdwijnt (clipping) en er 2 lagere pieken overblijven. Mijn idee hier is dat omdat het Ha filter natuurlijk geen G/B pixels belicht, die grote piek de rode pixels zijn, die uiteindelijk overbelicht raken en die 2 kleine piken de G/B pixels zijn. De flat is ook zwaar overbelicht. Kan nu zo 1-2-3 geen voorbeelden laten zien helaas.