PixInsight

  • This topic contains 65 replies, has 10 voices, and was last updated by  Bakx 4 weeks ago.
Viewing 15 posts - 1 through 15 (of 66 total)
  • Author
    Posts
  • #6647

    Theunissen
    Keymaster
    posts: 1037

    Het PixInsight topic (sticky). Een plek om tips and tricks met en over PI te bespreken.

    PixInsight gids

    • 1 person likes this.
    #6756

    KeesScherer
    Participant
    posts: 1404

    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.

    • 1 person likes this.
    #6757

    Groenewold
    Moderator
    posts: 1159

    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?

    #6759

    KeesScherer
    Participant
    posts: 1404

    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:

    • 2 people like this.
    #6760

    Groenewold
    Moderator
    posts: 1159

    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). 🙂

    #6937

    KeesScherer
    Participant
    posts: 1404

    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?

    #7473

    KeesScherer
    Participant
    posts: 1404

    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.”)

    • 1 person likes this.
    #8544

    Theunissen
    Keymaster
    posts: 1037

    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.

    • 2 people like this.
    #8550

    KeesScherer
    Participant
    posts: 1404

    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.

     

    #8555

    KeesScherer
    Participant
    posts: 1404

    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”.

     

    • 1 person likes this.
    #8559

    Theunissen
    Keymaster
    posts: 1037

    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.

    #8653

    Theunissen
    Keymaster
    posts: 1037

    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 🙂 .

    • 1 person likes this.
    #8660

    KeesScherer
    Participant
    posts: 1404

    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!

    • 1 person likes this.
    #8672

    Haverkamp
    Participant
    posts: 648

    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.

    • 2 people like this.
    #8673

    Theunissen
    Keymaster
    posts: 1037

    Dank Mabula voor de theoretische verklaring als onderbouwing van een empirisch bereikt resultaat 🙂 , dit noemt men wetenschap 🙂 .

    • 1 person likes this.
Viewing 15 posts - 1 through 15 (of 66 total)

You need to log in or to reply to this topic.