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

Posté par yazgoo (site web personnel) le 11 février 2020 à 08:34. Licence CC By‑SA.

Étiquettes :

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 :

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

# Intéressant

Posté par David Demelier (site web personnel) le 11 février 2020 à 08:57. Évalué à 8.

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.

git is great because linus did it, mercurial is better because he didn't
- [^] # Re: Intéressant
  
  Posté par yazgoo (site web personnel) le 11 février 2020 à 09:24. Évalué à 1. Dernière modification le 11 février 2020 à 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 HL le 12 février 2020 à 23:23. Évalué à 3. Dernière modification le 12 février 2020 à 23:23.
    
    Vraie question, ça sert à quoi d'avoir un terminal super rapide utilisant le GPU pour le rendu ?
    - [^] # Re: Intéressant
      
      Posté par Jerome le 13 février 2020 à 09:16. Évalué à 5.
      
      Regarder un flim en ssh
      - [^] # Re: Intéressant
        
        Posté par Benoît Sibaud (site web personnel) le 13 février 2020 à 09:27. Évalué à 5.
        
        Remplacer le tout HTTP par le tout SSH :).
        
        [^] # Re: Intéressant
        
        Posté par Jerome le 13 février 2020 à 09:42. Évalué à 2.
        
        Avec de la blockchain pour valider les paquets TCP et de l'IA pour un meilleur routage ?
      - [^] # Re: Intéressant
        
        Posté par vv222 le 13 février 2020 à 23:45. Évalué à 2.
        
        Pour ça, rien ne vaut l’excellent duo sshfs + mpv ;)
        Bien sûr, pour rester dans le sujet on lance mpv depuis un terminal.
    - [^] # Re: Intéressant
      
      Posté par yazgoo (site web personnel) le 13 février 2020 à 09:41. Évalué à 2.
      
      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 HL le 13 février 2020 à 16:43. Évalué à 3.
        
        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 yazgoo (site web personnel) le 13 février 2020 à 17:38. Évalué à 1.
        
        Je ne tappe pas vite mais à un moment j'utilisais iterm2 que je trouvais très désagréable et dès que je suis passé à kitty je me suis mieux senti, c.f:
        https://danluu.com/term-latency/
      - [^] # Re: Intéressant
        
        Posté par barmic 🦦 le 13 février 2020 à 23:52. Évalué à 2.
        
        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 ?
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Intéressant

Posté par barmic 🦦 le 11 février 2020 à 09:35. Évalué à 5.

Ç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.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Intéressant
  
  Posté par yazgoo (site web personnel) le 11 février 2020 à 09:57. Évalué à 3.
  
  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 Yth (Mastodon) le 12 février 2020 à 09:21. Évalué à 3.
    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 dnanar le 11 février 2020 à 20:28. Évalué à 1.
  
  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 Zenitram (site web personnel) le 11 février 2020 à 09:57. Évalué à 6. Dernière modification le 11 février 2020 à 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 yazgoo (site web personnel) le 11 février 2020 à 10:02. Évalué à 1.
  
  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 Zenitram (site web personnel) le 11 février 2020 à 10:27. Évalué à 4. Dernière modification le 11 février 2020 à 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 yazgoo (site web personnel) le 11 février 2020 à 10:38. Évalué à 4.
      
      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 Davy Defaud le 11 février 2020 à 15:28. Évalué à 3.
  
  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.
  - [^] # Re: Fichier licence manquant, UTF-8 vs Unicode
    
    Posté par yazgoo (site web personnel) le 11 février 2020 à 15:53. Évalué à 3.
    
    Merci pour la correction !
- [^] # Re: Fichier licence manquant, UTF-8 vs Unicode
  
  Posté par Olivier Jeannet le 20 mars 2020 à 19:05. Évalué à 1. Dernière modification le 20 mars 2020 à 19:05.
  
  Merci pour ton commentaire, juste une remarque de forme :
  
  UTF-8 est un format de codage (oui l'anglicisme me brûle les yeux à chaque fois, car on parle de codage d'information, codage de Huffman, message codé, etc.).
# frustrant :)

Posté par Anonyme le 11 février 2020 à 10:17. Évalué à 3.
ç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…
- [^] # Re: frustrant :)
  
  Posté par yazgoo (site web personnel) le 11 février 2020 à 10:25. Évalué à 2.
  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 Anonyme le 11 février 2020 à 10:39. Évalué à 3.
    
    merci je vais pouvoir jouer :)
    - [^] # Re: frustrant :)
      
      Posté par Anonyme le 11 février 2020 à 11:26. Évalué à 4.
      
      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.
      - [^] # Re: frustrant :)
        
        Posté par yazgoo (site web personnel) le 11 février 2020 à 11:59. Évalué à 2.
        
        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 Psychofox (Mastodon) le 11 février 2020 à 14:29. Évalué à 8.

…et c'est étonnamment assez regardable. Alors bravo même si ça ne sert à rien ;-)
- [^] # Re: Testé avec quelques films...
  
  Posté par steph1978 le 11 février 2020 à 23:09. Évalué à 6.
  
  PeerTube en SSH, ça ne sert à rien ! Mais dans quel monde vis-tu :)
- [^] # Re: Testé avec quelques films...
  
  Posté par jyes le 12 février 2020 à 09:44. Évalué à 5.
  
  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 Elfir3 le 12 février 2020 à 11:30. Évalué à 4.
    
    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.
    - [^] # Re: Testé avec quelques films...
      
      Posté par yazgoo (site web personnel) le 12 février 2020 à 11:46. Évalué à 2.
      
      Je suis d'accord, surtout que l'async se stabilise de plus en plus

Suivre le flux des commentaires

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