@keesscherer
active 4 weeks, 1 day agoForum Replies Created
-
Posts
-
Helemaal met je eens. Toen ik 6 jaar geleden begon schoot ik echt ik weet niet hoe veel opnamen. Soms had je na een weekje een soort van slaapgebrek. De laatste 1,5 jaar kan ik me zo’n periode niet meer herinneren. Schijnt dat El Nino hiervoor ook niet mee werkt
Eeh, heel herkenbaar. Maar dan in mijn huidige situatie, ik heb slaapgebrek door de aanhoudende heldere nachten hier in Portugal, ga nu van 12nm Ha met de Esprit 100 naar 6nm Ha met 200 mm telelens om weer eens wat anders te doen…..
Heb zelf ook ooit een mozaiek van de zwaan gemaakt van 42 opnamen.
Ja die opname ken ik Andre, met de 100mm lens genomen, vooral de sterloze versie is prachtig. Ik wilde een hogere resolutie versie hebben, en dan het mooiste stuk.
Wat ging er precies minder door gebruik te maken van GoTo ipv coordinaten?
Sorry, staat er niet duidelijk genoeg. In beide gevallen is goto gebruikt, maar wanneer ik dan de SAO stercatalogus wil gebruiken dan loop ik tegen de beperkingen aan, niet elke ster met een “HIP” nummer in Stellarium heeft een SAO nummer in de Synscan handset van Skywatcher. Dus dan kies je de dichtsbijzijnde en dat is minder nauwkeurig dan het invoeren van coordinaten in de Synscan.
Hier nog een screenprint van de “geboorte” van het mozaiek, bij de eerste 2 panelen (rechts)heb ik de Goto naar een uitgezochte ster laten bewegen, bij het uitrichten van de laatste 2 panelen heb ik coordinaten gebruikt en dat ging al een stuk beter. Daarnaast is de rotatie te zien tussen juni en juli. Het is leerzaam om deze dingen eerst een paar keer zelf “met de hand” te doen en dan pas gebruik te gaan maken van de Frame and Mosaic wizard van Sequence Generator Pro (Ik heb SGP met die optie ook op de harde schijf staan) . Ik vraag mij nu b.v. af hoe SGP omgaat met de rotatie bij opnamen met een maand ertussen. (Dat zou weleens een probleem kunnen zijn bij onvoldoende overlap en een DSLR)
Het maakt bij de GradientMergeMosaic uit of je ABCD of DCBA als volgorde gebruikt, vooral bij de “Overlay” methode. In dit geval koos ik uiteindelijk voor DCBA en de “average” methode.
Overigens, kunnen tags onderling gescheiden worden met komma’s …
En op Flickr juist weer met spaties. ( helptekstje erbij ?)
Supergaaf! Interessante oplossing ook wat dimensies betreft, heb je dan die 2 panelen echt een beetje moeten stretchen? Kan me voorstellen dat dat minder is voor je sterbeeld..
Ja, dit was een heel project tot nu toe. Gelukkig geleidelijk op kunnen bouwen (want telkens 1 paneel erbij) want het “mozaieken” is een heel gedoe. De afmetingen heb ik maar heel weinig hoeven aan te passen want 1 en 2 pixels op 9300 en 5900 pixels is niet heel veel, maar op 1 pixel verschil stopt de mozaiek funktie er mee.
De totaalstack valt dan ook een beetje tegen. Maar M16 met de “Hubble” Pillars of creation komt mooi uit de verf. Dit is dan ook een kleine crop uit het totaalbeeld.
Heb je al eens gestacked met het BatchPreProcessing script (en vergeleken met de resultaten van DSS)? Ik ben erg geinteresseerd in een vergelijk.
Nee nog niet, maar ik ga dat doen zodra ik door mijn huidige lopende projectjes heen ben. Komt goed, ik ben ook benieuwd.
Dit is het resultaat van PIP met 2.1 en 0.0 als settings.
Dit is alles wat je gedaan hebt t.o.v. het eerste image? Ik vind dit een enorm verschil (positief!) en ik kan niet echt negatieve effecten van de bewerking ontdekken (door pixelpeeping).
Ja, dit is alles, vandaar “lieve help”. Uren druk geweest en net dat laatste beetje helderheid er niet goed in weten te krijgen en hopla, 1 druk op de knop met ET en de frisse kleuren springen je tegemoet.
Heb je hier dan alleen ET gebeld of toch ook de andere contrast tools erin meegenomen?
Van de exotische contrasttools die ik tot nu toe gebruik (ET, LHE en HDRM) alleen ET toegepast.
Het duizelt me zo langzamerhand wel van de contrast-tools in PixInsight, is dit niet weer iets wat LHE zou moeten kunnen ook? Dat ging erom om vlakke histogram gedeeltes wat meer uit elkaar te trekken, iets wat je ook hier zou verwachten. .
Klopt, maar het merkwaardige is dat elke opname weer anders zal reageren op de verschillende tools en de parameters. Bij deze opname hebben zowel LHE als HDRMultiscale geen enkel zichtbaar effect, en tot mijn verrassing werkte ET (Leuk, die afkorting) juist wel erg goed.
Lieve help, ik kwam een beschrijving tegen van de ExponentialTransormation funktie (PI). (The goal of ExponentialTransformation is to increase the contrast in the shadows, avoiding noise amplification and preserving the information in the highlights at the same time. )
Dit is het resultaat van PIP met 2.1 en 0.0 als settings.
Wat ik interessant vindt te weten bij dit object is hoe je de achtegrond hebt bewerkt, want ik neem aan dat enige ruisreductie oid de nevel doet verdwijnen?
Ja het is een sport om objecten te vinden die zelden op de foto worden gezet. Dat zijn dan ook meestal ook hele lastige onderwerpen, maar dat maakt het alleen maar uitdagender. Voor de lol zie bijgaand de RGB opname, nu je weet waar de nevel te vinden is kan je hem met moeite terug vinden (en hier is zelfs sterreductie op toegepast) . De achtergrond is niet bewerkt, geen ruisreductie toegepast.
Zo, die Aerith.net site heeft weer een hoog Geocities gehalte zeg! Maar het gaat tenslotte om de informatie. Zelf gebruik ik The Sky Live.
Goed om een kometenhoekje te hebben op Starry-night!
Pixelmath: Het hoeft niet altijd ingewikkeld te zijn, in dit NGC6914 voorbeeld gebruik ik Pixelmath om data uit 2015 (69x120sec ISO1600) samen te voegen met 2016 (40x 240 sec iso1600) data. De stacks werden herbenoemd tot _15 en _16 en met de vergelijking : (_15+_16)/2 wordt een gemiddelde stack gegenereerd. (Een betere vergelijking is welicht 0.5*_15+0.5*_16 ) Aan de stacks is dan ook heel simpel een andere weegfactor toe te kennen zoals (_15 +_16 *2)/3 waarbij de 2016 stack 2 maal zoveel invloed krijgt als de 2015 stack.
Een goede basis uitleg is te vinden in deze PDF
Een zoekopdracht bij “Pixinsight resources” met Pixelmath laat meer voorbeelden zien.
Wie hebben er leuke pixelmath vergelijkingen die voor anderen handig zijn?
Ik heb het gebruikt voor opnamen met Canon 5Dmk2 en dat ging goed. Je moet de orientatie van de te “behandelen” opname wel eerst precies goed hebben voor het beste resultaat. Naast een relatie met de sensor is banding dacht ik ook afhankelijk van pooluitlijning (het steeds opschuiven in 1 richting dat in de stack zichtbaar wordt)