PSS Installationsproblem | Astronomie.de - Der Treffpunkt für Astronomie

PSS Installationsproblem

Wario

Mitglied
Hallo zusammen,

(vorab, ich komme mir ein wenig dämlich vor, aber ich frage doch mal öffentlich - es könnten ja noch mehr ein ähnliches Problem haben).

ich hatte Version 0.7.0 auf meinem Win10 installiert & benutzt, ohne Probleme.
Leider bekomme ich 0.8.0+ nicht zum Laufen.

Der Win Installer bricht direkt nach Angabe des Installationspfades mit der Fehlermeldung "could not read setup package" ab. Ich hab die Datei mehrfach heruntergeladen und auch Varianten probiert (als Admin, Kompatibilitätsmodus etc.) - immer das Gleiche.

Die direkte Python Installation geht auch nicht. Ich hatte verschiedene Python Versionen und Entwicklungsumgebungen installiert (u.a. Anaconda) und habe letztlich alles deinstalliert, Python 3.6 installiert, Pfade gecheckt usw.
Der Download klappt, alle Pakete werden sauber geladen.
Beim Aufruf kommt dann die Fehlermeldung "cannot load mkl_intel_thread.dll".
Auch hier habe ich ein paar Dinge probiert, wie z.B. die DLL aus dem Python Verzeichnis direkt ins PSS Verzeichnis zu legen, bisher ohne Erfolg.
Edit: gerade noch ein "pip3 install --upgrade planetary-system-stacker" ausgeführt, er hat auch einige Dateien aktualisiert, aber gleiche Fehlermeldung beim Start.

Für eine Idee wäre ich dankbar :)

Viele Grüße,
Mario
 

Rolf_Hempel

Mitglied
Hallo Mario,

das ist wirklich ein komischer Fehler. PSS wurde ja schon oft in beiden Varianten (mit Installer und über pip) auf Windows 10 installiert, aber dieser Fehler ist noch nie aufgetreten.

Nach Deiner Beschreibung bist Du ja kein unbedarfter Windows-Nutzer ohne jegliche Softwarekenntnisse. Was Du beschrieben hast, sollte eigentlich alles funktionieren. Da muss irgendetwas im System vermurkst sein. Verdächtig ja auch, dass beide Wege nicht funktionieren. Wieso sollte dasselbe Windows-Installationsprogramm, das auf x Systemen klaglos durchgelaufen ist, auf einmal das "setup package" nicht lesen können. Und dann die Sache mit der dll, die nicht geladen wird, obwohl im Verzeichnis vorhanden.

Tut mir leid, das lässt mich völlig ratlos! Vielleicht hast Du ja eine Virtual Machine (z.B. Ubuntu - Linux), in der Du es probieren könntest. In Ubuntu ist die Installation ganz einfach, weil dort Python 3 schon an Bord sind.

Schöne Grüße
Rolf

PS: Ist das Windows 10 auf dem neuesten Stand? Das wäre das Einzige, das ich mir noch vorstellen könnte.
 

Wario

Mitglied
Hallo Rolf,

danke für die Rückmeldung!
Mein Win10 ist auf dem neuesten Stand, und auch sonst hatte ich nie Probleme mit irgendwas.
Ich vermute, es liegt an den diversen Python Versionen und Entwicklungsumgebungen, die ich im Laufe der Zeit installiert hatte (ich hab ein paar Kurse zu maschinellem Lernen gemacht, da musste man die Umgebungen immer spezifisch einstellen.. gut möglich das da was durcheinandergekommen ist).

Also, ich hab eine frische Ubuntu VM aufgesetzt. Die Installation von PSS hat geklappt (Pip3 musste ich erst nachinstallieren).
Beim Start kommt aber auch eine Fehlermeldung:

~$ PlanetarySystemStacker
QObject::moveToThread: Current thread (0x283bf30) is not the object's thread (0x31f9ee0).
Cannot move to target thread (0x283bf30)

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/home/mario/.local/lib/python3.8/site-packages/cv2/qt/plugins" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl.

Abgebrochen (Speicherabzug geschrieben)

Das nur mal als feedback (fürs Kuriositätenkabinett), du musst mir nicht bei der Fehlersuche helfen, ich versuche mich da erstmal selber durchzuwühlen.

Danke nochmal,
Mario
 

felu999

Mitglied
Hallo und guten Tag,
ich bin Holger und neu hier. Und ich wollte letztes Wochenende auch einmal den PSS ausprobieren. Installiert habe ich ihn nach Anleitung auf einem Notebook mit einem frisch installierten Ubuntu 20.04. Die Installation verlief fehlerfrei, doch nach dem Start bekomme ich dieselbe Fehlermeldung wie Mario.
Leider konnte ich die Ursache bislang noch nicht herausfinden. Falls also jemand einen Tipp hat wäre ich sehr dankbar.
Viele Grüße
Holger
 

Rolf_Hempel

Mitglied
Hallo Mario und Holger,

das ist ja ein Mist! Ich habe mal nach der Fehlermeldung gegoogled. Hier habe ich eine Erklärung gefunden. Es scheint mit Versionsproblemen in OpenCV unter Linux zu tun zu haben. Diese Bibliothek wird von PSS benutzt.

Ich werde nach einer Lösung suchen. Wenn Ihr Euch mit Linux und Python auskennt, könntet Ihr es aber auch selbst versuchen. Jedenfalls hat es nichts mit dem PSS-Code selbst zu tun.

Schöne Grüße
Rolf
 

Rolf_Hempel

Mitglied
Hallo Mario und Holger,

jetzt habe ich das mal in einer frischen VM Ubuntu 20.04 (unter VMWare) ausprobiert. Ich hatte vorher dort schon PSS mit pip3 installiert und erfolgreich getestet. Jetzt habe ich das mit "pip3 install --upgrade planetary-system-stacker" auf die neueste Version 0.8.10 aktualisiert. Die Software funktioniert einwandfrei.

Ich kann mir beim besten Willen nicht erklären, warum das bei Euch nicht klappt. Habt Ihr vielleicht vorher irgendetwas anderes mit Python installiert, z.B. Anaconda? Mit Anaconda habe ich in der Vergangenheit die übelsten Erfahrungen gemacht, weil das Paket hinter den Kulissen einiges umdreht. Wenn nicht, sollte ein neues Ubuntu 20.04 doch immer dieselbe Software installieren.

Könnt Ihr vielleicht mal eingeben "pip3 list" und den Output hier posten? Ich habe mal den Output auf meinem System hier angehängt. Wenn unterschiedliche Pakete erscheinen, wäre das ja vielleicht eine Erklärung.

Schöne Grüße
Rolf
 

Anhänge

Wario

Mitglied
Mysteriös.
Ich habe ebenfalls eine frische VM erstellt (VirtualBox), und außer PSS zu installieren rein gar nichts gemacht. Nur pip3 musste ich noch installieren.
(In meiner Win-Umgebung hatte ich vorher Anaconda, gut möglich das daher die Problemen dort kommen.)

Ich habe den output mal verglichen - hier nur das delta:
certifi 2020.6.20
imagecodecs - nicht vorhanden
imageio 2.9.0
networkx 2.5
numpy 1.19.1
opencv-python 4.4.0.42
psutil 5.7.2
PyQT5 5.15.0
PyQt5-sip 12.8.1
scipy 1.5.2
tifffile 2020.8.25

Ich hatte allerdings eben ein paar Ratschläge aus deinem Link oben probiert (ohne Erfolg). opencv-python de- und neuinstalliert (allerdings noch nicht aus den sourcen kompiliert).

Viele Grüße, Mario
 

felu999

Mitglied
Hallo,
ich habe jetzt PPS zum Laufen bekommen, es muss wohl was bei der Installation von PPS schief gegangen sein.
Was habe ich getan:
Ich habe die Verzeichnisse .local/bin und .local/lib (liegen im Home-Verzeichnis) in .local/bin1 und .local/lib1 umbenannt (man kann sie auch löschen, habe ich am Ende auch getan).
Dann habe ich PPS mit pip3 install planetary-system-stacker neu installiert.
Und jetzt läuft es.
Ich habe jetzt nicht weiter analysiert was da schief gegangen war, aber irgendwas falsches muss ja wohl beim ersten Installationsversuch oder bei rgendenem Update (pip, pps, ich weiß nicht) in die Verzeichnisse gelangt sein.

Ich hoffe ich kann hiermit helfen.

Viele Grüße und gute Nacht
Holger
 

felu999

Mitglied
Nachtrag:
Ich glaube ich habe den/die Übeltäter gefunden:
Bei der nicht lauffähigen Version gab es im Verzeichnis local/lib1/python3.8/site-package die Unterverzeichnisse PyQT5*
Hier war wohl aus irgendeinem Grund eine (inkompatible ?) PyQT5 Installation mit hineingeraten. Warum kann ich nicht mehr nachvollziehen.
Viele Grüße Holger
 

Rolf_Hempel

Mitglied
Hallo Holger,

vielen Dank für die Erfolgsmeldung! Das ist wirklich merkwürdig. Ich kann mir nur vorstellen, dass die inkompatiblen PyQT5*-Verzeichnisse schon vor der PSS-Installation da waren. Das pip3-Skript von PSS lädt ja nur die Bibliotheken, die auch wirklich gebraucht werden. Da kann ich mir nicht vorstellen, dass ab und zu mal etwas "Beifang" mitgeschleppt wird.

Die Frage wäre jetzt, wie diese Verzeichnisse da hingekommen sind. Vielleicht warten wir einfach mal, ob sich weitere Ubuntu 20.04-User mit Problemen melden. Auf "Cloudy Nights", wo viel mehr PSS-Interessenten unterwegs sind als hier, habe ich von sowas noch nichts gehört. Auch mit anderen Linux-Versionen scheint es da geklappt zu haben.

Auf jeden Fall bin ich froh, dass es jetzt auch bei Dir funktioniert.

Schöne Grüße
Rolf
 

felu999

Mitglied
Hallo Rolf,
das lässt sich leider so jetzt nicht mehr herausfinden, dazu müsste ich dann wohl den Rechner nochmal komplett neu aufsetzen. Aber so wichtig ist mir das dann auch wieder nicht als dass ich diese Zeit nochmal investiere. Schließlich läuft PSS ja jetzt. Und vielleicht hilft mein Tipp ja auch Mario.
Noch einen schönen Sonntag
Holger
 

Sven_Wienstein

Mitglied
Hallo Zusammen,

sollte jemand auf der Suche nach Hilfe zur Fehlermeldung "cannot load mkl_intel_thread.dll" in diesen Thread geraten: Hier fehlte in meinem Fall die Pfadangabe zur "libiomp5md.dll".
Um das zu reparieren:
- In die Windows 10 Suche "Umgebungsvariablen" eingeben, dann findet man "Umgebungsvariablen für dieses Konto bearbeiten". Das Klickt man an.
- Es öffnet sich ein Fenster, in dem es zwei Bereiche gibt. Der obere heißt "Benutzervariablen für ..." mit dem eigenen Benutzernamen. Hier klickt man auf "Path" und dann auf "Bearbeiten...".
- Es geht ein Fenster mit den eingestellten Suchpfaden für Programmdateien auf. Auf Neu klicken und in der ersten freien Zeile kann man dann dies einfügen:
C:\Users\__MEINKONTO__\AppData\Local\Programs\Python\Python36\Library\bin
Bitte dabei __MEINKONTO__ ersetzen durch Euren Benutzerordner. Wenn ihr unsicher seit, schaut in den vorhandenen Einträgen, die mit c:\users\... anfangen. Direkt danach folgt Euer Benutzerordner.

Die Fenster dann schließen und falls noch eine Konsole offen ist, diese auch zumachen und neu öffnen (sie übernimmt den neuen Suchpfad sonst nicht). Der nächste Startversuch klappt dann - wenn sonst nichts ist.

Clear Skies
Sven
 

Wario

Mitglied
Hallo,

spätes feedback (Dienstreise..):

Sven, dein Tipp hat funktioniert! Im Pfad war nur das python Stammverzeichnis und /scripts, nicht aber Library/bin.
(Da waren auch noch Überbleibsel bzw. Pfade von vorherigen Python3.8 Installationen, die ich gelöscht habe..)

Der Win Installer funktioniert übrigens jetzt auch (wieder).
Für weiter tests unter Ubuntu hatte ich leider bis jetzt keine Zeit.

Danke & viele Grüße,
Mario
 

Rolf_Hempel

Mitglied
Hallo Sven, hallo Mario,

diesen Tipp habe ich vor ein paar Tagen auch von einem anderen User bekommen. Ist eigentlich blöd, dass die Installationsroutine von Python 3 diesen Ordner nicht in den Pfad aufnimmt. Wie sollen die dlls dort dann bloß gefunden werden. Ich werde das ins Handbuch aufnehmen, wenn ich keine andere Lösung finde.

Schöne Grüße
Rolf
 

Sven_Wienstein

Mitglied
Hallo Rolf,

noch eine Rückmeldung: Mein Eindruck ist, dass bei der Abarbeitung mehrerer Jobs der Speicher praktisch nicht bereinigt wird. Gleichzeitig scheinen die Zugriffszeiten für Objekte erheblich zu steigen (obwohl ich kein Swappen feststelle). Das schließe ich daraus, dass ich bei einer Reihe kleinerer Jobs trotz vergleichbarer Größe immer mehr Speicherbelegung und schließlich sehr lange Verabeitungszeiten hatte.
Bei mehreren größeren Jobs kam immer bei Job #2 der Ausstieg mit Hinweis auf Buffer-Level, da durch Job #1 schon 11GB belegt waren und nicht freigegeben wurden. Nach einem Neustart einzeln vorgenommen gingen die Jobs durch, um das Schließen von PSS nach jedem Job kam ich aber nicht herum. Auch dann wurden im Taskmanager hohe RAM-Belegungen gezeigt.

Außerdem hatte ich mir vom Config-Schalter Debayer-Default = grayscale erhofft, dass nicht debayert würde. Ich bekam aber eine sw-Aufnahme mit Farbrauschen als Ergebnis. Wird das Debayer zwangsweise durchgeführt, wirkt es automatisch als Rohbild-Weichzeichner für IR-Frames mit Kameras, deren Bayermatrix im IR transparent wird (z.B. Sony IMX 290, IMX 462). Bei U-Aufnahmen, die scheinbar auch mit viel mehr Chips, wie dem IMX 178 gehen, dürfte es praktisch genauso stören. Sollte das wirklich nicht funktionieren: Nicht schlimm, muss man nur wissen und einen Lauf mit PiPP vorschalten.

Clear Skies
Sven
 

Rolf_Hempel

Mitglied
Hallo Sven,

das Problem mit der RAM-Freigabe kenne ich. Das ist in Python nicht einfach zu lösen. Tatsächlich lösche ich am Anfang eines jedes Jobs die Datenobjekte des Vorgängers, aber der Garbage-Collector wartet manchmal zu lange mit der tatsächlichen Freigabe. Das passiert aber nur im interaktiven Modus, d.h. mit GUI. Deswegen ist mein Vorgehen so: Ich führe den ersten Job mit GUI durch und setze alle Parameter (dafür hat man ja die GUI). Dann starte ich PSS neu, lade alle weiteren Jobs und setze das "Automatic"-Kästchen für Batch-Prozessierung. Dann funktioniert die Speicherfreigabe nach jedem Job.

Auf meiner Roadmap steht schon, dass ich das Problem auch bei GUI-Verwendung lösen möchte. Aber dafür habe ich noch keine Lösung gefunden. Unterstützung durch Python-Experten auch hier im Forum wäre natürlich wie immer willkommen.

Was das "Debayering" angeht, muss man sehr genau sein in der Beschreibung, was man macht. Das kann ich aus Deinem Text nicht präzise genug verstehen. Ich versuche mal zu beschreiben, was genau passiert: Wenn PSS ein 3-Kanal-Bild zu verarbeiten hat, kann es eigentlich kein "Grayscale" sein. Wenn man aber "mit Gewalt" die Debayer-Option auf "Grayscale" gesetzt hat, wird das Farbbild in S/W umgewandelt. Das Ergebnis ist ein 1-Kanal-Bild. Insofern wird "nicht debayert", wie Du es Dir erhofft hast. Wenn "Farbrauschen" im Bild war, wird es natürlich auch im B/W-Bild irgendwie ankommen.

Eigentlich interessant ist die Option "Grayscale" dann, wenn der Input ein 1-Kanal-Bild ist. Dann wird nicht debayert, und das Ergebnis ist wie das Eingabe-Frame. Mit den anderen Optionen kannst Du festes Debayering einschalten, je nach Bayer-Matrix, oder mit der Automatic-Option PSS die Entscheidung überlassen. Durch dieses Debayering wird aus dem 1-Kanal-Input ein 3-Kanal-Color-Output. Im "Automatic"-Fall analysiert PSS tatsächlich die Pixel der Bayer-Matrix mit statistischen Verfahren, um die Lage des rauschanfälligsten Kanals zu finden. Das ist immer Blau. Die Lage von Rot und Grün ergibt sich daraus. Sollte diese Automatic mal nicht funktionieren, bleibt nur noch die explizite Angabe des Bayer-Patterns. Das ist aber nur relativ selten nötig.

Ich habe über diese Technik lange mit Chris Garry, dem Autor von PIPP, korrespondiert. Die oben beschriebene Strategie habe ich mit ihm abgestimmt und finde sie nach wie vor optimal.

Beste Grüße
Rolf
 

Sven_Wienstein

Mitglied
Hallo Rolf,

möglicherweise ein Bedienfehler von mir. Es könnte sein, dass ich den Parameter umgestellt habe, nachdem die Datei bereits in der Job-Liste aufgenommen war. Dass man die Behandlung für Dateien in der Job-Liste einzeln umstellen kann, habe ich erst später gefunden.

Was die Garbage-Collection angeht: Es reicht ja, wenn in der Gui noch irgendein Verweis auf die Datenstruktur des Jobs steht. Das dürfte am ehesten die Go-Back-Logik-sein, oder gerne übersehen: Rückmeldungen in der Statusleiste.

Viele Grüße
Sven
 

Rolf_Hempel

Mitglied
Hallo Sven,

ja, der Default-Parameter wird bei der Jobdefinition übernommen. Wenn Du ihn nachher änderst, wirkt sich das nur auf spätere Jobs aus. Das halte ich auch für einigermaßen plausibel. Sonst gäbe es ziemliches Chaos. Aber besser ist sowieso die jobspezifische Setzung mit Kontext-Menu.

Klar, solange eine Referenz aus der GUI aktiv ist, tut der Garbage-Collector von sich aus nichts. Aber ich versuche ihn ja durch explizite Aufrufe in der Form "del(object)" trotzdem dazu zu bewegen, das Objekt zu löschen. Aber das hilft nichts. Leider ist die GUI-Logik so umfangreich, dass es die Suche nach der Nadel im Heuhaufen ist. Ich muss mal meine Python-Experten im Institut fragen, ob sie mir ein Diagnosetool empfehen können.

Schöne Grüße
Rolf
 

Sven_Wienstein

Mitglied
Hallo Rolf,

Speicherdiagnose kostet meiner Erfahrung nach immer Geld, teils nicht wenig. Eventuell rettet man sich bei Community-Projekten mit einer 30 Tage Probierfrist, aber das ist eigentlich auch an jemandem Vorbei, dessen Lebensunterhalt dran hängt.

Was ich aus Erfahrung beisteuern kann, ist das wenigstens unter Windows etliche "seltsame" Mechanismen am Werk sind, die Speicher im Grafikbereich auffuttern. Da reicht es, einen Brush zum Fontrendern zu definieren, und die Windows GDI+ bleibt auf dem Pointer hocken, bis man ihr den entreißt. Interessant wäre also die Eingrenzung, ob es da betriebssystemspezifisches Verhalten gibt, oder ob man innerhalb von Python suchen darf.
Ich kenne ja den Code nicht und Python ist auch nicht mein Ding. Ich würde in der Situation versuchen, eine GUI-Verknüpfung nach der anderen abzustellen, bis die Garbage-Collection hoffentlich auf einmal reagiert. Dann die anderen Sachen wieder einschalten und dadurch schauen, ob noch eine zweite Verknüpfung den Speicher blockt, und schließlich überlegen, wie man die kritischen Verknüpfungen sauber wieder abbaut, wenn der Job erledigt ist. Es kann ja etwas ganz profanes sein. Z.B. sollten die Einträge in der Combo-Box der Go-Back-Logik einen Pointer haben, und sollte der nun auf eines der Controls mit der Frame-Selektion, der ROI-Auswahl usw. zeigen, reicht das schon, damit der Garbage-Kollektor die Objekte für in Benutzung hält und über die Vorschau in den Controls hängen dann die ganzen Daten im Speicher fest. Überhaupt ist GDI+ und Windows Forms sehr zickig, was das Blocken von Bitmaps betrifft. Bei etlichen Grafikoperationen wie Skalieren bleiben z.B. die Quellbitmaps im Speicher liegen und müssen explizit einen Dispose-Aufruf bekommen.

Clear Skies
Sven
 

Rolf_Hempel

Mitglied
Hallo Sven,

vielen Dank für Deine Gedanken zum RAM-Problem. Um hier wirklich weiterzukommen, müssten wir allerdings über die Details des Python-Codes sprechen. So glaube ich z.B. nicht daran, dass das "Go back to"-Menü ein Problem ist. Zu dem Zeitpunkt, wo ich die Objekte des letzten Jobs lösche, gibt es keine Rücksprungmöglichkeit mehr zu einzelnen Phasen des letzten Jobs. Man kann nur mit dem letzten Job nochmal von vorn beginnen. Aber dann werden die Datenobjekte neu angelegt.

Natürlich wäre es schön, wenn ich das Aufräumen dem Garbage-Collector überlassen könnte und nur die Zugriffe entsprechend gestaltete. Aber gerade für den Fall, dass das (wie hier) kompliziert ist, man aber genau weiß, was man tut, gibt es in Python das "del"-Kommando. Damit sollte man ein Datenobjekt löschen können, auch wenn in der GUI noch Referenzen darauf vorhanden sind. Man ist dann eben selbst dafür verantwortlich, dass die GUI danach das Objekt nicht doch noch nutzt. All das habe ich versucht, aber es hat nicht geklappt. Wie gesagt: Hier brauche ich Hilfe von wirklichen Python-Experten. Wegen Corona sehe ich meine Mitarbeiter nicht mehr wie früher z.B. beim Mittagessen. So gibt es weniger Gelegenheit, solche Themen mal zwischendurch anzusprechen. Aber ich habe es nicht vergessen.

In der Zwischenzeit funktioniert zumindest im Batch-Betrieb der Workaround, den ich in meinem Post von gestern Morgen beschrieben habe.

Schöne Grüße
Rolf
 

sky_24

Mitglied
Hallo Rolf und Experten,

ich bin ganz frisch dabei und sage zuerst herzlichen Dank für Deine Initialzündung des Projektes.
Dir und auch Manfred Gentsch besonderen Dank für die deutsche Doku - ja, auch wenn sie Dir "Bauchschmerzen" bringt. Da habe ich volles Verständnis für. Prima wäre es auf jeden Fall, wenn die DEU Doku nicht zu schnell wieder "sterben" muß.
Zumindest habe ich mich jetzt hingesetzt und wollte PSS zum Laufen bringen.
Das hat noch nicht geklappt. Im Gegensatz zu allen obigen Beiträgen bin ich python-/befehls-/terminal-/computertechnisch nicht sooo bewandert... (mein Problem habe ich oben zumindest nicht herauslesen können)
Spannend war für mich schon der Begriff "Terminal" und "da was eingeben".
Aber gut, hab's schnell gefunden :)

Mein System:
macOS Catalina 10.15.6
Zunächst fehlte für ein weiteres Vorgehen "Command Line Developer..." Apple wollte mich direkt zur Installation bringen :) nach kurzer Zeit kam die Meldung "nicht verfügbar" :-(
Ich hab's dann per Suche manuell gefunden - und toll: hat geklappt! :)
Nächster Schritt im Terminal: Python war drauf :) --> Python 3.8.2 (default, Aug 25 2020, 09:23:57) :)
Nächster Schritt im Terminal: quit()
Nächster Schritt im Terminal: pip3 --> sieht gut aus, es werden eine Reihe von Kommandos und Optionen angezeigt
Nächster Schritt im Terminal: pip3 install planetary-system-stacker
--> :) es läuft! Viele schwarze Downloadbalken folgen :)
...dann stand ich erst mal auf, da ich nicht wußte wie lange das noch so geht...
...kam wieder: viele rote Zeilen :-( - (etwa 5 Seiten lang)

Zusammenfassung davon (Versuch):
kurz bevor "Feierabend" war:
...
...
Collecting decorator>=4.3.0 (from networkx>=2.0->scikit-image->planetary-system-stacker)
Downloading https://files.pythonhosted.org/pack...e7cc6df0/decorator-4.4.2-py2.py3-none-any.whl
Building wheels for collected packages: psutil
Building wheel for psutil (setup.py) ... error
ERROR: Command errored out with exit status 1:
command: /Library/Developer/CommandLineTools/usr/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/private/var/folders/zj/2_v_08j51_z6vh23pqwm79600000gp/T/pip-install-lxqat9_3/psutil/setup.py'"'"'; __file__='"'"'/private/var/folders/zj/2_v_08j51_z6vh23pqwm79600000gp/T/pip-install-lxqat9_3/psutil/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /private/var/folders/zj/2_v_08j51_z6vh23pqwm79600000gp/T/pip-wheel-okutjeug --python-tag cp38

cwd: /private/var/folders/zj/2_v_08j51_z6vh23pqwm79600000gp/T/pip-install-lxqat9_3/psutil/
Complete output (141 lines):
running bdist_wheel
running build
running build_py
creating build
creating build/lib.macosx-10.14.6-x86_64-3.8
creating build/lib.macosx-10.14.6-x86_64-3.8/psutil
copying psutil/_pswindows.py -> build/lib.macosx-10.14.6-x86_64-3.8/psutil
...
...
...
usw.

MacOSX.sdk/usr/include/sys/_types/_va_list.h:31:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
#error architecture not supported
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
error: command 'xcrun' failed with exit status 1
----------------------------------------
ERROR: Failed building wheel for psutil

Running setup.py clean for psutil
Failed to build psutil
Installing collected packages: PyQt5-sip, PyQt5, numpy, astropy, psutil, cycler, certifi, pillow, pyparsing, kiwisolver, python-dateutil, matplotlib, scipy, imageio, PyWavelets, tifffile, decorator, networkx, scikit-image, opencv-python-headless, intel-openmp, mkl, planetary-system-stacker
ERROR: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: '/Library/Python/3.8'
Consider using the `--user` option or check the permissions.

WARNING: You are using pip version 19.2.3, however version 20.2.3 is available.
You should consider upgrading via the 'pip install --upgrade pip'


Zusammenfassung davon (Versuch) Ende


Nun steh' ich auf'm Schlauch.

- psutil: Da scheint wohl der Hund begraben? Was gibt es da zu tun - für einen Normalsterblichen ;-)
- Was mir auffiel: Bei...
creating build
creating build/lib.macosx-10.14.6-x86_64-3.8

Ich habe, wie oben erwähnt: macOS Catalina 10.15.6 (Problem ...10.14.6 / 10.15.6 ???)
- Die grüne Warnung bezüglich pip Version ist denke ich zu ignorieren?
- Wenn nicht, was dann?

Ich hoffe Euch mit meinen Angaben geholfen zu haben und freue mich, wenn es einfach umzusetzende Ideen gibt :)

Gruß, Olaf
 

Rolf_Hempel

Mitglied
Hallo Olaf,

da ich noch nie einen Mac auch nur angefasst habe, kann ich auf diesem System leider keine Ünterstützung leisten. Vielleicht findet sich ja ein Mac-User, der PSS schon installiert hat (vielleicht sogar auf Catalina)?

Schöne Grüße
Rolf
 
Das Homepagetool mit der aktuellen Mondphase u.v.m.

(Alle Angaben für 10 Grad ö.L. Länge / 50 Grad n.B.)

In Kooperation mit www.Der-Mond.org Hole Dir jetzt das kostenlose Mondtool für Deine Homepage

Oben