- This topic has 66 replies, 10 voices, and was last updated 6 years, 6 months ago by
.
-
Posts
-
Het PixInsight topic (sticky). Een plek om tips and tricks met en over PI te bespreken.
https://www.starry-night.nl/pixinsight-gids/
LocalHistogramEqualisation, Een prachtige Pixinsight wondertool waarmee kleine helderheidsverschillen meer contrast krijgen. Deze bewerking kan als (bijna) laatste bewerking toegepast worden en met wat previewtests is vooral bij nevelstructuren veel detailweergave te winnen. Zie bijgaand “Lagoon” voorbeeld (waarbij eerst al de HDRMultiscaleTransform was toegepast!). Na deze bewerking met curves weer wat corrigeren.
Heel interessant, maar dit is precies de reden waarom ik HDRMultiscaleTransform gebruik, om meer detail te krijgen in de heldere gebieden. Wat is dan het verschil met LocalHistogramEqualisation?
Ik dacht dat ik dat duidelijk gemaakt had met :”(waarbij eerst al de HDRMultiscaleTransform was toegepast!).” Het werkt additioneel, haalt nog meer naar voren dan met HDRM mogelijk is, hier nog een voorbeeld, nu met M42 waarbij vooral kleine “Cirrusachtige” structuren beter zichbaar worden:
Hier wat achtergrond-info: LHE Als ik het goed lees haalt het dus het contrast omhoog in die gebieden welke een behoorlijk vlak verloop laten zien in het histogram. Verschil met HDRMultiScaleTransformation lijkt dan te zijn dat deze eerste meer lokaal toegepast wordt (zoals de naam ook doet vermoeden). :)
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?
Het augustus 2016 Sky & Telescope artikel Pixinsight Processing van Ron Brecher is beschikbaar als PDF. (Hij schreef dit erbij op Facebook: ” My Sky & Telescope article on deep-sky image processing with PixInsight is now available at my website. I hope you enjoy it, and welcome any feedback.”)
Als je het Image Plate Solver Script gebruikt en een image probeert te solven vergeet dan niet een juiste brandpuntsafstand in te geven van je optiek in relatie tot de gebruikte sensor. M.a.w. gebruik je een DSLR met een APS-C sensor, vermenigvuldig dan de “focal distance” in het script met 1,5 of 1,6.
Het Image Plate Solver Script is een geweldige manier om meer te ontdekken in je images. Het script heeft overigens moeite met melkweg opnames, waarschijnlijk door het groot aantal sterren en crashed frequent.
Als je het Image Plate Solver Script gebruikt en een image probeert te solven vergeet dan niet een juiste brandpuntsafstand in te geven van je optiek in relatie tot de gebruikte sensor. M.a.w. gebruik je een DSLR met een APS-C sensor, vermenigvuldig dan de “focal distance” in het script met 1,5 of 1,6.
Daar heb ik zo mijn twijfels over. Het script werkt op basis van de image scale en gebruikt het aantal boogseconden per pixel. Dat is alleen afhankelijk van de echte brandpuntsafstand in mm en de pixelafmeting van de gebruikte camera in Mu. Het vermenigvuldigen van de brandpuntsafstand met 1.6 voor APS-C camera’s zou een hele extra ingewikkelde rekenarij toevoegen aan het script met alle typen camerasensoren die er zijn.
Wanneer het platesolven in Pixinsight met het platesolve script niet wil lukken (en dat is best wel vaak) dan is dit een prima alternatief:
1) Upload de foto naar http://nova.astrometry.net/upload .
2) Na platesolven, download het new-image.fits bestand van de resultaten pagina.
3) Open het new-image.fits bestand in Pixinsight.
4) Gebruik het “render”, “annotate image” script in Pixinsight om de annotatie te doen.
Dit werkt ook bij mozaieken en er hoeft niets te worden ingevuld, het is een “blind solver”.
Daar heb ik zo mijn twijfels over. Het script werkt op basis van de image scale en gebruikt het aantal boogseconden per pixel. Dat is alleen afhankelijk van de echte brandpuntsafstand in mm en de pixelafmeting van de gebruikte camera in Mu. Het vermenigvuldigen van de brandpuntsafstand met 1.6 voor APS-C camera’s zou een hele extra ingewikkelde rekenarij toevoegen aan het script met alle typen camerasensoren die er zijn.
Ik begrijp wat je bedoeld. Empirisch werkt 216mm echter, en 135mm niet (op het M31 en Dubbele Cluster image althans), zie bijlage met 135mm. In theorie heb jij echter volledig gelijk. Op zijn minst een interessante constatering…ik duik hier zelf nog wat dieper in.
Plate solving via PI wil vaak niet lukken, met name niet in Melkweg gebieden, bijv rondNGC7000. Al door experimenterende heb ik geprobeerd een solve uit te voeren op een niet bewerkt image (alleen op het integratie resultaat). Succes de eerste keer. Andere moeilijke gebieden (melkweg gebieden) heb ik ook getest met alleen het integratie resultaat van NGC7000, werkt eveneens.
Vervolgens heb ik een simpele ABE (achtergrond extractie) losgelaten op het NGC7000 image en door bewerkt t/m CurvesTransformation (niet afgebeeld!) en een nieuwe annotatie losgelaten op het ABE resultaat en het resultaat in de non-lineaire fase, werkt ook. D.w.z. dat het naar voren halen van de PlateSolve in de workflow stabieler en consistenter werkt (in ieder geval in de lineaire fase uit te voeren).
Resumerend, solven in de lineaire fase, annoteren na volledige bewerking in de non-lineaire fase.
Hiermee is mijn doel weer bereikt, ontdekken middels astrofotografie :-) .
Plate solving in de lineaire fase, annoteren na volledige bewerking in de non-lineaire fase. Hiermee is mijn doel weer bereikt, ontdekken middels astrofotografie .
Mooi resultaat Marc, ga ik vanaf nu standaard doen!
Hoi Marc en Kees,
Ik heb de technische verklaring waarom plate solven beter werkt met de lineaire data voor jullie ;-).
Plate solven berust op patroon herkenning tussen de foto en sterren uit een catalogus. De patronen komen het best overeen als de sterlokaties in de foto die gesolved moet worden, optimaal zijn bepaald. Als je een sterlokatie wilt bepalen op subpixel niveau (middels regressie aan een bepaald intensiteitsprofiel) dan moet je dat doen met de lineaire data. Als de data niet meer lineair is, kan er ook geen realistische fit gemaakt en komt er een grote foutmarge in de bepaling van de sterlokatie op subpixel niveau.
Normaal kan je 0.1 pixel precisie halen bij de bepaling van de sterlokatie, beter is eigenlijk niet te doen en wordt ook niet vermeld in de literatuur voor zover ik weet. Gebruik je niet-lineaire data, dan is de fout al snel een halve pixel.
Ik moet hierbij ook zeggen, dat optiek vervorming de resultaten beinvloed. Dus data die correct wordt gecorrigeerd voor optiek vervorming zal beter te solven zijn. Het gebruik van thin plate splines ( wat PI doet bij optische vervorming) zal het resultaat niet verbeteren. Pi noemt het optische distortie correctie, maar dat is het zeker niet. Thin plates veroorzaken arbitraire niet-realistische vervormingen in je stacks en verslechteren daardoor de mogelijkheid om goed te kunnen solven…
Als laatste, ik denk dat de Thin plate splines van PI meer ellende veroorzaken dan het fitten aan niet-lineaire data. De fout die thin plates veroorzaken is snel een paar pixels bij sterke vervorming. Terwijl de niet-lineaire fit fout niet groter zal zijn dan 1 pixel.
En fouten < 1 pixel mogen geen probleem zijn voor een goede registratie en dus solve module. Mijn registratie module kan fouten aan die een factor 10 keer groter zijn en nog steeds dus het optimale registratie model vinden.
- You must be logged in to reply to this topic.