@bula
active 4 years, 5 months agoForum Replies Created
-
Posts
-
Hoi Mabula, Dank voor je leuke reactie! Je bent van harte welkom, laat maar weten wanneer je zin en tijd hebt. Groet, Marc
@mth75, heb je een pm gestuurd om wat af te spreken ;-)Mabula
Beste Marc,
Hartelijk dank voor al je werk, inzet en je ontwikkeling aan en van Starry Night.
Ik vind het jammer om te horen dat je liefde voor astronomie nu iets is bekoeld, maar ik hoop dat je na een periode van afstand mogelijk weer de liefde kan en zal terugvinden :-)
Mijn dank aan jou is nog steeds groot voor het faciliteren van ruimte op Starry Night voor de Astro Pixel Processor Beta fase. Het heeft mij aanvankelijk goed geholpen om Astro Pixel Processor in de markt te zetten.
Ik zou graag nog een keer bij je langs komen na al deze jaren als je dat leuk vindt? Ik herinner me onze eerste ontmoeting nog goed bij jou thuis toen ik hard werkte aan mijn revalidatie vanwege mijn ziekte die gelukkig nu helemaal is uitgedoofd.
Ik heb er alle vertrouwen in dat Starry Night in zeer goede handen zal zijn van Rob en Nicolàs :-) en wens hun dan ook veel plezier en succes met dit !
Groet,
Mabula
Om de ruis beter te tonen zijn hier 3 ingezoomde screenshots uit APP, eerste is niet-gecalibreerd, 2de alleen gecalibreerd met een Bad Pixel Map, de derde volledig gecalirbeerd (MD, MF, BPM).
Dit toont extreem goed dat een BPM heel veel kleinschalige ruis er al meteen uithaalt bij deze cmos camera’s bij gebruik van narrowband filters. Er is geen enkele reden om niet een BPM te gebruiken ;-) en het verbetert je resultaten snel, sterk en makkelijk.
Even een visueel voorbeeld met mijn asi1600mm-c:
H-alpha exposure van 900 sec = 15min met een 3nm Astrodon H-a filter, Takahashi TSA102 @ F/5.6, M101
Uncalibrated opname, zoom in en wees verbaasd over de ruis en het aantal niet-lineaire (hot) pixels ! Juist met een smalband opname filter zie dit extreem goed. Ook de asi 1600mm-c heeft amp-glow…
Beste Hans,
Als dit enkel H-alpha data is geschoten met de OSC camera, dan heeft Kees een goed punt, groen en blauw is niks waard en toont daarom veel ruis ;-) Veel beter om je data te verwerken met het H-alpha debayer algortihme ( 0) RAW/FITS) ) dat levert je meteen de monochrome H-alpha data op zonder resolutie verlies en zonder injectie van de ruis uit de groene en blauwe kanalen.
Daarnaast, 19 frames x 2min is op zich niet zoveel, zeker niet voor H-alpha data. De vraag is echter wat voor een MasterDark je hebt gemaakt. Een correct gemaakte MasterDark moet de Amp-Glow er volledig uithalen bij de ASI294MC Pro. Er kunnen mijns inziens 3 problemen zijn
- de darks zijn niet gemaakt op dezelfde temperatuur, dan wel belichtingstijd dan wel gain, dan wel offset als de lights. Al deze 4 parameters moeten voor de darks hetzelfde zijn als voor je lights bij deze cmos camera’s om de amp-glow weg te krijgen. Dat komt omdat de amp-glow niet-linear gedrag heeft.
- Omdat je H-alpha hebt met een belichtingstijd van slechts 2 minuten is de kans heel groot dat de data niet afdoende belicht is. Na aftrek van de dark krijg je dan serieus clipping van het histogram op zwart/de linkerkant. Dit kan je oplossen met de Adpative Pedestal functie in 2) calibrate.
- Je hebt een masterdark gemaakt van slechts enkele darks, dat injecteert dan zichtbaar ruis.
Je probleem kan door deze 3 factoren allemaal worden bepaald in meer of mindere mate. Daarnaast raad ik je sterk aan om zeker gebruik te maken van APP’s Bad Pixel Map functie om in ieder geval alle niet-lineaire pixels (hot/cold) beter te corrigeren. Darks zijn niet heel geschikt daarvoor want de niet-lineaire pixels laten zich niet goed weg calibreren door subtractie van een masterdark. Een camera zoals de ASI294MC Pro heeft veel ! niet-lineaire pixels (dat is heel normaal voor deze cmos camera’s, mijn asi1600 heeft er ook veel) , dus een Bad Pixel Map alleen maakt de data al veel beter ;-)
Mabula
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
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 ;-).
” 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
Hoi Rutger,
Je bedoelt denk ik background calibration… ;-) ?
Backkground neutralization is een histogram operatie die nooit goede resultaten geeft als er veel neveligheid is ;-) Background neutralization is enkel een manier om beter te zien wat er in de data zit, maar af te raden om te gebruiken om de achtergrond echt goed te krijgen. APP past Background neutralization standaard toe in het normalisatie proces 5)normalize om je te helpen om een betere indruk te krijgen van wat er in je data zit. Maar om het goed te doen, moet je altijd Background calibration uitvoeren.
Background Calibration werkt met het plaatsen van area select boxes waardoor het histogram niet gebruikt hoeft te worden. Op die manier vertel je waar de hemel achtergrond is.
Background Neutralization and Background Calibration zijn dus verschillende zaken.
Het beste gebruik je de Remove Light Pollution tool, die voert background calibration ook uit. Een uitgebreide tutorial is hier:
Bij heel veel neveligheid werkt dit ook, het correctie model is stijf waardoor je ermee weg komt als je sommige area select boxes niet goed plaatst ;-)
Mabula
p.s. APP 1.072 met Sony ARW support is denk ik vanavond te downloaden ;-) !
Prima Kees, Ik heb in mijn prioriteiten genoteerd dat het correctie model voor “remove light pollution” en ook “correct vignetting” opgevraagd moet kunnen worden middels een vinkje ;-)
Ik zal dan de optie bieden dat je het model kan bekijken voordat je de correctie toepast.
Mabula
Ik heb de minimum area select box in APP gezet op 16×16 pixels, ik kan het wel verlagen in de komende release, sta op het punt om hem uit te brengen.
Moet er wel bijzeggen dat ik data vol met nebulosity probleemloos gecorrigeerd krijg in APP. Te kleine boxjes is juist een probleem eerder. Je wilt genoeg data voor een goede statistiek. 16×16=256 is veel robuuster dan 4×4=16 pixel. De pixels uit die boxjes ondervinden iteratief outlier rejectie (daarom mag er ook gewoon een ster in een box aanwezig zijn) en met meer pixels krijg je een vele betere achtergrond waarde schatting.
Om te corrigeren moet er altijd een model gemaakt worden. Dus dat model is aanwezig, mijn vraag is: wat is het nut om dat model te bekijken. Gebruik je het ergens voor? Of wil je dat zien om te vergelijken met een ander model, zodat je ziet waar de verschillen zitten? (De gecorrigeerde opname zegt in mijn ogen voldoende namelijk).
Ik kan zeker wel opschrijven dat je met een vinkje ook het model zels als output krijgt, is dat een idee?
Een voorbeeld, m42 H-alpha data met een Nikon D600 mono (courtesy of @yves Yves van den Broek) vol met neveligheid, geen probleem. Er zit zelfs een sensor probleem in de data die je er met APP dus uit krijgt bij dit soort data (zie rechter donker kolom):
Plaatje voor en na correctie:
Hmm, ik zie bij de setups alleen Astronomic filtersets, geen Astrodon… dat is zeker opvallend te noemen denk ik.
Per project inderdaad een beperkt aantal gebruikers, dat is denk ik goed. Sommige 25, anderen maar 15.
Heel interessant hoor ;-).
Heeft enorme voordelen, zoals veel en goede data als het goed is ;-)
Maar ook wel wat nadelen..
Je wordt dan wel een data processor, je bent natuurlijk geen fotograaf meer op deze manier. Dat is denk ik ook het idee hiervan, de moeilijkheid van data vergaren wordt hiermee eruit gehaald door ervaren experts die dit goed onder controle hebben met hun software en scripts.
Bij veel deelnemers heb je denk ik zeer weinig controle over het te fotograferen object, integratie tijd, spreiding over filters etc.. ,maar je krijgt wel heel veel objecten binnen op goede kwaliteit natuurlijk. Je kan binnen een paar jaar een enorm archief opbouwen met data, waar je voorlopig zoet mee bent…
Ik vind het persoonlijk gezegd wel aan de prijs als je meeneemt dat je geen aandeel hebt in de apparatuur, dus die 1000-2500 euro per jaar ben je sowieso kwijt. Als je zelf apparatuur koopt blijft dat veel geld waard met name de montering en de optiek, dat wordt niet meegenomen op het kosten plaatje op de site, dus dat geeft wel een scheef beeld denk ik… Als je deze apparatuur koopt doe je daar normaal gesproken vele jaren mee (5-10 jaar).
Maar al met al is het wel fair denk ik, de meerwaarde van dit zit echt in veel en goede data, die ja vanuit Nederland nooit kan binnenharken vermoed ik…
Ik lees wel dat je als lid loyalty bonusen kan krijgen, maar wat dat inhoudt?
Is deze site pas net in de lucht dat je weet @KeesScherer?
Ik vind GUS wel interessant om mee te doen… voor mij als APP ontwikkelaar eigenlijk prachtig om veel mooie data om allerlei zaken te testen binnen te kijgen. Ik gebruik mijn eigen apparatuur echt nauwelijks door de prioriteit van APP’s ontwikkeling.
En @KeesScherer,
Door de WISE data wordt ik nu ook gedwongen bijna om de LNC module te herschrijven (lees up te graden). De WISE data heeft voor het mosaicen echt maar 5% overlap ofzo en de data normalisatie wordt nu heel lastig…. de LNC module corrigeert alleen de hemelachtergrond lokaal, het veranderd niks aan de spreiding/dispersie van de data lokaal. De WISE data toont dat we dat ook moeten gaan doen, want daar zit veel kwaliteit verschil in per mosaic paneel… Bovendien moet de LNC veel zwaarder gaan wegen op de gebieden van overlap. Met maar 5-10% overlap werkt het eigenlijk niet voldoende.
Hoi @KeesScherer,
Hartelijk dank, ik ben dit nu op het spoor.
Als 1 of meerdere frames niet een registratie pad kunnen vinden naar de referentie frame, omdat APP geen overlap ergens vind, dan kan dit probleem ontstaan. En vanwege een onvolkomenheid in de mosaic formulering krijg je dan dit rare gedrag. Ik zag dit zelf afgelopen dagen ook door het falen van een mosaic van WISE data die ik van Judy Schmidt heb ontvangen. Dat is hoge kwaliteit infrarood data en APP had moeite om genoeg sterren te vinden en dus kon er een paneel niet geregistreerd worden met dit probleem als gevolg.
De onvolkomenheid is nu opgelost en APP kan nu in hoge kwaliteit data meer en beter sterren vinden. Dat zou jouw mosaic hier ook moeten helpen. APP vond eerst in een bepaald WISE paneel maar 500 sterren, dat zijn er nu 2500. En bij visuele inspectie van de starmap tov de data zie ik ook dat APP nu vrijwel alle sterren die er zijn kan detecteren zonder ze te mixen met signalen van nevels en dergelijk ;-) Dus dat is weer een grote verbetering die dit soort werk robuuster zal maken in APP.
