Seestar S50 FITS-bestanden bewerken: wat de app niet voor je doet

De ZWO Seestar S50 verkoopt zichzelf met een belofte die hij echt waarmaakt: richt hem vanaf je telefoon op een object, wacht, en je hebt een foto. Voor veel mensen is dat de hele hobby, en er is niets mis mee om daar te stoppen.

Maar de Seestar bewaart stilletjes iets beters dan de JPEG die hij je laat zien. Als je Elk frame opslaan aanzet in de instellingen, schrijft hij elke sub-belichting van 10 seconden als FITS-bestand naar de opslag. Die bestanden bevatten meetbaar meer dan de live stack, en het verschil is groter dan de meeste mensen verwachten.

Dit gaat over wat er werkelijk in zit, en wat je ermee doet.

Wat de live stack opgeeft

Het stacken op het apparaat moet in realtime draaien op een kleine ARM-processor terwijl die ook de montering aanstuurt, en dat beperkt het op drie concrete manieren.

Het kan frames niet achteraf afkeuren. De live stack integreert terwijl hij bezig is. Als er op minuut 40 van een sessie van 90 minuten een wolk voorbijtrekt, zitten die frames al in het gemiddelde. Een desktopprogramma kan eerst alle 540 frames bekijken, beoordelen en de slechte weggooien voordat het iets combineert.

Zijn afkeuring is beperkt. Satellietsporen, vliegtuigen en kosmische straling hebben statistische uitschieterafkeuring over de hele stack nodig, en daarvoor moet je de hele stack hebben. Realtime-integratie kan maar zoveel doen.

Het strekt één keer, en vroeg. Het live-beeld is al voor weergave bewerkt - het histogram is al samengedrukt om er goed uit te zien op een telefoon. Zodra dat gebeurt, is het zwakke uiteinde platgedrukt en krijg je het niet terug. De FITS-subs zijn lineair: het volledige dynamische bereik van hemelachtergrond tot nevelkern is nog intact en nog scheidbaar.

Het praktische resultaat: bij dezelfde data laat een goede stack van de subs doorgaans zwakkere buitenste nevels, schonere sterkleuren en een merkbaar betere ruisvloer zien dan de live JPEG. Geen andere foto - dezelfde foto, verder gebracht.

De bestanden eraf halen

Ga in de Seestar-app naar het tandwiel en zet Elk frame opslaan aan voordat je begint met fotograferen. Het staat standaard uit en kan niet achteraf worden toegepast.

De bestanden komen terecht in MyWorks op het apparaat, geordend per object, met namen als:

Light_M42_10.0s_IRCUT_20260304-213512.fit

Alles wat je nodig hebt staat in die naam: het object, de belichting, het filter en de tijdstempel. Haal de map over wifi of via USB op. Een sessie van 90 minuten op 10 seconden is zo’n 540 bestanden en ruwweg 10 GB, dus geef het de tijd.

Je ziet daar ook een Stacked_*.fit. Dat is het resultaat van het apparaat zelf. Bewaar het ter vergelijking, maar stop het niet in een stack van subs - het is al een gemiddelde, en het middelen met losse frames geeft het een verkeerd gewicht.

Wat er in de headers staat, en wat ontbreekt

Hier hebben Seestar-bestanden één eigenaardigheid die je moet kennen.

De headers bevatten de nuttige basis: EXPTIME, GAIN, INSTRUME met de naam Seestar, het filter, de datum en - belangrijk - RA en DEC, omdat het apparaat via plate solving het object heeft gevonden. Die richtinformatie is echt waardevol; het is wat later fotometrische kleurkalibratie en annotatie mogelijk maakt.

Wat ze niet betrouwbaar bevatten, is brandpuntsafstand en pixelgrootte. En dat is een probleem, want plate solving heeft een pixelschaal nodig, en een pixelschaal heeft beide getallen nodig.

De oplossing is dat een Seestar een gesloten instrument is. Hij heeft één optiek en één sensor, en je kunt geen van beide vervangen. De modelnaam is dus de specificatie:

	Seestar S50	Seestar S30
Brandpuntsafstand	250 mm	150 mm
Opening	50 mm	30 mm
Pixelgrootte	2,9 µm	2,9 µm
Sensor	Sony IMX462	Sony IMX662
Pixelschaal	≈ 2,39 ″/px	≈ 3,99 ″/px

Seestar S50 herkennen in het INSTRUME-veld levert beide ontbrekende getallen op, en de schaal volgt daaruit. Akastroid doet dit automatisch - het vult alleen velden in die de header leeg heeft gelaten, en overschrijft nooit wat het bestand daadwerkelijk heeft vastgelegd, vanuit het principe dat het instrument zijn eigen configuratie beter kent dan een opzoektabel.

Dat cijfer van 2,39 ″/px zegt je ook iets nuttigs over je data: op die schaal, bij gemiddelde seeing, is de Seestar licht onderbemonsterd. Sterren vallen op heel weinig pixels. Dat is van belang voor wat je later wel en niet kunt terughalen.

De debayer-valkuil

Seestar-FITS-bestanden zijn ruwe Bayer-data - een kleurfiltermozaïek, geen kleurenbeeld. Het mozaïek is GRBG.

Twee manieren waarop dit misgaat. Debayer met het verkeerde patroon en de kleuren komen verwisseld eruit, meestal met een sterke magenta- of groenzweem die geen witbalans verhelpt. Debayer twee keer - één keer door een tussenprogramma, één keer door je stacker - en je krijgt een zachte, geblokte brij.

Het gestackte bestand dat de Seestar maakt is al gedebayerd. De subs niet. Elk programma dat ze hetzelfde behandelt, doet er één verkeerd.

Korte subs stacken

Tien seconden is kort, en dat bepaalt de juiste aanpak.

Reken op veel frames. 500-1.000 is normaal voor een behoorlijke sessie. Dat is goed - het is wat agressieve uitschieterafkeuring veilig maakt.

Gebruik afkeuring die bij het aantal past. Bij een diepe stack kun je je sigma clipping veroorloven, dat aanneemt dat elk frame dezelfde verdeling bemonstert en weggooit wat ver van het gemiddelde ligt. Maar die aanname breekt als de transparantie tijdens de sessie is verlopen - hoge bewolking, het object dat naar de horizon zakt, dauw die zich vormt. Dan verschillen de frames echt, is de spreiding werkelijk en geen ruis, en begint sigma clipping frames aan de uiteinden van het bereik weg te gooien, die vaak de helderste zijn die je hebt.

Linear-fit clipping behandelt dat geval goed: het sorteert de waarden van elke pixel over de stack en past er een lijn doorheen, zodat een geleidelijke drift verwacht is en niets kost, terwijl een satellietspoor nog steeds opvalt als één waarde ver van de lijn. Akastroid meet de spreiding van de hemelniveaus per frame en kiest automatisch tussen de twee - boven ongeveer 8 % drift schakelt het om.

Verwacht niet veel van drizzle. Drizzle haalt subpixel-detail uit geditherde frames. De azimutale montering van de Seestar geeft veldrotatie, wat wel enige subpixel-variatie oplevert, maar het is geen bewuste dithering. Controleer of je set die subpixel-spreiding werkelijk heeft voordat je het inschakelt - reconstrueren op een fijner raster uit niet-geditherde frames geeft je alleen een groter, zachter bestand.

Veldrotatie is de echte beperking

De Seestar is een azimutale montering zonder veldderotator. In een uur draait het veld. Frames die 40 minuten uit elkaar zijn genomen, zijn ten opzichte van elkaar gedraaid, soms tientallen graden.

Elke stacker die je gebruikt moet rotatie aankunnen, niet alleen verschuiving. Uitlijning met alleen verschuiving faalt op Seestar-data, en faalt op een manier die lijkt op slechte scherpstelling in plaats van een duidelijke fout - alles komt er licht uitgesmeerd uit en niemand kan zeggen waarom.

Rotatie betekent ook dat de hoeken van je uiteindelijke stack door minder frames worden gedekt dan het midden. Het overlapgebied krimpt naarmate rotatie zich opstapelt. Reken op bijsnijden, en reken erop dat de buitenrand ruiziger is dan het midden. Dit is geen fout in je bewerking; het is meetkunde.

De limiet van 10 seconden, eerlijk

De Seestar begrenst belichtingen op 10 seconden om een reden - hij is niet gegidst, en langere subs zouden strepen trekken.

Het gevolg is uitleesruis. Elke belichting voegt een vaste ruisstraf toe door het uitlezen van de sensor, en een stack van 540 frames van tien seconden draagt er 540 porties van. Dezelfde 90 minuten in 18 subs van vijf minuten zouden er 18 dragen. Daarom loopt een gevolgde, gegidste opstelling uit op zwakke objecten, zelfs bij identieke totale integratie.

Wat dat praktisch betekent: de Seestar is uitstekend op heldere en middelheldere objecten - Orion, de Lagunenevel, de kern van Andromeda, het grootste deel van de Messier-lijst. Zeer zwakke, uitgestrekte nevels zijn waar de uitleesruisvloer zichtbaar wordt, en geen enkele bewerking verzint signaal dat er nooit bovenuit kwam.

Dat weten is meer waard dan welke bewerkingstip ook. Het vertelt je welke objecten nog twee uur belonen en welke niet.

Wat je werkelijk moet doen

1. Zet Elk frame opslaan aan vóór de sessie, niet erna.
2. Haal de hele objectmap op. Zet de Stacked_*.fit van het apparaat apart ter vergelijking.
3. Laat de stacker de FITS-headers lezen in plaats van het patroon met de hand op te geven - GRBG, en niet twee keer debayeren.
4. Gebruik een afkeurmethode die past bij of je transparantie stabiel bleef.
5. Snijd de door rotatie uitgedunde randen bij.
6. Vergelijk met de eigen stack van het apparaat. Als de jouwe in de zwakke gebieden niet duidelijk beter is, maakt iets in je workflow het voordeel ongedaan.

Die laatste stap is degene die mensen overslaan, en het is de enige die je vertelt of de extra moeite iets heeft opgeleverd.