Python et ImageMagick

Il faut que tu utilises quelques options bien choisies pour régler le délai entre deux images.

Qu'est-ce que ça donne si tu convertis les fichiers pdf en png :

mogrify -format png fichierTemp*.pdf

Est-ce que les png obtenus sont corrects ?

Tu as dix images à renuméroter, préfère cette méthode, ça sera moins prise de tête.

Je ne pense pas que ce soit ImageMagick qui prend les images dans l’ordre lexicographique, c’est le shell de Windows.
En effet, un moyen de contourner ça serait d’aller chercher la liste des fichiers de la forme fichierTemp*.pdf avec le module scandir. Ensuite tu tries les fichiers à l’aide de Python.
Sans expression régulière, tu peux le faire comme ça :

from os import scandir

liste=list()
for fichier in scandir("tonrépertoire"):
  nom=fichier.name
  if nom.startswith("fichierTemp") and nom.endswith(".pdf"):
    numéro=int(nom[11:-4])
    liste.append((numéro,nom))

liste.sort()

commande="magick convert "
for _,fichier in liste:
  commande+=fichier+" "
commande+=" -set delay 50 -layers Optimize Modele_animation_001a.gif"

# Et hop, un coup d’os.system pour finir…

Tu peux écrire la fin de cette manière plus élégante :

commande="magick convert "+" ".join(fichier for _,fichier in liste)+" -set delay 50 -layers Optimize Modele_animation_001a.gif"

Chouette, je ne connaissais subprocess.run. Merci du tuyau.

@Alban_

Nicolas à répondu au sujet de sys.argv. L'erreur que tu as rapportée provient probablement du fait qu'il n'y a d'exécutable 'spleeter' (tel que spleeter.exe, spleeter.com ou spleeter.bat[1]) dans aucun répertoire de ton PATH.

Il faut procéder méthodiquement. subprocess.run() lance le programme spécifié par le premier élément de la liste passée en argument, en le cherchant dans le PATH sauf si tu as passé un chemin au lieu d'un simple nom de fichier (par exemple, "machin\truc\spleeter.exe" ou "C:\machin\truc\spleeter.exe" : le premier est un chemin relatif, le second un chemin absolu). Il faut donc vérifier que tu peux effectivement lancer un tel programme (spleeter.exe, spleeter.com ou spleeter.bat) de cette manière. Essaie donc en ligne de commande avec cmd.exe.

La variable d'environnement PATH contient une liste de dossiers (= répertoires) séparés par des ';' sous Windows (':' sous Unix). Dans un terminal tel que celui ouvert par cmd.exe, tu peux afficher sa valeur avec :

echo %PATH%

Il est aussi possible de la consulter et la modifier à partir d'un menu Windows, je te laisse chercher avec ton moteur de recherche préféré (p. ex. "Windows modify PATH environment variable"). C'est probablement dans Paramètres système ou quelque chose comme ça.

Si tu n'arrives à lancer la commande spleeter que depuis le répertoire où se situe l'exécutable (spleeter.exe, spleeter.com ou spleeter.bat), cela suggère que tu peux régler le problème :

• soit en ajoutant ce répertoire à ton PATH ;
• soit en mettant dans ton script[2] le chemin complet menant au répertoire contenant l'exécutable 'spleeter' (quelque chose comme "C:\machin\truc\spleeter.exe").

La deuxième solution est moins invasive mais a pour conséquence que si tu veux réutiliser ton script sur une autre installation de Windows, il faut vérifier que le chemin utilisé dans le script est bien celui où est installé l'exécutable 'spleeter'.

Note : dans la fenêtre crée par cmd.exe, la commande 'cd' permet de changer de répertoire. Le répertoire courant est affiché au début de chaque ligne avant le signe '>', en principe — il fait partie du « prompt ».

Comme Microsoft a choisi de rendre ses utilisateurs... dépendants d'autrui et vulnérables aux attaques les plus grossières (genre : 'chat-trop-mignon.exe' affiché comme 'chat-trop-mignon' <- double-clique sur moi en croyant que je suis un fichier image et tu es infecté), il se peut que sur ton système, l'explorateur Windows n'affiche pas les extensions des fichiers telles que .exe, .bat, etc. Dans ce cas, pour les voir, il faut décocher une option de l'explorateur qui doit s'intituler Masquer les extensions de fichiers, ou quelque chose comme ça.

[1] Il y a probablement d'autres extensions qui peuvent intervenir, du genre .lnk.
[2] Précisément, dans le premier élément de la liste passée à subprocess.run().

Edit : ajout de la note sur la commande 'cd'.

Tout à fait d'accord avec ton dernier paragraphe : il est a priori inutile de modifier le PATH tant que tu n'arrives pas à lancer spleeter à la main, après t'être rendu dans le bon répertoire (= dossier).

Je n'ai jamais utilisé anaconda, mais il y a des choses qui ont l'air assez standard dans ce que tu as mentionné. Dans .../Lib/site-packages/spleeter, ce n'est pas très surprenant que cela ne fonctionne pas : il doit y avoir là les modules Python composant spleeter : ils sont faits pour être importés depuis un (autre) module Python avec la commande Python 'import'. Ce sont donc des bibliothèques Python, en quelque sorte, pas des exécutables à lancer directement (directement signifiant ici « hors contexte Python » : depuis cmd.exe, avec subprocess.run() qui lance un programme quelconque sans se soucier du langage dans lequel il est écrit, etc.).

La bonne piste est à mon avis ton Scripts/spleeter.exe. Il faudrait voir le message d'erreur. Il y a peut-être des choses spéciales à faire pour pouvoir l'utiliser s'il a été installé par anaconda, mais comme ça, je ne saurais dire lesquelles. Peut-être que le message d'erreur nous donnera des idées.

Note : il est possible de lancer un exécutable sans être dans le répertoire qui le contient, et le résultat n'est pas équivalent. Si tu es dans C:\...\machin\Scripts avec cmd.exe et que tu lances :

spleeter argument1 ... argumentn

spleeter.exe va voir qu'il est lancé depuis le répertoire C:\...\machin\Scripts (pour le processus exécutant le programme, c'est le répertoire courant tant qu'il ne le change pas en utilisant un truc comme os.chdir()). Mais tu peux aussi te placer dans C:\...\machin et lancer :

Scripts\spleeter argument1 ... argumentn

Dans ce cas, le répertoire courant au lancement de spleeter.exe est C:\...\machin. Ce n'est donc pas la même chose que dans le cas précédent. Par exemple, si le programme essaie d'ouvrir un fichier en donnant un chemin relatif, ce sera relatif au répertoire courant. Cas extrême : on peut aussi se placer « n'importe où » et lancer

C:\...\machin\Scripts\spleeter argument1 ... argumentn

Le répertoire courant au lancement de spleeter.exe sera alors le « n'importe où » choisi.

Le répertoire depuis lequel on lance le programme peut donc avoir une influence sur le bon déroulement des choses. Je ne dis pas que c'est ça qui pose problème ici(*), mais il peut être utile de l'avoir en tête.

(*) À moins qu'il y ait une bonne raison, on ne fait généralement pas dépendre le bon déroulement d'un programme de son répertoire de lancement, car ça n'est pas très convivial...

Concernant cette erreur :

from . import _mklinit
ImportError : DLL load failed: Le module spécifié est introuvable.

_mklinit est certainement un module Python écrit en C, C++ ou autre langage et compilé sous forme de DLL. Les DLL utilisent également le PATH pour se charger, donc il se peut que le fichier correspondant, _mklinit.dll ou quelque chose du genre, ne soit pas dans le PATH, ou encore qu'une dépendance — directe ou indirecte — de ce fichier ne le soit pas (si la DLL est dynamiquement liée à d'autres DLLs). Cela s'explique sans doute par le fait que tu dois probablement « activer un environnement » pour utiliser certaines choses installées par *conda hors contexte (p. ex., depuis cmd.exe). Voir par exemple ce qui est écrit ici.

Le lien précédent vient de cette page. Comme tu peux le voir, il y a pas mal de solutions proposées, dont certaines consistent à récupérer le « bonne valeur » de PATH avec 'echo %PATH%' depuis le prompt Anaconda, puis à ajouter au PATH global de Windows les chemins additionnels présents dans le PATH récupéré depuis le prompt Anaconda.

En fait, comme tu travailles en Python, tu n'es pas rigoureusement obligé de modifier ton PATH global si le problème est bien celui-ci. Tu peux :

• récupérer l'environnement courant avec os.environ.copy() (c'est un object de type 'dict') ;
• ajouter les répertoires manquants au PATH dans la valeur récupérée (pas dans os.environ lui-même) ;
• transmettre le nouveau 'dict' représentant l'environnement souhaité à subprocess.run() via son argument 'env'.

Avantage : tu ne modifies pas ta config Windows et tu changes le PATH uniquement à l'endroit nécessaire. Le reste de ton programme tourne avec le PATH normal (c'est pour ça que j'utilise dict.copy() ici). Inconvénient : ce n'est pas portable car les chemins à ajouter seront potentiellement différents sur un autre ordi.

[ Note par rapport à ta réponse et à mon message précédent : si tu souhaites lancer spleeter.exe dans un répertoire particulier (c'est-à-dire choisir le répertoire courant qu'il aura à son lancement), il y a mieux que os.chdir(). Tu peux utiliser à la place l'argument 'cwd' de subprocess.run(). De cette façon, le répertoire courant ne change pas pour ton programme, il change uniquement pour le processus qui exécute spleeter.exe (lequel est un processus fils de celui qui exécute ton programme). ]

De toute manière, il est sans doute plus facile de valider d'abord la solution en ligne de commande en modifiant le PATH soit temporairement dans l'invite de commandes cmd.exe, soit globalement via Paramètres système, quitte à le rétablir après le test de validation.

Quant à l'erreur sur l'autre ordi :

"Fatal error in launcher : unable to create process using '"d:\bld\spleeter_1574775900394\_h_env\python.exe"

le mot “launcher” évoque ce que Python fait pour lancer un script sous Windows, mais je ne saurais dire pourquoi cela ne marche pas ici (le message est trop vague).

Concernant le :

CompletedProcess(args='spleeter separate -i audio_example.mp3 -o audio_output', returncode=1)

le mot “completed” ne signifie pas (ici) une fin d'exécution avec succès. Par convention, le code de retour 0 quand on lance un programme (fonctions os.exec*() en Python) signifie « pas d'erreur ». Un code non nul peut également signifier « pas d'erreur » (c'est par exemple le cas lorsque grep retourne le code 1), mais disons que ce n'est pas le cas le plus courant. De manière générale, pour pouvoir interpréter le code de retour d'un programme, il faut voir soit le code, soit la documentation dudit programme. En général, lorsqu'il y a une erreur, les messages écrits sur stdout ou stderr sont bien plus utiles que le code de retour du processus (je ne parle pas d'un appel de fonction), d'où l'utilité de travailler en ligne de commande ici. Autrement, ton script peut récupérer et afficher — ou écrire dans un fichier — tout ce que le processus lancé a écrit sur stdout et stderr :

• par exemple en passant capture_output=True à subprocess.run() puis en lisant les attributs 'stdout' et 'stderr' de l'objet retourné ;
• ou bien en appelant subprocess.Popen() avec les arguments stdout=subprocess.PIPE et stderr=subprocess.STDOUT (il faut alors lire intégralement p.stdout, où p est la valeur de retour de subprocess.Popen(), avant d'appeler p.wait() qui donne le code de retour du processus et fait le ménage).

(pour la première méthode, voir l'exemple donné dans la documentation de subprocess.run()).

Edit: correction dans le dernier point (deuxième méthode) : utiliser subprocess.run() n'est pas la meilleure idée lorsqu'on a connecté stdout ou stderr du processus fils à un PIPE (tube), car vu que cette fonction attend que le processus fils se termine, elle ne permet pas de lire le tube en même temps (sauf à le faire dans un fil d'exécution séparé, hum !), ce qui peut causer un deadlock dès lors que le tube en question a été rempli par le processus fils. En effet, lorsque cela arrive, ce dernier va dans le meilleur des cas s'endormir tant qu'il ne peut pas écrire, et dans le pire des cas boucler « en attendant que ça se libère », donc ne pas se terminer, donc empêcher subprocess.run() de se terminer elle aussi.

Je ne vois pas grand-chose dans ton PATH qui pourrait interférer avec numpy, mais je n'ai pas d'éléments très solides pour affirmer cela — je ne sais pas ce qu'il y a dans WindowsApp, par exemple. Je vais faire l'hypothèse que le message d'erreur n'est pas très précis. Tu peux aussi lancer 'echo %PYTHONPATH%' pour suivre gentiment les instructions du message d'erreur dont tu viens de parler.

Pour le moment, je vois plus d'espoir de ce côté-ci : est-ce que tu peux lancer un truc genre « Anaconda Prompt » comme mentionné ici ?