M86

Meine mit Theli erstellten Bilder, Mosaike, Videos ...

M86

Beitragvon moos » Mittwoch 27. Mai 2020, 21:25

Hi, heute noch ein Bild durchgenudelt.
Theli stürzt bei mir immer ein bis zweimal zwischendurch ab.
Heute war es während der Anzeige der Statistik. Seitdem sind auch keine Seeingwerte mehr enthalten.
Die Astrometrie mache ich nun nur noch mit der Einstellung "minimize memory usage". Danach stelle ich den Haken wieder aus. ( siehe früheren Post dazu)
Da ist noch ein Typo im Coadd-Code:
Code: Alles auswählen
calculating backgound

Nachdem astrometry.net gescheitert ist, hat scamp zuverlässig eine Lösung gefunden. Bei mir braucht scamp dafür 4 Stunden ( 4 CPU/ 4GB in VM)

So jetzt aber zum Bild:
ca. 37x180 mit EOS 1200D

Bild
Ciao Carsten
moos
 
Beiträge: 504
Registriert: Dienstag 18. Oktober 2011, 19:06

Re: M86

Beitragvon spiegelei » Donnerstag 28. Mai 2020, 08:07

Hi Carsten,
4h ist ganz schön happig. Das liegt wohl auch teilweise an der VM. Was für eine CPU hst Du drin?
Gruß
Karsten

PS: Schönes Bild. Mir kommt es so vor, als ob oben links die Sterne ein bisschen verzogen sind.
Atik 383 - AP80/560 - GSO RC 8" - LX50 8" SC - TSAPO65Q - CGEM
Theli 3 - SUSE Leap 15.1/64 - Dual XEON 12K/24T - 32GB
Die meisten großen Erfindungen beginnen nicht mit "HEUREKA" sondern mit "Das ist aber komisch....."
Benutzeravatar
spiegelei
 
Beiträge: 197
Registriert: Donnerstag 29. September 2011, 15:15
Wohnort: Chemnitz

Re: M86

Beitragvon moos » Donnerstag 28. Mai 2020, 08:14

spiegelei hat geschrieben:4h ist ganz schön happig. Das liegt wohl auch teilweise an der VM. Was für eine CPU hst Du drin?
Keine Ahnung. Aber entscheidend ist wohl die VM-CPU, oder?

spiegelei hat geschrieben:PS: Schönes Bild. Mir kommt es so vor, als ob oben links die Sterne ein bisschen verzogen sind.

Das ist der Schönheitsfehler, damit es was zu meckern gibt. Nein, der Reducer kommt leider nicht dichter ran und der original-Reducer ist viel zu teuer. Ich beschneide normalerweise auf 1:1 und das ist für mich in Ordnung. Die optische Achse ist auch nicht ganz in der Mitte des Sensors sondern leicht verschoben ( nicht gekippt) , daher kommt es oben links am stärksten raus.
Ciao Carsten
moos
 
Beiträge: 504
Registriert: Dienstag 18. Oktober 2011, 19:06

Re: M86

Beitragvon spiegelei » Donnerstag 28. Mai 2020, 09:38

Hi Carsten,

moos hat geschrieben:Keine Ahnung. Aber entscheidend ist wohl die VM-CPU, oder?


bei mir merke ich teilweise einen signifikanten Unterschied zwischen Anwendungen in einer VM und Anwendungen im nativen OS. Z.B. dauert der Build von Theli in der VM (gefühlt ;) ) 4x so lange wie "out of the Box", dabei werden sowohl in der VM als auch ausserhalb bei weitem nicht alle Kerne verwendet.

Gruß
Karsten
Atik 383 - AP80/560 - GSO RC 8" - LX50 8" SC - TSAPO65Q - CGEM
Theli 3 - SUSE Leap 15.1/64 - Dual XEON 12K/24T - 32GB
Die meisten großen Erfindungen beginnen nicht mit "HEUREKA" sondern mit "Das ist aber komisch....."
Benutzeravatar
spiegelei
 
Beiträge: 197
Registriert: Donnerstag 29. September 2011, 15:15
Wohnort: Chemnitz

Re: M86

Beitragvon mischa » Donnerstag 28. Mai 2020, 09:56

Die Dauer des matching in Scamp laesst sich ganz wesentlich durch passende Katalogeinstellungen beeinflussen. Du solltest in etwa eine gleiche Dichte an detektierten Objekten wie an Referenzobjekten haben. In iView kannst du das sehr leicht pruefen und dann ggf korrigieren. Die Genauigkeit der Zentrumskoordinaten (bzw POSITION_MAXERR) spielt auch eine Rolle.

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

Re: M86

Beitragvon dietmar » Freitag 29. Mai 2020, 10:10

Moin,

hat 'ne AP-Montierung aber fotografiert mit 'ner billigen EOS 1200 :D
Egal.
Mir ist schon mal aufgefallen, dass Du bei der Astrometrie ziemlich große Tolleranzen zulässt. Ohne mich zu weit aus dem Fenster lehnen zu wollen möchte ich behaupten, dass die Astrometrie umso schneller und/oder zuverlässiger arbeitet, je kleiner die Tolleranzen sind.
Ich schiebe vor der Astrometrie immer ein "Binned preview" auf Astrometry.net. Das rechnet dann ein bischen rum und spuckt die Mittelpunktskoordinaten, Kameraorientierung, Pixelskaierung, ... aus, die ich dann an die Astrometrie verfüttere. So kann ich mit ziemlich kleinen Tolleranzen arbeiten und die Astgrometrie flutscht so durch (Theli 3/scamp 2.9).
Auf meinem Westbalkon mit Blick auf die (helle) düsseldorfer Skyline hab' ich aber auch keinen Ärger mit Meridian-Flips :)

spiegelei hat geschrieben:bei mir merke ich teilweise einen signifikanten Unterschied zwischen Anwendungen in einer VM und Anwendungen im nativen OS. Z.B. dauert der Build von Theli in der VM (gefühlt ;) ) 4x so lange wie "out of the Box", dabei werden sowohl in der VM als auch ausserhalb bei weitem nicht alle Kerne verwendet.
Wenn ihr Intel-CPUs auf Intel-CPUs virtualisiert, werden diese 1 zu 1 durchgereicht.
Was die virtuelle Maschine jedoch als Festplatte sieht ist eine Datei im Dateisystem der Host-Maschine. Dateisystemzugriffe sehen somit wie folgt aus:

Dateisystem des Guest
|
v
virtuelle Hardware
|
v
Dateisystem des Host
|
v
richtige Hardware

und das dauert eben.
So 'ne Build ist sehr Disk-IO-intensiv (da werden Header-Dateien eingebunden, die rekursiv sind bis der Arzt kommt). Die Astrometrie dagegen ist mehr CPU- als IO-intensiv (mischa, korrigier mich ggf.), so dass es keinen großen Einfluss haben dürfte, ob sie nativ oder in einer VM abläuft.

Dietmar
dietmar
 
Beiträge: 151
Registriert: Montag 24. Februar 2014, 11:41
Wohnort: Hilden (in der Lichtglocke von Düsseldorf)

Re: M86

Beitragvon moos » Freitag 29. Mai 2020, 18:36

Hallo Dietmar,
Ich schiebe vor der Astrometrie immer ein "Binned preview" auf Astrometry.net. Das rechnet dann ein bischen rum und spuckt die Mittelpunktskoordinaten, Kameraorientierung, Pixelskaierung, ... aus, die ich dann an die Astrometrie verfüttere. So kann ich mit ziemlich kleinen Tolleranzen arbeiten und die Astgrometrie flutscht so durch (Theli 3/scamp 2.9).

Das ist ne gute Idee....

Die EOS1200D ist sehr leicht und zuverlässig. Ich hatte keine Lust auf 3 A für Kühlung. Aber ich neige schon wieder zu einer gekühlten Astrokamera. Sein Geld versenken kann man da ja auch sehr gut.
Ciao Carsten
moos
 
Beiträge: 504
Registriert: Dienstag 18. Oktober 2011, 19:06

Re: M86

Beitragvon moos » Dienstag 2. Juni 2020, 07:07

Hallo Dietmar,

dietmar hat geschrieben:Mir ist schon mal aufgefallen, dass Du bei der Astrometrie ziemlich große Tolleranzen zulässt. Ohne mich zu weit aus dem Fenster lehnen zu wollen möchte ich behaupten, dass die Astrometrie umso schneller und/oder zuverlässiger arbeitet, je kleiner die Tolleranzen sind.

Ich habe jetzt auch ein PA.fits aus theli online astrometriert und mir die Ergebnisseite angesehen. Daraus konnte ich die Toleranz von 2' aus 1' senken. Der Winkel ist 177° und da bin ich mit den 180° genau richtig. Ich habe das in theli2 auch immer so gemacht und da ging es viel schneller.
Ich denke, dass ich weniger Sterne in die Kataloge tun muss.

dietmar hat geschrieben:Wenn ihr Intel-CPUs auf Intel-CPUs virtualisiert, werden diese 1 zu 1 durchgereicht.
Was die virtuelle Maschine jedoch als Festplatte sieht ist eine Datei im Dateisystem der Host-Maschine. Dateisystemzugriffe sehen somit wie folgt aus:

Dateisystem des Guest
|
v
virtuelle Hardware
|
v
Dateisystem des Host
|
v
richtige Hardware

und das dauert eben.
So 'ne Build ist sehr Disk-IO-intensiv (da werden Header-Dateien eingebunden, die rekursiv sind bis der Arzt kommt). Die Astrometrie dagegen ist mehr CPU- als IO-intensiv (mischa, korrigier mich ggf.), so dass es keinen großen Einfluss haben dürfte, ob sie nativ oder in einer VM abläuft.

Es kann doch nicht sein, dass wir vor 10 Jahren schon ausreichend schnelle Hardware hatten und von Gigabyte RAM nur träumen konnten. Das aktuelle theli-Build dauert bei mir in der VM mit 4 CPU ca 15 Minuten. Das war vor 10 Jahren auch so mit einer CPU. Beides auf einer HDD. Damals 32 Bit und heute 64 Bit breite Adressen bedeutet natürlich, dass wir doppelt soviel RAM brauchen, für die gleiche Programmgröße. Aber das Programm theli ist ja ein Winzling.
Ich denke, dass die Virtualisierung nicht so stufenweise läuft, wie es deine Pfeile darstellen. Bedenke zum Beispiel DMA, da kann sich die VM einen direkten Kanal zum RAM machen oder die HAL ( Hardware Abstraction Layer) machen auch Zugriffe zwischen Guest und Host auf derselben Ebene möglich. Ich halte eine VM für nicht so benachteiligt. Was man sicherlich viel braucht, ist RAM, da beide Systeme mit 4 GB gerade so auskommen und da bin ich mit 8 GB wohl nicht gerade üppig bestückt.


Fazit: ich habe scamp nun auf eine Toleranz von 1' gesetzt und es braucht immer noch so lange, dass ich es abgebrochen habe. Wie gesagt, ich versuche die Kataloge zu reduzieren.
Ciao Carsten
moos
 
Beiträge: 504
Registriert: Dienstag 18. Oktober 2011, 19:06

Re: M86

Beitragvon spiegelei » Dienstag 2. Juni 2020, 07:53

Hi Carsten,
das klingt schon eigenartig. Ich arbeite mit deutlich größeren Positionstoleranzen und scamp schafft das i.d.R. ohne zu Murren in einer durchaus akzeptablen Zeit. Die Zahl der Referenzen liegt da bei 500....1000. Es wird von Scamp auch nur ein Kern benutzt. Scamp ist allerdings die aktuelle Version, selber gebaut. Vielleicht mag der alte Scamp in den neuen Systemen nicht mehr so richtig. Das Problem hatte ich mit DS9, da hat eine ältere Version im neuen System ewig gebraucht, ein aktuelles Build ist da deutlich schneller.

Gruß
Karsten
Atik 383 - AP80/560 - GSO RC 8" - LX50 8" SC - TSAPO65Q - CGEM
Theli 3 - SUSE Leap 15.1/64 - Dual XEON 12K/24T - 32GB
Die meisten großen Erfindungen beginnen nicht mit "HEUREKA" sondern mit "Das ist aber komisch....."
Benutzeravatar
spiegelei
 
Beiträge: 197
Registriert: Donnerstag 29. September 2011, 15:15
Wohnort: Chemnitz

Re: M86

Beitragvon dietmar » Dienstag 2. Juni 2020, 16:20

moos hat geschrieben:Das aktuelle theli-Build dauert bei mir in der VM mit 4 CPU ca 15 Minuten.
Bei mir dauert es mit 8 Kernen auf 'ner SSD 30s (in Worten dreissig, in Zahlen auch).

moos hat geschrieben:Damals 32 Bit und heute 64 Bit breite Adressen bedeutet natürlich, dass wir doppelt soviel RAM brauchen
Das kannst Du so pauschal nicht sagen. Adressen haben jetzt zwar 64 Bit, Ints auch (wenn Du nicht die hardwareunabhängigen aus der stdint.h benutzt), aber ein float hat immer noch 32 und ein double 64 Bit.

moos hat geschrieben:Bedenke zum Beispiel DMA, da kann sich die VM einen direkten Kanal zum RAM machen...
RAM wird natürlich, wie CPU-Kerne, 1:1 durchgereicht. Und das auch wenn Du 'ne Sparcstation oder einen Mac virtualisierst.

moos hat geschrieben:... oder die HAL ( Hardware Abstraction Layer)
Ist schon klar, dass Du keinen Kubrick-Film meinst :D

Ich nehme mal an, dass Du deiner VM keine eigene Platte zur Verfügung stellst (bei qemu geht das, ich weiss aber nicht womit Du virtualisierst), sondern eine Datei als Platte vorgaukelst. Und dann gilt das Bild da oben.

Wie dem auch sei:
Wie Karsten (mit "K") habe ich den Eindruck, dass das neue Scamp schneller und zuverlässiger arbeitet.
Hast Du das Alte vielleicht noch im Suchpfad?
Frag mal:
Code: Alles auswählen
scamp -v


Bis denn
Dietmar
dietmar
 
Beiträge: 151
Registriert: Montag 24. Februar 2014, 11:41
Wohnort: Hilden (in der Lichtglocke von Düsseldorf)

Re: M86

Beitragvon moos » Dienstag 2. Juni 2020, 20:45

Code: Alles auswählen
WARNING: This executable has been compiled using a version of the ATLAS library without support for multithreading. Performance will be degraded.
----- SCAMP 2.9.0 started on 2020-06-02 at 21:23:32 with 4 threads 1A----- 108 inputs:

Was ist die das für eine lib? Macht das scamp bei mir langsam?
Ciao Carsten
moos
 
Beiträge: 504
Registriert: Dienstag 18. Oktober 2011, 19:06

Re: M86

Beitragvon spiegelei » Dienstag 2. Juni 2020, 22:45

Hallo Carsten,
das mit der Atlas-lib ist wahrscheinlich eher Standard als Ausnahme wenn Du Atlas aus dem Ubuntu-Repository hast. Davon muessten aber dann (fast) Alle gleichermaßen betroffen sein. Wenn ich mir die Zahl der Dateien aus dem chi-Plot im anderen Fred ansehe wird dann wohl eher der Speicher der Flaschenhals sein. Wenn Thelie relativ wenig im Speicher halten kann und Linux anfangen muss zu swappen ist es schon denkbar, dass die Perfomance in die Kniehe geht.

Gruß
Karsten
Atik 383 - AP80/560 - GSO RC 8" - LX50 8" SC - TSAPO65Q - CGEM
Theli 3 - SUSE Leap 15.1/64 - Dual XEON 12K/24T - 32GB
Die meisten großen Erfindungen beginnen nicht mit "HEUREKA" sondern mit "Das ist aber komisch....."
Benutzeravatar
spiegelei
 
Beiträge: 197
Registriert: Donnerstag 29. September 2011, 15:15
Wohnort: Chemnitz

Re: M86

Beitragvon dietmar » Mittwoch 3. Juni 2020, 10:13

Moin Carsten,

die scamp-version ist schon die aktuelle. ATLAS ist so 'n Ding für lineare Algebra. Die hab' ich auch als Binärpaket für Debian, weil ich beim Versuch sie aus Sourcen zu bauen die Geduld verloren hab'.
Ich glaube was bei dir bremst sind die 108 Einzelframes zu je 68,7 MB (dein Sensor hat genauso viele Pixel wie meiner), was zusammen mit wenig RAM zu viel Disk-IO führt.

Gruß
Dietmar
dietmar
 
Beiträge: 151
Registriert: Montag 24. Februar 2014, 11:41
Wohnort: Hilden (in der Lichtglocke von Düsseldorf)

Re: M86

Beitragvon mischa » Mittwoch 3. Juni 2020, 10:52

Hallo ihr beiden,

scamp hat keinen grossen disk-io. Die Kataloge belegen jeweils ein paar 100 kB, und es werden nur winzige Dateien als Ergebnis rausgeschrieben. Scamp kann unter Umstaenden sehr speicherhungrig werden wenn viele Quellen geladen werden, aber das habt ihr ja in THELI leicht unter Kontrolle. Was lange dauert ist das matching. Wenn der Quellkatalog nicht richtig mit dem Referenzkatalog zusammenpasst, dann kann das dauern und ist nicht unbedingt von Erfolg gekroent. Hierzu habe ich hier schon Romane geschrieben und werde das an dieser Stelle nicht wiederholen. Meistens hilft es, die Anzahldichte der Quellen in den Katalogen (Bild und / oder Referenz) zu erhoehen oder zu erniedrigen.

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

Re: M86

Beitragvon moos » Mittwoch 3. Juni 2020, 17:43

Hi Mischa
mischa hat geschrieben:
scamp hat keinen grossen disk-io. Die Kataloge belegen jeweils ein paar 100 kB, und es werden nur winzige Dateien als Ergebnis rausgeschrieben. Scamp kann unter Umstaenden sehr speicherhungrig werden wenn viele Quellen geladen werden, aber das habt ihr ja in THELI leicht unter Kontrolle. Was lange dauert ist das matching. Wenn der Quellkatalog nicht richtig mit dem Referenzkatalog zusammenpasst, dann kann das dauern und ist nicht unbedingt von Erfolg gekroent. Hierzu habe ich hier schon Romane geschrieben und werde das an dieser Stelle nicht wiederholen. Meistens hilft es, die Anzahldichte der Quellen in den Katalogen (Bild und / oder Referenz) zu erhoehen oder zu erniedrigen.

Ja verstehe ich ja auch. Man muss probieren. Das ist nur nicht so leicht.
Ich habe jetzt mal nur ca. 30 Bilder und teste. Im Moment sind es pro Bild ca. 50 Sourcen und der TYC hatte nur 35 Sorucen, von denen 15 verwendet werden. Trotzdem alledem braucht scampt alle vier CPU zu 400% , allen Speicher ( > 90% ) und benötigt pro Bild etwa 1 Minute.
Ciao Carsten
moos
 
Beiträge: 504
Registriert: Dienstag 18. Oktober 2011, 19:06

Nächste

Zurück zu Ergebnisse

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

cron