Beiträge von j4s8

Morgen,

ich habe mir das gerade mal an einem meiner Bilder angeschaut. Die Bilder werden durch das php interface zu libgd angepasst (Exif-Tag "Comment : CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 90."). Das Bild das über "Originalversion aufrufen" (ganzen rechtes Symbol unter dem Bild) angezeigt wird, ist wirklich das unveränderte Bild, wie ich es hoch geladen habe (gleiche Checksum). Wenn also die "Originalversion" deines Bildes hier im Astrotreff im Browser auch den Grünstich hat, stimmt wohl die Farbwiedergabe von PI nicht mit der deines Browsers überein. Da kann der Astrotreff nichts dran ändern.

Gruß

Jörg

Hi Oliver,

das sind aber nicht die gleichen Dateien hier und im Nachbarforum.

Die hier ist 479kB groß bei 1807x1200 Pixel mit 80% JPEG-Kompression mit einem Google ICC-Profil

Das andere Bild 1.4MB bei 2061x1368 Pixel mit 95% Kompression mit einem Hewlett-Packard Farbprofil

Ich kann Dir anbieten deine Datei unverändert auf meinem Server abzulegen und Du schaust, ob dein Browser sie Dir anders anzeigt als deine Bearbeitungssoftware.

Gruß

Jörg

Hallo zusammen,

aus der Frankfurter Einflugschneise. Mit dem niedrigen Mond zur Zeit und nördlich der Einflugschneise sollte man meinen "da erwische ich ständig einen!", aber die meisten fliegen doch am Mond vorbei

Dar erste ist mit einem 100mm-300mm Tele und Lumix DC-G9 aufgenommen, das zweite gleiche Kamera und TS 80/480 Triplet.

Gruß

Jörg

Hallo zusammen,

bei den vielen tollen Zeichnungen traue ich mich kaum mal wieder ein Foto zu zeigen. Nach der obigen Diskussion um HN84 hab ich ihn mir mit den neuen TS 80/480 + 0.8 Reducer und Canon 600Da (22*20s ISO400) auch mal vorgenommen. Das ergab eine Pixelgröße von 2.3", damit ist HN84 mit 12 Pixeln knapp getrennt. Das ganze Bild mit reduzierter Auflösung ist hier: http://www.j4s8.de/galleries/sky/double-stars/#&gid=1&pid=9

Danke nochmal für die viele Arbeit mit der tollen Liste, ohne diese wäre ich nicht auf die Idee gekommen nach bunten Doppelsternen zu suchen. Hier der Ausschnitt mit eps Sge und HN84, extra exakt nach Norden ausgerichtet

Gruß & CS,

Jörg

Hallo Manfred,

das kommt aber auch auf die Übertragungsrate zu der externen Fesplatte an: USB 2.0 kann theoretisch maximal 60 MB/s, USB 3.2 2.5 GB/s, USB-C 5GB/s. Effektiv erreiche ich z.B. zu einem USB-Stick mit USB 3.2 128MB/s und zu einer externe SSD über USB-C bis zu 900 MB/s.

Steht an der USB-Buchse am PC neben dem USB-Symbol "SS" für SuperSpeed, dann hättest Du zumindest USB 3.0 mit max 625 MB/s oder besser. Ansonsten ist dein Laptop wahrscheinlich so alt, dass er nur USB 2 hat. Weiterhin wird Siril schneller, je mehr RAM Du hast. Ich vermute mal Du hast Windows laufen, dann bleibt bei 8GB, nicht mehr viel für Siril übrig.

Gruß

Jörg

Hallo zusammen,

die wenigen wolkenlosen Nächte in letzter Zeit haben nicht in meine sonstige Planung gepasst, deshalb habe ich mich nochmal über "alte" Bilder hergemacht und mit Siril und Starnet++ mein Bild des Kometen C/2022 E3 (ZTF) von Ende Januar neu bearbeitet. Dabei habe ich aus den Einzelframes die Sterne entfernt und anschließend nur den Kometen gestackt (ohne große Farbkalibrierung, deshalb ist der Komet sehr grün) und das Ganze über ein Bild nur mit Sternen gelegt. Hier das Ergebnis:

Details mit Zwischenschritten sind hier zu finden:

Kometen-Stacking ohne Sterne

und ein Zeitraffer des Komet C/2022 E3 (ZTF)

www.j4s8.de

Wie macht ihr das mit dem Kometen-Stacking?

Gruß & CS

Jörg

Hallo Peter,

Danke für den Hinweis, ich hab leider nicht mehr gefunden, wo ich die 300/crop/Brennweite Formel her hatte, sie mir aber als passendste gemerkt. Und ja $500/1.6\approx 300$, das hab ich vermutlich überlesen, da ich mit MFT fotografiere. Ich werde den Text anpassen.

Gruß

Jörg

Hallo zusammen,

um zum ursprünglichen Thema zurück zu kommen, hab ich mir nach @pete_xl's Kommentar die NPF-Regel mal angeschaut. Bisher hab ich immer mit der 300er Regel und dem verpönten Crop-Faktor (2 für MFT) meine Belichtungszeit angenähert.

Zitat von pete_xl

Daraus hat sich die 300er Regel für APS-C Kameras abgeleitet. Mittlerweile findet man im Netz für unterschiedliche Sensorgrößen einen ganzen Sack voller Empfehlungen (600er, 500er, 300er, 200er etc.). In Zeiten unterschiedlicher Pixelgrößen hat sich auch die so genannte NPF-Regel etabliert: Belichtungszeit = (35 x Blende + 30 x Pixeldichte) / Brennweite (Pixeldichte = Breite des Kamerasensors (mm) / Anzahl horizontaler Pixel des Sensors x 1000).

Die Formeln führen doch alle zu einer ähnlichen Kurve und mit dem Crop-Faktor wird sogar die 300er Regel konservativer. Ich hab dazu ein Programm geschrieben, in das jeder seine Parameter eingeben kann und die "ideale" Belichtungszeit anzunähern. Aber im Endeffekt, kommt es doch auf die örtlichen Gegenheiten (z.B. Seeing bei höheren Brennweiten), das eigene Equipment (z.B. Blende) und das persönliche Empfinden von Rundheit an. Das Programm ist hier zu finden:

Belichtungszeit ohne Nachführung

300er, 500er, NPF Näherungen und trigonometrische Berechnung

www.j4s8.de

Viel Spaß & CS

Jörg

Hallo,

für (Debian) Linux gibt es das Paket astrometry.net und mindestens astrometry-data-tycho2 für offline plate-solving. Das beinhaltet auch den Befehl plot-constellations, der ein transparentes PNG erzeugt, welches man sich über sein Bild legen kann. Hierbei kann die Schriftgröße ("-f") und Gitter ("-G", "-g") festgelegt werden. "-CBN" heißt plotte Konstellationen, bright stars, NGC. Das Ganze sieht dann etwa so aus:

$ solve-field -O -D solve-field result_4845s_GraXpert_stretched_mirrorx.fit 
Reading input file 1 of 1: "result_4845s_GraXpert_stretched_mirrorx.fit"...
Found an existing WCS header, will try to verify it.
Extracting sources...
This looks like a multi-color image: processing the first image plane only.  (NAXIS=3)
[...]
Field 1 solved: writing to file solve-field/result_4845s_GraXpert_stretched_mirrorx.solved to indicate this.
Field: result_4845s_GraXpert_stretched_mirrorx.fit
Field center: (RA,Dec) = (186.540262, 13.024913) deg.
Field center: (RA H:M:S, Dec D:M:S) = (12:26:09.663, +13:01:29.685).
Field size: 5.47372 x 4.10736 degrees
Field rotation angle: up is 155.451 degrees E of N
Field parity: neg
Creating new FITS file "solve-field/result_4845s_GraXpert_stretched_mirrorx.new"...

$ plot-constellations -J -CBN -G 60 -g 0.67:0.0:0.0 -f 72 -w solve-field/result_4845s_GraXpert_stretched_mirrorx.wcs -o overlay.png
NGC 4216
NGC 4254 / Virgo Cluster Pinwheel / Coma Pinwheel / M 99
NGC 4302
NGC 4374 / M 84
NGC 4388
NGC 4406 / M 86
NGC 4429
NGC 4438
NGC 4486 / Virgo Galaxy / M 87
NGC 4501 / M 88
NGC 4548 / M 91
NGC 4552 / M 89
NGC 4569 / M 90
{ 
  "status": "solved",
  "git-revision": 0.92,
  "git-date": "Sun_Nov_27_15:52:21_2022_-0500",
  "annotations": [
{ "type"   : "ngc",   "names"  : [ "NGC 4216" ],   "pixelx" : 4710.08,   "pixely" : 848.715,   "radius" : 61.9348 },
{ "type"   : "ngc",   "names"  : [ "NGC 4254", "Virgo Cluster Pinwheel", "Coma Pinwheel", "M 99" ],   "pixelx" : 3587.93,   "pixely" : 42.8823,   "radius" : 39.9171 },
{ "type"   : "ngc",   "names"  : [ "NGC 4302" ],   "pixelx" : 2913.65,   "pixely" : 165.14,   "radius" : 47.5203 },
{ "type"   : "ngc",   "names"  : [ "NGC 4374", "M 84" ],   "pixelx" : 2890.13,   "pixely" : 1966.08,   "radius" : 58.6876 },
{ "type"   : "ngc",   "names"  : [ "NGC 4388" ],   "pixelx" : 2828.23,   "pixely" : 2229.39,   "radius" : 42.6099 },
{ "type"   : "ngc",   "names"  : [ "NGC 4406", "M 86" ],   "pixelx" : 2628.24,   "pixely" : 2023.89,   "radius" : 91.3182 },
{ "type"   : "ngc",   "names"  : [ "NGC 4429" ],   "pixelx" : 3090.9,   "pixely" : 3734.24,   "radius" : 41.9763 },
{ "type"   : "ngc",   "names"  : [ "NGC 4438" ],   "pixelx" : 2273.94,   "pixely" : 2119.86,   "radius" : 72.5477 },
{ "type"   : "ngc",   "names"  : [ "NGC 4486", "Virgo Galaxy", "M 87" ],   "pixelx" : 1869.16,   "pixely" : 2947.67,   "radius" : 56.3116 },
{ "type"   : "ngc",   "names"  : [ "NGC 4501", "M 88" ],   "pixelx" : 831.794,   "pixely" : 1299.18,   "radius" : 68.5084 },
{ "type"   : "ngc",   "names"  : [ "NGC 4548", "M 91" ],   "pixelx" : 75.2907,   "pixely" : 1558.03,   "radius" : 43.9563 },
{ "type"   : "ngc",   "names"  : [ "NGC 4552", "M 89" ],   "pixelx" : 779.092,   "pixely" : 3264.39,   "radius" : 64.39 },
{ "type"   : "ngc",   "names"  : [ "NGC 4569", "M 90" ],   "pixelx" : 297.698,   "pixely" : 2847.02,   "radius" : 72.2309 }
]
}

$ gimp overlay.png result_4845s_GraXpert_stretched.fit

Die Schriftart ist leider hardcoded in der Datei plot-constellations. Wer will kann aber die Pixel-Koordinaten aus den JSON-Output (Option "-J") nehmen und sich selber z.B. ein SVG damit basteln. Es gibt auch noch mehr Kataloge zum plotten, die hab ich aber noch nicht ausprobiert. Das Ergebnis wäre hier dann:

Gruß

Jörg

Hallo,

um noch eine Alternative ins Spiel zu bringen: es gibt noch die IDAS NB? Filter, wobei das Fragezeichen für 1 (Ha+Hb+OIII), 3 (SII+OIII) oder Z (Ha+OIII) steht. Nach dem LEsen des Artikels https://astrogeartoday.com/fil…das-for-shooting-nebulas/ habe ich mich für IDAS NB1 entschieden, mir fehlt aber völlig der Vergleich zu anderen Filtern.

Gruß

Jörg

Hallo,

von mir gibt's zwei Fotos von Alamak mit dem MAK 127/1500 + 3x Barlow auf wackeliger Alt-Az Monitierung (die EQM-35 hat grad ne Schraube an der RA-Achse locker). Wobei ich sagen muss im 8mm Hyperion ohne Barlow waren die Farben viel knalliger. Das erste Bild ist der beste Einzelframes als JPG, wie es die Kamera verarbeitet hat, das zweite ein Stack aus 49 raw-Bildern 1s, ISO 800. Gecroppt auf 1024 Pixel, mit Originalauflösung.

Gruß

Jörg

Hallo zusammen,

also um ein paar Spekulationen hier zu beenden:

1.) Die Suchmaschinen filtern (leider) keine Inhalte von Klimawandelverharmlosern

2.) Astrotreff.de ist auf keiner der üblichen Blacklists: https://mxtoolbox.com/SuperTool.aspx?action=ptr%3a212.60.42.252&run=toolpage

3.) Beim SSL gibt es Optimierungsbedarf (unter anderem ist TLS 1.1 veraltet/unsicher): https://www.ssllabs.com/ssltest/analyze.html?d=astrotreff.de

Ich wünsche viel Spaß bei der Kommunikation mit Microsoft, falls sich überhaupt jemand/ein Mensch zurück meldet

Gruß

Jörg

Hallo zusammen,

es fehlt nicht nur die robots.txt, sondern auch die Datei sitemap.xml auf dem Server. Beide werden von den Suchmaschinen gelesen und ausgewertet. Normalerweise sollten die beiden Dateien durch eure Foren-Software erstellt werden. Falls ihr Backups habt, könnt ihr ja mal schauen, seit wann die weg sind und nachvollziehen warum.

Des Weiteren gibt es für Google die Search-Console. Dafür muss eine Datei "google<random>.html" im Server-root abgelegt werden und ihr könnt nachschauen, womit Google Probleme bei astrotreff.de hat. Für Bing gibt es equivalent Webmaster-Tools, das kenne ich aber nicht. Hier noch ein Beispiel für eine robots.txt:

Sitemap: https://astrotreff.de/sitemap.xml

User-Agent: *
Disallow: /bitte/nicht/indexieren

Wenn die sitemap.xml in der robots.txt steht, muss sie natürlich auch da sein.

Gruß

Jörg

Hallo zusammen,

danke für die weiteren Beiträge. Ich für mich habe entschieden, das nächste Mal Siril zum Stacken von Startrails zu benutzen.

dkracht unter "StarTraX" hab ich nicht gefunden, meinst Du vielleicht StarStaX?

Beide sind (leider) nur für Windows und/oder Mac.

Gruß

Jörg

Hallo,

Und danke für eure schnellen Vorschläge. im Nachbarforum hab ich grade den Hinweis bekommen, dass Siril auch unregistrierte Bilder stacken kann, dabei kommen dann super sSartrails raus, was meine Arbeit mit den Scripten überflüssig macht. Ichlebe seit über zwanzig Jahren privat Microsoft-frei, so soll es auch bleiben. Und Stativ ist selbstverständlich bei 27x 60s

Gruß

Jörg

Hallo zusammen,

beim Versuch meine erste Startrail-Aufnahme zusammenzufügen, habe ich ewig lange in Gimp herumgeklickt, bis ich alle Einzelaufnahmen vorverarbeitet und durch Aufhellen übereinander gelegt hatte. Darauf dachte ich mir, das muss doch auch automatisiert gehen und habe mich erstmal mit den ImageMagick-Befehlen in einem shell-Script abgemüht. Mit mäßigem Erfolg, bzw. sehr langsam. Mein zweiter Versuch mit Python war da schon wesentlich vielversprechender und ich denke für Dämmerung auf der einen und Vollmond-Aufgang auf der anderen Seite ist das Ergebnis für den ersten Versuch akzeptabel. Ich habe die Ergebnisse und Scripte hier veröffentlicht.

Nun meine Frage an diejenigen hier, die Opensource-Software unter Linux einsetzen und sich schon mal an Startrails versucht haben: Wie habt ihr die Einzelbilder prozessiert und übereinander gelegt?

Gruß & CS

Jörg

Hallo Seraphin,

Ich weiß ja nicht, was Du exakt mit Archivierung meinst. Willst Du alles Sichern (Backup), falls der Rechner kaputt geht? Oder willst Du in 10 Jahren noch wissen wie Du zu Deinen finalen Bildern gekommen bist oder "nur" neu gelerntes damit ausprobieren?

Für ersteres empfiehlt sich ein NAS (Network Attached Storage) mit RAID-5 (mindestens 3 Platten -> eine Platte kann ohne Datenverlust ausfallen) oder besser RAID-6 (mindestens 4 -> zwei Platten können ohne Datenverlust ausfallen) . Danach fragen die NAS-Geräte aber jeweils bei der Einrichtung. Wenn Du viel Geld hast und Dir eine teure Stromrechnung nichts ausmacht: RAID-50/-60. Außerdem hast Du jetzt ja nach einem Jahr etwa 1.2TB, es wird die nächsten Jahre nicht weniger werden. D.h. um die nächsten 5 Jahre über die Runden zu kommen, sollte die Kapazität >> 6TB sein. Da Du dann bestimmt auch Musik und andere Fotos drauf sichern wirst, solltest Du deutlich mehr nehmen. Ich habe z.B. ein RAID-6 mit 4x4TB, was mir 8TB Speicherplatz gibt + die Sicherheit, dass zwei Platten ausfallen können.

Anständige Archivierung ist etwas komplexer, beinhaltet aber auch das NAS: um Deine Ergebnisse möglichst reproduzierbar zu halten, solltest Du die Rohdaten aufheben + einen kurzen Text, wie Du zu dem jeweiligen Ergebnissen gekommen bist. Idealerweise sogar die Software in der entsprechenden Version (da diese sich ja weiter entwickeln) aber das ist für ein Hobby der Overkill. Zwischenschritte sind dann nicht mehr nötig.

Des weiteren solltest Du Dir eine Ordner-Struktur überlegen, wie oben einige schon geschrieben haben, also was ist eventuell wichtig:

• Welches Objekt?
• Welches Teleskop/Objektiv?
• Welche Montierung?
• Welche Kamera?
• Mit Filtern und welche?
• Datum?

Ich habe z.B. nur die Ordner <Objekt>/<Datum>, der Rest ist bei mir in den Metadaten der RAW-Bilder, da ich nur mit einer DSLM fotografiere.

Zum darauf Arbeiten ist eine NAS nicht zu empfehlen, dafür habe ich eine schnelle 1TB-SSD, die per USB-3 an meinem Laptop angeschlossen ist. Wenn Du einen Desktop-Rechner benutzt, ist eine interne SSD/NVMe natürlich noch besser.

BTW, ich arbeite als Sys-Admin an einer Uni und bin für das Langzeit-Archiv zuständig und Wissenschaftler, die sich vor ihren Projekten keine Gedanken machen und bei Projektende einfach alles archivieren wollen, am Besten in Millionen 1KB-Dateien ohne jegliche Dokumentation sind uns die liebsten. Wenn man sich rechtzeitig Gedanken macht wie hier, muss auch nicht jeder Müll archiviert werden.

Zitat von Picastro

In meiner Branche ist die Zeit teuer, daher speichern wir eben alles.

Gruß

Jörg

Guten Morgen,

Wenn ihr euch obige "Warnwetter-APP" des DWD mal anschaut, dann seht ihr bis etwa zum aktuellen Zeitpunkt die Messdaten (Satellit + Radar), dann für zwei Stunden die Wolken (+Niederschlag) wie sie vom Wind bewegt werden, die Form ändert sich aber nicht, d.h. Wolkenauflösung oder Nebelbildung sind hier nicht mit drin! Am besten sieht man das bei Gewittern, die sehr dynamisch sind und schwer zu berechnen. Dann kommt die Vorhersage, also eine Modellberechnung (bzw. Mittel aus mehreren). Diese Modellberechnungen werden aber nicht ständig durchgeführt, sondern etwa alle 6 Stunden, deshalb weichen sie grade bei Wolken von den Beobachtungen ab. Und da es nicht für jeden Gitterpunkt (räumlich + zeitlich, also 4D) eine exakte Messung gibt, werden diese Werte leicht variiert und mehrmals gerechnet (der berühmte Flügelschlag des Schmetterlings). Das nennt man dann Ensemble, woraus die Vorhersage berechnet wird.

Für den Bedeckungsgrad könnt ihr euch mal das hier ansehen und mit die Modelle wechseln. Mit ein bißchen Erfahrung findet ihr dann das Modell, welches für eure Location am besten passt: https://kachelmannwetter.com/d…falz/bewoelkungsgrad.html (Achso, Region natürlich wechseln).

Um zu sehen, wie die Vorhersage auseinander läuft, können auch die Ensemble-Member" für ausgewählte Parameter angeschaut werden, wobei die Bedeckung hier glaub nicht dabei ist: https://kachelmannwetter.com/d…-mainz/ensemble/rapid-id2 Auch hier könne die Modelle gewechselt werden!

Und natürlich wird die Vorhersage von allen angepasst, sobald es neue Daten gibt, je aktueller, desto genauer. Aber daraus einen verlässlichen Trend ableiten, ich weiß nicht ob das sinnvoll wäre.

Gruß

Jörg

Hi Gert,

der einzige Unterschied der mir noch auffällt, ist TCP MSS (maxumum segment size). "0" bedeutet eigentlich default (1448). Setze die mal auf Windows-Seite fix auf den Wert 1448 mit der Option "-M 1448".

Zum Kopieren, wo kopierst Du den hin? Auf die SD-Karte, eine externe USB-Festplatte (und hier SSD oder HDD)? Und wenn USB, in welchem Port steckt die Platte (die blauen sind die schnelleren). Du kannst die Schreibgeschwindigkeit mit `dd if=/dev/zero of=testfile bs=4M count=10 oflag=dsync && rm testfile` testen. Wenn Du das noch komplexer testen willst, gibt es den Befehl 'fio', der ist aber nicht installiert nehme ich an.

Gruß

Jörg

Hi Gert,

beim TCP-Protokoll gibt gibt es eine sog. "Window-Size". Die muss auf Server- und Client-Seite zusammen passen für optimalen Transfer. Von RPi zu RPi wird diese gleich sein. und von Windows aus unterschiedlich. Versuche es mal mit den Optionen "-V", um mehr Info zu bekommen und mit "-w 128k" von Windows aus, um diese Windowsize zu erhöhen.

Beim Datei kopieren, kommt es darauf an, worüber Du das machst, eventuell verschlüsselt? Dann ist eine CPU einfach langsamer als die Daten ankommen.

Gruß

Jörg