Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

À partir d’avant-hierFlux principal

LinuxFr.org
Sortie de GIMP 2.99.18 (version de développement)
13 mars 2024 à 03:48

Sortie de GIMP 2.99.18 (version de développement)

Par : Jona Matthieu Jehan C138 orfenor Julien Jorge patrick_g Benoît Sibaud Arkem

13 mars 2024 à 03:48

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.99.18 du 21 février 2024 (en anglais).

Voici enfin la dernière version de développement avant GIMP 3 ! Bien que la sortie de la version 2.99.18 soit un peu en retard par rapport au planning espéré, celle-ci contient un certain nombre de fonctionnalités et d'améliorations que nous sommes ravis de pouvoir partager avec vous.

⚠️ ☢️ Nous vous rappelons qu'une version de développement sert à présenter les travaux en cours, mais vous permet aussi de détecter et signaler les problèmes au plus tôt. En d'autres termes, cette version est instable et nous ne recommandons pas son usage en production. Utilisez-là parce que vous voulez aider à améliorer GIMP en signalant des bogues.

En particulier, cette version 2.99.18 est peut-être l'une des versions les plus instables de la série 2.99 à cause du projet « space invasion » (NDT : « invasion venue de l'espace », un jeu de mots avec l'anglais colorspace signifiant espace de couleurs). Cela est parfaitement attendu et normal. ⚠️ ☢️

Sommaire

Cette dépêche présente les changements les plus notables et les plus visibles. En particulier, elle ne contient pas de liste exhaustive des correctifs de bogues ou des améliorations un peu moins importantes. Pour une liste plus complète des changements, nous vous invitons à consulter le fichier NEWS ou à jeter un coup d’œil à l'historique du dépôt Git.

L'invasion de l'espace (des couleurs) !

Nous avons travaillé dur sur le projet Space Invasion, qui est — comme vous vous en rappelez peut-être — le nom de code que nous avons donné au projet visant à rendre GIMP plus correct en ce qui concerne les couleurs.

Ces derniers temps, nous avons réalisé le portage des anciennes structures de couleurs utilisées en interne (GimpRGB, GimpCMYK, GimpHSV…) dont nous nous servions pour stocker les informations de couleurs vers GeglColor. Cet objet générique peut contenir n'importe quelle donnée de couleur, quel que soit le modèle colorimétrique, la précision ou l'espace, du moment que ceux-ci sont pris en charge par babl, notre moteur pour l'encodage des pixels.

En ce qui concerne la justesse des couleurs, cela signifie que nous ferons maintenant les conversions de couleurs uniquement si cela est nécessaire (conversions à la dernière minute), ce qui permettra de ne pas perdre d'information lorsque cela peut être évité. Par exemple, imaginons que vous utilisiez la pipette à couleurs sur une image : si nous convertissions cette couleur vers un format intermédiaire avant de l'utiliser sur une autre image (qui peut avoir le même format de couleurs ou un format différent), deux conversions auraient lieu. Cela augmente les possibilités de perte de précision. Ce problème est encore plus flagrant si les formats d'entrée et de sortie sont les mêmes (autrement dit, lorsqu'aucune conversion n'est nécessaire). Et cela sera encore plus problématique lorsque le modèle CMJN sera pris en charge nativement (nous voulons éviter à tout prix de faire un aller-retour entre un format intermédiaire et le CMJN, qui n'a pas de relation bijective avec la plupart des autres modèles de couleurs, même en travaillant sans bornes et en ignorant les problèmes de précision).

Définition d'un espace non borné (ajout par rapport à la dépêche originelle) : lorsque la précision est entière, l'espace est toujours borné (par exemple [0-255] en 8-bit). Par contre, en flottant, où l'espace de travail standard est [0, 1], on peut décider d'accepter les valeurs négatives et supérieures à 1. Cela rend les conversions entre beaucoup d'espaces de couleurs bijectives, aux erreurs de précisions près. Notamment, les conversions entre deux espaces RVB, ou même un espace RVB et divers autres modèles, deviennent bijectives. Ce n'est pas le cas entre RVB et CMJN, même en espace de couleurs infini.

Nous sommes également en train de migrer le stockage des données de couleur vers ce type d'objet générique. Cela signifie entre autres que les palettes de couleurs pourront comporter des couleurs au format CMJN, CIELAB ou bien encore dans tout autre modèle pris en charge (et pas seulement ces couleurs après une étape de conversion vers le sRVB non borné - « unbounded sRGB »).

Une conséquence pour la maintenance logicielle est qu'il sera beaucoup plus facile de gérer les conversions de couleurs au sein de notre code, étant donné que cette structure comprend à la fois les données et leur « signification ». Cela rend la gestion des couleurs beaucoup moins susceptible d'introduire des bogues par rapport à l'approche précédente, qui consistait à faire suivre les deux types d'information séparément.

Finalement, nous travaillons à faire apparaître l'information concernant l'espace de couleurs à plusieurs endroits de l'interface où cela est pertinent, par exemple lorsque des données RVB, CMJN, TSL ou TSV sont affichées ou peuvent être choisies. Les valeurs brutes dans ces modèles de couleurs en l'absence de la connaissance de l'espace de couleurs associé n'ont pratiquement aucun sens. L'affichage dans l'interface de valeurs RVB sans autre précision est un reliquat du passé, lorsque cela signifait le plus souvent sRVB. Cela n'est plus vrai dans un contexte graphique moderne et l'interface devrait être claire à ce sujet.

La vidéo ci-dessous montre quelques aspects de ce travail sur l'interface, par exemple le fait que les modèles RVB, TSV ou CMJN affichent à tout instant l'espace de couleurs dans lequel les valeurs sont considérées (ce qui très souvent correspond au nom du profil ICC). Cela est déjà fait pour la pipette à couleurs, les échantillons de couleurs, l'ancrable des couleurs de premier/d'arrière plan, la boîte de dialogue « Changer la couleur de premier/d'arrière plan », ainsi qu'à d'autres endroits.

Non seulement cela, mais lorsque les gens sélectionnent un profil d’épreuve sur écran et activent l'épreuve sur écran (par exemple grâce à la nouvelle bascule de simulation qui a été ajoutée dans GIMP 2.99.12), nous afficherons également non seulement la zone hors gamme de l'espace colorimétrique de l'image, mais également celle de l'espace d’épreuve.

Invasion de l'espace dans l'interface - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Avertissement très important : il s'agit encore une fois d'un portage énorme dans notre base de code, ce qui a impacté littéralement des milliers de lignes de code. Ce travail est inachevé mais il devra être terminé avant la première version candidate. Des instabilités ou des bugs sont à prévoir dans cette mise à jour donc si vous rencontrez un problème, nous recommandons de le rapporter.

Amélioration des algorithmes de couleur

Øyvind Kolås a amélioré quelques algorithmes internes :

Les pixels achromatiques de l'outil Teinte-Saturation sont désormais un cas spécial afin que les pixels en niveaux de gris (saturation de 0) ne soient modifiés que par le réglage principal, pas par le réglage rouge.
Les dégradés en niveaux de gris restent désormais achromatiques même avec "Tramage" coché dans l'outil Dégradé.

Au fur et à mesure que le projet space invasion avance, obtenir des résultats cohérents devient plus facile dans divers algorithmes liés aux couleurs, nous permettant ainsi de découvrir rapidement les problèmes et de les résoudre.

Édition non-destructive, première mouture

Un domaine dans lequel nous sommes « en avance sur le planning » est l'édition non destructive, qui était très demandée ! Les fondations de ces fonctionnalités ont été mises en place par de nombreux développeurs au cours de nombreuses années, depuis l'introduction de GEGL dans GIMP. Bien qu'initialement prévue pour la feuille de route de la version 3.2, une première implémentation a vu le jour en tant que continuation d'un projet Google Summer of Code. Si vous n'êtes pas familier avec ce terme, « édition non destructive » implique notamment que des effets de filtres tels qu'un effet de flou sont stockés séparément des pixels du calque. Cela signifie que si vous désirez plus tard modifier un réglage, réarranger ou même retirer le filtre, vous pouvez le faire très facilement sans affecter le reste de l'image. Jusqu'à présent, GIMP utilisait une procédure d'édition destructive où les effets étaient immédiatement appliqués sur le calque, c'est donc un changement majeur !

Toute opération GEGL munie d'une interface graphique est désormais appliquée aux calques de manière non destructive. (Les effets non destructifs pour les masques de calques et les canaux sont prévus pour les versions ultérieures.) Cela inclut les greffons GEGL tiers et les opérations personnalisées créées avec notre outil GEGL Graph. Ces effets peuvent être sauvegardés et chargés via les fichiers de projet .xcf, bien que toutes les propriétés GEGL ne soient pas encore prises en charge dans la version actuelle.

Une fois qu'un filtre a été appliqué, vous pouvez continuer à interagir avec lui en cliquant sur l'icône de filtre dans l'ancrable des calques. Cela ouvrira une boîte de dialogue montrant tous les filtres actuellement appliqués au calque. À partir de là, vous pouvez alterner l'état de visibilité du filtre, modifier ses réglages, réordonner les filtres et retirer les effets un à un. Vous pouvez aussi fusionner tous les filtres et les appliquer à l'image pour retrouver une procédure d'édition destructive.

Effets non destructifs - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Notez bien que tout cela est seulement une première implémentation, et beaucoup de travail reste à faire pour disposer d'une édition non destructive complète et riche. Nous allons continuer à affiner les fonctionnalités existantes pour la sortie de la version 3.0 en nous basant sur les tests et les retours des utilisateurs, et nous les développerons davantage par la suite. L'interface elle-même ne correspond pas à notre vision idéale de cette fonctionnalité, et un premier jet de spécifications a été écrit pour définir un processus d'édition bien plus intégré.

La capture d'écran ci-dessous est une maquette réalisée à partir de ces premières spécifications. Elle montre les effets de calque placés au sein de la liste principale des calques, partageant les mêmes boutons « œil » et « cadenas », mais également avec leurs propres masques faciles à éditer :

Maquette des spécifications pour l'application non-destructive d'effets de calque

Maquette des spécifications : les effets de calque sont visibles directement dans la liste des calques, avec leur propres masques

Néanmoins, l'implémentation de cette nouvelle interface sera un défi en elle-même et nous avons donc décidé de la remettre à après la sortie de GIMP 3 et de proposer cette première mouture en premier lieu.

N'hésitez pas à partager vos opinions dans les forums de discussion et dans le suivi des incidents !

Amélioration de la prise en charge des polices de caractères

Idriss Fekir, un autre étudiant du GSoC 2023, a travaillé avec Liam Quinn, un développeur de longue date, sur l'amélioration de la prise en charge des polices de caractères par GIMP. Une grande partie de ce travail concerne le code interne de GIMP afin d'améliorer sa capacité à gérer les futures mises à jour de polices et de texte. Certains changements plus visibles sont par exemple :

GIMP n'a plus besoin que les noms des polices de caractères soient uniques pour pouvoir les distinguer les unes des autres. Cela signifie qu'il n'ajoutera plus « #1 », « #2 » et ainsi de suite, mais gardera à présent les noms originaux dans la liste de sélection des polices. Malgré des noms apparemment identiques, deux polices avec le même nom fonctionneront désormais correctement.
GIMP peut maintenant charger des polices avec des styles personnalisés (en contournant l'utilisation de Pango qui n'est pas capable de les charger).
Nous pouvons à présent charger davantage de types de polices qu'auparavant. Si jamais nous ne prenons pas encore en charge une police donnée (ou si elle est inexistante), nous sommes mieux à même de le détecter et nous pouvons nous replier sur une police par défaut. Cela permet d'améliorer la prise en charge d'un fichier .xcf créé sur un autre ordinateur avec différentes polices disponibles.
Sous Windows, nous forçons le moteur Pango à toujours utiliser l'anticrénelage. Cela augmente la lisibilité du texte des menus sous ce système d'exploitation, en particulier lorsqu'un thème sombre est utilisé.
Le code pour la sauvegarde au format XCF stocke désormais les informations concernant les polices de manière bien plus précise, ce qui aide à éviter de charger une police incorrecte lors de la réouverture d'un fichier XCF.
L'alignement du texte dans les calques de texte pour les langues écrites de la droite vers la gauche est maintenant plus cohérent avec la manière dont cela fonctionne dans d'autres programmes (par exemple LibreOffice et Scribus).

Ces changements sont beaucoup moins voyants que certaines autres fonctionnalités et pourraient sembler moins importants, mais ils constituent en fait les fondations qui permettront d'avoir une gestion du texte bien plus fiable dans GIMP. Notre vision pour le futur est d'avoir une édition de texte plus simple tout en étant plus puissante et plus riche en fonctionnalités (en particulier les fonctionnalités OpenType qui sont quelques-unes des améliorations majeures que nous espérons ajouter un jour ou l'autre).

Expansion automatique des calques

Le troisième projet GSoC de l'été dernier par l'étudiant Shubham Daule a apporté une fonctionnalité demandée depuis longtemps : l'expansion automatique de calques ! Les outils de peinture ont désormais une option supplémentaire « Étendre les calques ». Lorsque cette case est cochée, peindre au-delà des limites des calques les fera s'étendre automatiquement afin que vous n'ayez pas à gérer vous-même la taille du calque. Si vous souhaitez étendre le calque au-delà de la taille actuelle du canevas, vous devrez également cocher l'option « Afficher tout » dans le menu Affichage.

Calques à expansion automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

L'option d'expansion des calques comporte également des paramètres supplémentaires lorsqu'elle est sélectionnée. Vous pouvez décider dans quelle mesure vous souhaitez que les limites du calque s'étendent chaque fois que le pinceau les atteint. Il existe également des options pour spécifier comment les nouvelles zones du calque et du masque de calque doivent être remplies une fois étendues.

Nouvelles options d'alignement

Le nouveau contributeur mr. fantastic a développé deux nouvelles options pour aligner les calques sur le canevas. Avec « Snap to Bounding Boxes » (« Aligner sur les boîtes englobantes ») activé, des guides dynamiques s'afficheront désormais pour vous montrer quand le calque que vous déplacez est aligné avec le centre ou les côtés des autres. Le calque actif s'alignera également sur ces bordures pour vous aider à les organiser correctement. La deuxième option, « Snap to Equidistance » (« Aligner à équidistance »), vous permet un alignement entre trois calques équidistants les uns des autres.

Nouvelles options d'alignement automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Thèmes

Nous avons continué à améliorer l'interface utilisateur et le style de cette version. L’une des améliorations les plus importantes concernait la gestion des « fuites de thèmes système ». Il existe des styles qui n'ont pas été spécifiquement définis dans nos thèmes, donnant ainsi l'opportunité aux règles de style du thème système de "fuiter" de manière conflictuelle dans notre interface. Avec l’aide et les retours de plusieurs contributeurs et utilisateurs, nous avons beaucoup progressé dans la définition de ces styles afin que tous aient une expérience cohérente !

Récemment, Jehan a travaillé sur la réorganisation et la simplification de notre système de thèmes. Dans les versions de développement précédentes, nous avions cinq thèmes différents : Par Défaut, Gris, Système, Plus Sombre et Compact (chacun avec des options claires et sombres). Ceux-ci ont été simplifiés dans le thème Système et un seul thème par défaut avec trois états possibles : clair, foncé et gris. De même, nos quatre thèmes d'icônes distincts ont été condensés dans l'ensemble Legacy et un thème d'icôns par défaut avec des variantes couleur et symbolique. Nous pensons que ces changements réduiront la confusion des utilisateurs et leur permettront de trouver plus facilement leur apparence d'interface préférée.

De plus, sous Windows, la barre de titre principale (et la plupart des barres de titre des boîtes de dialogue) s'ajuste désormais au mode clair ou sombre en fonction du thème sélectionné.

Boîte de dialogue de bienvenue

La boîte de dialogue de bienvenue a été étendue pour fournir un accès rapide à un certain nombre de fonctionnalités et d'options utiles. Elle comporte ainsi quatre nouvelles sections :

Personnaliser : Plusieurs options de personnalisation nécessitent de fouiller dans la boîte de dialogue des Préférences pour être modifiées. À présent, vous pouvez facilement modifier les thèmes de couleurs et d'icônes, la langue et la taille de la police de l'interface utilisateur, ainsi que certains réglages en fonction du système d'exploitation.
Créer : Cette section affiche les huit images que vous avez ouvertes en dernier et vous permet de les rouvrir rapidement. Des boutons pour créer une nouvelle image ou pour en charger une existante sont également présents. À l'instar d'autres programmes, vous pouvez demander à ce que cet écran apparaisse automatiquement au démarrage de GIMP pour un accès direct à ces fonctionnalités.
Contribuer : Nous avons réuni ici quelques-unes des nombreuses façons dont vous pouvez participer au développement de GIMP. Cette section comporte des liens pour le signalement de bogues, pour écrire du code, pour aider aux traductions ou pour faire un don.
Notes de version : Précédemment, le lien vers ces notes étaient affichées dans la moitié inférieure de la boîte de dialogue de bienvenue. À présent, nous avons un onglet entier dédié à ces notes pour une lecture plus aisée.

Formats de fichiers

Comme cela était déjà le cas avec les versions précédentes, nous avons amélioré la prise en charge de formats de fichiers déjà existants et nous avons ajouté la prise en charge de l'importation et de l'exportation pour de nouveaux formats.

DDS

Stayd, un nouveau contributeur, a travaillé avec notre développeur Jacob Boerema pour apporter de nombreuses améliorations au greffon DDS. Pour commencer, les fonctions d'importation ont été écrites afin d'être plus simples et plus faciles à étendre dans le futur. Les mises à jour supplémentaires incluent également :

Le chargement d'images DDS RVBA 16 et 32 bits/canal est maintenant possible.
Le filtre cubique Catmull-Rom a été ajouté pour la génération de mipmaps, et tous les calculs pour générer les mipmaps sont effectués avec une précision de 32 bits.
Les images DDS aux formats R8G8, R16 et R16G16 peuvent maintenant également être chargées.
Une option pour renverser verticalement les images DDS lors de l'importation a été ajoutée pour faire écho à l'option d'exportation correspondante, étant donné que certaines images de jeux stockent leurs données de cette manière.

GIF

Par le passé, écraser un fichier GIF à la sauvegarde (plutôt que de l'exporter) le convertissait systématiquement en un fichier avec une seule image. Désormais nous vérifions lors du chargement si le fichier GIF est une animation, de manière à également sauvegarder une animation lors de l'écrasement.

HEIF et JPEG-XL

Les deux greffons utilisent maintenant leurs bibliothèques respectives (libheif et libjxl) pour le chargement des métadonnées. Cela nous a permis de retirer notre code maison chargé d'interpréter l'orientation des images et d'utiliser à la place les informations fournies par ces bibliothèques.

OpenEXR

Le format OpenEXR permet aux canaux d'avoir des noms personnalisés, outre le type de couleur. Dans ce cas, nous considérons maintenant toute image à un seul canal avec un nom non conventionnel comme étant en niveaux de gris. Lors de l'importation, nous affichons une notification afin que les utilisateurs soient prévenus de cette conversion.

PDF

L'option d'exportation « Calques en tant que pages » fonctionne maintenant même s'il y a un seul groupe de calques. Auparavant, cette option n'était pas disponible car le greffon vérifiait seulement s'il y avait plus d'un « calque » sans examiner s'il s'agissait d'un groupe de calques avec de multiples sous-calques.

PNG

Les fragments de fichiers PNG qui sont « copiables sans risque » (« safe-to-copy chunks ») sont maintenant préservés lors de l'importation et inclus dans l'image exportée. Un autre souci qui existait lors de l'exportation de PNGs indexés avec transparence (et qui nous avait été souvent signalé) a été résolu. Désormais les couleurs indexées devraient être affichées correctement après exportation.

PSD

Jacob Boerema a poursuivi son travail d'amélioration du greffon PSD. En plus d'avoir résolu des bogues, par exemple dans l'ordre des calques lors de l'importation, il a aussi clarifié l'avertissement présenté lors de l'exportation et concernant la compatibilité des modes de calques entre GIMP et Photoshop.

PSP

Le greffon Paintshop Pro peut maintenant importer davantage de caractéristiques depuis un fichier projet, comme par exemple le profil de couleurs ICC, les guides, les grilles, et la sélection active lors de la sauvegarde. Les failles de sécurité ZDI-CAN-22096 et ZDI-CAN-22097 ont également été corrigées dans cette version.

Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2

Nous avons récemment ajouté la prise en charge de l'importation et de l'exportation pour le format Farbfeld, un format d'image sRVB conçu pour être facile à lire, à envoyer dans des pipes et à compresser avec des outils tiers.

Nous avons aussi ajouté la prise en charge de l'importation seule pour les nouveaux formats suivants :

Esm Software PIX : Un format JPEG modifié utilisé exclusivement par l'entreprise Esm Software pour stocker leurs images propres. Cela a été implementé en réponse à un signalement de bogue qui avait confondu ce format avec le format Alias PIX que nous prenions déjà en charge.
HEJ2 : Un ajout à notre greffon HEIF déjà existant fourni par Daniel Novomeský qui permet d'importer des images JPEG 2000 compressées.

Nouveau format de palette pris en charge : Swatchbooker

Swatchbooker est un programme libre de création et de conversion de palettes de couleurs qui prend en charge de nombreux formats. Bien que le programme lui-même n'ait pas été mis à jour depuis de nombreuses années, son format de palette propre .sbz est le plus complet de tous ceux que nous prenons en charge actuellement. Parmi ses nombreuses fonctionnalités, on peut citer la possibilité de définir des couleurs dans plusieurs modèles de couleurs pour chaque entrée d'une palette, des noms et des descriptions régionalisables, et la prise en charge de profils de couleurs ICC différents pour chaque entrée.

Via notre travail sur la prise en charge de son importation, nous avons pu fournir des informations qui ont conduit à un correctif de bogue dans la prise en charge de Swatchbooker par Krita. C'est toujours sympa quand des projets peuvent collaborer et s'entraider !

Interactions avec les pads de tablettes graphiques sous Wayland

Carlos Garnacho, un contributeur GNOME de longue date, a ajouté la prise en charge de l'interaction directe des boutons de tablettes graphiques (pad) avec GIMP. Quand une tablette est branchée, vous pouvez désormais assigner différentes actions aux contrôles de la tablette depuis la boîte de dialogue « Périphériques d'entrée » dans le menu Édition.

Assigner des actions aux boutons d'une tablette graphique - GIMP 2.99.18

Ce travail a aussi impliqué le portage de fonctionnalités vers GTK 3, la boîte à outils utilisée par GIMP pour son interface graphique. Notez que cette fonctionnalité est seulement disponible sous Wayland pour le moment.

Mise à jour de l'API

L'interface de programmation d'application (API), destinée aux créateurs de greffons, est régulièrement retravaillée dans le cadre de la refonte de GIMP 3. Une partie de ce travail est de migrer l'API vers l'utilisation de GeglColor lorsque les couleurs sont impliquées, ce qui entre dans le cadre plus général du projet Space Invasion. Malgré tout, ce n’est qu’une petite partie de l’ensemble des améliorations de l’API.

Nous nous orientons également vers plus de classes pour représenter les différentes ressources gérées par GIMP (pinceaux, polices, motifs, etc.) au lieu de les représenter uniquement par des noms (ce qui était une limitation historique alors qu'il est tout à fait possible à 2 créateurs de ressources de choisir le même nom et le fait est que nous voyons de tels cas dans la nature — par exemple, 2 polices créées indépendamment peuvent avoir le même nom).

Un autre grand pas consiste à remplacer le GimpValueArray représentant les arguments ordonnés d'une procédure d'un greffon par un GimpProcedureConfig qui contient les arguments par nom plutôt que par ordre. Cela permet une utilisation beaucoup plus sémantique des procédures de greffon (surtout lorsqu'elles ont une longue liste d'arguments) et facilitera également l'amélioration des greffons à l'avenir, avec des arguments nouveaux ou réorganisés sans créer de nouvelles procédures, car l'ordre et le nombre des arguments comptent beaucoup moins. Cela signifie que l'ajout de nouveaux arguments dans le futur ne brisera plus les scripts déjà existants qui dépendaient des versions antérieures de ces greffons (les auteurs de greffons devront toujours choisir des valeurs par défaut appropriées pour les nouveaux arguments afin que cela soit vrai, bien sûr).

En parallèle, nous continuons d'améliorer la capacité de création automatique d'interfaces graphiques offerte aux greffons, rendant la création de boîtes de dialogue plus simple que jamais. Cela inclut (parmi de nombreuses autres améliorations) un nouveau type d'argument de procédure nommé GimpChoice qui est une liste de choix sous forme de chaînes de caractères qui peut être présentée aux créateurs sous forme de widgets de liste déroulante dans la boîte de dialogue de votre greffon.

Nous prévoyons d'écrire et de publier un didacticiel pour les rédacteurs de greffons dans la section Développement de ressources de notre site Web pour développeur en même temps que la sortie de GIMP 3, ou peu de temps après.

GEGL et babl

Cette version de GIMP est accompagnée de nouvelles versions de GEGL et babl, qui contribuent toutes deux au projet (Color) Space Invasion.

babl 0.1.108 apporte une nouvelle fonction babl_space_is_rgb pour nous aider à confirmer directement qu'un espace colorimétrique est RVB (plutôt que de faire plusieurs tests pour voir s'il n'est pas CMJN ou niveaux de gris). Plusieurs améliorations ont également été apportées au processus de compilation et à l'outil d'interface de ligne de commande de babl.

GEGL 0.4.48 fournit plusieurs mises à jour de l'objet GeglColor qui prend désormais en charge une grande partie des opérations de couleur de GIMP. Les améliorations spécifiques incluent la possibilité d'obtenir et de définir directement les valeurs de couleur CMJN, ainsi que l'attribution de l'espace colorimétrique lors de la définition des couleurs RVB(A).

Un crash dans le filtre gegl:voroni existant a été corrigé, et un bogue de longue date avec le filtre gegl:dropshadow qui empêchait l'effet de rétrécir a également été corrigé.

Enfin, un nouveau filtre gegl:shuffle-search a été ajouté à l'atelier. Il mélange les pixels voisins pour créer un effet de tramage plus optimisé.

Statistiques de sortie

Hormis la première version de la série (2.99.2), GIMP 2.99.18 est clairement la plus grosse mise à jour à bien des égards. Depuis la version 2.99.16 :

238 rapports ont été clôturés comme CORRIGÉS.
201 demandes de fusion ont été acceptées.
1358 commits ont été poussés.
26 traductions ont été mises à jour : allemand, basque, biélorusse, portugais brésilien, bulgare, catalan, chinois (Chine), danois, espagnol, espéranto, finnois, géorgien, grec, hongrois, islandais, italien, lituanien, norvégien nynorsk, persan, polonais, russe , slovène, suédois, turc, ukrainien, vietnamien.

60 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.99.18 (l'ordre est déterminé par le nombre de commits; certaines personnes apparaissent dans plusieurs groupes) :

23 développeurs pour le code principal : Jehan, Alx Sa, Shubham, Jacob Boerema, Idriss Fekir, bootchk, Anders Jonsson, Carlos Garnacho, mr.fantastic, Stanislav Grinkov, lillolollo, Øyvind Kolås, Sabri Ünal, programmer_ceds, Lukas Oberhuber, programmer-ceds, James Golden, Luca Bacci, Massimo Valentini, Niels De Graef, Zander Brown, psykose, sonia.
17 développeurs de greffons ou de modules : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Stayd, Zander Brown, Bruno Lopes, Daniel Novomeský, Sabri Ünal, programmer_ceds, Kamil Burda, Mark, Michael Schumacher, Stanislav Grinkov, programmer-ceds, sonia.
31 traducteurs : Yuri Chornoivan, Martin, Ekaterine Papava, Luming Zh, Sabri Ünal, Anders Jonsson, Rodrigo Lledó, Jordi Mas, Alan Mortensen, Vasil Pupkin, Asier Sarasua Garmendia, Kolbjørn Stuestøl, Boyuan Yang, Víttor Paulo Vieira da Costa, dimspingos, Alexander Shopov, Alexandre Prokoudine, Aurimas Černius, Balázs Úr, Marco Ciampa, Sveinn í Felli, Danial Behzadi, Ngọc Quân Trần, Jürgen Benvenuti, Piotr Drąg, Timo Jyrinki, Andre Klapper, Kristjan SCHMIDT, MohammadSaleh Kamyab, Rafael Fontenelle, Tim Sabsch.
9 créateurs de ressources (icônes, thèmes, curseurs, splash screen, métadonnées…) : Alx Sa, Jehan, Ferry Jérémie, Stanislav Grinkov, Anders Jonsson, Bruno Lopes, Jacob Boerema, Sabri Ünal, mr.fantastic.
5 contributeurs à la documentation : Jehan, Bruno Lopes, Jacob Boerema, Alx Sa, Anders Jonsson.
14 contributeurs pour la compilation, l'empaquetage ou l'intégration continue : Jehan, Bruno Lopes, bootchk, Alx Sa, Zander Brown, Jacob Boerema, Jacob Boerema, Stayd, Carlos Garnacho, Heiko Becker, mr.fantastic, Daniel Novomeský, U-YGGDRASIL\ender, lillolollo.

Contributions à d'autres dépôts du GIMPverse (l'ordre est déterminé par le nombre de commits) :

babl 0.1.108 est composé de 17 commits par 6 contributeurs : Jehan, Øyvind Kolås, John Marshall, Andre Klapper, John, sid.
GEGL 0.4.48 est composé de 77 commits par 20 contributeurs : Øyvind Kolås, Jehan, Anders Jonsson, Jacob Boerema, Yuri Chornoivan, Alan Mortensen, Sabri Ünal, Andre Klapper, Ekaterine Papava, Jan Tojnar, Jordi Mas, Luming Zh, Martin , Piotr Drąg, Víttor Paulo Vieira da Costa, Asier Sarasua Garmendia, Marco Ciampa, Rodrigo Lledó, dimspingos, woob.
ctx a eu 308 commits depuis la version 2.99.14 par 1 contributeur : Øyvind Kolås.
La version gimp-macos-build (scripts d'empaquetage macOS) est composée de 32 commits par 1 contributeur : Lukas Oberhuber.
La version flatpak est composée de 15 commits par 3 contributeurs : Jehan, Daniel Novomeský et Hubert Figuière.
Notre site Web principal a eu 31 commits depuis la sortie du 2.10.36 par 6 contributeurs : Jehan, Alx Sa, Sabri Ünal, Anders Jonsson, Bruno Lopes, Jonathan Demeyer.
Notre site Web des développeurs a eu 30 commits depuis la version 2.10.36 par 5 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Robin Swift.
Notre documentation 3.0 a enregistré 247 commits depuis la version 2.99.16 par 17 contributeurs : Andre Klapper, Jacob Boerema, Yuri Chornoivan, Alx Sa, Jordi Mas, Alan Mortensen, Dimspingos, Anders Jonsson, Boyuan Yang, Sabri Ünal, Víttor Paulo Vieira da Costa, Juliano de Souza Camargo, Rodrigo Lledó, Kolbjørn Stuestøl, Marco Ciampa, Danial Behzadi, Emin Tufan Çetin.

N'oublions pas de remercier toutes les personnes qui nous aident à faire le tri dans Gitlab, rapportent des bogues et discutent avec nous d'éventuelles améliorations. Notre communauté est également profondément reconnaissante envers les guerriers d'Internet qui gèrent nos différents canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de pièces qui composent GIMP et son environnement, et de la manière dont nous obtenons des statistiques via des scripts git, des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous dire si nous avons manqué ou mal catégorisé certains contributeurs ou contributions.

Nouvelles de l'équipe et procédure de sortie

Les droits d'accès au dépôt git ont été récemment accordés à Bruno Lopes (qui a été très actif dans l'amélioration de notre processus de compilation et de l'empaquetage pour Windows).

Plusieurs développeurs ou empaqueteurs de longue date ou plus récents qui ont commencé à contribuer au nouveau site Web des développeurs ont également reçu l'accès au dépôt git associé.

De plus en plus de contributeurs participent désormais activement aux tests des versions et du processus d'empaquetage, et c'est la première dépêche depuis des années (NDT : cela désigne la news originale sur le site de GIMP) que Jehan n'a pas écrite presque entièrement ! Merci beaucoup à Alx Sa (alias Nikc ou CmykStudent) d'avoir entamé la rédaction collaborative de la nouvelle !

Il est clair que nous consolidons jour après jour une solide équipe de contributeurs et cela se voit dans notre processus de publication, avec de plus en plus de retours à chaque version.

Nous sommes également particulièrement heureux et fiers que les 4 projets GSoC que nous avons eus, depuis que nous avons recommencé à souscrire à ce programme de mentorat, aient tous été couronnés de succès et ont fini par être fusionnés avec la branche principale du code au plus tard six mois après la fin du stage.

Autour de GIMP

Des nouvelles des miroirs

Depuis la dernière dépêche, un nouveau miroir a été apporté à GIMP par :

Sahil Dhiman, à Nuremberg, en Allemagne, comme projet personnel.

Cela nous amène à un total de 46 miroirs répartis dans le monde.

Les miroirs sont importants car ils aident le projet en partageant la charge de dizaines de milliers de téléchargements quotidiens. De plus, en disposant de miroirs répartis à travers le monde, nous garantissons que tout le monde puisse avoir un accès rapide au téléchargement de GIMP.

GIMP sous Windows/ARM

Depuis notre annonce d'une version expérimentale sur Windows pour l'architecture ARM 64 bits (en anglais), nous avons reçu l'aide de Hernan Martinez, contributeur bien connu du projet MSYS2, qui a hébergé notre tout premier runner pour l'intégration continue (CI) pour Windows sur l'architecture Aarch64. Bien que cela n'ait été qu'une configuration temporaire (littéralement une machine de compilation dans le salon de quelqu'un) en attendant une situation plus stable, nous sommes extrêmement reconnaissants envers Hernan qui nous a aidés à faire notre deuxième pas sur cette plateforme (la première étape a été effectuée par Jernej, qui a créé notre premier installateur expérimental), s'est assuré que notre processus de compilation automatique fonctionne sur cette machine, et plus encore.

Depuis lors, la situation plus stable est arrivée : Arm Ltd. eux-mêmes se sont mobilisés et ont officiellement contribué trois runners pour notre processus d'intégration continue dans Gitlab ! Arm Ltd. a également sponsorisé un kit de développement Windows pour l'un de nos développeurs.

Bien que nous considérions toujours cette version comme expérimentale, en raison du manque de tests et du fait que seuls 2 contributeurs disposent actuellement d'une machine capable de l'exécuter, le plus gros facteur bloquant a été supprimé et nous sommes heureux d'annoncer que notre programme d'installation Windows universel pour GIMP 2.99.18 contient GIMP pour les 3 plates-formes (x86 32 et 64 bits, et maintenant ARM 64 bits) !

Télécharger GIMP 2.99.18

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

Flatpaks Linux pour x86 et ARM (64 bits)
Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
Paquets macOS DMG pour le matériel Intel
Paquets macOS DMG pour le matériel Apple Silicon

D'autres paquets réalisés par des tiers devraient évidemment suivre (paquets des distributions Linux ou *BSD, etc.).

Et ensuite ?

Alors que nous sommes maintenant entrés dans un gel des fonctionnalités, notre attention s'est déplacée vers la correction des bogues, le nettoyage et la préparation de la première version candidate 3.0.

Nous pensons en effet qu'il s'agit de la dernière version de développement puisqu'aucune nouvelle fonctionnalité ne sera introduite désormais, du moins au niveau de l'interface utilisateur (l'API est encore en évolution jusqu'à la première version candidate). Donc, ce que vous voyez maintenant est essentiellement ce que vous devriez obtenir dans GIMP 3.0.0, en termes de fonctionnalités.

C'est pourquoi nous avons sorti cette version même si nous savons qu'elle est assez instable. C'est l'heure des commentaires de dernière minute ! C'est aussi le moment de signaler et de corriger les bogues comme si demain n'existait pas. Nous espérons pouvoir bientôt livrer une RC1 et elle devrait être aussi dépourvue de bogue que possible.

Nous espérons actuellement pouvoir publier GIMP pour le prochain Libre Graphics Meeting du 9 au 12 mai. Pour être honnête, ce n’est pas un objectif facile et nous ne sommes donc pas sûrs de pouvoir l’atteindre. Ce qui est sûr, c'est que même si nous n'y parvenons pas à temps, cela ne devrait pas arriver trop longtemps après. En particulier, nous ne publierons pas simplement parce que nous avons fixé une date limite. Nous voulons offrir la meilleure expérience possible, ce qui signifie que si nous découvrons des bogues bloquants de dernière minute, nous retarderons la sortie jusqu'à ce qu'ils soient corrigés.

N'oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, c'est un moyen de donner en retour et d'accélérer le développement de GIMP. L’engagement communautaire permet au projet de se renforcer ! 💪🥳

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

LinuxFr.org
Sortie de LuneOS « Eiskaffee »
16 février 2024 à 14:16

Sortie de LuneOS « Eiskaffee »

LinuxFr.org

Par : Christophe orfenor Ysabeau 🧶 🧦

16 février 2024 à 14:16

Tentés par un café glacé ? LuneOS « Eiskaffee » vient de sortir !

LuneOS est une distribution GNU/Linux pour téléphones mobiles et tablettes, héritière de feu webOS. Le projet est porté par l’équipe webOS-Ports, dont le but est de faire revivre webOS sur les matériels contemporains.

logo de LuneOS

lien nᵒ 1 : Lien vers l'annonce officielle
lien nᵒ 2 : Dépôts du projet sur GitHub
lien nᵒ 3 : Images de LuneOS pour essayer

Sommaire

Voici bien longtemps que l’équipe de webOS-ports n’avait fait de nouvelle version de LuneOS. De nombreux changements de fond, de nouveaux téléphones et tablettes, des difficultés techniques mais aussi une équipe développement modeste expliquent ce rythme un peu lent qui avance selon le temps libre de chacun.

Pendant ce temps, des versions de test de LuneOS ont été régulièrement mises à disposition sur Github, dans le dépôt « luneos-testing ». Cela permet aux personnes intéressées d’essayer LuneOS, tout en gardant à l’esprit que ce ne sont que des versions intermédiaires.

Petits rappels et lexique

Le projet s’appuie sur Yocto, webOS-OSE, Halium et SHR. Il utilise OpenEmbedded comme environnement de compilation. Cette dernière version de LuneOS se base sur la version « Kirkstone » de Yocto. Ces projets ne vous disent rien ? Voici un rapide lexique :

OpenEmbedded est un environnement de compilation, qui utilise un ensemble de « recettes » pour décrire les composants à compiler et installer.
Yocto est un ensemble de recettes prêtes à l’emploi qu’on peut utiliser pour se construire une distribution Linux personnalisée. Les recettes mises à disposition vont du noyau Linux à Firefox, et forment un ensemble déjà assez complet.
SHR est un système d’exploitation GNU/Linux s’appuyant aussi sur Yocto et OpenEmbedded, et orienté téléphones. Il a connu son heure de gloire à l’époque des téléphones Openmoko comme le FreeRunner. Seule une petite partie est maintenant réutilisée pour les besoins de LuneOS.
Halium est un ensemble d’utilitaires et d’images Android permettant de faire tourner un Android minimaliste dans un container dédié sur la distribution hôte. Cela permet d’exploiter les pilotes et firmwares disponibles seulement pour Android, tout en gardant le reste de l’OS sur une pile GNU/Linux/systemd/Wayland classique.
webOS-OSE est une distribution Linux maintenue par LG, héritière du code de webOS, et dont LuneOS reprend maintenant beaucoup de composants logiciels.

À l’exception des blobs utilisés pour faire tourner les pilotes Android, l’ensemble de la distribution est libre : tout le monde peut, s’il le veut, recompiler sa propre image chez soi.

Fin du forum webOS Nation et autres tracasseries techniques

Le forum « webOS Nation », qui regroupe des discussions autour de webOS au sens large (vieilles versions de webOS, mods, LuneOS…) a connu quelques turbulences ces dernières années. Devant une fermeture imminente du site web, un nouveau site webOS Archive a été mis en place, avec notamment la majorité des archives des forums de webOS Nation. Un nouveau forum a été mis en place, reprenant globalement le style de webOS Nation.

Sans avoir une activité folle, la communauté autour de webOS reste présente, notamment grâce à la présence aujourd’hui de webOS sur les téléviseurs.

Mort du « builder » dédié à LuneOS

Suite à plusieurs avaries, le builder « Jenkins » a dû prendre une retraite bien méritée. Malheureusement cela implique pour l’équipe de webOS-ports de compiler les différentes images de LuneOS chez soi, ce qui n’est pas très pratique (sans être une catastrophe). Sur une machine raisonnablement puissante, la création d’une image de LuneOS depuis zéro demande plusieurs heures, il faut donc parfois s’armer de patience. Heureusement Yocto permet de mutualiser les résultats de compilation pour les architectures semblables, ce qui fait gagner beaucoup de temps.

Les changements majeurs

Depuis la dernière version publique de LuneOS, beaucoup de changements de fond ont eu lieu. On retrouve entre autres:

Passage de Qt 5 à Qt 6

LuneOS utilise maintenant Qt 6.5.2, l’une des dernières disponibles.

Utilisation du compositeur Wayland de webOS OSE

Le compositeur Wayland propre à LuneOS luna-next a été abandonné, au profit du compositeur Wayland de webOS OSE surface-manager. Cependant la partie graphique (codée en QML) a été conservée, et l’expérience utilisateur reste donc très similaire.
Cela permet de se concentrer sur la partie GUI du compositeur, tout en bénéficiant des mises à jour venant de OSE relatives au cœur même du compositeur.

Changement de moteur Chromium

Les apps webOS utilisant intensivement HTML/Javascript/CSS, l’affichage nécessite un moteur web bien à jour et optimisé. Jusqu’à la dernière version, LuneOS utilisait QtWebEngine, fourni par Qt, pour faire tourner les applications.
Cependant webOS-OSE fournit son propre moteur basé sur chromium, indépendant de Qt et optimisé pour une utilisation embarquée. LuneOS a donc également migré vers cette nouvelle infrastructure logicielle, adoptant ce composant WebAppManager.

Migration générale vers les composants de webOS-OSE

Plus généralement, les composants hérités de feu Open WebOS ont été remplacés par leur équivalent dans webOS-OSE, plus récents et encore maintenus par LG. Pour cette version de LuneOS, la version 2.23.0 de webOS-OSE est utilisée comme base.
Cette migration inclut notamment l’utilisation des « Enhanced ACG », un modèle de sécurité plus efficace utilisé pour la communication entre les services de webOS et les apps.

Ces changements, qui pour la plupart ne sont pas visibles à l’utilisation, apportent de multiples bénéfices pour LuneOS :

une réutilisation plus large du code de webOS-OSE (maintenu par LG), ce qui implique moins de maintenance côté webOS-ports
meilleure stabilité des composants, qui sont utilisés depuis des années dans les téléviseurs et appareils LG
la rétro-compatibilité a tout de même pu être assurée pour les vieilles apps webOS, grâce à des modifications mineures dans certains composants
plus de facilité pour mettre à jour les composants venant de webOS-OSE

Téléphones et tablettes: vers plus de Linux « mainline »

Dans le domaine des distributions Linux pour téléphones et tablettes, on parle de noyau « mainline » pour désigner l’utilisation directe du code source venant du noyau Linux, par opposition à l’utilisation d’un code source dérivé et proposé par un constructeur. Ce dernier est souvent proposé dans une vieille version, avec une maintenance très limitée dans le temps.

Cependant, utiliser un noyau « mainline » est à double tranchant : d’un côté, on bénéficie des dernières avancées du noyau, et des dernières versions des pilotes libres. Mais de l’autre, cela signifie devoir se passer des pilotes proposés par le constructeur (pour le son, le GPS, le modem…), qui souvent n’ont jamais été proposés à l’inclusion dans le code source principal de Linux.

Au final, dans le cas de LuneOS, trois voies se dessinent lorsqu’il s’agit de faire tourner l’OS sur un téléphone ou une tablette :

Le constructeur remonte ses changements dans le noyau Linux, et s’appuie sur un développement open-source: Pine64 et Purism sont deux exemples récents de cette approche. C’est le cas idéal pour LuneOS, où des pilotes open-source bien intégrés peuvent être utilisées pour faire fonctionner les composants matériels.
Le constructeur ne propose qu’une version Android de ses pilotes et du noyau; ce dernier reste figé dans une même version, relativement récente, avec une maintenance minimale. LuneOS va alors utiliser Halium pour profiter des pilotes faits pour Android, tout en gardant le reste du système sur une pile logicielle « systemd/glibc » classique. Cette situation reste très présente, car l’immense majorité des téléphones et tablettes du marché tournent sur Android.
Le constructeur propose une vieille version du noyau, non maintenue, et dont les limitations deviennent problématiques pour LuneOS. Dans ce cas, LuneOS va tenter d’utiliser un noyau plus récent, mais qui a un support partiel du matériel. Cette stratégie a souvent un résultat très mitigé, avec de gros manques fonctionnels. En gros, c’est la tentative de la dernière chance avant l’abandon du support de ce matériel.

Le matériel Pine64

Une tablette PineTab2 avec LuneOS

Comme évoqué plus haut, Pine64 cultive ses liens avec la communauté open-source, et incite celle-ci à proposer leurs OS sur leur matériel. On retrouve ainsi de nombreux OS comme PostmarketOS, Plasma Mobile ou encore Ubuntu Touch. LuneOS a pris le train en marche très tôt, et peut aujourd’hui s’installer sur le Pinephone, le Pinephone Pro ainsi que sur la tablette PineTab 2.

Pour le Pinephone et le Pinephone Pro, LuneOS nécessite maintenant l’installation préalable de Tow-boot sur le téléphone. Ce dernier est un dérivé de U-Boot, qui vise à standardiser et faciliter le démarrage des OS sur du matériel embarqué.

Comme ce matériel tourne avec une version très récente du noyau Linux, il est possible pour LuneOS de lancer Waydroid; cependant cette fonctionnalité est jeune et nécessite encore beaucoup de travail.

Le matériel Android

LuneOS peut s’installer sur de nombreux autres téléphones (et sur la vénérable tablette HP Touchpad), grâce à l’utilisation de Halium (ici en version 9.0).

Cependant, même s’il n’est pas prévu d’abandonner les téléphones et tablettes Android, les efforts se concentrent de plus en plus sur le matériel pour lequel un noyau « mainline » existe.

Plans pour la prochaine version

Continuer la migration vers l’infrastructure de webOS-OSE

Mettre à jour les composants vers la dernière version de webOS-OSE, et finir la migration:

mettre à jour le moteur web vers Chromium 108 (tout juste sorti du four chez LG)
re-baser l’infrastructure audio et multimédia de LuneOS sur les composants fournis par webOS-OSE
travailler également sur le support des caméras

Continuer le travail sur le matériel supporté

Avoir un noyau « mainline » fonctionnel pour Tenderloin, Hammerhead, Mido and Tissot.
Fournir une image GSI unique pour les téléphones Android, permettant de faciliter grandement le support d’autres téléphones

Compléter l’espace applicatif

Améliorer ou ajouter des apps de base comme Camera, Flashlight, Audio Player ou Video Player, et améliorer les composants QML.
Essayer de profiter du travail fait par la communauté sur les TVs LG « homebrew » : webOS Brew

Envie d’essayer ?

Pour le téléchargement et l’installation, c’est par ici. Il existe notamment une image pour émulateur x86-64, utilisable directement dans VirtualBox.

L’équipe webOS-ports est présente sur IRC (Libera:#webos-ports) ou encore Telegram.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

L’auteur de Nginx enfourche le proprio

LinuxFr.org

Par : orfenor Ysabeau 🧶 🧦

15 février 2024 à 18:01

Maxim Dounin, l'un des principaux développeurs de NGINX (il est Nginx disent même certains) se barre et crée un fork.

Nginx est l'un des principaux serveurs web, voire le plus utilisé mais ça dépend des statistiques. Il est réputé pour sa vitesse, sa légèreté et sa solidité. La version libre est au coeur d'Nginx, aussi costaud, rapide et sécurisée que la version avec quelques extensions propriétaire. Malheureusement, ça pourrait ne plus être le cas :

En 2019, F5 Networks a racheté la société derrière Nginx. En 2022, F5 a fermé les bureaux de Moscou, signant un accord avec Maxim Dounin qui continuait bénévolement à travailler sur Nginx. Ayant quitté la société, il veillait sur cette pièce essentielle du web et du libre. Or en 2024, la nouvelle direction d'F5 n'entend que pouic à la technique et se focalise sur le marché. Elle s'est mêlée des questions de sécurité, préférant une version libre moins robuste afin de vendre plus de prestations — d'après Maxim Dounin.

Le 14 février, il en a eu marre et a lancé le projet Freenginx pour garantir un développement sans interférences marketing.

lien nᵒ 1 : Courriel d'annonce et réponses
lien nᵒ 2 : Le projet Freenginx

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

LinuxFr.org
Archiver ses vidéos : retour d’expérience.
18 janvier 2024 à 02:22

Archiver ses vidéos : retour d’expérience.

LinuxFr.org

Par : mobuturoiduzaire Julien Jorge orfenor Ysabeau gUI Tequila_Yuen

18 janvier 2024 à 02:22

Préambule : ma vie (et peut-être aussi la vôtre)

Comme probablement beaucoup d’entre vous, j’ai des milliers de photos et vidéos accumulées au cours des 20 dernières années. C’est très pratique de pouvoir stocker cela sur un seul disque dur. Mais cela pose trois problèmes majeurs :

la pérennité du support ;
le classement des fichiers pour pouvoir en retrouver un en particulier dans… très longtemps.
la possibilité de lire des fichiers dans plusieurs années (je pense à des fichiers Publisher 2.0 que je ne suis plus parvenu à lire par la suite – et non : les versions ultérieures à Publisher 2.0 ne lisent pas ces fichiers.

Ce texte s’adresse à toute personne qui se pose trois questions :

Pourrai-je visionner mes fichiers vidéos dans 30 ans pour les montrer à mes petits-enfants ?
Comment organiser/classer mes fichiers vidéos pour les retrouver rapidement ?
Comment réencoder mes fichiers vidéos pour limiter la place occupée (ou, dit autrement : quel format utiliser) ?

Après avoir lu cette dépêche, je vous recommande très fortement de vous reporter aux commentaires qui suivent car vous y trouverez probablement des précisions, liens, corrections ou suggestions qui l’enrichissent.

Pour le point 1., aucun support n’étant inaltérable/incassable, la règle tient en une phrase : « sauvegarder sur plusieurs supports (pour parer une éventuelle défaillance), dans différents endroits (en cas d’incendie, de vol, d’inondation…) et si possible en chiffrant ses disques (pour protéger votre vie privée en cas de vol : c’est incroyablement simple sous linux)
Pour le point 2., j’avais rédigé un document il y a fort fort longtemps où j’expliquais que le seul classement pérenne était le classement chronologique (je vous laisse vous reporter au document pour comprendre pourquoi l’utilisation de logiciels propriétaires est à proscrire). Pour résumer, je crée un dossier par année (2023) dans lequel il y a douze sous-dossiers (2023_01, 2023_02 etc.) et dans chacun d’eux, je crée un dossier par jour avec la date et le lieu (par exemple, 2023_06_25_saint_denis_la_reunion indique immédiatement où et quand ont été prises les photos et les vidéos à l’intérieur de ce dossier). Les photos sont renommées (et retournées si nécessaire) automatiquement avec l’instruction jhead -autorot -nf%Y_%m_%d__%H_%M_%S_ *.jpg. Les vidéos sont renommées manuellement sous la forme 2023_06_25__video_02_christophe_et_philippe_en_velo.mov ¹
Pour le point 3., le format JPG étant ouvert, la lisibilité des photos est garantie dans le temps. Pour les vidéos, c’est un peu plus compliqué puisqu’en général, trois formats interviennent :
- le codec vidéo pour l’image (comme h264, h265, av1, mjpeg…) ;
- le codec audio pour le son (comme mp3)
- le format de conteneur (comme avi, mp4, mts…)

C’est là où on en revient à l’histoire de ma vie.

note : je n’ai jamais trouvé comment récupérer les métadonnées des vidéos pour les utiliser dans le nom du fichier, comme je le fais avec jhead. ↩

Sommaire

I Il était une fois MA vie !

Après plus de 20 ans de stockage, mon disque dur de 1 To frisait les 90 % de remplissage. Alors, oui, 1 To, c’est très commun aujourd’hui : il me suffisait d’acheter un disque de 4 To et le problème était réglé.

Oui… mais non. Je n’aime pas occuper de la place. Je pense que c’est une mauvaise habitude que d’avoir des téraoctets disponibles ou des gigaoctets sur une carte SD pour son smartphone que l’on utilise sans se poser de questions en ayant l’impression d’un stockage illimité. Car un jour, cela nous revient dans les dents (carte SD/disque dur qui plante sans sauvegarde, réinstallation de tout le système, sauvegarde de ses milliers de photos que l’on se décide - un jour - de ranger dans un dossier A_RANGER1 puis A_RANGER2 puis A_RANGER3, etc. puis on abandonne).

En ayant un espace de stockage limité, on doit apprendre à le gérer.

Les plus anciens se souviennent peut-être des magnétoscopes : on achète des cassettes, on enregistre des films en se disant « je le regarderai un jour » et on se retrouve avec des centaines de cassettes qui prennent la poussière. Ben c’est pareil avec les disques durs : on a des téraoctets en pagaille et on se dit : « je garde, on ne sait jamais. Et un jour (qui n’arrivera jamais), je ferai le tri ! »
J’en reviens donc à mon disque dur quasi plein. Je fais une recherche sur mes fichiers vidéos et regarde le débit binaire (bitrate par la suite) : 40 000 kb/s soit environ 5 Mo/s pour des vidéos FullHD et jusqu’à 100 Mb/s (12 Mo/s) pour des vidéos 4k (évidemment, cela dépend de l’appareil à l’origine de la vidéo). Voici les différents bitrate que j’ai pu rencontrer :
• fichier mp4 4K drone : 100 Mb/s ;
• fichier mp4 4K go pro : 60 Mb/s
• fichier mov FullHD : environ 16Mb/s
• ficher avi 640*480 : environ 15 MB/ (mjpeg et format son araw)
• fichier avi 320*240 : entre 1 et 2,5 Mb/s

Loin d’être un expert dans la compression vidéo, le poids des fichiers m’interpelle quand même. En effet, un site de téléchargement de films - que je n’ai jamais fréquenté car c’est illégal - a pour objectif d’optimiser le ratio qualité/poids et donc d’offrir une bonne qualité visuelle pour un poids réduit. Ainsi, un film en FullHD de 90 min a un poids de 1400 Mo soit un bitrate d’environ 2 Mb/s (250 ko/s avec le codec H264). Un film en 4K de 90 min a un poids de 4 Go soit un bitrate d’environ 4Mb (500 ko/s avec le codec H265). Et il paraît – je ne le sais pas directement car je n’ai jamais fréquenté ce site dont je ne connais même pas l’existence – que la qualité des films sur le site en question est bonne, visuellement parlant s’entend.

Il était donc temps de se mettre au travail et de réencoder mes vidéos personnelles.

L’objectif de ce document est donc triple (et permettra de répondre aux questions 1. et 3. que s’est posé le lecteur ou la lectrice dans le préambule :

ré encoder ses vidéos automatiquement via un script bash (en utilisant le logiciel libre ffmpeg ) sans perte de qualité visible ;
réduire le poids des fichiers de façon notable (par notable, j’entends ici une réduction d’au moins 20 %, ce qui est totalement subjectif, mais j’assume) ;
s’assurer de la pérennité de ses vidéos (i.e. être capable de les visionner dans 20 ans) ;

II Mon environnement

Le matériel : Lenovo V45 (payé 300 € environ avec un AMD A4-9125 radeon R3, 8Go de mémoire vive et un SSD Samsung de 1To, le tout sous kubuntu 22,04).
Les logiciels : ffmpeg version 4.4.2, vlc, krename (pour renommer ses fichiers par lot), kfind pour retrouver des fichiers avec des extensions précises (je ne maîtrise pas du tout l’outil en ligne de commande find), avidemux pour faire du montage vidéo basique (couper quelques minutes d’une vidéo par exemple), dolphin pour naviguer dans les fichiers et, surtout, indicator-cpufreq (qui permet de réduire la fréquence du processeur et éviter que le ventilateur ne tourne en permanence).

III Les choix techniques

Je ne devais utiliser que des logiciels libres et des formats ouverts. Pour les logiciels : mon choix s’est porté sur ffmpeg pour l’encodage car c’est LA référence pour la conversion de vidéos, même si l’usage de la ligne de commande peut rebuter cetains (mais vous verrez par la suite que les scripts simplifient grandement la vie). Pour les formats :

MP3 pour l’audio : il n’est plus protégé par un brevet depuis 2017 et me convenait parfaitement, en choisissant un débit de 250kb/s (ce qui est sûrement excessif mais la place occupée par le son dans une vidéo est faible par rapport à la vidéo). Je sais qu’il y a vorbis mais le mp3 me semble plus « universel », notamment si l’on regarde la vidéo sur un téléviseur
MKV pour le conteneur : c’est un format ouvert et qui est lu sur tous les téléviseurs sur lesquels j’ai pu le tester.
H265 pour le format vidéo : c’est un format sorti en 2013 soumis à brevet mais il est possible d’utiliser une bibliothèque libre (x265) pour effectuer l’encodage (c’est cette bibliothèque qu’utilise ffmpeg). Là encore, lorsque j’ai testé des vidéos encodées en h265 sur différents téléviseurs pas trop vieux, je n’ai jamais eu de problème. Sachez qu’il existe le format AV1, plus récent, plus efficace en termes de compression, libre et qui répond à mes besoins. Mais deux éléments m’ont fait renoncer à l’utiliser :
- l’encodage (avec ma machine) est extrêmement lent (j’ai abandonné l’encodage de 30 secondes de vidéo quand, après une heure, il en était toujours à la première seconde !) ;
- il n’est pas encore généralisé : peu de téléviseurs peuvent lire ce format (si vous en connaissez, je suis preneur). Il est fort probable que dans une dizaine d’années, je réencoderai mes vidéos en AV1, mais laissons cela pour plus tard.

J’ai également choisi d’encoder mes vidéos en deux passes car cela me permet de décider du débit binaire (et donc de la taille du fichier finale) tout en ayant une meilleure qualité qu’en une passe.
J’ai utilisé le programme indicator-cpufreq qui me permet de réduire au minimum la fréquence de mon processeur (ici 1,2 Gh) afin d’éviter que le ventilateur ne tourne sans arrêt (à noter qu’une mise en veille repasse la fréquence au maximum et il n’est plus possible de la réduire, sauf à redémarrer l’ordinateur). Avec une fréquence réduite au minimum, le ventilateur ne se déclenche que quelques secondes toutes les minutes et le processeur ne dépasse pas les 50°C (c’est hardinfo qui me le dit).

IV Les problèmes rencontrés et les contraintes (spoiler : il faut du temps !)

L’encodage en deux passes permet d’obtenir une meilleure qualité visuelle (de ce que j’ai compris) mais au prix d’un temps de calcul doublé. Ainsi, une vidéo d’une minute (en FullHD) a nécessité environ 100 minutes d’encodage pour obtenir le fichier final. Autant vous dire que mon ordinateur a tourné pendant environ 5 mois près de 20 heures par jour en moyenne. En revanche, j’ai découvert comment arrêter un processus (kill - STOP numero_pid_util) lorsque j’avais besoin de retrouver toute la puissance du processeur et comment le reprendre plus tard (kill - CONT numero_pid_util). Par ailleurs, je n’ai pas trouvé comment utiliser la carte graphique pour le réencodage, car il paraît que c’est plus rapide…
Je ne connais pas l’instruction ou l’option (si elle existe) de ffmpeg qui permet de conserver les métadonnées des vidéos. Ainsi, la conversion effectuée avec les scripts ci-dessous supprime toutes les métadonnées (pourtant, cela semble possible)
Je n’ai pas trouvé, malgré mes recherches, comment reprendre la première passe d’un encodage après une coupure ou un bug (ffmpeg génère un fichier log durant la première passe, fichier qu’il devrait être possible de réutiliser afin de reprendre là où il s’est arrêté). Il m’a donc fallu, parfois, reprendre l’encodage d’une vidéo à zéro.
La procédure avant encodage demande de l’organisation :
- Rechercher toutes ses vidéos est relativement aisé et rapide : kfind permet d’effectuer une recherche sur de multiples formats. Ensuite, un copier-coller sur un autre disque dur permet de les isoler.
- Il est nécessaire de connaître le bitrate de chacune d’elle. Une recherche Internet et hop, le script qui va bien (voir la partie sur les scripts) génère un fichier CSV pour nous faciliter le travail.
- Il faut ensuite regrouper les vidéos par débit et définition : ainsi, une vidéo 640*480 de 10 Mb/s ne pouvait pas être dans le même répertoire qu’une vidéo en 320*240 de 5 Mb/s également puisque le bitrate final n’était pas le même. Là, pas de secret, il faut le faire manuellement. Mais rassurez-vous, bien souvent, les vidéos d’une même période ont toute le même bitrate.
- L’étape suivante a consisté à choisir le débit final des vidéos suivant leur définition de façon à ce que la vidéo finale subisse une compression pas ou peu visible à l’œil par rapport à l’original (ce qui est très subjectif). J’ai donc choisi (en partant des débits de YiFY et un peu au doigt mouillé) :
  - 10 Mb/s pour de la 4K (porté très rarement à 12 Mb/s si la vidéo comportait beaucoup de mouvements) ;
  - 4 Mb/s pour de la FullHD ;
  - environ 2 Mb/s pour de la 640*480
  - 1 Mb/s pour de la 320*240
Un bug est apparu lors de la conversion des fichiers MJPEG directement en H265 : les couleurs finales étaient complètement différentes des originales. Je ne suis pas le seul à avoir subi ce qui semble être un bug. Au final, j’ai contourné ce désagrément en convertissant d’abord ces fichiers en xvid avec un gros bitrate pour limiter la perte de qualité (opération très rapide) puis les xvid en H265, ce qui a réglé le problème.
J’imagine que, comme beaucoup d’entre nous, je souhaite limiter mon impact environnemental. N’ayant pas de panneaux photovoltaïques, mon empreinte carbone est probablement élevée car j’ai été contraint de laisser tourner mon ordinateur jour et nuit en consommant de l’électricité pas toujours verte. En contrepartie, j’économise l’achat d’un nouveau disque dur. Cela me permet de me donner bonne conscience.

V Les scripts utilisés

Ces scripts (qui fonctionnent sous Linux. Pour Windows, il faudra adapter…) ont été écrits à partir de ce que j’ai trouvé sur Internet car ma maîtrise de ce genre d’outils est très fragile voire inexistante (j’ai donc pas mal bidouillé et ils peuvent sûrement être optimisés). Je vous dirais volontiers qu’ils sont sous licence libre ou dans le domaine public mais n’ayant pas noté mes sources, je les livre ci-dessous sans aucune garantie de quoi que ce soit (la seule chose que je peux garantir, c’est que j’ai fait pas mal de modifications par rapport aux scripts originaux).
Je vous rappelle que pour utiliser ces scripts, vous devez faire un copier-coller du script dans un fichier texte (en utilisant kate par exemple), l’enregistrer puis le rendre exécutable. Ensuite, vous placez ce script dans le répertoire de vos vidéos, et, dans une console, vous tapez ./nom_du_script
Je pense avoir mis suffisamment de commentaires pour comprendre ce que fait chaque script. Si cela n’était pas le cas, signalez les erreurs ou les suggestions dans les commentaires.
Voici un résumé pour chacun d’eux :

convertion_par_lot_videos_en_265 : c’est le script que j’ai le plus utilisé pour convertir des vidéos en H265 en choisissant une ou deux passes et le bitrate.
convertion_par_lot_videos_en_265_une_passe_crf : convertir en une seule passe en choisissant la qualité voulue
convertion_par_lot_videos_en_xvid : convertir des vidéos au format XVID, lorsque la conversion des MJPEG vers H265 pose problème
convertion_vers_mkv_par_lot : convertir tous les formats de conteneur en MKV (j’ai eu parfois des problèmes avec certaines extensions, le passage en MKV réglait le problème) ;
convertion_videos_en_son_par_lot : ne garder que le son (pour des vidéos youtube que l’on souhaite uniquement écouter par exemple) ;
convertir_son_en_mp3_garder_video : réeconde uniquement le son en MP3, ne touche pas la vidéo
extraire_image_precise_d_une_video : permet d’extraire une image précise (par exemple la 123) d’une ou plusieurs vidéos. Ce script m’a permis de comparer l’image d’origine et l’image réencodée. J’utilisais ensuite Gimp pour visualiser les différences entre les deux images.
recuperer_bitrate_video_par_lot : récupère tous les bitrates des vidéos d’un même répertoire et l’exporte dans un fichier CSV (données séparées par une espace) ;
recuperer_toutes_infos_video_par_lot : exporte dans un fichier csv les dimensions de l’image, le fps etc. mais pas le bitrate (je n’ai pas trouvé comment fusionner ce script avec le précédent)
stabiliser_video_par_lot_en_testant_les_10_qualites : script pour stabiliser une vidéo avec une image « secouée » en testant les 10 qualités possibles automatiquement. Vous pouvez faire des tests, chez moi, ce n’était pas probant. Le script est à revoir probablement.
stabiliser_video_par_lot_version : idem que ci-dessus mais vous choisissez le paramètre de la stabilisation.
creer_video_cote_a_cote_par_lot : pour comparer deux vidéos en en créant une nouvelle avec les deux côte à côte (je l’utilise pour comparer la vidéo d’origine et la vidéo stabilisée).
supprimer_bande_son_video : ne conserve que la vidéo, supprime le son (pour des vidéos où le son ne présente aucun intérêt). Et c’est parti !

convertion_par_lot_videos_en_265

#/bin/bash
# conversion par lot de fichier video au format H265 avec audio en mp3 qualité 256k
# nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes (en théorie tout au moins...)
# si vous souhaitez interrompre le programme pour avoir accès à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util
echo "Ce script va réencoder vos vidéos (MKV MP4 MTS AVI MOV WEBM FLV MPG MPEG WMV 3GP RM ASX VOB F4V MKS M4V OGV M2V MPV TS M2TS AVC HEVC M1V M2V MPV) en H265, le son en MP3 256k et au format de conteneur MKV en 1 ou 2 passes. Vous allez pouvoir choisir le bitrate d'encodage pour la vidéo, le codec et le nombre de passe. Les extensions des vidéos peuvent être en minuscules ou majuscules mais pas un mélange des deux. Les fichiers originaux seront déplacés dans le dossier originaux et les fichiers convertis dans le dossier convertis_x265"
echo -n "Entrez le bitrate -sans espace - que vous souhaitez utiliser : (4000 recommandé pour de la video FullHD, 10000 pour de la 4K) "
read bitrate
# les lignes (rm x265_2pass.log / rm x265_2pass.log.cutree / rm x265_2pass.log.cutree.temp / rm x265_2pass.log.temp) suppriment les fichiers générés lors des deux passes
# pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
# pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)
echo -n "Souhaitez-vous une passe ou deux passes ? Taper 1 pour une passe (plus rapide mais de moins bonne qualité) ou 2 pour deux passes (plus lent mais la vidéo finale est de meilleure qualité) :  "
read passe
if [ "$passe" = "1" ] ; then
mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_x265
#crée un répertoire où seront déplacés les fichiers convertis
    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
    nice -19 ffmpeg -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=1 -c:a libmp3lame -b:a 256k "$i.mkv"
    mv "$i.mkv" ./convertis_x265
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux
    done
elif [ "$passe" = "2" ]; then
mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_x265
#crée un répertoire où seront déplacés les fichiers convertis
    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
    nice -19 ffmpeg -y -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=1 -an -f null /dev/null && \
    #première passe
    nice -19 ffmpeg -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=2 -c:a libmp3lame -b:a 256k "$i.mkv"
    mv "$i.mkv" ./convertis_x265
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux
#les lignes suivantes suivantes suppriment les fichiers temporaires de la première passe en cas d'interruption.
    rm x265_2pass.log
    rm x265_2pass.log.cutree
    rm x265_2pass.log.cutree.temp
    rm x265_2pass.log.temp
    rm x264_2pass.log
    rm x264_2pass.log.cutree
    rm x264_2pass.log.cutree.temp
    rm x264_2pass.log.temp
    done
else
    echo "Il faut taper 1 ou 2, rien d'autre. Relancez le script !"
fi
    rm x265_2pass.log
    rm x265_2pass.log.cutree
    rm x265_2pass.log.cutree.temp
    rm x265_2pass.log.temp
    rm x264_2pass.log
    rm x264_2pass.log.cutree
    rm x264_2pass.log.cutree.temp
    rm x264_2pass.log.temp

convertion_par_lot_videos_en_265_une_passe_crf

#!/bin/bash
# conversion par lot de fichier video au format H265 avec audio en mp3 qualité 320k
# nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes.
# si vous souhaitez interrompre le programme pour avoir accès à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util

echo "Ce script va réencoder vos vidéos (MKV, MP4, MTS, AVI, MOV, WEBM FLV) en H265, le son en MP3 256k et au format de conteneur MKV en 1 passe. Vous allez pouvoir choisir CRF (constant rate factor) pour la vidéo. Les extensions des vidéos peuvent être en minuscules ou majuscules mais pas un mélange des deux."
echo -n "Entrez le CRF que vous souhaitez utiliser : (entre 1 et 51 - 1 pour la meilleure qualité, 51 pour la plus mauvaise) - 28 est recommandé : "
read crf

echo -n "Entrez la vitesse que vous souhaitez utiliser : (ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow) - votre choix joue sur la vitesse de traitement et la qualité. Superfast sera très rapide mais de moins bonne qualité. medium est le choix recommandé. Votre choix : "
read speed

# on peut modifier le fichier de sortie en ajoutant un répertoire : "$i.mkv" devient "/home/perso/mon_repertoire/$i.mkv"
# les lignes (rm x265_2pass.log / rm x265_2pass.log.cutree / rm x265_2pass.log.cutree.temp / rm x265_2pass.log.temp) suppriment les fichiers générés lors des deux passes
# pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
# pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)
mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_x265
#crée un répertoire où seront déplacés les fichiers convertis

    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ;
    do
    nice -19 ffmpeg -i "$i" -c:v libx265 -crf "$crf" -preset "$speed" -c:a libmp3lame -b:a 256k "$i.mkv"

    mv "$i.mkv" ./convertis_x265
    #déplace les fichiers convertis

    mv "$i" ./originaux
    #déplace les fichiers originaux
    done

#les lignes suivantes suivantes suppriment les fichiers temporaires de la première passe en cas d'interruption.
    rm x265_2pass.log
    rm x265_2pass.log.cutree
    rm x265_2pass.log.cutree.temp
    rm x265_2pass.log.temp
    rm x264_2pass.log
    rm x264_2pass.log.cutree
    rm x264_2pass.log.cutree.temp
    rm x264_2pass.log.temp

convertion_par_lot_videos_en_xvid

#!/bin/bash
# ce script balaie tous les fichiers d'un même répertoire et va convertir les AVI en XVID et conserver le son d'origine
# nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes.
# si vous souhaitez interrompre le programme pour avoir accès à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util

echo "Ce script va réencoder vos vidéos AVI en XVID, conserver le son d'origine et au format de conteneur MKV en 2 passes. Les extensions des vidéos (AVI ou avi) peuvent être en minuscules ou majuscules mais pas un mélange des deux. La convertion directe de MJPEG vers 265 pose des problèmes de couleurs. Il faut donc passer par XVID d'abord (voir https://stackoverflow.com/questions/71397605/ffmpeg-mjpeg-h-265-smeared-color-on-output-video-file )"
# on peut modifier le fichier de sortie en ajoutant un répertoire : "$i.mkv" devient "/home/perso/mon_repertoire/$i.mkv"
# pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
# pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion

mkdir convertis_xvid
#crée un répertoire où seront déplacés les fichiers convertis

    for i in *.avi *.AVI ; do
    nice -19 ffmpeg -y -i "$i" -c:v mpeg4 -vtag xvid -b:v 16000k -pass 1 -an -f avi /dev/null
    ffmpeg -i "$i" -c:v mpeg4 -vtag xvid -b:v 16000k -pass 2 -c:a copy "$i.mkv"

    mv "$i.mkv" ./convertis_xvid
    #déplace les fichiers convertis

    mv "$i" ./originaux
    #déplace les fichiers originaux

    done

convertion_vers_mkv_par_lot

#!/bin/bash
# conversion par lot de fichiers vers mkv - mofifier l'extension si nécessaire - supprimer les extensions d'origine avec krename ensuite. Attention, s'il y a déjà des fichiers MKV, ils seront reconvertis en MKV

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_mkv
#crée un répertoire où seront déplacés les fichiers convertis

    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do


#    autre chose trouvé sur internet avec bug : ffmpeg -flags +genpts -i "$i" -c copy -sn "$i.mkv"

nice -19 ffmpeg -y -i "$i" -c:v copy -c:a copy "$i.mkv"
  mv "$i.mkv" ./convertis_mkv
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux

done

convertion_videos_en_son_par_lot

#!/bin/bash
# conversion par lot de fichiers vers mkv - mofifier l'extension si nécessaire - supprimer les extensions d'origine avec krename ensuite. Attention, s'il y a déjà des fichiers MKV, ils seront reconvertis en MKV

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_mkv
#crée un répertoire où seront déplacés les fichiers convertis

    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do


#    autre chose trouvé sur internet avec bug : ffmpeg -flags +genpts -i "$i" -c copy -sn "$i.mkv"

nice -19 ffmpeg -y -i "$i" -c:v copy -c:a copy "$i.mkv"
  mv "$i.mkv" ./convertis_mkv
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux

done

convertir_son_en_mp3_garder_video

#!/bin/bash
echo -n "Ce script va convertir le son des videos en mp3 sans toucher la video et ajouter l'extension .MKV à la fin du fichier. Choisissez la qualité mp3 (256 recommandé) : "
read bitratemp3

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_mp3
#crée un répertoire où seront déplacés les fichiers convertis


for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do

    nice -19 ffmpeg -i "$i" -c:v copy -c:a libmp3lame -b:a "${bitratemp3}k" "$i.mkv"

    mv "$i.mkv" ./convertis_mp3
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux
done

extraire_image_precise_d_une_video

#!/bin/bash


echo -n "Entrez le numéro de l'image que vous souhaitez extraire (attention, la numérotation commence à 0 donc si vous souhaitez la frame 536, il faut saisir 535) "
read num_frame


for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do



nice -19 ffmpeg -i "$i" -vf "select=eq(n\,$num_frame)" -vframes 1 screenshot_frame_"$num_frame"_"$i".png

done

recuperer_bitrate_video_par_lot

#!/bin/bash

#recherche le bitrate des videos de façon récursive
find . \( -iname "*.mkv" -or -iname "*.mov" -or -iname "*.mts" -or -iname "*.mp4" -or -iname "*.mpg" -or -iname "*.mpeg" -or -iname "*.flv" -or -iname "*.avi" -or -iname "*.webm" -or -iname "*.wmv" -or -iname "*.3gp" -or -iname "*.rm" -or -iname "*.asx" -or -iname "*.vob" -or -iname "*.f4v" -or -iname "*.mks" -or -iname "*.m4v" -or -iname "*.ogv" -or -iname "*.m2v"  -or -iname "*.mpv" -or -iname "*.ts" -or -iname "*.m2ts" -or -iname "*.avc" -or -iname "*.hevc" -or -iname "*.m1v" -or -iname "*.m2v" -or -iname "*.mpv" \) -print0 | xargs -0 -i{} sh -c " echo -n '{} ' && ffmpeg -i '{}' 2>&1 | sed -n -e 's/^.*bitrate: //p' " > result_bitrate.csv
#ecrit le bitrate de toutes les videos d'un dossier dans le fichier result_mts.csv.
# Ouvrir avec tableur et choisir séparateur ESPACE pour mieux visualiser les bitrate

recuperer_toutes_infos_video_par_lot

#!/bin/bash

#recherche les informations des videos
find . \( -iname "*.mkv" -or -iname "*.mov" -or -iname "*.mts" -or -iname "*.mp4" -or -iname "*.mpg" -or -iname "*.mpeg" -or -iname "*.flv" -or -iname "*.avi" -or -iname "*.webm" -or -iname "*.wmv" -or -iname "*.3gp" -or -iname "*.rm" -or -iname "*.asx" -or -iname "*.vob" -or -iname "*.f4v" -or -iname "*.mks" -or -iname "*.m4v" -or -iname "*.ogv" -or -iname "*.m2v"  -or -iname "*.mpv" -or -iname "*.ts" -or -iname "*.m2ts" -or -iname "*.avc" -or -iname "*.hevc" -or -iname "*.m1v" -or -iname "*.m2v" -or -iname "*.mpv" \) -print0 | xargs -0 -i{} sh -c " echo -n '{} ' && ffmpeg -i '{}' 2>&1 | sed -n -e 's/^.*Video: //p' " > result_toutes_les_infos.csv


#ecrit les informations toutes les videos d'un dossier dans le fichier result_toutes_les_infos.csv.
#Ouvrir avec tableur et choisir séparateur ESPACE pour mieux visualiser les bitrate

stabiliser_video_par_lot_version

#!/bin/bash
# stabiliser des videos par lot

echo -n "Sélectionnez la stabilité de la vidéo que vous souhaitez : 1 (très stable) jusqu'à 10 (très instable)  "
read stabilite

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir stabilisee
#crée un répertoire où seront déplacés les fichiers convertis

for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do

    nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$stabilite:accuracy=15 -f null - && \

#shakiness=10 peut etre modifié en mettant shakiness = nombre_entre_1_et_10 : 1 video stable, 10 video très instable

    nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$stabilite:accuracy=15 -f null -&& nice -19 ffmpeg -i "$i" -vf vidstabtransform=smoothing=30:input="transforms.trf" "stabilisee_$i"

rm transforms.trf

mv "stabilisee_$i" ./stabilisee
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux
done

creer_video_cote_a_cote_par_lot

#!/bin/bash
#ce script va créer une vidéo à partir de deux vidéos, l'une que l'on peut nommer ma_video.mkv et l'autre qui doit alors se nommer stabilisee_ma_video.mkv
#les deux vidéos seront côte à côte, ce qui permet de les comparer
for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB ; do


# la video d'origine correspond à $i et l'autre video doit commencer par "stabilisee" mais il suffit de changer le prefixe si necessaire

    ffmpeg -i "$i" -i "stabilisee_$i" -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w" "cote_a_cote_$i"


done

supprimer_bande_son_video

#!/bin/bash
#supprimer la bande son de toutes les videos (au format voir ci-dessous) d'un même répertoire et crée un fichier MKV sans bande son. Ne réencode pas la vidéo.

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir sans_son
#crée un répertoire où seront déplacés les fichiers convertis


    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
    nice -19 ffmpeg -i "$i" -c copy -an "$i.mkv"

    mv "$i.mkv" ./sans_son
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux


    done

stabiliser_video_par_lot_en_testant_les_10_qualites

#!/bin/bash
# test toutes les qualités de stabilisation pour un même fichier

# test les 10 qualités de stabilité

        for qualite in 1 2 3 4 5 6 7 8 9 10 ; do
            for i in *.mkv ; do

            # nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$qualite:accuracy=15 -f null - && \

            #shakiness=10 peut etre modifié en mettant shakiness = nombre_entre_1_et_10 : 1 video stable, 10 video très instable

            nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$qualite:accuracy=15 -f null -&& nice -19 ffmpeg -i "$i" -vf vidstabtransform=smoothing=30:input="transforms.trf" "stabilisee_$i_$qualite.mp4"

            rm transforms.trf

            done


        done

En conclusion

Il faut du temps et de l’envie pour se lancer dans cette aventure, même si le CPU fait 80 % du travail. Mais les 20 % restant ne sont pas à négliger. Entre les copier-coller qu’il ne faut pas rater, le classement des vidéos par bitrate ou dimension, les vidéos réencondées qu’il faut visionner (en accéléré) pour s’assurer qu’elles sont correctes, etc. il faut vraiment rester concentré pour éviter d’oublier une vidéo ou, pire, de l’effacer alors qu’elle n’a pas été réencondée.

Les avantages

Mais je ne regrette pas tout ce temps, surtout pour avoir revisionné quasiment toutes mes vidéos, celle de mes enfants bébé (le coup de vieux en pleine figure), les moments en famille, les grands-parents disparus… Cela a été des moments vraiment agréables.

Cela m’a également permis de ranger des vidéos qui n’étaient pas dans le bon répertoire ou de renommer celles qui comportaient une erreur dans leur nom.

J’ai maintenant toutes mes vidéos avec le même format de conteneur (MKV), et les mêmes codec vidéo et audio, ce qui facilitera grandement un réencodage ultérieur.

Et puis – c’était l’un des objectifs – le gain de place est très important puisque mon disque dur est passé de 90 % à 48 % d’occupation (j’ai fait aussi un peu de ménage donc ce gain ne provient pas que du réencodage des vidéos).

Les inconvénients

Est-ce une bonne idée de mettre tous ses œufs dans le même panier (un seul format de conteneur, un seul codec video, un seul codec audio) , même si ces formats sont libres et, pour H265, lisible avec des logiciels libres, ce qui est tout de même une bonne assurance pour l’avenir ?

Du temps, du temps, et encore du temps : il faut en avoir pour ce projet (mais j’espère que les scripts vous permettront d’en gagner)

Cela consomme de l’énergie et, si beaucoup de gens veulent réencoder leurs vidéos, l’impact environnemental ne sera pas négligeable.

L’opération monopolise un ordinateur (nice -19 ne m’a pas paru très efficace quand je lançais trois encodages simultanément!). Mais cela peut être l’occasion d’en utiliser un qui dort dans un placard et qui pourrait ainsi resservir.

Si c’était à refaire…

Je le referai, sans aucun doute !
J’essaierai de conserver les métadonnées (date, heure, coordonnées GPS) de mes vidéos (même si les informations les plus importantes sont dans leur nom) ;
Je tenterai d’utiliser le GPU pour le réencodage, ce qui réduirait le temps de calcul.

Note pour le prochain confinement :

convertir les vidéos en AV1 ;
convertir les photos en AVIF ;
créer des fichiers PAR2 pour sécuriser mes sauvegardes

[1] : je n'ai pas réussi à trouver l'équivalent de la commande jhead -autorot -nf%Y_%m_%d_%H%M_%S_ *.jpg pour les videos

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

LinuxFr.org
Degate : espionner un CPU depuis les waters
16 janvier 2024 à 08:26

Degate : espionner un CPU depuis les waters

LinuxFr.org

Par : devnewton 🍺 Dorian Bachelot orfenor Benoît Sibaud Kannagichan L'intendant zonard theojouedubanjo

16 janvier 2024 à 08:26

Degate est un logiciel libre pour faire de l'ingénierie inverse sur les processeurs.

Pour le présenter, Dorian Bachelot, mainteneur du projet, a accepté de répondre à nos questions.

Logo Degate

lien nᵒ 1 : Degate
lien nᵒ 2 : Code source

Sommaire

Présentation

Entretien avec Dorian Bachelot

Présentation

Qui êtes-vous ? Quel est votre parcours ?

C’est sûrement très « bateau », mais comme beaucoup je suis avant tout un passionné d’informatique et d’électronique. J’ai commencé à programmer dans mes années collège (début des années 2010) et suis rapidement arrivé à découvrir Linux ainsi que d’autres galaxies (C++, git, virtualisation, reverse engineering…). Par la suite j’ai eu la chance de réaliser un diplôme d’ingénieur à l’ESIEA (école d’ingénieur généraliste sur Laval) qui m’a permis de découvrir de nombreux domaines comme l’électronique embarquée, la cybersécurité et l’intelligence artificielle. Comme beaucoup, j’ai un faible pour les domaines complexes et devoir me limiter à une seule spécialité pour mes études ne m’allait pas trop. C’est sur ce dernier point que démarre l’aventure Degate au côté du laboratoire de recherche en cybersécurité de mon école. Cette dernière proposait en effet un format « espoir recherche » permettant de creuser un sujet de recherche en plus des cours. Mon sujet a justement porté sur Degate, puisque comme nous allons le voir la rétro-ingénierie matérielle a l’avantage de toucher autant à l’électronique, qu’à la physique, la cybersécurité et l’intelligence artificielle !

Quant à aujourd’hui, après avoir travaillé sur le sujet de la rétro-ingénierie matérielle pendant presque 3 ans (en publiant 5 articles dans Hackable et en travaillant sur Degate) et avoir obtenu mon diplôme, je suis Tech Lead R&D Cyber/IA chez Neverhack (on vient de lever 100 millions d’euros). J’ai pu en effet garder une dualité de spécialité, à travers la cybersécurité et l’intelligence artificielle, principalement grâce à cette aventure d’espoir recherche (et donc en partie de Degate) ¹.

Est-ce que vous êtes parent de Roselyne ?

Et non, du tout, mais bien vu ;)

Qu’est-ce que Degate ?

En une phrase : Degate est un logiciel open source (GPL-3.0) et multiplateforme aidant ses utilisateurs à effectuer de la rétro-ingénierie sur des puces de silicium ².

Maintenant, pour donner un peu de contexte, le développement de Degate a commencé dès 2008 avec la thèse de master de Martin Schobert ³. Jusqu’à la fin de cette dernière en 2011, Martin a pu faire évoluer la solution et collaborer avec d’autres chercheurs pour l’utiliser sur des sujets de cybersécurité. Par exemple, Degate a pu être utilisé ⁴ pour aider à la rétro-ingénierie de la puce RFID MIFARE Classic de NXP (le développement de Degate a d’ailleurs pour source ce cas précis). Par la suite, les chercheurs Karsten Nohl et Starbug ont pu trouver une faille cryptographique dans la puce permettant d’outrepasser toutes les sécurités (on parle ici d’un impact économique énorme pour NXP) ⁵.

Degate est donc un logiciel avec une histoire riche de plus de 10 ans, qui a déjà permis d’avoir un impact dans l’industrie (et, suite au cas MIFARE Classic, dans la société). Il est aujourd’hui le seul bastion permettant à n’importe qui (ou presque) d’effectuer de la rétro-ingénierie matérielle sur des puces.

Pourquoi dis-tu que c’est le seul bastion ?

On peut voir ça sous différents angles, mais je parle d’unique bastion car Degate est le seul logiciel disponible à la fois gratuit, accessible (traduction de l’interface, documentation, etc.) et extensible (car open source). Or, les alternatives payantes sont généralement vendues sous conditions et donc difficilement accessibles. Seulement, comme je l’ai expliqué (modulo une déformation par mon parcours), la sécurité d’aujourd’hui passe, pour moi, forcément par une utilisation de la rétro-ingénierie matérielle beaucoup plus massive pour valider tout matériel critique. Et Degate n’est pas qu’un logiciel (surtout à sa création en 2008, c’était plus un outil ou un démonstrateur), c’est aussi une preuve d’importance (MIFARE Classic) et des ressources en ligne (wiki, articles, thèse, etc.). Il ne faut pas seulement voir le logiciel (avec ses défauts), mais plutôt l’approche : essayer de rendre plus accessible la rétro-ingénierie matérielle. Je ne clame pas que Degate réussit à remplir cette vision, mais je crois que nous sommes quasiment les seuls à essayer depuis maintenant plus de 10 ans (outre les projets visant à « rétro-ingénierier » certaines puces en particulier, sans prendre le prisme de la sécurité et de l’accessibilité).

Comment ça fonctionne ?

Avant tout il faut comprendre les contraintes et méthodes permettant d’effectuer de la rétro-ingénierie sur un objet aussi petit et complexe qu’une puce de silicium. Quand on parle d’une puce, on parle d’un agencement de milliards de transistors sur quelques millimètres et de leurs liens répartis sur plusieurs couches. La première étape est alors de définir un objectif, pouvant être la reconstruction d’un algorithme implémenté matériellement (et donc dans une zone réduite de la puce) ou encore la reconstitution complète du fonctionnement de la puce, par exemple pour construire un simulateur. Ensuite, il faut réussir à récupérer des images de la puce et de toutes ses couches (images en 2D ou 3D, un de mes articles dans Hackable aborde le sujet ⁶). Toutes les méthodes permettant d’obtenir ces images impliquent un processus destructeur pour la puce. Cela passe par exemple par un processus de polissage itératif et la prise de photographies (attention, on parle d’un exercice très complexe puisqu’une couche de silicium c’est extrêmement fin, et trop polir implique de devoir recommencer sur une nouvelle puce). On peut aussi prendre une approche chimique (utilisation d’acide pour attaquer couche par couche) ou laser. Sans développer beaucoup plus, ce processus est le plus important, car c’est avec ces photos très hautes résolutions que l’on va pouvoir débuter l’analyse de la puce.

C’est là que Degate rentre en jeu, son objectif est de permettre d’utiliser les images obtenues, de les importer dans le logiciel (on parle généralement d’images de plusieurs Giga, voire Tera, tellement la résolution et leur taille sont grandes) puis de commencer l’analyse. Ensuite, l’utilisateur peut analyser les parties de la puce en partant de la couche la plus basse, celle avec les transistors, et ainsi reconstruire les portes logiques (c’est ici que des connaissances en physique et en électronique sont importantes, il faut savoir lire à travers les transistors !). Comme vous vous en doutez, effectuer l’analyse de chaque transistor quand il peut y en avoir des milliards serait trop fastidieux, et Degate facilite le processus. Ce dernier propose en effet de construire une bibliothèque de portes logiques reconstituée depuis une zone de l’image de la puce, et puisque l’agencement des transistors ne change pas pour chaque porte logique, on peut alors automatiser la recherche et reconstitution de ces portes via des algorithmes de reconnaissance d’images. Il ne reste alors à l’utilisateur qu’à analyser les connexions entre les portes logiques toujours grâce aux images de la puce (couches supérieures, les liaisons entre couches sont appelées des « Via ») et ainsi reconstituer les algorithmes utilisés par la puce. Degate permet là encore d’automatiser une partie du processus en aidant à la reconnaissance des connexions et en proposant d’exporter toute l’analyse dans un langage type VHDL (permettant de simuler le fonctionnement de la puce, si l’analyse a été réussie).

Degate ne permet donc pas d’automatiser tout le processus de rétro-ingénierie, et une expertise humaine reste nécessaire (décapage de la puce, prise des photos, analyses des portes logiques puis des connexions), mais il permet de gagner un temps non négligeable sur l’analyse en automatisant plusieurs étapes. Pour cela, Degate implémente des algorithmes de reconnaissances d’images, supporte l’importation d’images extrêmement grandes (plusieurs millions de pixels de large), vous aide dans la navigation des images et couches, vous permet d’identifier les portes logiques formées par des transistors et bien plus.

Si le sujet vous intéresse, je peux vous donner les références suivantes : on peut citer Ken Shirriff qui est LA personne à suivre sur le sujet (auteur de beaucoup d’analyses sur des puces historiques ⁷, comme la Intel 8086 ou la fameuse Z80), ou encore la communauté Visual 6502 ⁸ qui ont rétro-ingénierié plusieurs puces (en partant de simples images pour finir par la création de simulateurs complets) ! Vous pourrez également explorer le super site Silicon Pr0n ⁹. Enfin, pour trouver une liste plus complète n’hésitez pas à vous rendre directement sur le dépôt de Degate ¹⁰.

Il existe des protections contre ceci ? J’imagine que certaines entreprises n’aimeraient pas qu’on fasse de la retro-ingénierie sur leur puce, il me semble que certaines puces possèdent un genre de grillage.

En effet, il existe beaucoup de méthodes pour essayer de s’en protéger. On parle de deux grandes catégories : les protections passives et actives. Les protections passives peuvent par exemple prendre la forme de résine que l’on “coule” sur les puces pour complexifier leurs récupérations (et aussi empêcher la récupération des références), ou d’une couche directement dans le silicium pour bloquer l’analyse visuelle de surface. D’autres méthodes existent, mais généralement de l’huile de coude et du bon matériel permettent de passer outre. Les méthodes actives sont plus recherchées et protègent contre d’autres approches de la rétro-ingénierie matérielle. Comme cité dans la question, l’ajout d’un grillage actif est une solution assez répandue dans les puces de cartes bleues par exemple. L’idée est à la fois de bloquer une analyse visuelle de surface de la puce, mais aussi d’empêcher le “probing” (essayer d’utiliser une sonde directement sur un “circuit” de la puce) ou la modification de la puce (par exemple en connectant deux “circuits” de la puce). Cela passe par un maillage avec des formes complexes (on peut voir ça comme un labyrinthe) alimenté par un courant qui, en cas de modification du circuit, peut rendre la puce non fonctionnelle. Il est alors compliqué d’aller voir et manipuler les couches inférieures en laissant la puce fonctionnelle. ¹¹

Est-ce que les différentes façons de gravure qui utilise différent MOSFET (CMOS, FinFET, MBCFET, FD-SOI etc) ne demandent pas des analyses différentes ? Est-ce que ça sera fiable avec les derniers types de gravure avec des transistors imbriqués 3D ?

À tout problème sa solution : les méthodes d’analyses 3D de puces de silicium se développent également ⁶. Si le matériel nécessaire pour créer les données 3D venait à être plus accessible, je prévois déjà l’ajout d’un mode d’analyse à Degate permettant de les exploiter. Je ne doute cependant pas que les méthodes d’analyses actuelles fonctionnent pour la majorité des cas, même si le problème est déjà suffisamment complexe pour ne pas rajouter ces spécificités. Je n’ai personnellement pas pu couvrir toutes les méthodes de gravures dans mes analyses ni les nouvelles approches en 3D. Seulement, ces méthodes s’appliquent pour l’instant majoritairement à la mémoire, ce qui n’est pas forcément la cible des analyses.

Qui se sert de Degate ? Est-ce une communauté de fans de consoles ou des professionnels confrontés à des puces qui ne sont plus documentées ou des gens du logiciel libre, etc. ?

Dès ses premiers jours, Degate a été pensé pour la cybersécurité. L’idée était de pouvoir faciliter l’analyse d’algorithmes implémentés directement dans les puces de silicium, à la fois pour essayer d’identifier des failles, mais aussi pour vérifier la présence de portes dérobées. En effet, d’un point de vue sécurité trop peu de personnes vont voir ces puces alors que tout dépend d’elles. Comment faire confiance à un système si l’on ne peut pas vérifier la sécurité de son composant le plus important et bas niveau ? Permettre à des chercheurs et passionnés d’attaquer le sujet est ma principale motivation quand je travaille sur Degate, le sujet est pour moi majeur. On a trop tendance à s’arrêter à la rétro-ingénierie logicielle, et c’est malheureusement un risque que l’on oublie trop.
Je sais aujourd’hui que Degate est utilisé (ou a été étudié) par des entreprises américaines dans le cadre de l’analyse de puces (je ne sais pas pour quel objectif), par la police allemande et par une université.

Malheureusement le domaine n’encourage pas beaucoup la communication et Degate pourrait être utilisé ailleurs. J’ai d’ailleurs de gros doutes sur son utilisation par une entreprise américaine sous forme de fork non-partagé (ne respectant alors pas la licence GPL qui est copyleft…). Mais ça, c’est un combat classique du monde libre (pour dire, on m’avait même proposé de me payer pour travailler dessus…).

Mais autrement, le logiciel peut être utilisé par d’autres communautés, comme pour les fans de vieux systèmes. Je sais que la communauté qui s’occupe de rétro-ingénierer la PlayStation s’est déjà intéressée à Degate ¹².

Concernant la sécurité, quels types de puces sont concernées ? J’imagine qu’il ne s’agit pas d’analyser les processeurs généralistes de nos ordinateurs… Ce sont des puces qu’on trouve dans quels matériels ?

C’est très large, généralement on parle de puces avec des missions/parties critiques. Par exemple (comme pour le cas MIFARE Classic), des puces implémentant des algorithmes cryptographiques sont importantes à regarder : au niveau logiciel on recommande (et c’est un euphémisme) de ne jamais réimplémenter ses propres primitives cryptographiques, pourtant beaucoup de puces le font (méthode simple pour booster les performances, aujourd’hui tout utilise de la cryptographie). Maintenant, on parle généralement de certaines parties/fonctions d’une puce plus que des puces entières. On peut par exemple citer en plus de la cryptographie tout ce qui concerne le stockage de données critiques (comme les clés de chiffrement). Aujourd’hui, je pense que l’on retrouve ces fonctionnalités dans tout type de matériel.

Comment en êtes-vous devenu le mainteneur ?

Comme je l’ai expliqué précédemment, c’est via un programme proposé par mon école d’ingénieur que j’ai été amené à travailler sur le sujet de la rétro-ingénierie matérielle à partir de fin 2018. Et comme Degate était le seul programme gratuit et open source permettant d’automatiser une partie du processus (indispensable pour arriver à des résultats sans y passer 10 ans), j’ai rapidement eu l’occasion de pouvoir l’utiliser. Malheureusement l’auteur originel du logiciel ne contribuait plus au projet depuis quasiment 8 ans à l’époque, et j’ai rapidement rencontré des difficultés pour l’utiliser plus largement dans mes recherches.

Après quelques mois de travail et un refactor à 70 % du projet (j’ai par exemple refait toute la GUI en Qt5 + OpenGL moderne) pour repartir sur de bonnes bases, j’ai publié mon fork sur Github. Par la suite Martin (l’auteur originel de Degate) a préféré mettre le projet initial en archive sur Github, et faire une redirection vers cette nouvelle version (aujourd’hui refaite à quasiment 80 % par moi-même). L’idée était de garder le nom et la communauté même si la grande majorité du logiciel a été refait.

Maintenant, suite à la fin de mes études, je dispose de moins de temps qu’avant et je suis forcément moins actif. Mais j’essaie de traiter toutes les issues et pull request, tout en continuant à travailler sur de nouvelles fonctionnalités. Je cherche également à faire pérenniser le projet en proposant à des étudiants comme moi (à l’époque) un financement pour travailler sur le sujet (et surtout Degate). Reste maintenant à trouver des personnes motivées, car le sujet est vraiment complexe.

Tu n’utiliseras donc pas Degate dans le cadre de ton travail ?

Aujourd’hui non, mais je sais que la question se pose pour des collègues. Le test d’intrusion matériel se développe, et le sujet se pose de plus en plus. Maintenant les compétences nécessaires pour s’attaquer à la rétro-ingénierie de puces de silicium sont un frein pour descendre aussi bas, sans compter le problème du matériel (faut-il encore pouvoir décaper/déstratifier les puces avant de pouvoir commencer l’analyse). La solution actuelle est de pouvoir accéder au design des puces (test en white box), mais les limites sont déjà visibles (un matériel est généralement composé de nombreuses puces de constructeurs différents).

Quelle est ta motivation ? Qu’est ce qui t’anime avec Degate ? Puisque tu as commencé l’informatique assez jeune, tu jouais peut-être avec des consoles ; est-ce que Degate te permet aussi d’imaginer recréer les puces de ton enfance ?

Étant aujourd’hui un ingénieur chercheur porté sur la cybersécurité, cela me force à voir Degate et la rétro-ingénierie matérielle à travers ce prisme. Pouvoir permettre à des chercheurs d’analyser des puces utilisées dans des millions de matériels à travers la planète est ce qui m’anime, même si je ne doute pas que bien d’autres cas d’utilisations peuvent être tout aussi intéressants. Je suis par exemple aussi très porté sur l’histoire, et la rétro-ingénierie matérielle est aussi un moyen de ne pas perdre certaines pièces de notre histoire.

Est-ce que vous tirez un revenu de ce travail ? Est-ce une bonne wafer ?

Je suis actuellement financé 100$/mois par le mainteneur principal de Rizin/Cutter (logiciel de rétro-ingénierie software) et j’ai déjà eu plusieurs autres propositions de financement. Ayant également publié des articles sur le sujet, j’ai quand même pu être rémunéré pour ce travail, mais on est très loin de quelque chose me permettant de vivre (et ce n’est pas l’objectif).

Pour finir

Que dire sur vos autres projets ?

Au niveau personnel je travaille (quand j’ai le temps) sur une nouvelle approche IA au service de la cybersécurité défensive. Malheureusement mon temps est très limité, et j’évite de trop m’éparpiller. Au niveau professionnel je suis aujourd’hui Tech Lead et Team Leader sur un projet d’automatisation de cybersécurité offensive. L’idée étant de créer un outil entièrement automatisé par IA permettant de jouer des attaques avec le même niveau de sophistication que les vrais acteurs (généralement quand je parle du projet on me parle de Skynet, pour ceux ayant la référence). Un produit devrait sortir dans les deux ans, nous avons déjà fait de nombreuses avancées scientifiques mais la route est encore longue. C’est aujourd’hui ce qui occupe le plus clair de mon temps !

Que pensez-vous de la directive NIS 2 sur la cybersécurité ?

La France a été pionnière en matière de réglementation dans le domaine de la cybersécurité, et je pense que la directive NIS 2 se place dans le même esprit que ce que l’on fait déjà depuis plusieurs années (avec la LPM de 2013 par exemple). Je sais que ces réglementations peuvent aussi faire peur, et l’accompagnement sera une condition nécessaire pour réussir son application. Malheureusement je pense qu’il est nécessaire d’agir au plus vite, les récents évènements géopolitiques ainsi que les (très) nombreuses attaques observées chaque semaine imposent d’investir dans la sécurité de nos entreprises. Je pense également que comme la NIS 1, la NIS 2 n’est qu’une étape, et que des évolutions seront nécessaires dans la prochaine décennie pour étendre les attentes concernant la sécurité des entreprises européennes.

Au niveau personnel, quels logiciels libres utilisez-vous, sur quel OS ?

J’utilise depuis maintenant quatre ans Manjaro, venant de Debian/Ubuntu, et je suis très satisfait (le modèle rolling release me plaît beaucoup à l’usage).

Au niveau professionnel, quels logiciels libres utilisez-vous, sur quel OS ?

Au niveau professionnel je tourne sur du Ubuntu 22.04, et j’utilise principalement du VS Code.

Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?

Manjaro et Ubuntu sont les distributions que j’utilise dans la vie de tous les jours. Concernant les logiciels, la question est difficile puisque j’en utilise tellement. En ce moment je ne pourrais plus me passer de Joplin ou Signal, mais je pourrais en citer beaucoup (Virtual box, Kali linux, VSCode, Zotero…).

Références

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Vue normale

Sommaire

L'invasion de l'espace (des couleurs) !

Amélioration des algorithmes de couleur

Édition non-destructive, première mouture

Amélioration de la prise en charge des polices de caractères

Expansion automatique des calques

Nouvelles options d'alignement

Thèmes

Boîte de dialogue de bienvenue

Formats de fichiers

DDS

GIF

HEIF et JPEG-XL

OpenEXR

PDF

PNG

PSD

PSP

Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2

Nouveau format de palette pris en charge : Swatchbooker

Interactions avec les pads de tablettes graphiques sous Wayland

Mise à jour de l'API

GEGL et babl

Statistiques de sortie

Nouvelles de l'équipe et procédure de sortie

Autour de GIMP

Des nouvelles des miroirs

GIMP sous Windows/ARM

Télécharger GIMP 2.99.18

Et ensuite ?

Sommaire

Petits rappels et lexique

Fin du forum webOS Nation et autres tracasseries techniques

Mort du « builder » dédié à LuneOS

Les changements majeurs

Passage de Qt 5 à Qt 6

Utilisation du compositeur Wayland de webOS OSE

Changement de moteur Chromium

Migration générale vers les composants de webOS-OSE

Téléphones et tablettes: vers plus de Linux « mainline »

Le matériel Pine64

Le matériel Android

Plans pour la prochaine version

Continuer la migration vers l’infrastructure de webOS-OSE

Continuer le travail sur le matériel supporté

Compléter l’espace applicatif

Envie d’essayer ?

Sommaire

I Il était une fois MA vie !

II Mon environnement

III Les choix techniques

IV Les problèmes rencontrés et les contraintes (spoiler : il faut du temps !)

V Les scripts utilisés

convertion_par_lot_videos_en_265

convertion_par_lot_videos_en_265_une_passe_crf

convertion_par_lot_videos_en_xvid

convertion_vers_mkv_par_lot

convertion_videos_en_son_par_lot

convertir_son_en_mp3_garder_video

extraire_image_precise_d_une_video

recuperer_bitrate_video_par_lot

recuperer_toutes_infos_video_par_lot

stabiliser_video_par_lot_version

creer_video_cote_a_cote_par_lot

supprimer_bande_son_video

stabiliser_video_par_lot_en_testant_les_10_qualites

En conclusion

Les avantages

Les inconvénients

Sommaire

Présentation

Entretien avec Dorian Bachelot

Présentation

Qui êtes-vous ? Quel est votre parcours ?

Est-ce que vous êtes parent de Roselyne ?

Qu’est-ce que Degate ?

Pourquoi dis-tu que c’est le seul bastion ?

Comment ça fonctionne ?

Il existe des protections contre ceci ? J’imagine que certaines entreprises n’aimeraient pas qu’on fasse de la retro-ingénierie sur leur puce, il me semble que certaines puces possèdent un genre de grillage.

Mort du « builder » dédié à LuneOS

Téléphones et tablettes: vers plus de Linux « mainline »