Offset

Alles over techniek; Hardware en Software zaken.
Bericht
Auteur
Gebruikersavatar
Wjdrijfhout
Berichten: 573
Lid geworden op: 14 jan 2019 20:47
Contacteer:

Re: Offset

#11 Bericht door Wjdrijfhout » 30 jun 2023 09:29

gerard van den braak schreef: 26 jun 2023 17:27
Astrovirus schreef: 26 jun 2023 16:49 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.
Ja, inderdaad leuk! Zie nu al dat ik weer een paar dingen geleerd heb. Onderstaand wat toevoegingen aan de discussie zoals ik ze altijd begrepen heb, maar zou mezelf zeker geen expert noemen.
gerard van den braak schreef: 26 jun 2023 11:41 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?
Waar ik het op de starparty over had was inderdaad het eerste voorbeeld. En dat wordt inderdaad meestal backfocus genoemd. Om een vlak beeldveld te krijgen voor fotografie heeft bijna elk systeem een corrector nodig. Uitzondering is bijv. het Petzval design (FSQ-106) die van zichzelf al een vlak beeldveld heeft. Elke corrector/flattener heeft een vaste afstand waarop de correctie 100% werkt, de backfocus afstand. Gaat in principe niet direct om scherpte, die stel je in met focus. Een niet vlak beeld leidt tot vervormingen aan de randen van het beeld, meestal uitgestrekte sterren. Op de starparty had ik voor de eerste keer een systeem mee, niet getest (fout natuurlijk). Bij het berekenen van de benodigde tussenringen had ik een fout gemaakt. Mijn backfocus zat er flink naast. Wel een millimeter of 10. Hoeveel effect dat uiteindelijk heeft hangt van een aantal dingen af, maar beeldveld en f-ratio zijn wel de belangrijkste. Hoe korter de f/ratio, hoe gevoeliger voor afwijkingen. Bij f/2 systemen zie je mensen vaak fine-tunen tot op de 0.1mm nauwkeurig. Mijn systeem was f/6.2, dus gemiddeld, niet super-snel. Het vlakke beeldveld van de gebruikte flattener is 44mm, genoeg voor een full-frame sensor. Ik gebruikte maar een APS-C sensor en heb daarbij ook nog eens een redelijke crop toegepast. Dus mijn foto laat dus maar een klein stukje zien van wat de flattener projecteert. Maar geloof me, in de hoeken van het oorspronkelijke beeld was het echt waardeloos. Dat alles gezegd hebbende, viel het mij eerlijk gezegd ook mee dat met 10mm afwijking ik er toch nog zo'n redelijk vlakke foto uit heb weten te krijgen.
Astrovirus schreef: 26 jun 2023 12:33 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).
Als je clipping hebt van je histogram bij een belichte foto (RGB, Ha, of wat dan ook), dan ligt dit niet aan de offset. Er komt dan te weinig licht op je sensor. Verhogen van de offset is alleen een cosmetisch effect, het verkleint je dynamisch bereik en lost je onderliggende probleem niet op. Een juiste offset wordt bepaald middels je darks (dus onafhankelijk van filters). In een dark meet je de thermische en elektronische ruis van je sensor. Meestal een signaal van een paar honderd tot een paar duizend ADU. Maar dat signaal heeft een normaal-verdeling. En om een goed dark-signaal te krijgen wil je zeker weten dat je alle pixels in die normaal-verdeling meeneemt, en dat er niet pixels zijn die signaal 0 geven. Oftewel dat je darks geen clipping vertonen. Daarom voeg je die offset/pedestal waarde toe om de piek van de normaal-verdeling een beetje naar rechts te schuiven zodat ook het laatste staartje aan de linkerkant erop past.
Als jouw Ha filter clipping geeft aan de linkerkant bij instellingen die bij RGB wel goed werken, is je foto onderbelicht. Zoals je zelf al aangeeft belicht je langer en met hogere gain (versterking) met Ha omdat je maar een heel klein stukje van het spectrum meet. Maar als met een verhoging van de gain en een flink langere belichtingstijd toch nog geen redelijk signaal krijgt, is er wat anders aan de hand. De twee waar ik zo in eerste instantie aan denk zijn de volgende. 1. Mogelijk een probleem met het filter. Helaas zijn niet alle filters 'on bandpass' en is de daadwerkelijke golflengte die ze doorlaten net een paar nanometer anders dan op de doos staat. Voor hetzelfde type van hetzelfde merk kan de ene wel goed zijn de andere niet. Op de fora kom je regelmatig discussies hierover tegen en Cuiv de Lazy Geek (YouTube) heeft hier diverse videos aan gewijd, waarbij hij hele series filters gemeten heeft met een spectrometer. 2. Als je een hele snelle telescoop hebt (f/3 of f/2 of zo), treedt er verschuiving van de bandpass op. Dus dan zit je Ha-band niet op de plek waar hij normaal gesproken zit. Voor dat soort telescopen heb je speciale filters die een net iets andere bandpass hebben en zo corrigeren voor dit effect.
gerard van den braak schreef: 26 jun 2023 15:33 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.
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.
Zo had ik het nog niet bekeken, en op eerste gezicht lijkt dat een logische gedachte. Immers, maar 1 van de vier pixels levert signaal, dus je meet maar een deel van je onderwerp. Toch is dit volgens mij niet zo, want in het debayering process krijg je gewoon een rood-waarde voor elke pixel. Het is alleen een soort ingewikkeld gemiddelde van de omringende pixels, waarvan de anderen niet echt bijdragen. Het resultaat is dat het signaal dus lager is. Oftewel, OSC geeft per kleur minder signaal. Overigens kun je dat wel deels weer compenseren. Als je filters neemt met twee bandpasses (OIII en Ha), gebruik je wel veel meer van de data die je verzamelt. Het is nog steeds niet helemaal het niveau van mono, maar het verschil wordt wel een stuk kleiner. Het hangt dan een beetje van je onderwerp af of dit nut heeft. Als je wat Ha-gebieden in een galaxy wilt meten heb je er niet heel veel aan. Maar als je een nevel in narrow-band wilt fotograferen, wil je juist ook vaak die OIII hebben.

Han schreef: 26 jun 2023 16:54 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.
Kan dat software afhankelijk zijn? In mijn INDI setup kan ik van elke camera onafhankelijk de gain en de offset instellen.
Alleen de rode pixels extraheren, daar had ik nog niet eerder van gehoord. Bedoel je dan vòòr het debayeren? Ik wist niet eens dat dat kon, dan moet je software dus wel heel goed het raw formaat kennen. Dat zou wel interessant zijn om eens te proberen. Kun je iets meer zeggen over hoe je dat doet? Overigens klopt dan Gerard's opmerking over lagere resolutie dus wel degelijk.
Astrovirus schreef: 26 jun 2023 16:49 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.
Er is wel een relatie tussen gain en offset, maar dit hoeft geen praktische consequenties te hebben. Bij hogere gain is de normaal verdeling van je dark signaal vaak breder. Met andere woorden, om die linker uitloop van je curve boven de 0 te tillen moet je vaak de hele curve een beetje meer naar rechts schuiven. Dus een hogere offset toepassen. Ik heb ooit dit soort experimenten met een aantal van mijn cameras gedaan, omdat ik in de documentatie niet kon vinden wat de beste offset was voor elke gain. Het experimentje is simpel, je neemt darks met vast gain en oplopende offset en je meet gemiddelde en minimale signaal. Je krijgt dan een curve als onderstaand.
Offset assessment.png
Offset assessment.png (262.87 KiB) 1213 keer bekeken
Dit was voor de ASI533MM camera. Dezelfde test gedaan bij twee verschillende gain instellingen (0 en gain 100). Je ziet dat bij gain 100 de curve net iets later los komt. Maar het verschil is niet groot. Voor deze camera zou je dus een offset van 5 kunnen gebruiken, maar ik gebruik meestal offset 10, dan weet ik zeker dat ik goed zit, en kan ik het voor beide gains gelijk laten.
Wellicht ten overvloede, maar welke offset je ook kiest, je moet altijd zorgen dat je dezelfde gebruikt voor darks, flats en lights, anders gaan er gekke dingen gebeuren.

Het is een heel verhaal geworden...

Zoals gezegd, leuke discussie, en ik kijk uit naar aanvullende inzichten!

Gr. Willem Jan.

Han
Berichten: 302
Lid geworden op: 27 dec 2018 09:52

Re: Offset

#12 Bericht door Han » 30 jun 2023 19:40

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.
Omhoog
Als je de blauwe and groene pixels meeneemt tijdens het stacken dan heb je vier keer zoveel camera ruis dan nodig. Dat is zonde. De resolutie met bovenstaande methode is schijn. Het signaal van elke vier pixels komt slecht van een pixel. De scherpte bij roodkanaal extractie is gelijk aan bovenstaande methode maar wel ruisarmer.


Een hogere camera gain dan unity gain kan een theoretische verbetering geven van de camera uitleesruis. Deze is bij moderne camera verwaarloosbaar in vergelijking met de hemelruis.In een seconde heb je al meer ruis van de hemel dan uitleesruis Het grote nadeel van een hogere gain dan unity gain is dat de dynamiek van de camera weggaat. Deze is typisch 12 bit ofwel 4096 grijswaarden. Zet je de gain een factor twee te hoog dan zakt deze naar 2048 ofwel 11 bit grijswaarden. Sterren zijn twee keer snel volledig verzadigd en verliezen kleur. Een hogere gain dan unity gain heeft alleen maar zin bij belichtingstijden van een paar seconden maximaal.

Zet je de gain een factor twee te laag dan is de dynamiek ook gehalveerd en bovendien is de camera gevoeligheid met een factor twee gehalveerd. Twee electrons gedetecteerd geeft maar een ADU verschil. Bij pixel verzadigng van 4096 komen er maar 2048 ADU's uit. Dat is zonde.

Het beste kan je de camera gewoon op unity gain laten staan.


Han

Gebruikersavatar
Astrovirus
Berichten: 223
Lid geworden op: 10 mar 2020 22:15

Re: Offset

#13 Bericht door Astrovirus » 30 jun 2023 21:58

Even nog ter illustratie wat ik nu ongeveer zag bij mijn eerste Ha pogingen en deze camera.

Tot voorkort werkte ik altijd bij Gain 282 (= unity gain voor deze camera) en offset van 25 (advies vanaf andere gebruikers) bij RGB opnames. Onderstaande figuur laat 3 testopnames zien met Ha fileter bij Gain 282 en offset 25 en oplopende belichtingstijd van 300, 600 en 900s. Zoals je ziet komt het histogram niet volledig los (wat bij RGB wel gebeurde en al bij veel kortere belichtingstijden). Daarnaast lijkt het bij 300s uit een piek met hoge amplitude te bestaan, terwijl er bij 600 en 900s naast de geclipte piek met hoge amplitude ook een 2e lagere piek die zijn die langzaam naar rechts kruipt in het histogram.

De 4e belichting is een voorbeeld van hoe ik uiteindelijk al deze Ha opnames heb gemaakt, met Gain 282 en offset 150 en nu is zelfs bij een 180s belichting gewoon 1 mooi piek met hoge amplitude te zien, die ook niet meer geclipt word.
Ha offset 25 vs 150 Gain 282.png
Ha offset 25 vs 150 Gain 282.png (3.88 MiB) 1198 keer bekeken

Gebruikersavatar
Wjdrijfhout
Berichten: 573
Lid geworden op: 14 jan 2019 20:47
Contacteer:

Re: Offset

#14 Bericht door Wjdrijfhout » 01 jul 2023 08:57

Weet je zeker Tim dat je histogram is geclipt? Hoe ziet het eruit als je inzoomt? Een narrowband filter geeft maar heel weinig signaal, dus het histogram ligt altijd erg ver naar links. Maar als je dan inzoomt blijkt het toch vaak mee te vallen. Hierbij een voorbeeld van een Ha-opname met een ASI6200MM. Links zoals je het histogram normaal gesproken ziet, rechts zoals het er uitziet als je inzoomt.
Histograms.png
Histograms.png (43.54 KiB) 1195 keer bekeken

Gebruikersavatar
Wjdrijfhout
Berichten: 573
Lid geworden op: 14 jan 2019 20:47
Contacteer:

Re: Offset

#15 Bericht door Wjdrijfhout » 01 jul 2023 09:09

Han schreef: 30 jun 2023 19:40 Als je de blauwe and groene pixels meeneemt tijdens het stacken dan heb je vier keer zoveel camera ruis dan nodig. Dat is zonde. De resolutie met bovenstaande methode is schijn. Het signaal van elke vier pixels komt slecht van een pixel. De scherpte bij roodkanaal extractie is gelijk aan bovenstaande methode maar wel ruisarmer.
Hmm, dat is een interessante gedachte. Nooit zo over nagedacht eerlijk gezegd. Zal uiteindelijk van je debayering algoritme afhangen vermoed ik. Maar de moeite waard om eens uit te zoeken. Zo'n test is wel uit te voeren lijkt me. Stacken met debayered frames en stacken met rode pixel extracted frames. Resolutie naar elkaar toebrengen en resultaat vergelijken.
Weet jij hoe je zonder debayering alleen de rode pixels uit een OSC foto haalt?

Overigens zul je dan voor platesolving de pixelgrootte met twee moeten vermenigvuldigen vermoed ik? Want je hebt dan een soort gatenkaas genomen uit je beeldveld.

Gebruikersavatar
Astrovirus
Berichten: 223
Lid geworden op: 10 mar 2020 22:15

Re: Offset

#16 Bericht door Astrovirus » 01 jul 2023 10:11

Voor zover ik weet heeft NINA geen zoom functie op het histogram. Dit waren ook de eerste opnamen waarbij ik het histogram niet los kreeg aan de linker kant.

Over het extraheren van alleen de rode pixels ben ik ook wel benieuwd, want ik kan me niet herinneren dat ik daar ooit wel eens iets over ben tegengekomen op het internet.

Daarnaast vraag ik me dan ook af hoe dat dan werkt bij OSC opnames van bijvoorbeeld een waterstofnevel, die dus predominant rood is, en dus als je een kleurenopname maakt zonder Ha filter dus ook weinig signaal op de blauwe en groene pixels zal krijgen. Daar wordt volgens mij ook bij de debayering een gemiddelde genomen en zou je dan ook meer ruis uit G/B krijgen? Als dat zo is, zie ik geen enkel bezwaar tegen mijn werkwijze, te meer omdat het alternatief mij veels te omslagtig lijkt te zijn, als ik eerst alle losse frames het rood moet extraheren, dan kalibreren/stacken, met drizzle om de resolutie van de OSC weer terug te krijgen om bijvoorbeeld een HaRGB te krijgen.

Gebruikersavatar
Wjdrijfhout
Berichten: 573
Lid geworden op: 14 jan 2019 20:47
Contacteer:

Re: Offset

#17 Bericht door Wjdrijfhout » 01 jul 2023 14:29

Astrovirus schreef: 01 jul 2023 10:11 Voor zover ik weet heeft NINA geen zoom functie op het histogram. Dit waren ook de eerste opnamen waarbij ik het histogram niet los kreeg aan de linker kant.
Misschien kun je het in PixInsight nagaan. Het proces HistogramTransformation laat het histogram zien en daarin heb je veel controle over hoe ver je inzoomt.

Han
Berichten: 302
Lid geworden op: 27 dec 2018 09:52

Re: Offset

#18 Bericht door Han » 02 jul 2023 09:04

Zoals je ziet komt het histogram niet volledig los (wat bij RGB wel gebeurde en al bij veel kortere belichtingstijden). Daarnaast lijkt het bij 300s uit een piek met hoge amplitude te bestaan, terwijl er bij 600 en 900s naast de geclipte piek met hoge amplitude ook een 2e lagere piek die zijn die langzaam naar rechts kruipt in het histogram.
De getoonde histogrammen in je opnames lijken verkeerd. Probeer het eens in een ander programma te meten of in in de opname zelf. In ASTAP kan met de muis de x axis van het histogram meten
Hmm, dat is een interessante gedachte. Nooit zo over nagedacht eerlijk gezegd. Zal uiteindelijk van je debayering algoritme afhangen vermoed ik. Maar de moeite waard om eens uit te zoeken. Zo'n test is wel uit te voeren lijkt me.
Daarnaast vraag ik me dan ook af hoe dat dan werkt bij OSC opnames van bijvoorbeeld een waterstofnevel, die dus predominant rood is, en dus als je een kleurenopname maakt zonder Ha filter dus ook weinig signaal op de blauwe en groene pixels zal krijgen. Daar wordt volgens mij ook bij de debayering een gemiddelde genomen en zou je dan ook meer ruis uit G/B krijgen? Als dat zo is, zie ik geen enkel bezwaar tegen mijn werkwijze, te meer omdat het alternatief mij veels te omslagtig lijkt te zijn, als ik eerst alle losse frames het rood moet extraheren, dan kalibreren/stacken, met drizzle om de resolutie van de OSC weer terug te krijgen om bijvoorbeeld een HaRGB te krijgen.
Omhoog
Het is meetbaat maar je krijgt vier keer zoveel cameraruis omdat je vier pixels combineerd terwijl maar een nodig is. De ruis wordt belangrijk omdat je in H-alpha bijzonder weinig hemelruis oppikt doordat het filter smallbandig is. Ik weet niet hoe het in PI gaat maar in ASTAP gaat het extraheren met een paar klikken. Het kan in het ASTAP batch menu maar het gemakkelijkste in gebruik is de photometrie tab:

1) calibratie selected files
2) rood kanaal extractie
Dan de opnames laden in de gewone lights tab voor sigma clip average stacken.
Untitled.png
Untitled.png (34.55 KiB) 1185 keer bekeken


De reden dat het in the photometrie tab is ingebouwd omdat het groen kanaal gevoeligheid ongeveer overeen komt met een Johnson-V filter en veel gebruikt wordt voor DSLR photometrie.
Overigens zul je dan voor platesolving de pixelgrootte met twee moeten vermenigvuldigen vermoed ik? Want je hebt dan een soort gatenkaas genomen uit je beeldveld.
Bij de roodkanaal extractie van de raw wordt de opname een mooie grijstinten opname. Het enigste wat wat er gebeurd is dat de hoogte en breedte van de opname halveren. Voor de solver maakt het niet uit want het blikveld in graden blijft hetzelfde.



Han

Plaats reactie