Astrometrie mag kein Ultra-Weitwinkel

Der schwierigste und komplizierteste Teil von Theli.
Forumsregeln
Bitte die Beiträge kurz fassen, so kann man sie nachher besser finden. Sollte ein Problem gelöst sein, dann einen neuen Beitrag eröffnen. Ebenso wenn die Ursache eine ganz andere ist, oder es Offtopic wird.

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon selste » Dienstag 17. September 2013, 13:12

So,
Maschine ist wieder halbwegs hergestellt ...

Wolfgang, ich hab - mit einem Frame - in Theli alles durchgenudelt bis einschließlich 'Create global weights', danach wie Mischa geschrieben hatte eine Region mit ds9 erstellt (mit Radius 2200) und über fitspolygon daraus ein korrigiertes FITS erstellt, anschließend 'Create WEIGHTS' laufen lassen.

Referenzkatalog gezogen (Tycho, Mag 7 Grenzgröße, ist eigentlich schon fast zu viel), zur Überprüfung habe dann
Code: Alles auswählen
lensdistortion.sh /opt/THELI/theli/bin/Linux_64 /opt/theli/perseids/fisheye/IMG_1670_R_1OFC.fits  20:38:00 47:37:00 -118 73.9 1.18e-4 1.3e-9 9.5e-12 /opt/THELI/theli/bin/Linux_64/ds9

rennen lassen, das Ergebnis schaut so aus:
lensdistortion.jpg

Das ist einigermaßen anständig, denke ich.

Bevor ich jetzt weitermache muß ich erst nochmal deine Anleitung im anderen Thread genau durchlesen :D
Gruß,

Steffen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
selste
 
Beiträge: 110
Registriert: Montag 19. März 2012, 18:39

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon woho » Sonntag 22. September 2013, 19:08

Hi Steffen,

kommst Du weiter?

Ich habe mit den Daten @10mm nochmal einige Versuche gemacht, um auf ein besseres Matching zu kommen. Mein Resume: ich denke das Polynom 7. Grades ist zu wenig, um die Fisheye-Projektion genau genug modellieren zu können, um ein ordentliches Ergebnis von Bildmitte bis zum Rand zu bekommen (mit Rand meine ich zumindest nahe der entfernteren Längsseite, die Ecken sind hoffnungslos).

Ich kann über den Crossid-Radius das Verhalten von Scamp folgendermaßen steuern:
  • Großer Crossid-Radius (z.B. 20 * Pixelscale): Scamp findet Src/Ref Sternpaare bis nahe an den Rand und versucht, diesen großen Bereich zu entzerren. Das geht aber auf Kosten des Bildzentrums, die Sterne bekommen auch in der Bildmitte Farbsäume.
  • Kleiner Crossid-Radius (z.B. 5 * Pixelscale): Scamp findet Src/Ref Sternpaare in Randnähe nicht mehr und kann die Freiheitsgrade des Polynoms 7. Grades nützen, um das Matching in der Bildmitte zu verbessern (saubere Sterne), aber dann verliert man sehr viel Bildperipherie (bereits ab der näheren Längsseite wirds wild).
Das ist beides nicht wirklich brauchbar.

Dazu kommt, dass meine Verknüpfung der Vor-Entzerrung mit dem Scamp-Ergebnis höhere Polynom-Terme als 7. Grades verwerfen muss, was zu weiteren Fehlern führt, von denen Scamp beim Optimieren des Matchings nichts weiß. Auch die Error-Plots zeigen diese Fehler nicht.

Neuere Scamp-Versionen unterstützen übrigens eine Vorentzerrung. Ich habe versuchsweise den Scamp Headstand gebaut (r314) und die THELI-Scripten so modifiziert, dass die Vorentzerrung Scamp bekannt ist. Das Ergebnis ist aber wegen den Punkten oben immernoch nicht wirklich besser, lediglich die Scamp-Charts sind aussagekräftiger. Die Error-Plots werden dann sehr ernüchternd (Pixelscale sind 89"/px):
astr_referror1d_1.png

Der Distortion-Plot zeigt aber sehr schön die gleichmäßige Pixelscale über das Feld des Fisheyes, ganz anders als bei gnomonischen Linsen:
distort_1.png


Eigentlich liegen die Fisheye-Bilder sehr nahe an der ZEA Projektion. Wenn man im FITS-Header der kalibrierten Frames CTYPE1/2 durch RA---ZEA bzw. DEC--ZEA ersetzt und in ds9 den Referenzkatalog drüberlegt, sieht man das auch. Ich weiß nur nicht, wie man die Toolchain dazu überreden könnte, in ZEA statt TAN zu astrometrieren, wahrscheinlich geht das mit dem aktuellen scamp/swarp einfach nicht, oder es braucht einen genialen Trick.

Vielleicht gehts Dir mit Deinen etwas langbrennweitigen Bildern besser. Evtl. ist aber für diese Linse eine simple Ausrichtung der Bilder zueinander und ein Stacken ohne Korrektur der Linsenverzerrung der bessere Weg.

Ciao,
Wolfgang
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
woho
 
Beiträge: 56
Registriert: Samstag 30. Juni 2012, 09:00
Wohnort: Bad Aibling

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon mischa » Sonntag 22. September 2013, 23:04

woho hat geschrieben:Eigentlich liegen die Fisheye-Bilder sehr nahe an der ZEA Projektion. Wenn man im FITS-Header der kalibrierten Frames CTYPE1/2 durch RA---ZEA bzw. DEC--ZEA ersetzt und in ds9 den Referenzkatalog drüberlegt, sieht man das auch. Ich weiß nur nicht, wie man die Toolchain dazu überreden könnte, in ZEA statt TAN zu astrometrieren, wahrscheinlich geht das mit dem aktuellen scamp/swarp einfach nicht, oder es braucht einen genialen Trick.


Aus dem Kopf raus weiss ich dass nicht, aber du kannst ja mal versuchen, den CTYPE1/2 durch RA---ZEA / DEC--ZEA zu ersetzen, und danach "create source cat" laufen lassen. Der Projektionstyp wird in die Kataloge uebernommen, Scamp und Swarp sollten das unterstuetzen.

Mischa
mischa
Moderator
 
Beiträge: 986
Registriert: Freitag 7. Oktober 2011, 14:07
Wohnort: Chile

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon woho » Montag 23. September 2013, 19:58

Hi Mischa,

ja, das funktioniert, danke :)

Ich habe nur CTYPE1/2 geändert und dann die originial THELI Skripten laufen lassen (mit Scamp Headstand r314), und bekomme ein ordentliches Koadditionsergebnis. Jetzt brauche ich einen großen Crossid-Radius (2000), um die Abweichungen der Linse von der idealen ZEA zu überbrücken. Distortion-Degree 3 reicht dann, mit 5 wird das Ergebnis nicht mehr sichtbar besser.

Kleiner Schönheitsfehler: die Beurteilung des Astrometrie ist schwierig, weil die Plots nicht so recht zum Ergebnis passen: die sehen immer gleich aus, egal welchen Distortion-Degree ich einstelle. In den Headern sieht man aber die PVi_j Keys, und Swarp wertet sie offenbar auch wirklich aus. Die Coadds unterscheiden sich sichtlich mit Distortion-Degree 1 ggü 3 (Farbkanäle decken sich mit 3 besser).
Die Vorentzerrung für das Fisheye ist damit hinfällig (für meine 24mm Aufnahmen im anderen Thread aber nicht).

Mit DS9 sehe ich im Coadd noch leichte Abweichungen vom Referenzkatalog, das muss ich mir nochmal in Ruhe anschauen.

Steffen, schaffst Du die Ersetzung des CTYPE1/2 manuell? Ich hab das in mein Skript eingebaut, das mit Mittelpunkt und Drehlage einträgt, das mag ich aber nicht posten, weil es ein Sauhufen ist mit hardcodeten Pfade, Bilderbennenungsschemata etc., das verwirrt wohl mehr als es hilft. Im wesentlichen mache ich sowas, wobei IMAGE über alle Science frames läuft (z.B. lights/IMG_0602_G_1OFC.fits):
Code: Alles auswählen
<pfad_aufs_theli_bind>/replacekey ${IMAGE} \
        "CTYPE1  = 'RA---ZEA          ' / WCS coordinate type                           " "CTYPE1  " \
        "CTYPE2  = 'DEC--ZEA          ' / WCS coordinate type                           " "CTYPE2  "

Mach evtl. vorher ein Backup der Science-Frames ...

Ciao,
Wolfgang
woho
 
Beiträge: 56
Registriert: Samstag 30. Juni 2012, 09:00
Wohnort: Bad Aibling

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon selste » Dienstag 24. September 2013, 17:21

Hallo Wolfgang,
hab erst eine Erkältung auskurieren dürfen, und dann viel Arbeit im Büro gehabt ... bin noch nicht weiter.
Die Ersetzung bekomme ich hin, zur Not poliere ich meine eingerosteten Perl-Kenntnisse auf :wink:

An der Aktualisierung von scamp komme ich aber net vorbei, oder habe ich da was falsch verstanden?
Gruß,

Steffen
selste
 
Beiträge: 110
Registriert: Montag 19. März 2012, 18:39

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon woho » Dienstag 24. September 2013, 21:07

selste hat geschrieben:An der Aktualisierung von scamp komme ich aber net vorbei, oder habe ich da was falsch verstanden?

Die ZEA Projektion könnte mit dem klassischen Scamp funktionieren, probiers einfach, ich habs noch nicht getestet. Für die TAN Projektion mit Berücksichtigung der Vorentzerrung in Scamp brauchst Du einen aktuellen Stand, aber mit dem Fisheye geht ZEA besser, finde ich.

Zum Compilieren von Scamp hatte Thomas einen sehr hilfreichen Thread gestartet. Ich hatte mich daran gehalten und meine Schritte in diesem Posting zusammengefasst, das funktioniert bei mir unter Ubuntu 13.04 immernoch. Dauert ein bischen, ansonsten aber kein Problem.

Ciao,
Wolfgang
woho
 
Beiträge: 56
Registriert: Samstag 30. Juni 2012, 09:00
Wohnort: Bad Aibling

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon selste » Mittwoch 25. September 2013, 18:29

Hallo Wolfgang,
Danke für den Link - /eigentlich/ wollte ich ja an der Theli-Installation so wenig wie möglich 'rumpfuschen' ... mal schauen, versuch mein Glück vermutlich trotzdem mit dem aktuellen scamp-Code!
Meld mich, sobald ich Neuigkeiten hab,

Steffen
selste
 
Beiträge: 110
Registriert: Montag 19. März 2012, 18:39

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon woho » Sonntag 29. September 2013, 18:27

Hallo zusammen,

woho hat geschrieben:Ich habe nur CTYPE1/2 geändert ... und bekomme ein ordentliches Koadditionsergebnis.

... so kann man sich täuschen :oops:
woho hat geschrieben:Mit DS9 sehe ich im Coadd noch leichte Abweichungen vom Referenzkatalog, das muss ich mir nochmal in Ruhe anschauen.

Das habe ich jetzt getan, und dabei festgestellt, dass Swarp offensichtlich die PVi_j Keys bei Frames mit ZEA Projektion _nicht_ berücksichtigt. Die Aufnahmen waren nicht gedithert und sauber nachgeführt, so dass das bei den Coadds nicht gleich aufgefallen ist. Gegen den Referenzkatalog sieht man es aber doch, und auch die Farbkanäle haben etwas Versatz zueinander.

Schade.

Mischa, wäre es möglich, die Bilder doch in der TAN Projektion durch die Toolchain zu schleusen, aber den Referenzkatalog so zu manipulieren, dass die Referenzkoordinaten eigentlich ZEA sind? Das Coadd wäre dann ZEA, obwohl Swarp TAN reinschreibt, aber das lässt sich zum Schluss ja mit replacekey korrigieren. Idee dahinter ist, das Distortion Polynom wirklich nur zum Ausgleich der Abweichung der Linse von der idealen ZEA Projektion zu verwenden. Das sollte doch prinzipiell klappen, solange der Versatz der Rohframes minimal ist, oder? Evtl. mit STABILITY_TYPE EXPOSURE?

Ciao,
Wolfgang
woho
 
Beiträge: 56
Registriert: Samstag 30. Juni 2012, 09:00
Wohnort: Bad Aibling

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon mischa » Sonntag 29. September 2013, 20:25

woho hat geschrieben:Mischa, wäre es möglich, die Bilder doch in der TAN Projektion durch die Toolchain zu schleusen, aber den Referenzkatalog so zu manipulieren, dass die Referenzkoordinaten eigentlich ZEA sind?


Wenn du mir die entsprechenden Transformationen raussuchst, dann sehe ich mir das gerne an (aber ohne Implementationsgarantie, andere baustellen sind grad wichtiger).
mischa
Moderator
 
Beiträge: 986
Registriert: Freitag 7. Oktober 2011, 14:07
Wohnort: Chile

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon selste » Montag 30. September 2013, 17:52

So,
scamp ist jetzt auch aktualisiert ... ging Dank der Anleitung von Thomas und den Ergänzungen von Wolfgang recht problemlos über die Bühne.
ATLAS zu bauen dauert allerdings ewig und drei Tage :shock:

Ok, und was habe ich in der Zwischenzeit alles verpasst - die Koaddition funktioniert doch nicht so richtig?!
Gruß,

Steffen
selste
 
Beiträge: 110
Registriert: Montag 19. März 2012, 18:39

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon woho » Montag 30. September 2013, 19:18

Hi Mischa,

mischa hat geschrieben:Wenn du mir die entsprechenden Transformationen raussuchst, dann sehe ich mir das gerne an (aber ohne Implementationsgarantie, andere baustellen sind grad wichtiger).


Ich möchte die Bilder auf eine ZEA Projektion astrometrieren, da diese näher an der Fisheye Abbildung ist als die TAN. Da Scamp/Swarp aber nur mit TAN die PVi_j richtig berücksichtigen (Plots und Coadds), möchte ich den Referenzkatalog zuerst mit ZEA von den sphärischen Koordinaten (Ra/Dec) auf Pixelkoordinaten transformieren. Die Pixelkoordinaten sind durch SIZEX/Y und REFPIXX/Y aus dem instrument.ini des (einzigen) Chips der DSLR festgelegt. Diese Pixelpositionen möchte ich dann mit TAN wieder in sphärische Koordinaten zurückprojezieren, um damit die ansonsten unveränderten Rohframes/Source-Kataloge zu astrometrieren und coaddieren. Bei der Koaddition muss ich als Projetion zwar TAN einstellen, wegen des reprojezierten Referenzkatalogs ist das Ergebnis dann aber tatsächlich ZEA. Das korrigiere ich dann ganz zum Schluß mit replacekey in den coadd.fits.

Ich bin mir nicht sicher, ob der Ansatz mathematisch richtig ist, weil ja z.B. eine Verschiebung der Frames in TAN anders zu kompensieren ist als in ZEA. Ich ignoriere das aber vorerst, da meine Daten nicht gedithert sind und praktisch nachführfehlerfrei sind (Pixelscale im Bogenminutenbereich), die Offsets zwischen den Frames also klein sind. In dem Fall würde ich das beinhart probieren und schauen, ob es für ein Pretty Picture reicht. Photometrische Auswertungen brauchts hier nicht ...

Ein schneller Implementierungshack würde so aussehen, einzufügen im create_astrorefcat_fromWEB.sh vor dem Erstellen der verschiedenen Refcat-Formate:
Code: Alles auswählen
if [ "${LENSPROJECTION}" == "ZEA" ]; then
    # we're running ZEA images through Scamp/Swarp, pretending they're TAN (so that PVi_j are treated correctly).
    # reproject ref catalog to pixel positions of ZEA projection, then back to spherical coordinates using TAN.
    # setup WCS with center at ${ra} ${dec}, pixelscale ${PIXSCALE} and camera chip 1 image dimensions
    ${P_IC} -c ${SIZEX[1]} ${SIZEY[1]} \
        -h CRVAL1 $(${P_HMSTODECIMAL} ${ra}) \
        -h CRVAL2 $(${P_DMSTODECIMAL} ${dec}) \
        -h EQUINOX 2000.0 \
        -h RADECSYS "'FK5     '" \
        -h CRPIX1 ${REFPIXX[1]}.0 \
        -h CRPIX2 ${REFPIXY[1]}.0 \
        -h CTYPE1 "'RA---ZEA'" \
        -h CTYPE2 "'DEC--ZEA'" \
        -h CD1_1 $(echo ${PIXSCALE} | ${P_GAWK} '{ print -1./$1; }') \
        -h CD1_2 0 \
        -h CD2_1 0 \
        -h CD2_2 $(echo ${PIXSCALE} | ${P_GAWK} '{ print 1./$1; }') \
        '0' > ${TEMPDIR}/wcszea_$$.fits
    ${P_IC} -c ${SIZEX[1]} ${SIZEY[1]} \
        -h CRVAL1 $(${P_HMSTODECIMAL} ${ra}) \
        -h CRVAL2 $(${P_DMSTODECIMAL} ${dec}) \
        -h EQUINOX 2000.0 \
        -h RADECSYS "'FK5     '" \
        -h CRPIX1 ${REFPIXX[1]}.0 \
        -h CRPIX2 ${REFPIXY[1]}.0 \
        -h CTYPE1 "'RA---TAN'" \
        -h CTYPE2 "'DEC--TAN'" \
        -h CD1_1 $(echo ${PIXSCALE} | ${P_GAWK} '{ print -1./$1; }') \
        -h CD1_2 0 \
        -h CD2_1 0 \
        -h CD2_2 $(echo ${PIXSCALE} | ${P_GAWK} '{ print 1./$1; }') \
        '0' > ${TEMPDIR}/wcstan_$$.fits
    # ${TEMPDIR}/tmp1_$$ contains lines RA DE MAG, e.g. 6.350881 1.939696 5.770000
    ${P_SKY2XY} ${TEMPDIR}/wcszea_$$.fits @${TEMPDIR}/tmp1_$$ > ${TEMPDIR}/tmp2_$$
    ${P_GAWK} '{ print $5 " " $6 " " $3; }' ${TEMPDIR}/tmp2_$$ > ${TEMPDIR}/tmp3_$$
    ${P_XY2SKY} -d -n 7 -a ${TEMPDIR}/wcstan_$$.fits @${TEMPDIR}/tmp3_$$ > ${TEMPDIR}/tmp4_$$
    ${P_GAWK} '{ if ($1 != "") print $1 " " $2 " " $6; }' ${TEMPDIR}/tmp4_$$ > ${TEMPDIR}/tmp5_$$
    mv ${TEMPDIR}/tmp5_$$ ${TEMPDIR}/tmp1_$$
    rm ${TEMPDIR}/tmp[234]_$$
    rm ${TEMPDIR}/wcszea_$$.fits
    rm ${TEMPDIR}/wcstan_$$.fits
fi

# make an astrometrix catalogue
...

Ich lege mir mit ic zwei Dummy-Bilder an, deren WCS ich dann für sky2xy und xy2sky verwende. Geht das einfacher, oder würdest Du das auch so implementieren? Im instrument.ini muss man LENSPROJECTION=ZEA ergänzen, um den Code zu aktivieren.

Ich hab das jetzt auf die Schnelle probiert, und das Ergebnis schaut vielversprechend aus. Mit Vorbehalt, da das jetzt sehr brutal mit der heißen Nadel gestrickt wurde. Die Error-Plots sind jetzt wieder aussagekräftig und liegen erstmals, seit ich die Daten habe, im Sub-Pixel Bereich. Die Distortion-Plots sehen wie klassische TAN-Plots aus, logisch. Die coadds der Farbkanäle decken sich gut, Ref-Katalog (den unmodifizierten) muss ich erst noch drüberlegen, dann wird sich's zeigen.

Was meinst? Ist zwar ein Hack, aber mei ...

Ciao,
Wolfgang
woho
 
Beiträge: 56
Registriert: Samstag 30. Juni 2012, 09:00
Wohnort: Bad Aibling

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon woho » Montag 30. September 2013, 19:35

Hi Steffen,
selste hat geschrieben:Ok, und was habe ich in der Zwischenzeit alles verpasst - die Koaddition funktioniert doch nicht so richtig?!

Ja, leider, aber wie oben geschrieben läßt sichs wohl trotzem hintricksen.

Zusammengefaßt:
  • nimm die original Theli Installation und ersetze nur das
    create_astrorefcat_fromWEB.sh
    mit diesem Attachment (das hat das Code-Sniplet von oben drin, mehr nicht). Alle anderen Scripten bleiben gleich.
  • erweitere Dein <instrument>.ini um folgende Zeile:
    Code: Alles auswählen
    LENSPROJECTION=ZEA

    Die LENSDISTORT Parameter brauchst Du nicht, da wir hier keine Vorentzerrung der Source-Kataloge machen.
  • Setze in der Theli GUI die Mittelpunkkoordinaten für den Referenzkatalog auf Deine genaue Bildmitte (so genau wie möglich). Mach dann "Get Catalog". Hintergrund: die Projektionstrickserei wird vermutlich nur dann funktionieren, wenn die Bildmitte der Einzelframes und des Referenzkataloges möglichst gut übereinstimmen.
  • Ganz normal Source-Kataloge generieren und Astrometrie durchführen. Den CROSSID_RADIUS hatte ich jetzt auf 900 (10-fache Pixelscale), DISTORT_DEGREE auf 7.
  • Beim Coadd die Felder für Ref RA|DEC leer lassen, so dass auch da wieder der gleiche Mittelpunkt verwendet wird. Als Projektion unbedingt TAN und EQUATORIAL auswählen. Coadd für alle drei Farbkanäle ausführen.
  • Die Projektion im Koadd-Ergebnis korrigieren, das ist ZEA, Swarp schreibt aber TAN rein. Also auf der Kommandozeile:
    Code: Alles auswählen
    P_REPLACEKEY=~/work/theli/theli/bin/Linux_64/replacekey; for IMG in lights/coadd_{Red,Green,Blue}/coadd{,.weight}.fits; do ${P_REPLACEKEY} ${IMG}     "CTYPE1  = 'RA---ZEA          ' / WCS coordinate type" "CTYPE1  "     "CTYPE2  = 'DEC--ZEA          ' / WCS coordinate type" "CTYPE2  "; done

    Den Pfad im P_REPLACEKEY wie gewohnt anpassen.

Ciao,
Wolfgang

Edit: ich hab das mit dem alten Scamp und dem aktuellen Headstand versucht. Prinzipiell funktioniert beides, allerdings bekomme ich mit dem Alten eine Warning (significant inaccuracy likely to occur oder so ähnlich), und die Error-Plots zeigen mit dem Headstand besseres Matching. Ich bleibe also beim Selbstcompilierten.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von woho am Montag 30. September 2013, 19:43, insgesamt 1-mal geändert.
woho
 
Beiträge: 56
Registriert: Samstag 30. Juni 2012, 09:00
Wohnort: Bad Aibling

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon mischa » Montag 30. September 2013, 19:42

Hi Wolfgang,

auf die Schnelle schaut mir das ok aus, der "Umweg" ueber die wcstools sky2xy / xy2sky ist sogar sehr elegant, da er explizites Rumfummeln mit den Koordinaten vermeidet. Haette ich ganz genauso gemacht!
Ob es funktioniert wird das koaddierte Bild sagen. Du hast es ja offensichtlich schon weitgehend selbst implementiert. Bin gespannt, was bei leicht deditherten Aufnahmen bei rauskommt.

Mischa
mischa
Moderator
 
Beiträge: 986
Registriert: Freitag 7. Oktober 2011, 14:07
Wohnort: Chile

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon Knickohr » Montag 30. September 2013, 19:48

So langsam schlattern mir hier echt die Ohren :shock:

Macht weiter so 8)

Thomas
Benutzeravatar
Knickohr
Moderator
 
Beiträge: 623
Registriert: Donnerstag 29. September 2011, 12:01
Wohnort: Blaustein

Re: Astrometrie mag kein Ultra-Weitwinkel

Beitragvon woho » Montag 30. September 2013, 19:51

Hi Mischa,

mischa hat geschrieben:auf die Schnelle schaut mir das ok aus, der "Umweg" ueber die wcstools sky2xy / xy2sky ist sogar sehr elegant, da er explizites Rumfummeln mit den Koordinaten vermeidet. Haette ich ganz genauso gemacht!

Danke :) Das lass ich das so, sehr schön.

mischa hat geschrieben:Ob es funktioniert wird das koaddierte Bild sagen. Du hast es ja offensichtlich schon weitgehend selbst implementiert. Bin gespannt, was bei leicht deditherten Aufnahmen bei rauskommt.

Ja. Meine Coadds schauen gut aus, hab jetzt einen unmodifizierten Ref-Katalog über die Ergebnisse gelegt, das passt.

Ich selber hab die Linse nicht, mein Arbeitskollege hatte sie auf der Astrotrac, daher kein Dithering. Aber schau ma mal, was Steffen an Rohdaten hat.

Ciao,
Wolfgang
woho
 
Beiträge: 56
Registriert: Samstag 30. Juni 2012, 09:00
Wohnort: Bad Aibling

VorherigeNächste

Zurück zu Astrometrie und Photometrie

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron