Journal Des images (et des vidéos) dans le terminal avec des caractères Unicode

Posté par (page perso) . Licence CC by-sa.
53
11
fév.
2020

Nal,

Ces derniers temps, je m’amuse à rendre des images dans le terminal en utilisant notamment les caractères « blocs » d’Unicode et les codes couleurs ANSI. J’ai donc créé une crate Rust nommée blockish pour afficher des color buffers (images, GIF et rendus 3D).

Comme je me suis dit que ce serait sympa de rendre des vidéos aussi, j’ai écrit blockish‑caca, un projet utilisant LD_PRELOAD pour afficher le color buffer à la place de libcaca dans des lecteurs vidéo (pour l’instant, MPlayer et mpv — et je suis en train de bosser sur VLC). Cela me permet de ne réimplémenter que l’affichage du color buffer, sans avoir à réécrire un pilote pour chaque lecteur vidéo.

Voici un exemple de rendu :

Exemple de rendu video

Cf. le readme pour plus d’info sur comment l’utiliser.

  • # Intéressant

    Posté par (page perso) . Évalué à 8 (+6/-0).

    J'ai vu beaucoup de choses à ce sujet et j'ai toujours trouvé ça intéressant. Par contre je ne connais pas trop le sujet, mais je sais qu'il existe aussi les Sixel pour pouvoir réaliser ce genre de graphismes, à priori il faut un support explicit du terminal pour l'utiliser.

    l'azerty est aux dispositions ce que subversion est aux SCMs

    • [^] # Re: Intéressant

      Posté par (page perso) . Évalué à 1 (+0/-0). Dernière modification le 11/02/20 à 09:24.

      Oui, sixel serait l'idéal mais malheureusement il n'est pas beaucoup supporté (et notamment pas dans mon emulateur de terminal préféré)

      • [^] # Re: Intéressant

        Posté par . Évalué à 3 (+2/-0). Dernière modification le 12/02/20 à 23:23.

        Vraie question, ça sert à quoi d'avoir un terminal super rapide utilisant le GPU pour le rendu ?

        • [^] # Re: Intéressant

          Posté par . Évalué à 5 (+4/-0).

          Regarder un flim en ssh

        • [^] # Re: Intéressant

          Posté par (page perso) . Évalué à 2 (+1/-0).

          Perso j'avais besoin d'un emulateur terminal rapide (ne pas ressentir de lenteur à la frappe).
          Avant j'utilisais kitty qui fait ausssi du rendu GPU.
          Je ne pense pas que ce soit vraiment nécessaire néamoins (st est très rapide sans GPU).
          Pour plus d'explications sur les motivations du truc:
          https://jwilm.io/blog/announcing-alacritty/

          Un des autres avantages que je voit est qu'il est en rust => moins de leaks, moins de segfaults

          • [^] # Re: Intéressant

            Posté par . Évalué à 3 (+2/-0).

            Je me réponds, j'avais loupé ça :

            Alacritty is incredibly fast. Compare find /usr or equivalent with your favorite terminal emulator.

            Effectivement, la sortie standard (STDOUT) ralentit beaucoup l'exécution d'une commande.

            Par contre, tu tapes à quelle vitesse pour ressentir une lenteur à la frappe ?

          • [^] # Re: Intéressant

            Posté par . Évalué à 2 (+1/-0).

            J'ai choisi mon émulateur avant l'arrivée de ces émulateurs sur gpu. Mon objectif était juste d'avoir des polices lissées (ce que je n'avais pas de base avec xterm) et rapide (faire un cat sur un gros log rapidement). Ce blog m'avait your essayer et adopter urxvt. Je l'utilise encore et en suit satisfait. J'ai toujours des scrupules avec ce qui utilise un peu intensivement la gpu, car ça dépend du driver que des drivers buggés j'en ai eu ma dose.

            Ils apportent vraiment beaucoup par rapport à mon rxvt ?

  • # Intéressant

    Posté par . Évalué à 5 (+4/-0).

    Ça m'intéresse ce genre de choses, j'ai pas mal de photos sur un serveur que je parcourt en ssh. Pouvoir avoir un minimum de visualisation sans avoir à télécharger est bien pratique. Pour le moment j'utilise un outil qui s'appelle img2txt, mais il laisse une grosse part à l'imagination on va dire :)

    Faut que je test si blockish ou sixel peuvent marcher dans mon contexte.

    • [^] # Re: Intéressant

      Posté par (page perso) . Évalué à 3 (+2/-0).

      C'est possible d'utiliser blockish en CLI.
      Sur ton server, tu peux faire un:

      $ cargo install blockish

      Puis

      $ blockish /path/to/image --width $COLUMNS

      • [^] # Re: Intéressant

        Posté par . Évalué à 3 (+1/-0).

        Tu as peut-être un léger bug dans la gestion de --width.
        Si j'ouvre un terminal de base à 80 colonnes, je peux mettre --width 81 pour que ça remplisse le terminal.
        Testé avec terminology et st.

        À part ça c'est super efficace !

        • Yth.
    • [^] # Re: Intéressant

      Posté par . Évalué à 1 (+4/-0).

      Normalement tu peux afficher ton image si tu as un emulateur de terminal qui va bien. E.g. duckduckgo rapide : https://linoxide.com/tools/terminology-terminal/

      Ça me rappelle il y a 15/20 ans ou tu pouvais faire tourner un browser avec image a la elinks/lynx sans avoir a démarrer X tant que le schmilblick a du framebuffer. Utile quand les pilotes NVidia foirent.

      Sinon bravo pour le projet OP qui a son propre charme !

  • # Fichier licence manquant, UTF-8 vs Unicode

    Posté par (page perso) . Évalué à 6 (+6/-2). Dernière modification le 11/02/20 à 09:57.

    La vidéo que tu a mise est une sacrée démo… Et j'apprends que LD_PRELOAD existe :).

    2 remarques :
    - UTF-8 est un format d'encodage (d'Unicode, mais ça pourrait être d'autre chose), mais ça marcherait avec UTF-16 sans doute, car ce que tu utilises est Unicode et tu ne dépends pas (à priori) du format d'encodage, tant que Unicode est transmis et affiché.
    - Je note que l'intention est de faire du libre, mais tu le caches pas mal et pas sûr que ce soit suffisant de marquer le nom de licence visée dans un TOML au nom "aléatoire" (pour qui recherche une licence) (au passage, la date est incohérente avec l'âge du repo), tu devrais ajouter le fichier LICENSE correspondant dans chaque repo pour que ce soit explicite et que GitHub flaggue ton repo comme libre, et en bonus ça se fait aussi pas mal de marquer la licence dans le README.
    - Remarque annexe : le lien sur ce site vers ta page perso est en "server not found".

    • [^] # Re: Fichier licence manquant, UTF-8 vs Unicode

      Posté par (page perso) . Évalué à 1 (+0/-0).

      Merci pour ton commentaire, je me suis pas posé la question de la license pour l'instant, évidemment c'est une license libre, je préfère utiliser la meme license que la plupart des projets rust que j'ai vu.

      • [^] # Re: Fichier licence manquant, UTF-8 vs Unicode

        Posté par (page perso) . Évalué à 4 (+4/-2). Dernière modification le 11/02/20 à 10:32.

        évidemment c'est une license libre,

        Pas toujours si évident pour tout le monde, tu sais… Surtout quand le fichier de licence ne fait pas partie de l'init d'un repo, et encore plus quand on fait la pub avant de mettre la licence.

        je me suis pas posé la question de la license pour l'instant,

        Euh… J'avais noté que tu visais du libre parce que tu as indiqué en caché la licence. Mon ton aurait été un peu différent ("dommage que ce ne soit pas libre") si je n'avais pas vu ça ;-).
        Vu la date indiquée aussi, problème de copier/coller?

        Toujours est-il que la licence actuellement indiquée est celle la plus conseillée de nos jours, et celle utilisée le plus par les logiciels en Rust il me semble (et même la licence de Rust lui-même, enfin une de ces 2 licences proposées).

        • [^] # Re: Fichier licence manquant, UTF-8 vs Unicode

          Posté par (page perso) . Évalué à 4 (+3/-0).

          Oui, la license MIT est intentionelle, quand je disais

          je me suis pas posé la question de la license pour l'instant,

          Je voulais dire que j'ai un peu choisi cette license par défaut (pour les raisons que tu mentionnes) meme si je ne suis pas un grand fan des licenses ultra permissives.

    • [^] # Re: Fichier licence manquant, UTF-8 vs Unicode

      Posté par . Évalué à 3 (+1/-0).

      Je me suis fait la même remarque concernant l’amalgame entre Unicode et UTF-8. Je me suis permis de corriger le journal.
      @yazgoo : Je ne t’ai pas demandé ton accord, mais j’espère que tu n’y verras que bienveillance et non haute trahison.

  • # frustrant :)

    Posté par . Évalué à 3 (+1/-0).

    ça vient peut être de chez moi, je n'ai pas creusé: j'ai un souci lors du build de blockish-caca

    Updating git repository `https://github.com/yazgoo/redhook#07dc2275e02c5676293e90aeccb0660ccb79306a`
    warning: spurious network error (2 tries remaining): unexpected HTTP status code: 400; class=Net (12)
    warning: spurious network error (1 tries remaining): unexpected HTTP status code: 400; class=Net (12)
    error: failed to load source for a dependency on `redhook`
    
    Caused by:
      Unable to update https://github.com/yazgoo/redhook#07dc2275e02c5676293e90aeccb0660ccb79306a
    
    Caused by:
      failed to clone into: /home/pierre/.cargo/git/db/redhook-0a0d276329482a0b
    
    Caused by:
      unexpected HTTP status code: 400; class=Net (12)
    

    tout est correct sauf redhook qui s'obstine à ne pas exister…

    Ce commentaire passe-t-il les trois tamis de Socrate ?

    • [^] # Re: frustrant :)

      Posté par (page perso) . Évalué à 2 (+1/-0).

      Bizarre…

      Je ne reproduit pas le problème.
      En attendant un éventuel fix, tu peux remplacer, dans Cargo.toml

      redhook = { git = "https://github.com/yazgoo/redhook#07dc2275e02c5676293e90aeccb0660ccb79306a" }
      

      par

      redhook = "1.0"

      • [^] # Re: frustrant :)

        Posté par . Évalué à 3 (+1/-0).

        merci je vais pouvoir jouer :)

        Ce commentaire passe-t-il les trois tamis de Socrate ?

        • [^] # Re: frustrant :)

          Posté par . Évalué à 4 (+2/-0).

          en fait pas trop parce qu'avec rxvt-unicode-256color, ça manque de couleur pour un rendu intéressant. Selon mes vagues souvenirs, rxvt en millions de couleurs existe qqpart sous forme de patch mais n'est pas intégré dans debian.

          donc j'ai essayé avec st dans un terminal plein écran et c'est assez bluffant.

          Est-ce que le terminal utilisé influe sur la vitesse de traitement de l'image ?

          Sur ma machine qui a maintenant 10 ans, cela manque de fluidité, mais j'ai remarqué que cela n'utilisait qu'un seul core. Peut-être qu'une parallélisation, du code, si elle est possible, améliorerait ce point.

          Ce commentaire passe-t-il les trois tamis de Socrate ?

          • [^] # Re: frustrant :)

            Posté par (page perso) . Évalué à 2 (+1/-0).

            Merci pour ton retour.

            Pour ma part j'utilise alacritty et ça tourne correctement, je n'ai pas vraiment essayé avec d'autres emulateurs de terminaux.
            J'imagine que selon comment le terminal flush ou bufferise la sortie standard c'est plus ou moins rapide (blockish, lui, ne flush qu'une fois l'image complète écrite).

            Il y a encore des optimisations à faire, notamment celle que tu proposes, je vais m'y pencher.

  • # Testé avec quelques films...

    Posté par . Évalué à 8 (+6/-0).

    …et c'est étonnamment assez regardable. Alors bravo même si ça ne sert à rien ;-)

    • [^] # Re: Testé avec quelques films...

      Posté par . Évalué à 6 (+4/-0).

      PeerTube en SSH, ça ne sert à rien ! Mais dans quel monde vis-tu :)

    • [^] # Re: Testé avec quelques films...

      Posté par (page perso) . Évalué à 5 (+4/-1).

      J’ai voulu tester aussi et j’ai découvert rust. Ce langage qui sur le papier avait tout pour me plaire a été une énorme déception. J’ai pu découvrir que la version “stable” de rust est purement décorative et que personne ne s’en sert, et que cargo ne distingue pas les versions, du coup, quand on veut installer un logiciel avec cargo, il s’arrête après 5 minutes de compilation sur une dépendance quelconque que rust ne peut pas compiler car elle utilise des « fritures instables ».

      Super. Ça fait envie.

      Bon du coup, j’ai pu tester blockish, plutôt chouette, mais pas blockish-caca, alors que je me voyais déjà monter mon serveur vidéo sur SSH, comme le veut la nouvelle mode lancée par steph1978 qui me semble la friture-tueuse pour dépasser les services des GAFAM.

      J’ai testé avec d’autres logiciels en rust et visiblement blockish (sans -caca) est l’exception qui compile dans un univers rempli d’erreurs à la compilation.

      Don voilà, blockish : super ! Rust : langage aux idées sympa. Monde autour du langage et cargo : beaucoup moins biens.

      • [^] # Re: Testé avec quelques films...

        Posté par . Évalué à 4 (+2/-0).

        J’ai pu découvrir que la version “stable” de rust est purement décorative et que personne ne s’en sert, et que cargo ne distingue pas les versions, du coup, quand on veut installer un logiciel avec cargo, il s’arrête après 5 minutes de compilation sur une dépendance quelconque que rust ne peut pas compiler car elle utilise des « fritures instables ».

        En effet, certains projets prometteurs utilisent nightly, certaines fonctionnalités qui tuent n'y sont pas encore. Je pense notamment aux framework web asynchrones qui tirent parti d'async.

        Maintenant, je remarque que les projets que j'ai pu tester jusqu'ici semblent bien se compiler en stable pour la plupart : ggez, amethyst, tower-web, gotham, ripgrep, bat.. Bref je pense pas que ce soit encore vrai aujourd’hui.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.