- This topic has 22 replies, 8 voices, and was last updated 6 years ago by
.
-
Posts
-
Met dezelfde methodiek als gebruikt voor het “Cygnus 70 paneel mozaiek” ben ik nu bezig met het 72 (9×8) paneel mozaiek van Orion met een weergave van 21 bij 15 graden . Voor elk paneel ga ik tenminste 6 Ha subs van 600 seconden gebruiken en op dit moment is er data binnen van 40 panelen. Bijgaande opname geeft een indruk van 12 panelen uit het centrum, de volgorde van opnamen is zodanig dat eerst de stroken rond Betelgeuze en Bellatrix worden verzameld en als laatste rond Rigel en Saiph om zo alles tussen 30 en 50 graden boven de horizon op te kunnen nemen. gestart is op 12 september met 2 uur per nacht, inmiddels kan ik 3.5 uur per nacht toevoegen. Het is een heel leuk project om aan te werken en met wat puzzelen met de APP instellingen zit ik nu op een RMS registratienauwkeurigheid van 0.05 pixels voor deze 12 panelen. Ik heb ook panelen opgenomen over de 2 diagonalen totaal, maar daar verslikt APP zich nog in met registreren dus eerst zorgen voor mooiere rechthoekige secties….
Het wordt geen bijzonder moeilijk plaatje, het is alleen een boel werk. Ik heb een grote lege plek aan de muur naast dat Zwaan mozaiek, dat is de beloning straks ;-)
;-) ik zie dit nu pas ! Super
Kan je precieser aangeven waar APP zich verslikt met die diagonale panelen waaraan je refereert? eventueel per email?
Mabuka
ik zie dit nu pas ! Super Kan je precieser aangeven waar APP zich verslikt met die diagonale panelen waaraan je refereert?
@bula Zie bijgaande tussenstand van het mozaiekschema. Wanneer ik de middensectie neem (p32-p54), de rechter 3 rijen en ook linksonder p 68,69,59,60 dan gebeuren er rare dingen met registratie terwijl er voldoende overlap is. De console schermprint laat dat b.v. zien tussen iteratie 51 en 52 waar de RMS van 138 naar 8662 pixels springt.
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.
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.
De registratie van deze 30 panelen ( 6×600 sec per paneel) gaat prima (RMS: 0.05 pixel). Deze weergave is op 12.5% schaal zonder MBB en LNC om de paneel aansluitingen goed te kunnen zien. Er komt nog 1 rij links hiervan en 2 rijen onderaan. (en dan de open plekken invullen….) De halo verschijnselen rond Betelgeuze zijn het gevolg van diffractie/refecties tussen de microlensjes boven de pixels en het glas boven de sensor (Hier een discussie over dit verschijnsel op Cloudy Nights) . Een deel van Barnards loop is al te zien met zelfs de Boogie man.
Wow … absoluut wow … hier zal overigens wel geen kleurenversie van verschijnen (gezien de enorme hoeveelheid tijd en benodigde rekenkracht?)
Wow … absoluut wow … hier zal overigens wel geen kleurenversie van verschijnen (gezien de enorme hoeveelheid tijd en benodigde rekenkracht?)
Mooie vondst Marc! (Hoeveeltijd). De kleuren HaRGB versie zal verschijnen in (R: 2018, G:2019, B:2020) 2020 !
Status update: voor 59 panelen is alle data binnen, dus nog maar 13 te gaan. Dat is nog 13 uur (= 3nachten). Sinds de start op 12 september zijn er 29 heldere nachten geweest en het blijft de komende tijd helder. Maar ik ben er nog niet uit hoe het komende nacht zal gaan met de overgang naar wintertijd tijdens de automatische sessie. (De tijd is afkomstig van GPS) Toelichting op het schema: Het getal rechts van een paneelnummer geeft het aantal subs aan dat gemaakt is en een “S” links daarvan geeft aan dat er een stack is gemaakt.
- You must be logged in to reply to this topic.