❌

Vue lecture

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

FreeCAD 1.0

FreeCAD est sorti le 18 novembre 2024 en version 1.0 (voir l'annonce officielle et sa vidéo associée). Cette sortie est marquée par une amélioration majeure : l'atténuation du problÚme de dénomination topologique.

Nouveau logo FreeCAD

Sommaire

La derniĂšre dĂ©pĂȘche sur FreeCAD remonte Ă  avril 2021 pour la sortie de la version 0.19. Depuis, il y a eu les versions 0.20 (juin 2022) et 0.21 (aoĂ»t 2023). Cette version 1.0 a portĂ© le nom de 0.22 pendant son dĂ©veloppement.

Qu'est-ce que FreeCAD ?

Exemple 1 utilisation

Extrait de wiki.freecad.org :
FreeCAD est un modeleur paramĂ©trique de CAO 3D open source sous licence LGPL. FreeCAD est destinĂ© Ă  l'ingĂ©nierie mĂ©canique et Ă  la conception de produits mais — Ă©tant trĂšs gĂ©nĂ©rique — il s'adapte Ă©galement Ă  une gamme plus large d'utilisations autour de l'ingĂ©nierie, telles que l'architecture, l'analyse par Ă©lĂ©ments finis, l'impression 3D et d'autres tĂąches.

FreeCAD propose des outils similaires à CATIA, SolidWorks, Solid Edge ou Revit et entre donc également dans la catégorie CAO, GCVP, CFAO, IAO et BIM. Il s'agit d'un modélisateur paramétrique basé sur les caractéristiques d'une architecture logicielle modulaire qui permet de fournir des fonctionnalités supplémentaires sans modifier le systÚme de base.

FreeCAD est aussi multiplateforme. Il fonctionne sous Windows, Linux/Unix et macOS avec la mĂȘme apparence et les mĂȘmes fonctionnalitĂ©s sous toutes les plateformes.

Historique

La toute premiĂšre version de FreeCAD est sortie en 2002. FreeCAD est dĂ©veloppĂ© en C++, Qt et Python et son cƓur repose sur les bibliothĂšques OpenCASCADE (ou OCCT) spĂ©cialisĂ©es dans la CAO.

Son développement est assuré par un large panel de contributeurs : certains sont historiques, d'autres sont spécialisés sur un aspect particulier et beaucoup sont plus ou moins occasionnels.

Les versions se sont enchaßnées à un rythme quasi annuel, apportant moult améliorations et fonctionnalités nouvelles.

En 2021, quelques contributeurs historiques fondent la FreeCAD Project Association (FPA) qui est un organisme indépendant à but non lucratif pour collecter des dons et apporter un soutien au développement du projet.
Ce soutien passe notamment par leur programme "FreeCAD Grant Program", qui permet d'embaucher ou de récompenser des personnes pour des projets spécifiques. Ce programme a un budget de 50k$ pour l'année 2024. A titre d'exemple récent, 500$ ont été octroyés pour une étude sur les runners CI de Github, 1000$ pour un gros travail de correction de bugs, et enfin 500$ pour la création d'une vidéo sur les nouvelles fonctionnalités de cette version 1.0.

FreeCAD bénéficie d'une communauté impliquée permettant notamment d'avoir une documentation complÚte, à jour et traduite dans de nombreuses langues.

Le problÚme de dénomination topologique

C'Ă©tait un des points noirs de FreeCAD jusqu'Ă  cette version 1.0.
Il faut imaginer que dans ce logiciel, la modĂ©lisation d'une piĂšce (dans le sens objet physique) passe par une suite d'opĂ©rations mathĂ©matiques et gĂ©omĂ©triques en dĂ©finissant Ă  chaque fois des contraintes ou des paramĂštres. Une opĂ©ration est par exemple la crĂ©ation d'un trou borgne de 5 mm sur telle face Ă  10 mm des bords haut et gauche. Un autre exemple est d'ajouter une « languette » sur telle face cylindrique. Ou bien d'ajouter un chanfrein de 2 mm sur telle arĂȘte, etc.

Ainsi, petit à petit, la piÚce modélisée se construit, prend forme, se détaille et se complexifie.

Cet historique de ces opĂ©rations successives est toujours prĂ©sent et modifiable. À tout moment, il est possible de modifier une des Ă©tapes intermĂ©diaires.

D'un point de vue technique, vous aurez sans doute compris que chaque opĂ©ration s'applique Ă  un Ă©lĂ©ment prĂ©cis et existant de la piĂšce Ă  ce moment-lĂ  (une face ou une arĂȘte par exemple). Dans FreeCAD ces Ă©lĂ©ments ont tous un identifiant unique (Face6, Edge9, etc.), continu et incrĂ©mental. Si l'objet a 13 faces Ă  une des Ă©tapes, les faces seront numĂ©rotĂ©es de Face1 Ă  Face13. Chaque opĂ©ration est rattachĂ©e Ă  l'identifiant de l'Ă©lĂ©ment (Face5 par exemple).

Et le problĂšme se situe Ă  ce niveau : lors d'une modification d'une Ă©tape intermĂ©diaire, il arrive souvent que cela change la gĂ©omĂ©trie globale de la piĂšce et donc que les nombres de faces ou d'arĂȘtes augmentent ou diminuent. Et FreeCAD rĂ©attribue alors ces identifiants uniques aux diffĂ©rents Ă©lĂ©ments.
Ainsi, si l'objet passe de 13 à 11 faces, c'est l'ensemble des faces qui vont recevoir un nouvel identifiant dans la plage Face1 à Face11, avec un trÚs fort risque qu'une face, pourtant non touchée par la modification, porte un identifiant différent.

Et vous voyez le problĂšme arriver : si une des opĂ©rations suivantes dans l'historique Ă©tait de faire un perçage sur la Face6 qui est maintenant devenue la Face3
 Toute la modĂ©lisation part en vrille.

Ce problÚme de dénomination topologique est documenté sur le wiki de FreeCAD : problÚme de dénomination topologique.

Pour Ă©viter cela, il Ă©tait conseillĂ© de suivre un ensemble de bonnes pratiques de modĂ©lisation sous FreeCAD : Édition de fonctions. Il faudra certainement suivre l'Ă©volution de cette page avec cette sortie.

Cette version 1.0 marque donc l'intĂ©gration de codes correctifs de cette problĂ©matique. Les notes de version indiquent tout de mĂȘme que tout n'est pas rĂ©solu, et qu'il y aura d'autres amĂ©liorations dans les prochaines versions. Cette petite vidĂ©o en anglais vous montre la diffĂ©rence de comportement entre la version 0.21 et 0.22dev (qui a servi de base Ă  la 1.0).

Les autres améliorations

Un outil d'assemblage par défaut avec solveur dynamique

Le terme assemblage dĂ©signe la fonctionnalitĂ© de regrouper plusieurs Ă©lĂ©ments afin d'obtenir un objet fonctionnel. Ce peut ĂȘtre, par exemple, une boĂźte constituĂ©e d'un couvercle sur charniĂšres maintenues par des vis avec des rangements amovibles Ă  l'intĂ©rieur. Ou bien un moteur thermique avec ses carters, vilebrequin, bielles, pistons, soupapes, etc. Il est parfois utile de pouvoir fournir des indications de positionnement et/ou de libertĂ© des Ă©lĂ©ments entre eux, et de pouvoir animer le tout.
Ces opérations d'assemblage n'étaient pas intégrées dans FreeCAD avant la version 1.0. Elles étaient néanmoins possibles grùce aux ateliers. Plusieurs ont été créés pour cela avec chacun leurs spécificités et leurs approches mais aussi une incompatibilité entre eux : A2plus, Assembly3 ou Assembly4.
Cette version 1.0 propose un nouvel atelier mais intégré par défaut. Il a été mis au point par la société Ondsel (voir plus bas). Il est encore jeune, et il est encore trop tÎt pour savoir s'il finira par s'imposer par rapport à l'existant déjà en place. Un tutoriel concernant l'atelier d'assemblage est d'ores et déjà disponible pour une introduction à cette nouvelle fonctionnalité de la v1.0.

L'atelier sketcher amélioré

Cet atelier permet de dessiner les esquisses techniques utilisĂ©es dans la conception mĂ©canique. C'est dans celui-ci que sont dessinĂ©s les « plans 2D » avec les cotes et les contraintes dimensionnelles et spatiales. Cette version apporte un nombre consĂ©quent d'amĂ©liorations et de nouvelles fonctionnalitĂ©s rendant son utilisation plus facile, plus puissante et plus rapide. Le mieux est de regarder les notes de version animĂ©es.

Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC

Si le titre est cryptique, c'est que l'on parle de BTP et d'outils destinĂ©s aux Ă©quipes de MaĂźtrise d'ƒuvre impliquĂ©es dans la conception d'une opĂ©ration construction (Architectes, Bureaux d'Études). Comme ce n'est pas forcĂ©ment le lot commun des visiteurs de LinuxFr.org, rĂ©sumons la situation:

  • L'atelier Arch, pour Architecture, exploite depuis longtemps les capacitĂ©s de crĂ©ation 3D de FreeCAD pour dessiner facilement, fondations, murs, planchers, fenĂȘtres, portes etc. Cet atelier se basait sur le format natif des fichiers FreeCAD, *.FcStd.

  • Dans l'atelier BIM (pour Building Information Model <= l'article Wikipedia_FR est bien Ă©crit pour qui veut comprendre l'essentiel), on retrouve un certain nombre d'outils de dessin et de crĂ©ation d'objets qui s'avĂšrent redondants pour certains avec ceux de l'outil Arch tout en implĂ©mentant les paradigmes bien plus vastes qu'induit l'approche BIM d'un projet de construction <=> pas uniquement de la gĂ©omĂ©trie, mais aussi du prix, des donnĂ©es mĂ©caniques, physiques, des fiches produit, du planning 


  • L'approche BIM tend Ă  se gĂ©nĂ©raliser dĂšs lors que la complexitĂ© et le coĂ»t du projet le justifient. Elle repose (en thĂ©orie) sur un format d'Ă©change IFC (pour Industry Foundation Class).
    Il est ouvert et au format texte.
    Oui avec vim, c'est possible de bidouiller ;)
    mais un fichier IFC fait rapidement quelques centaines de Mo voire quelques Go 


L'Association "Building Smart" en définit les caractéristiques. Tous les logiciels sur le marché savent ouvrir et exporter dans ce format, à la norme IFC 2.3 ad minima et IFC 4.2 voire 4.3 pour les up to date.

L'atelier BIM de FreeCAD utilisait jusqu'à présent IfcOpenShell, une application tierce Open Source pour convertir un fichier du format *.ifc vers du *.FcStd en passant (sans doute) par du OpenScad dans le processus.

Titre de l'image
Une image qui devrait parler au LinuxFrien (!) pour la classe IFC Material-Constituent-Set,

Pour la version 1.0 de FreeCAD, Yorik Van Havre, développeur historique de FreeCAD, (par ailleurs, architecte et Président la FreeCAD Project Association) a entrepris de fusionner ces deux ateliers, d'en faire une fonctionnalité native de FreeCAD, c'est-à-dire qui se passe du vaillant IfcOpenShell (grùce notamment au travail fait sur Blender-Bim) pour que FreeCAD puisse ouvrir et enregistrer directement au format IFC sans conversion inutile.

L'atelier FEM

Cet atelier d'analyse par éléments finis comporte également des améliorations considérées comme majeures avec cette version 1.0, détaillées dans un article de blog sur l'atelier FEM de FreeCAD.

Les avancées majeures sont liées à la prise en charge de fonctionnalités de CalculiX, un des solveurs utilisés par cet atelier : symétrie cyclique, analyses 2D et contraintes de corps rigide.

Le reste

Comme à chaque nouvelle version, beaucoup de choses ont été apportées, que ce soit dans l'interface, ou dans la plupart des ateliers intégrés. Les notes de version de la v1.0, comme trÚs souvent détaillées en images, permettent de voir l'évolution de ce logiciel.

FreeCAD a également annoncé son nouveau logo, choisi aprÚs un appel à concourir auprÚs de la communauté (lien). Le logo en SVG est disponible sur cette page.

L'essai commercial d'Ondsel

Outre la crĂ©ation en 2021 de l'association FPA (voir plus haut), d'autres dĂ©veloppeurs, notamment Brad Collette, mainteneur de longue date de l'atelier Path et auteur de deux livres sur FreeCAD, ont crĂ©Ă© dĂ©but 2023 la sociĂ©tĂ© amĂ©ricaine ONDSEL sous la forme d'une Public Benefit Corporation (PBC) qui pourrait se traduire par « une entreprise d'intĂ©rĂȘt pour la sociĂ©té ». Malheureusement, aprĂšs environ 2 ans, Brad Collette informe de l'arrĂȘt de la sociĂ©tĂ© ONDSEL, faute d'avoir trouvĂ© un marchĂ©.

La sociĂ©tĂ© voulait s'appuyer sur FreeCAD pour « apporter des fonctionnalitĂ©s commerciales qui rendent FreeCAD plus utile aux utilisateurs commerciaux ». (Source)

Pour cela, ONDSEL a produit sa propre version de FreeCAD avec ses propres choix esthétiques et ergonomiques, et a fourni un cloud pour simplifier le travail en équipe et le partage.
À noter qu'ONDSEL indiquait soumettre ses amĂ©liorations Ă  FreeCAD pour intĂ©gration et que son cloud Ă©tait disponible sous forme de module dans FreeCAD. Ces amĂ©liorations se retrouvent dans cette version 1.0 de FreeCAD, notamment le nouvel outil intĂ©grĂ© d'assemblage ainsi que les trĂšs nombreuses nouvelles fonctionnalitĂ©s de l'atelier Sketcher.

La sociĂ©tĂ© ONDSEL avait dĂ©taillĂ© sa relation avec le projet FreeCAD indiquant notamment leur mode de collaboration. Ils avaient Ă©galement un blog en anglais intĂ©ressant, oĂč ils abordent plusieurs thĂ©matiques, notamment sur l'Ă©volution de CATIA ou bien la liste des nouveautĂ©s agrĂ©mentĂ©e de nombreuses animations.

Dans l'annonce de cet arrĂȘt, Brad Collette revient Ă©galement sur ce qu'ils ont apportĂ© au projet FreeCAD. Tout ce qu'ils ont dĂ©veloppĂ© Ă©tait en open source et dĂ©jĂ  intĂ©grĂ© pour la plupart Ă  FreeCAD. Les fondateurs d'ONDSEL continueront de contribuer au projet directement.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Comment l’archĂ©ologie entre progressivement dans l’ùre du logiciel libre

L’archĂ©ologie est un domaine qui, depuis ses dĂ©buts, s’attache au catalogage, Ă  la structuration et l’archivage de donnĂ©es issues de fouilles. Sur le terrain, elle a longtemps reposĂ© sur la crĂ©ation de fiches, la collecte manuelle d’information sur papier, et le dessin Ă  la main, retranscrit lors des phases d’étude sur support numĂ©rique. Ce n’est que rĂ©cemment que certains archĂ©ologues ont lancĂ© le mouvement de la fouille « tout numĂ©rique ». Je vous propose de raconter ici l’histoire de la numĂ©risation de l’archĂ©ologie, qui, comme vous allez le voir, repose en partie sur le logiciel libre.

Sommaire

Qu’est-ce qu’un chantier de fouilles ?

L’archĂ©ologie française se divise en deux branches principales : l’archĂ©ologie prĂ©ventive, qui intervient lors de projets de construction, et l’archĂ©ologie programmĂ©e, menĂ©e sur des sites choisis pour rĂ©pondre Ă  des problĂ©matiques de recherche. SupervisĂ©es par les Services RĂ©gionaux de l’ArchĂ©ologie du MinistĂšre de la Culture, ces activitĂ©s sont rĂ©alisĂ©es par diffĂ©rents organismes : opĂ©rateurs publics et privĂ©s pour l’archĂ©ologie prĂ©ventive, et associations, CNRS ou universitaires pour l’archĂ©ologie programmĂ©e. Cette derniĂšre mobilise souvent des bĂ©nĂ©voles, notamment des Ă©tudiants, leur offrant une formation pratique complĂ©mentaire.

Pour l’archĂ©ologue, la fouille est un outil, et non un but en soi. Ce que l’archĂ©ologue cherche, c’est de l’information. En substance, il s’agit de comprendre l’histoire d’un site, son Ă©volution, ses habitants Ă  travers les Ă©lĂ©ments qu’ils ont laissĂ©s derriĂšre eux, que ce soit les ruines de leurs habitats, de leurs activitĂ©s artisanales ou leurs sĂ©pultures. Ceci est d’autant plus important que la fouille est un acte destructeur, puisque l’archĂ©ologue dĂ©mantĂšle son sujet d’étude au fur et Ă  mesure de la fouille.

Pour ĂȘtre exploitĂ©e, l’information archĂ©ologique doit ĂȘtre organisĂ©e selon des principes bien Ă©tablis. Le premier concept clĂ© est la couche sĂ©dimentaire (UnitĂ© Stratigraphique - US), qui tĂ©moigne d’une action humaine ou d’un phĂ©nomĂšne naturel. L’étude de l’agencement de ces couches rĂ©vĂšle la chronologie du site, la succession des Ă©vĂšnements qui s’y sont dĂ©roulĂ©s. Ces couches peuvent ĂȘtre regroupĂ©es en faits archĂ©ologiques : fossĂ©s, caves, sĂ©pultures, sont en effet des regroupements de couches qui dĂ©finissent un Ă©lĂ©ment spĂ©cifique. Enfin, les objets trouvĂ©s dans ces couches, ou mobiliers, sont cataloguĂ©s et identifiĂ©s par leur couche d’origine, fournissant des indications chronologiques et culturelles cruciales.

chantier mastraits
Le chantier de fouilles de la NĂ©cropole des Mastraits, Ă  Noisy-le-Grand (93).

Les actions menĂ©es par l’archĂ©ologue tout au long du chantier sont Ă©galement enregistrĂ©es. En effet, l’archĂ©ologue procĂšde Ă  des sondages, rĂ©alise des tranchĂ©es, mais fait aussi de nombreuses photos, ou des dessins de tout ce qu’il dĂ©couvre au fur et Ă  mesure de l’avancement du chantier. La documentation produite peut ĂȘtre plĂ©thorique, et un catalogage indispensable.

Cette information descriptive est complĂ©tĂ©e par une information spatiale, le plan des vestiges mis au jour Ă©tant essentiel pour l’analyse et la prĂ©sentation des rĂ©sultats. L’étude de ce plan, associĂ©e aux informations descriptives et chronologiques, met en Ă©vidence les grandes Ă©volutions du site ou des dĂ©tails spĂ©cifiques. Sa rĂ©alisation est gĂ©nĂ©ralement confiĂ©e Ă  un topographe en collaboration avec les archĂ©ologues.

À l’issue de la phase de terrain, une phase d’analyse des donnĂ©es collectĂ©es est rĂ©alisĂ©e. Cette phase dite de post-fouille permet de traiter l’ensemble des informations recueillies, d’en rĂ©aliser la description complĂšte, d’effectuer les Ă©tudes nĂ©cessaires Ă  la comprĂ©hension du site en faisant appel Ă  de nombreux spĂ©cialistes : cĂ©ramologues, anthropologues, archĂ©ozoologues, lithiciens, carpologues, anthracologues, spĂ©cialistes de la palĂ©omĂ©tallurgie, etc.

Cette phase de post-fouille aboutit dans un premier temps Ă  la rĂ©alisation d’un rapport d’opĂ©ration, compte rendu le plus exhaustif possible du site et de son Ă©volution. Ces rapports sont remis au ministĂšre de la Culture qui en juge la qualitĂ©. Ils ne sont pas destinĂ©s Ă  ĂȘtre largement diffusĂ©s, mais sont normalement accessibles Ă  toute personne qui en fait la demande auprĂšs de l’administration concernĂ©e. Ils sont une base de travail importante pour l’ensemble de la communautĂ© scientifique.

Sur la base de ce rapport, la publication d’articles dans des revues spĂ©cialisĂ©es permet de prĂ©senter les rĂ©sultats de l’opĂ©ration plus largement, parfois en fonction de certaines thĂ©matiques ou problĂ©matiques spĂ©cifiques.

Pratique de l’archĂ©ologie : exemple dans le prĂ©ventif

L’utilisation de trĂšs nombreux listings papier est une constante. Ces listings permettent de tenir Ă  jour l’enregistrement de la donnĂ©e sous forme de tableaux d’inventaire des couches, des faits, des sondages, des photos, etc. Des fiches d’enregistrement spĂ©cifiques sont Ă©galement utilisĂ©es dans de nombreuses spĂ©cialitĂ©s de l’archĂ©ologie, telle que l’anthropologie funĂ©raire.

Sur le terrain, les Ă©lĂ©ments mis au jour sont encore pour une trĂšs grande majoritĂ© dessinĂ©s Ă  la main, sur papier calque ou millimĂ©trĂ©, qu’il s’agisse d’un plan de vestiges ou des nombreux relevĂ©s de coupe stratigraphique. Ceci demande bien entendu un temps important, en particulier en cas de vestiges complexes.
L’utilisation de tachĂ©omĂštres Ă©lectroniques, puis du GPS diffĂ©rentiel a permis de se passer des dĂ©camĂštres, ou des systĂšmes de carroyage, lors de la fouille des sites. Des topographes, spĂ©cifiquement formĂ©s, ont alors commencĂ© Ă  intervenir sur site pour la rĂ©alisation des plans gĂ©nĂ©raux.

La collection documentaire obtenue Ă  l’issue d’un chantier de fouille est particuliĂšrement prĂ©cieuse. Il s’agit lĂ  des seuls Ă©lĂ©ments qui permettront de restituer l’histoire du site, en croisant ces donnĂ©es avec le rĂ©sultat des Ă©tudes rĂ©alisĂ©es. La crainte de la disparition de ces donnĂ©es, ou de leur utilisation par autrui du fait d’une dĂ©couverte remarquable, est un sentiment souvent partagĂ© au sein de la communautĂ© archĂ©ologique. L’archĂ©ologue peut se sentir dĂ©positaire de cette information, voire exprimer un sentiment de possession qui va tout Ă  fait Ă  l’encontre de l’idĂ©e de science partagĂ©e et ouverte. L’idĂ©e que l’ouverture de la donnĂ©e est le meilleur moyen de la protĂ©ger est loin d’ĂȘtre une Ă©vidence.

fiche de conservation, illustrant le coloriage manuel des parties de squelette retrouvées
Fiche de conservation, illustrant le coloriage manuel des parties de squelette retrouvées

Exemple de fiche descriptive d’une couche archĂ©ologique
Exemple, parmi tant d’autres, de fiche descriptive vierge d’une couche archĂ©ologique

Le début de la numérisation

C’est essentiellement aprĂšs la phase terrain que les outils numĂ©riques ont Ă©tĂ© apprivoisĂ©s par les archĂ©ologues.

En post-fouille, la documentation papier est encore souvent une base documentaire fondamentale pour l’analyse du site. L’irruption de l’informatique au milieu des annĂ©es 80 a conduit les archĂ©ologues Ă  transcrire cette donnĂ©e sous forme numĂ©rique, afin de faciliter son analyse et sa prĂ©sentation. Bien que les logiciels aient Ă©voluĂ©, le processus est pratiquement le mĂȘme aujourd’hui, avec une numĂ©risation de la documentation sous de nombreux formats.

Les listings peuvent ĂȘtre intĂ©grĂ©s Ă  des bases de donnĂ©es (le plus souvent propriĂ©taires tel MS Access, FileMaker ou 4D) ou des tableurs. De nombreuses bases ont Ă©tĂ© dĂ©veloppĂ©es en interne, localement, par les archĂ©ologues eux-mĂȘmes. Uniquement attributaires, elles se sont progressivement mises en rĂ©seau et adaptĂ©es au support, permettant d’envisager un usage sur le terrain, sans que ceci ne soit largement dĂ©ployĂ©.

Base de données
Exemple d’une base de donnĂ©es au tournant des annĂ©es 2000

Toute la documentation dessinĂ©e sur le terrain est amenĂ©e Ă  ĂȘtre redessinĂ©e au propre sur support numĂ©rique, dans des logiciels de dessin vectoriel, trĂšs souvent Adobe Illustrator, parfois Inkscape.
Les donnĂ©es en plan, levĂ©es par le topographe, sont rĂ©alisĂ©es sous Autocad et Ă©taient exportĂ©s en .dxf ou .dwg avant d’ĂȘtre remis au propre sous Adobe illustrator, ce qui est le cas Ă©galement des dessins rĂ©alisĂ©s sur le terrain.
Le mobilier est confiĂ© Ă  des spĂ©cialistes qui le dĂ©crivent, le dessinent, en dressent l’inventaire, le plus souvent dans des tableurs. Leurs dessins sont lĂ  encore scannĂ©s et remis au propre numĂ©riquement.

Avec le recul, nous constatons que les outils numĂ©riques sont majoritairement utilisĂ©s comme des outils de mise au propre de l’information collectĂ©e sur le terrain. Bien des tableurs ne sont ainsi que la stricte transcription des tableaux papier utilisĂ©s par les archĂ©ologues, auquel on ajoutera quelques totaux, moyennes ou mĂ©dianes. Les dessins rĂ©alisĂ©s sur papier, sont dĂ©calquĂ©s dans des logiciels de vectorisation pour plus de lisibilitĂ© et les plus-values scientifique sont finalement assez limitĂ©es.

Il en rĂ©sulte une documentation numĂ©rique relativement disparate, avec l’usage de nombreux outils propriĂ©taires, des formats fermĂ©s, et une sĂ©paration trĂšs forte entre l’information spatiale et l’information descriptive (ou attributaire).

L’usage progressif des bases de donnĂ©es a cependant permis d’agglomĂ©rer certaines donnĂ©es et de rassembler et mettre en relation l’information. Des travaux universitaires ont Ă©galement permis d’alimenter la rĂ©flexion sur la structuration des donnĂ©es archĂ©ologiques et de former de nombreux archĂ©ologues, permettant d’adopter des pratiques plus vertueuses.

Le mouvement tout numérique

Jusqu’à prĂ©sent, passer au tout numĂ©rique dans le cadre archĂ©ologique semblait relativement utopique. Il a fallu que de nouvelles technologies apparaissent, que des supports portables et simples d’usage se mettent en place, que les rĂ©seaux se dĂ©veloppent, et que les archĂ©ologues s’emparent de ces nouveaux outils.

Le collectif Ramen (Recherches ArchĂ©ologiques en ModĂ©lisation de l’Enregistrement NumĂ©rique) est nĂ© des Ă©changes et des expĂ©riences de divers archĂ©ologues de l’Institut National De Recherches ArchĂ©ologiques PrĂ©ventives (Inrap) qui se sont regroupĂ©s autour de la rĂ©alisation de la fouille programmĂ©e de la nĂ©cropole mĂ©diĂ©vale de Noisy-Le-Grand, fouille gĂ©rĂ©e par l’association ArchĂ©ologie des NĂ©cropoles et confiĂ©e Ă  la direction scientifique de Cyrille Le Forestier (Inrap). Cette fouille programmĂ©e a permis de lancer une expĂ©rimentation sur la complĂšte dĂ©matĂ©rialisation de la donnĂ©e archĂ©ologique en se basant sur la photogrammĂ©trie, le SIG, et une base de donnĂ©es spatiale.

Principe général

Si le topographe intervient bien toujours pour la prise de points de rĂ©fĂ©rence, le relevĂ© dĂ©taillĂ© des vestiges est assurĂ©, pour cette expĂ©rimentation, par la mise en Ɠuvre de la photogrammĂ©trie de maniĂšre systĂ©matique. Cette mĂ©thode permet, par la rĂ©alisation de multiples photos d’un objet ou d’une scĂšne, de rĂ©aliser un modĂšle 3D prĂ©cis, et donc exploitable Ă  postĂ©riori par l’archĂ©ologue en post fouille. La photogrammĂ©trie constitue Ă  Noisy l’unique outil de relevĂ©, remplaçant purement et simplement le dessin sur papier. En effet, Ă  partir de ce nuage de points 3D, il est possible d’extraire de multiples supports en 2D et d’ajouter la gĂ©omĂ©trie ou des informations supplĂ©mentaires dans la base de donnĂ©es: contours de la sĂ©pulture, reprĂ©sentation du squelette in situ, profils, mesures, altitudes, etc.

RelevĂ© photogrammĂ©trique d’une sĂ©pulture
RelevĂ© photogrammĂ©trique d’une sĂ©pulture

L’enregistrement des donnĂ©es est assurĂ© par l’utilisation d’une base de donnĂ©es relationnelles et spatiales dont l’interface est accessible dans QGIS, mais Ă©galement via une interface web directement sur le terrain, sans passer par des inventaires ou listing papier. L’interface web a Ă©tĂ© rĂ©alisĂ©e grĂące Ă  SQLPage, serveur web qui utilise un langage Ă  base de SQL pour la rĂ©alisation de l’interface graphique, sans avoir Ă  passer par les langages de programmation plus complexes classiquement utilisĂ©s pour la crĂ©ation d’applications web, tel PHP.

Bien entendu, cette dĂ©marche se poursuit Ă©galement en laboratoire lors de l’étape d’analyse du site.

Logiciels et formats libres

Mais l’abandon du support papier nĂ©cessite de nous poser la question de la pĂ©rennitĂ© des fichiers et des donnĂ©es qu’ils contiennent.

En effet, dans un processus de dĂ©matĂ©rialisation complet, la mĂ©moire du site n’est plus contenue sur des centaines de fiches manuscrites, mais dans des fichiers numĂ©riques dont nous ignorons Ă  priori si nous pourrons les conserver sur le long terme. L’impossibilitĂ© d’accĂ©der Ă  cette donnĂ©e avec d’autres logiciels que ceux originellement utilisĂ©s lors de leur crĂ©ation Ă©quivaut Ă  leur destruction. Seuls les formats standards peuvent rĂ©pondre Ă  cette problĂ©matique, et ils sont particuliĂšrement utilisĂ©s par les logiciels libres. Pour la photogrammĂ©trie, les formats .ply et .obj, qui sont implĂ©mentĂ©s dans de nombreux logiciels, libres et propriĂ©taires, ont Ă©tĂ© choisis. Pour la donnĂ©e attributaire et spatiale, elle est enregistrĂ©e dans des bases de donnĂ©es relationnelles libres (Spatialite et Postgis), et facilement exportable en .sql, qui est un format standardisĂ© et reconnu par de trĂšs nombreuses bases de donnĂ©es.

Malheureusement, le logiciel libre reste peu utilisĂ© dans notre quotidien archĂ©ologique, et les logiciels propriĂ©taires sont souvent trĂšs bien implantĂ©s. Le libre souffre encore aujourd’hui d’a priori et d’une mauvaise image au sein de la communautĂ© archĂ©ologique, qui le trouve plus compliquĂ©, moins joli, moins efficace, etc.

Le libre a cependant fait une incursion majeure avec l’arrivĂ©e du SystĂšme d’Information GĂ©ographique (SIG) libre QGIS, qui a permis d’installer un SIG sur tous les postes des agents de l’institut et de l’envisager comme un outil d’analyse Ă  l’échelle d’un site archĂ©ologique. Par un accompagnement et la mise en place d’un plan de formation adĂ©quat, de nombreux archĂ©ologues ont Ă©tĂ© formĂ©s Ă  l’usage du logiciel au sein de l’Institut.

QGIS a vĂ©ritablement rĂ©volutionnĂ© nos pratiques en permettant l’interrogation immĂ©diate de la donnĂ©e attributaire par la donnĂ©e spatiale (quel est ce vestige que je vois sur le plan ?) ou, Ă  l’inverse, de localiser un vestige par sa donnĂ©e attributaire (oĂč se trouve la sĂ©pulture 525 ?). Il est cependant trĂšs frĂ©quent d’avoir encore d’un cĂŽtĂ© la donnĂ©e attributaire dans des tableurs ou des bases de donnĂ©es propriĂ©taires, et la donnĂ©e spatiale dans QGIS, l’interrogation des deux reposant sur des jointures.

Bien entendu, QGIS permet aussi l’analyse des donnĂ©es, la crĂ©ation de plans thĂ©matiques ou chronologiques, indispensables supports Ă  nos rĂ©flexions. Nous pouvons, Ă  partir de ces Ă©lĂ©ments, rĂ©aliser les trĂšs nombreuses figures du rapport d’opĂ©ration, sans passer par un logiciel de dessin vectoriel, en plan comme en coupe (reprĂ©sentation verticale de la stratigraphie). Il permet de normaliser les figures par l’emploi des styles, et, par l’usage de l’outil Atlas, de rĂ©aliser des catalogues complets, pour peu que la donnĂ©e soit rigoureusement structurĂ©e.

analyse spatiale
Exemple d’analyse dans Qgis de rĂ©partition des rejets de cĂ©ramique sur un site gaulois

Dans le cadre de l’expĂ©rimentation sur la nĂ©cropole des Mastraits, Si Qgis est bien un des piliers du systĂšme, quelques logiciels propriĂ©taires sont encore employĂ©s.

Le logiciel de traitement utilisĂ© pour la photogrammĂ©trie est propriĂ©taire. L’objectif Ă  terme est de pouvoir utiliser un logiciel libre, MicMac, dĂ©veloppĂ© par l’IGN, Ă©tant un possible candidat. Il manque cependant encore d’une interface pleinement intuitive pour que les archĂ©ologues puissent s’approprier l’outil de maniĂšre autonome.

De mĂȘme, les enthousiasmantes derniĂšres Ă©volutions du projet Inkscape devraient nous inciter Ă  nous tourner davantage vers ce logiciel et Ă  utiliser de maniĂšre systĂ©matique le .svg. L’usage de Scribus pour la PAO devrait Ă©galement ĂȘtre sĂ©rieusement envisagĂ©e.

Le logiciel libre et ses indĂ©niables avantages prend ainsi doucement place, essentiellement via QGIS, dans la chaĂźne de production de nos donnĂ©es archĂ©ologiques. Nous ne pouvons qu’espĂ©rer que cette place grandira. Le chemin paraĂźt encore long, mais la voie libre


Badass, spatial et attributaire réunis

Le dĂ©veloppement de la Base ArchĂ©ologique de DonnĂ©es Attributaires et SpatialeS a eu comme objectif d’intĂ©grer, au sein d’une seule et mĂȘme base de donnĂ©es, les informations attributaires renseignĂ©es par les archĂ©ologues et les informations spatiales recueillies par le topographe. Il s’agit mĂȘme de rassembler, au sein des tables dĂ©diĂ©es, les informations attributaires et spatiales, garantissant ainsi l’intĂ©gritĂ© de la donnĂ©e.
Son principe s’appuie sur le fonctionnement de la chaine opĂ©ratoire en archĂ©ologie, Ă  savoir l’identification et l’enregistrement par l’archĂ©ologue des vestiges mis au jour, auquel succĂšde le relevĂ© tridimentionnel rĂ©alisĂ© par le topographe. Ce dernier dispose, dans la base de donnĂ©es, de tables spĂ©cifiques dans laquelle il peut verser la gĂ©omĂ©trie et des donnĂ©es attributaires minimales (numĂ©ro, type). Des triggers vont ensuite alimenter les tables renseignĂ©es par les archĂ©ologues avec la gĂ©omĂ©trie, selon leur identifiant et leur type.

La base est ainsi l’unique dĂ©positaire de l’information attributaire et spatiale tout au long de l’opĂ©ration, du terrain Ă  la post fouille.

Le format de la base de donnĂ©es est Ă  l’origine SpatiaLite. Mais la masse documentaire produite par la nĂ©cropole des Mastraits nous a conduit Ă  la porter sous PostGIS. Nombre d’opĂ©rations archĂ©ologiques ne nĂ©cessitent cependant qu’une petite base SpatiaLite, qui permet en outre Ă  l’archĂ©ologue d’avoir la main sur son fichier de donnĂ©es. Seuls quelques gros chantiers peuvent avoir besoin d’une solution PostgreSQL, par ailleurs utilisĂ©e pour le CAtalogue de VIsualisation ARchĂ©ologique (Caviar) qui a vocation Ă  accueillir les donnĂ©es spatiales et attributaires produites Ă  l’institut.

Naturellement, Badass a Ă©tĂ© couplĂ©e Ă  un projet QGIS proposant dĂ©jĂ  des styles par dĂ©faut, mais aussi quelques requĂȘtes ou vues communĂ©ment utilisĂ©es lors d’une Ă©tude archĂ©ologique. Une extension QGIS a Ă©tĂ© dĂ©veloppĂ©e par plusieurs Ă©tudiants afin de permettre la gĂ©nĂ©ration automatique du projet et de la base de donnĂ©es.

Pour entrer dans Badass : la Bad’Mobil

Il restait la question de la portabilitĂ© de ce systĂšme. QGIS est un logiciel demandant beaucoup de ressource et dont l’interface est inadaptĂ©e aux petits Ă©crans, apprĂ©ciĂ©s pour leur portabilitĂ© sur le terrain (tĂ©lĂ©phones et tablettes).

Choisir d’utiliser une base SpatiaLite ou PostGIS permettait d’envisager dĂšs le dĂ©part une interface web, qui pourrait alors ĂȘtre utilisĂ©e sur n’importe quel terminal. Il avait d’abord Ă©tĂ© envisagĂ© de lancer un dĂ©veloppement en PHP/HTML/CSS avec un serveur web Apache. Mais ceci nĂ©cessitait de disposer d’un serveur web, et de programmer toute une interface. Il restait aussi Ă  rĂ©pondre Ă  quelques questions d’infrastructure : oĂč l’hĂ©berger, quels financements pour cela, et qui pour administrer l’ensemble ?

C’est ici mĂȘme, sur LinuxFR, que l’un des membres du collectif a dĂ©couvert SQLPage. Ce logiciel libre, dĂ©veloppĂ©e par lovasoa, permet de disposer d’un serveur web trĂšs simple, et la rĂ©alisation d’une application de type CRUD avec une interface dont le dĂ©veloppement ne repose que sur du SQL.

SQLPage repose sur un fichier exĂ©cutable, qui, lancĂ© sur un poste informatique, transforme celui-ci en serveur web. Un fichier de configuration permet de dĂ©finir notamment l’emplacement de la base de donnĂ©es qui sera interrogĂ©e. Pour chaque page web de l’interface, on Ă©crit un fichier .sql pour dĂ©finir les donnĂ©es Ă  aller chercher ou modifier dans la base, et les composants d’interface qui permettront de l’afficher (tableaux, formulaires, graphiques
). L’accĂšs Ă  cette interface se fait dans un navigateur web. Si le poste est en rĂ©seau, l’adresse IP du poste permet d’y accĂ©der Ă  distance, avec une adresse comme http://192.168.1.5:8080 par exemple. L’utilisation d’un VPN nous permet d’utiliser le rĂ©seau de tĂ©lĂ©phonie mobile, ce qui nous dispense de toute mise en place d’un rĂ©seau local avec routeur, antennes, etc.

principe
Principe de fonctionnement général

Ainsi, l’installation de l’ensemble est trĂšs simple et ne repose que sur une arborescence de fichiers Ă  dĂ©ployer sur le poste serveur : la base de donnĂ©e, et un rĂ©pertoire contenant le binaire SQLPage et les fichiers constituant les pages web.

En nous appuyant sur la documentation (et en posant parfois des questions Ă  l’auteur du logiciel), nous avons pu dĂ©velopper seuls une interface trĂšs complĂšte rĂ©pondant bien Ă  nos besoins sur le terrain. NommĂ©e Bad’Mobil, l’interface web permet d’accĂ©der Ă  l’ensemble des donnĂ©es attributaires renseignĂ©es par les archĂ©ologues et permet dĂ©sormais, grĂące aux Ă©volutions constantes de dĂ©veloppement de SQLPage, de visualiser la donnĂ©e spatiale. La documentation produite au cours du chantier peut Ă©galement ĂȘtre consultĂ©e si les fichiers (photos, dessins scannĂ©s, etc.) sont placĂ©s au bon endroit dans l’arborescence. Les pages se composent principalement de formulaires de crĂ©ation ou de modification, ainsi que de tableaux listant les Ă©lĂ©ments dĂ©jĂ  enregistrĂ©s. La visualisation de la gĂ©omĂ©trie permet de se repĂ©rer spatialement sur le terrain, en particulier en cas de chantier complexe, et d’interagir avec la donnĂ©e attributaire.

L’interface de BadMobil, avec SQLPage
L’interface de BadMobil, avec SQLPage

Cas d’utilisation et bĂ©nĂ©fices concrets

PremiÚre expérience aux Mastraits

Le chantier de fouille de la NĂ©cropole des Mastraits a Ă©tĂ© le chantier test de ces dĂ©veloppements. L’importante quantitĂ© de donnĂ©es rĂ©coltĂ©es, mais Ă©galement son statut de fouille programmĂ©e permet de mettre en place ce genre d’expĂ©rimentation avec un impact bien moindre que dans une fouille prĂ©ventive oĂč les dĂ©lais sont particuliĂšrement contraints.

La mise en place de l’interface SQLPage a permis la dĂ©matĂ©rialisation complĂšte de l’enregistrement attributaire, et se rĂ©vĂšle trĂšs performante. Il s’agit d’un changement majeur de nos pratiques et va nous permettre gagner un temps extrĂȘmement important lors du traitement des donnĂ©es.

Ceci permet Ă©galement de centraliser l’information, de travailler Ă  plusieurs personnes en mĂȘme temps sans attendre la disponibilitĂ© des classeurs d’enregistrement traditionnellement utilisĂ©s, et de guider les archĂ©ologues au cours du processus d’enregistrement, Ă©vitant les oublis et les erreurs. GrĂące Ă  une interface simplifiĂ©e, la saisie peut se faire de maniĂšre trĂšs intuitive sans rĂ©elle nĂ©cessitĂ© de formation approfondie.

L’homogĂ©nĂ©itĂ© de la donnĂ©e saisie est ainsi meilleure, et les possibilitĂ©s d’interrogation bien plus importantes.

Perspectives d’avenir

À l’issue du dĂ©veloppement de Badass et Bad’mobil sur la nĂ©cropole des Mastraits, il nous a paru possible d’envisager son dĂ©ploiement dans le cadre de l’archĂ©ologie prĂ©ventive. Si la question de l’infrastructure rĂ©seau nĂ©cessaire au fonctionnement de cette solution peut se poser (nĂ©cessitĂ© de disposer d’une alimentation Ă©lectrique stable sur des chantiers perdus en pleine campagne, disponibilitĂ© des tablettes, couverture rĂ©seau
), les bĂ©nĂ©fices en termes d’homogĂ©nĂ©itĂ© des donnĂ©es et de facilitĂ© de saisie sont trĂšs importants. Quelques chantiers d’archĂ©ologie prĂ©ventive ont ainsi pu tester le systĂšme, la plupart du temps sur des sites de petite ampleur, en bĂ©nĂ©ficiant de l’accompagnement des membres du collectif.

Les dĂ©veloppements futurs s’orienteront sans doute vers l’intĂ©gration de nouveaux formulaires, ou de nouveaux outils de suivi. Actuellement, Badass permet de recueillir les observations communes Ă  tous les sites archĂ©ologiques, ainsi que les observations anthropologiques du fait de son utilisation au sein de la nĂ©cropole des Mastraits.
Nous pourrions ainsi envisager d’intĂ©grer les nombreuses spĂ©cialitĂ©s de l’archĂ©ologie, mais il est probable que nous obtenions alors une Ă©norme machine dont la maintenance pourrait s’avĂ©rer complexe. Nous restons donc prudents Ă  ce sujet.

Conclusion

Petit Ă  petit, l’emploi des outils numĂ©riques s’est gĂ©nĂ©ralisĂ© dans les mĂ©tiers de l’archĂ©ologie. AprĂšs les traitements de texte et tableurs des annĂ©es 90 (souvent sous mac), les premiers dessins vectoriels numĂ©risĂ©s sous Adobe Illustrator, et les bases de donnĂ©es sous Filemaker, Access ou 4D, les outils numĂ©riques sont aujourd’hui en mesure d’ĂȘtre utilisĂ©s au cours de toute la chaĂźne d’acquisition de la donnĂ©e.

L’apport des logiciels et des formats libres est majeur pour cette nouvelle Ă©tape.

QGIS a fondamentalement rĂ©volutionnĂ© la pratique archĂ©ologique en offrant au plus grand nombre l’accĂšs au SIG, permettant de relier et de manipuler les donnĂ©es attributaires et spatiales. Il a ouvert la voie Ă  de nouvelles Ă©volutions, et Ă  l’intĂ©gration de technologies jusque-lĂ  peu utilisĂ©es par l’archĂ©ologie (notamment l’utilisation de bases de donnĂ©es relationnelles et spatiales au format SQL).
SQLpage nous a permis d’offrir Ă  l’archĂ©ologue une interface complĂšte et simple afin d’accĂ©der Ă  une base de donnĂ©es en rĂ©seau. Si son dĂ©veloppement nĂ©cessite une connaissance certaine du SQL et du fonctionnement d’un site web, son dĂ©ploiement et sa maintenance sont tout Ă  fait abordables.
SQLPage rĂ©pond Ă  un rĂ©el besoin sur le terrain. Pour les archĂ©ologues, il permet de simplifier leur pratique tout en rĂ©pondant Ă  la complexitĂ© grandissante face Ă  la masse documentaire Ă  traiter, et Ă  l’accroissement de l’exigence qualitative des rendus.

L’association de QGIS, des bases de donnĂ©es spatiales et relationnelles et d’une interface web parfaitement adaptĂ©e au terrain comblent dĂ©sormais le manque constatĂ© d’un outil efficace et fiable d’enregistrement archĂ©ologique Ă  l’échelle de l’opĂ©ration. À ce titre, Badass associĂ©e Ă  Bad‘Mobil comblent totalement les attentes des archĂ©ologues qui les ont expĂ©rimentĂ©s.

Si les logiciels libres ont, ces derniĂšres annĂ©es, entamĂ© une timide percĂ©e chez de nombreux opĂ©rateurs d’archĂ©ologie (certains les ont pleinement adoptĂ©s), des rĂ©ticences restent prĂ©sentes, que ce soit des utilisateurs, mais aussi parfois des DSI des administrations publiques, qui peuvent prĂ©fĂ©rer opter pour un service tout-en-un dotĂ© d’un support technique.

Mais la persistance des usages des logiciels propriĂ©taires n’est pas sans poser de rĂ©els problĂšmes quant Ă  la pĂ©rennitĂ© des donnĂ©es archĂ©ologiques et les archĂ©ologues commencent juste Ă  dĂ©couvrir le problĂšme. Leur attachement Ă  leurs donnĂ©es — si elle va parfois Ă  l’encontre du principe de la science ouverte — devrait cependant les inciter Ă  opter pour des formats dont la pĂ©rennitĂ© apparaĂźt certaine, garantissant par lĂ  mĂȘme l’accĂšs Ă  ces donnĂ©es dans le futur, quel que soit le logiciel ou le systĂšme d’exploitation utilisĂ©, s’ils ne veulent pas que leur travail tombe dans l’oubli


Commentaires : voir le flux Atom ouvrir dans le navigateur

Les langues peu documentées et le libre : quelques enjeux scientifiques

Comme beaucoup de domaines scientifiques, la documentation de la diversitĂ© linguistique entretient une relation forte avec les mondes du Libre. Dans cette dĂ©pĂȘche, je vous propose de dĂ©couvrir ce domaine Ă  travers la prĂ©sentation de plusieurs logiciels et ressources libres ou en accĂšs ouvert. La documentation des langues Ă©tant un thĂšme peu courant sur LinuxFr.org, on commencera par une prĂ©sentation de cette problĂ©matique. Nous continuerons par une description des deux ressources principales existantes pour cataloguer et se repĂ©rer au sein de cette diversitĂ© linguistique. Je parlerai ensuite d’ELAN et de FLEX, deux logiciels utilisĂ©s pour annoter des enregistrements audio-visuels, une Ă©tape clef dans l’analyse linguistique, et qui permet le partage et la rĂ©utilisation de ces enregistrements. Enfin, aprĂšs un court passage sur la question de l’archivage, je prĂ©senterai deux compilations de corpus de documentation en accĂšs libre, une pratique rĂ©cente qui permet de nouveaux questionnements quantitatifs sur les langues orales peu documentĂ©es, et qui contribue Ă©galement Ă  la transparence et la traçabilitĂ© des analyses linguistiques.

    Sommaire

    L’étude des langues Ă  travers le monde

    Actuellement, environ 7000 langues ont Ă©tĂ© recensĂ©es Ă  travers le monde. Ce chiffre ne peut ĂȘtre qu’une approximation car, il n’y a pas de consensus sur la dĂ©finition de ce qu’est une langue. Une difficultĂ© par exemple est de dĂ©finir Ă  quel moment une langue est distincte d’une autre. Lorsqu’il y a variation, mais intercomprĂ©hension, de nombreux linguistes s’accordent Ă  dire qu’il s’agit alors de dialectes d’une mĂȘme langue, et donc, lorsqu’il n’y a pas intercomprĂ©hension, alors il s’agit diffĂ©rentes langues. Cette perspective considĂšre que tout le monde parle un dialecte (que ce soit celui de rĂ©fĂ©rence, ou un plus rĂ©gional comme celui de Paris, de Marseille, du QuĂ©bec), la langue n’étant qu’une abstraction permettant de regrouper les diverses pratiques langagiĂšres. En ce qui concerne l’intercomprĂ©hension, ce critĂšre n’est malheureusement pas absolu car elle peut varier selon les personnes et leur parcours personnel. Et lorsqu’on considĂšre l’évolution d’une langue Ă  travers le temps, sa diachronie, dĂ©finir ce qu’est une mĂȘme langue Ă  travers ses Ă©volutions temporelles se complexifie d’autant plus.

    Si certaines langues ont Ă©mergĂ© rĂ©cemment, on pense assez souvent aux langues dites crĂ©oles (le Bichelamar, les crĂ©oles malais, Ă  Madagascar ou au Cap Vert), ou Ă©galement lorsque certains dialectes se distinguent suffisamment pour ne plus ĂȘtre intercomprĂ©hensibles, la tendance actuelle est surtout Ă  la disparition massive des langues. Cette disparition est souvent rapportĂ©e Ă  travers la mort des derniers locuteurs et locutrices, on peut aussi considĂ©rer qu’une langue meurt lorsqu’elle n’est plus parlĂ©e d’une part, et qu’elle disparait si elle n’est pas documentĂ©e. Si certains aujourd’hui se questionnent sur la corrĂ©lation entre la diversitĂ© culturelle et la diversitĂ© Ă©cologique, il est Ă©vident que la disparition des langues correspond Ă©galement Ă  des inĂ©galitĂ©s et des tensions socio-politiques.

    Bref, la documentation des langues, c’est un sujet actuel, et d’un point de vue scientifique, la perte de cette diversitĂ© aura de tristes consĂ©quences sur la connaissance des langues et de l’univers des possibles languagiers, encore souvent sous-estimĂ© :

    • l’article The myth of language universals : Language diversity and its importance for cognitive science d’Evans donne un bel aperçu du dĂ©bat qui existe entre les linguistes fonctionnalistes, notamment les approches gĂ©nĂ©rativistes telles que proposĂ©es par Noam Chomsky. Pourtant, rĂ©guliĂšrement Ă  travers la documentation des langues, des catĂ©gories cognitives jusque-lĂ  non-soupçonnĂ©s, voire rejetĂ©es car non-observĂ©es, sont identifiĂ©s. Nous nous sommes rendu compte rĂ©cemment qu’un quart des langues grammaticalisaient l’emploi d’évidentiels, ces morphĂšmes qui indiquent la source d’une information. Au niveau de l’odorat, des neurologistes pensaient que si nous n’avions pas de termes abstraits pour catĂ©goriser les odeurs, c’était liĂ© au fait que notre cerveau ne le permettait pas. La description des termes liĂ©s Ă  l’odorat en Jahai (par ici si vous souhaitez Ă©couter du Jahai), qui possĂšde donc des termes spĂ©cifiques pour catĂ©goriser les odeurs, a montrĂ© le contraire.
    • accĂ©der Ă  des facettes non-matĂ©rielles de la prĂ©histoire, non-accessibles Ă  travers l’archĂ©ologie. La documentation des langues nous permet d’accĂ©der, dans une certaine mesure, aux termes et aux concepts utilisĂ©s durant les diffĂ©rentes prĂ©histoires Ă  travers la comparaison des langues et de leurs structures. Les travaux sont nombreux et anciens en ce qui concerne les langues europĂ©ennes, mais les recherches en linguistique historique (ou comparĂ©e) portent Ă©galement sur toutes les langues connues Ă  travers le monde. Les chercheurs et chercheuses de ce domaine collaborent assez rĂ©guliĂšrement avec les archĂ©ologues pour retracer les mouvements de population.
    • mettre au point des systĂšmes d’écriture pour les langues orales, ou simplement des traitements de texte adaptĂ© aux Ă©critures existantes. Parfois, certaines personnes savent Ă©crire dans la ou les langues officielles du pays, mais ne connaissent pas d’écriture pour une de leurs langues rĂ©gionales. C’est ainsi souvent le cas pour les personnes au Vanuatu. Le pays reconnait mĂȘme le droit d’enseigner les langues locales Ă  l’école, mais il n’existe que trĂšs rarement des ressources (que ce soit les personnes ou les manuels) pour cela. Parfois, les gens ne connaissent tout simplement pas de systĂšme d’écriture.

    Quelques concepts et termes liés à la documentation des langues

    Comme tout domaine de recherche, la terminologie et les concepts linguistiques Ă©voluent au grĂ© des discussions et peut se distinguer de l’usage attendu des termes. Une Ă©tape importante dans la documentation d’une langue est la production d’une grammaire dĂ©crivant les structures linguistiques de cette langue. De nombreux linguistes estiment alors qu’on peut dire que cette langue est dĂ©crite. Il ne faut pas se tromper cependant, aucun linguiste ne considĂšre qu’une langue est alors complĂštement dĂ©crite. Une grammaire ne contient que quelques aspects estimĂ©s actuellement essentielles par les linguistes de terrain. Ces points sont, le plus souvent, une description du systĂšme phonologique d’une langue (c’est-Ă -dire comment les sons d’une langue sont organisĂ©s les uns vis-Ă -vis des autres), des morphĂšmes et des processus morphologiques associĂ©s (la conjugaison, l’expression de la possession, les dĂ©clinaisons, les genres, les classifications, etc.) d’une langue et souvent un dĂ©but de description des processus syntaxiques. Il existe de nombreuses approches pour dĂ©crire les faits linguistiques, et la description d’une langue se fait souvent en dialogue avec les pratiques et terminologies qui ont Ă©tĂ© employĂ©es dans l'aire linguistique concernĂ©e.

    Depuis l’article Documentary and descriptive linguistics de Nicholaus Himmelman, qui a promu la distinction entre la documentation linguistique et la description linguistique, on accorde beaucoup plus d’importance Ă  la production d’un corpus d’enregistrements annotĂ©s. On dit alors d’une langue qu’elle est documentĂ©e si des enregistrements annotĂ©s, de prĂ©fĂ©rences audio-visuels, de cette langue existe. Enfin, il existe la problĂ©matique de l’outillage d’une langue, c’est-Ă -dire si ses locuteurs et locutrices ont accĂšs ou non aux outils informatisĂ©s, du traitement texte aux dictionnaires informatisĂ©s en passant par la reconnaissance vocale, la transcription automatique, voire aujourd’hui aux modĂšles de langues et autres ressources nĂ©cessitant des corpus beaucoup plus grands.

    Les catalogues et base de donnĂ©es pour l’identification des langues

    Une problĂ©matique rĂ©currente dans le domaine des langues est de clairement identifier la langue sur laquelle on travaille. Cependant, identifier une langue, ce qui relĂšve ou non de cette langue, oĂč elle est parlĂ©e, est l’enjeu de nombreux dĂ©bats, souvent politique, et n’est pas une tĂąche simple. Quoi qu’il en soit, il existe des ressources, bases de donnĂ©es, qui proposent d’associer Ă  des noms de langues, endonymes ou exonymes, des codes pour rendre leur identification univoque.

    L’Ethnologue et l’ISO 639 : une norme gĂ©rĂ©e par le Summer Institute of Linguistics (SIL)

    Ethnologue, Languages of the World, ou plus simplement l’Ethnologue, est une base de donnĂ©es dĂ©veloppĂ©e et maintenu par l’organisme Ă©vangĂ©lique SIL, Summer Institute of Linguistic depuis 1951. Elle vise Ă  recenser toutes les langues du monde. L’ISO 639 est une norme issue de ce catalogue, Ă©galement maintenue par le SIL. Cet organisme est trĂšs actif au niveau de la documentation des langues et de la crĂ©ation d’écritures, car un de ses objectifs est de traduire la Bible dans toutes les langues du monde. Historiquement, l’Ethnologue est un des premiers catalogues dont l’objet a Ă©tĂ© de recenser les langues. Si cette norme semble le plus souvent suffisamment exhaustive pour les besoins liĂ©s Ă  l’informatique, aprĂšs tout, les internautes consultent Internet en trĂšs peu de langue, d’un point de vue linguistique, il possĂšde de nombreuses lacunes.

    La liste SIL des langues

    Un premier souci est la nĂ©cessitĂ© d’avoir une granularitĂ© plus importante que simplement la langue. Les linguistes travaillent sur des dialectes et des variĂ©tĂ©s, sur des familles de langues, et parfois ont travaillĂ© sur des distinctions qui n’ont parfois plus cours. Afin de pouvoir associer ces ressources Ă  des langues, ou des entitĂ©s linguistiques particuliĂšres, l’approche du SIL ne suffit pas.

    Enfin, la gestion du catalogue par un organisme religieux, donc avec parfois d’autres enjeux qu’uniquement scientifiques, le fait qu’il s’agisse d’une norme, donc la nĂ©cessitĂ© de collaborer avec l’ISO, et le fait que seule une partie du catalogue est accessible (il faut un abonnement pour accĂ©der Ă  la totalitĂ© de la ressource) rend la ressource moins pertinente pour de nombreux linguistes. Ces limites ont poussĂ© des linguistes Ă  proposer une ressource alternative.

    Glottocode : par le Max Planck Institute for Evolutionary Anthropology.

    Le projet Glottolog, initialement dĂ©veloppĂ© par Sebastian Nordhoff et Harald Hammarström, catalogue non seulement les langues du monde actuelles et passĂ©s, les familles de langues et leurs diffĂ©rentes branches, mais Ă©galement « les restes Â» des hypothĂšses de langues ou de regroupements historiques. Cette granularitĂ© permet de retrouver les documents associĂ©s Ă  chacun de ces objets. Si le catalogue est dĂ©diĂ© aux langues moins connues, les langues les plus centrales sont elles aussi rĂ©pertoriĂ©es. Il s’agit actuellement du catalogue mis en avant par les linguistes documentant les langues Ă  travers le monde. L’application Glottolog est disponible via la licence MIT.

    Aperçu du Glottolog à travers la liste des langues

    Si aux premiers abords, la liste des langues du Glottolog ne se distingue pas franchement de celle de l’ISO 639, c’est parce qu’il faut regarder plus en dĂ©tail pour comprendre les diffĂ©rences essentielles entre les deux ressources. Notons tout de mĂȘme la colonne « Child dialects » : « Dialectes enfants », et les champs vides au niveau des colonnes Top-level-family et pour la langue Abai Tubu-Abai Sembuak dans la colonne « ISO-639-3 Â». La colonne « Child dialects » reprĂ©sente une information qui n’est pas documentĂ© dans l’ISO 639, ce n’est pas son objet aprĂšs tout, mais qui est intĂ©ressant pour les linguistes travaillant sur cette langue, indiquant qu’un minimum de donnĂ©es sociolinguistiques sont disponibles. Les champs vides dans la colonne « Top-level family » sont dus au fait que ces langues sont des isolats, c’est-Ă -dire que la linguistique comparĂ©e ne trouve pas de correspondances significatives entre cette langue et d’autres langues qui permettraient de les regrouper en une famille. Enfin, le vide dans la colonne ISO-963-3 rĂ©vĂšle que la langue Abai Tubu-Abai Sembuak ne possĂšde pas d’entrĂ©e dĂ©diĂ©e dans la norme.

    Ainsi, lorsque l’on consulte une langue en particuliĂšre, ici le Nisvai, on voit apparaitre tous les embranchements existants associĂ©s Ă  cette langue :

    La langue Nisvai dans le Glottolog

    Cette vue de l’arborescence associĂ©e Ă  une langue particuliĂšre rĂ©vĂšle tous les embranchements auxquels peut⁻ĂȘtre associĂ©e une langue. Et Ă  chacun de ces embranchements, si des ressources linguistiques ont Ă©tĂ© identifiĂ©es par les mainteneurs du Glottolog, celles peuvent ĂȘtre proposĂ©es. Cette fonction permet aux linguistes de trouver des ressources sur les langues proches, non pas gĂ©ographiquement (mĂȘme si en pratique c’est le plus souvent le cas), mais d’un point de vue gĂ©nĂ©alogique.

    Les autres

    Il existe d’autres initiatives pour cataloguer les langues du monde, que ce soit la liste proposĂ©e par Wikipedia, la liste de la CIA ou encore The Linguasphere Register, mais ces initiatives ne sont pas aussi pertinentes du point de vue de la documentation des langues.

    Documenter les langues

    ELAN : des schĂ©mas d’annotation flexibles

    ELAN est un des logiciels libres (GPL3) les plus utilisĂ©s par les linguistes pour annoter des enregistrements audio et vidĂ©o. Il permet d’élaborer des structures d’annotation complexes permettant ainsi de rendre compte des analyses que les linguistes souhaitent associer Ă  un enregistrement. Ces couches d’annotation sont reliĂ©es les unes aux autres par des relations logiques, avec le plus souvent une couche de rĂ©fĂ©rence indexĂ©e temporellement Ă  l’enregistrement. Les annotations les plus courantes sont une transcription, une traduction et une annotation morphologique. Mais des nombreuses autres analyses peuvent ĂȘtre incluses, que ce soit les parties du discours, les rĂ©fĂ©rences et anaphores, l'animĂ©itĂ©, mais aussi les gestes, la structuration du discours, les signes pour les sourds et malentendants.

    Extrait d’une narration prĂ©sente dans DoReCo, et vue sur les diffĂ©rentes couches d’annotation pouvant ĂȘtre associĂ©s Ă  un enregistrement.

    Dans cette capture d’écran issu d’un texte de DoReCo retravaillĂ© par l’auteur, on aperçoit un extrait de quelques secondes d’une narration nisvaie. Il s’agit d’un des modes de visualisation des annotations proposĂ©es par ELAN pour reprĂ©senter les diffĂ©rentes couches d’annotation. Certaines de ces annotations ont Ă©tĂ© rĂ©alisĂ©es Ă  la main par l’auteur, d’autres ont Ă©tĂ© retravaillĂ©es par les algorithmes mis en place par DoReCo, puis manuellement corrigĂ©s. Enfin, il y a Ă©galement des couches d’annotation de la prosodie par le biais de SLAM+.

    FLEX : gĂ©rer un projet de documentation

    FLEX est un logiciel dĂ©veloppĂ© par le SIL et dont le code source est rĂ©gie par la licence LGPL 2.1. Il est conçu davantage pour coordonner l’ensemble d’une documentation linguistique, de la gestion des textes Ă  l’élaboration d’un dictionnaire, en passant par les analyses linguistiques. En revanche, il ne gĂšre pas rĂ©ellement l’annotation d’enregistrements. De nombreux linguistes l’utilisent en complĂ©ment d’ELAN.

    Si le logiciel est prometteur sur le papier, Ă  chaque fois que je l’ai essayĂ©, j’ai Ă©tĂ© rebutĂ© par son cĂŽtĂ© usine Ă  gaz, et surtout ses nombreux plantages notamment lorsqu’on essaie de gĂ©rer des fichiers multimĂ©dia avec. Et il en est de mĂȘme pour les autres logiciels dĂ©veloppĂ© par le SIL, tel que SayMore pour gĂ©rer les mĂ©tadonnĂ©es des enregistrements, WeSay pour faire des dictionnaires en collaboration avec les locuteurs et locutrices, Ă  chaque fois que je les ai essayĂ©s, enthousiasmĂ© par leurs fonctionnalitĂ©s, j’ai Ă©tĂ© déçu par le fait qu’ils ne fonctionnaient pas correctement sur mon ordinateur.

    Aperçu de Flex

    Cette capture d’écran illustre un des modes de saisie de FLEX, ici la vue tabulaire du lexique, qui permet de rentrer et gĂ©rer les dĂ©finitions des lexĂšmes (les entrĂ©es du dictionnaire) de maniĂšre assez rapide. On aperçoit dans la partie en haut Ă  gauche les autres modes d’édition du lexique, et en dessous les autres catĂ©gories liĂ©es Ă  la gestion d’un projet de documentation : Texts & Words, Grammar, Notebook et Lists. C’est Ă  travers la catĂ©gorie Texts & Words que l’on peut par exemple importer des textes transcrits, voire des fichiers ELAN pour peupler la base de donnĂ©es lexicales. Grammar permet de dĂ©crire les paradigmes grammaticaux, FLEX propose d’ailleurs quelques algorithmes qui aident Ă  la construction des paradigmes grammaticaux. Notebook et Lists servent Ă  la gestion du projet, le premier pour prendre des notes diverses, et le second pour crĂ©er des listes, en particulier des tĂąches encore Ă  rĂ©aliser.

    Et il y en a bien d’autres encore

    Il existe de nombreux autres logiciels similaires, tels qu’EXmaralda pour l’annotation des enregistrements (surtout utilisĂ© en Allemagne Ă  ma connaissance), Sonal (non libre, et dont le dĂ©veloppement semble arrĂȘtĂ©) qui est utilisĂ© par les sociologues et les anthropologues pour une annotation thĂ©matique de leurs entretiens, Anvil, qui semble intĂ©ressant mais que je n’ai jamais rĂ©ellement vu utilisĂ©, ou enfin le vieux Transcriber qui lui Ă©tait encore employĂ© par certains projets il y a quelques annĂ©es. Rentrer dans le dĂ©tail de tous ces logiciels dĂ©passerait le cadre d’une dĂ©pĂȘche comme celle-ci, mais Ă©numĂ©rer la diversitĂ© logicielle montre qu’il s’agit d’un secteur un minimum dynamique, d’ailleurs la question de la transcription et de l’annotation des enregistrements ne se limite pas du tout qu’au domaine de la documentation des langues du monde.

    L’archivage et la compilation de corpus

    Afin de conserver et partager les corpus et donnée enregistrées par les linguistes, chercheurs voire simplement les personnes ayant documenté une langue, il existe des archives, le plus souvent en ligne. Il y a en France par exemple Pangloss, géré par le LACITO, dédié aux langues orales, ou ORTOLANG, plus générique, pour les corpus de langue. En Océanie, il y a Paradisec. Il y a aussi ELAR, autrefois à Londres, et qui a déménagé récemment à Berlin récemment.

    Ces archives proposent diverses interfaces pour dĂ©poser, gĂ©rer et parfois mĂȘme consulter les enregistrements et les annotations rĂ©alisĂ©s par les linguistes et leurs collaborateurs·e·s. À noter que pour ces archives, Ortolang dĂ©crit son architecture logicielle qui repose sur des briques ouvertes, en revanche concernant Paradisec et Pangloss, bien que leur statuts soient sĂ»rement similaires du fait de la dĂ©marche gĂ©nĂ©rale de ses ingĂ©nieurs, je n’ai pas trouvĂ© de liens vers les logiciels employĂ©s. Quant Ă  ELAR, le logiciel utilisĂ© est Preservica, une solution propriĂ©taire qui, quand on a le malheur de devoir l’utiliser, fonctionne bien lentement.

    La compilation de corpus, si elle se rapproche de l’archivage en ce qu’il s’agit Ă©galement de recueillir, conserver et publier les corpus des linguistes, correspond Ă©galement Ă  une Ă©dition particuliĂšre de ces corpus. La compilation de corpus est rĂ©alisĂ© Ă  travers la mise en place de processus de qualitĂ©, d’annotations et de conventions particuliĂšres. Les deux compilations de corpus prĂ©sentĂ©es ici sont des compilations de corpus de documentation de langues orales. Les enregistrements ont Ă©tĂ© systĂ©matiquement annotĂ©s en utilisant une convention nommĂ©e les gloses interlinaires (le nom fait en fait rĂ©fĂ©rence Ă  la pratique ancienne d’insĂ©rer des explications entre les lignes d’un texte. En pratique aujourd’hui, ce n’est plus vraiment ce que font les linguistes, puisque le travail est informatisĂ© et les annotations ne sont plus entre les lignes, mais, le terme a cependant Ă©tĂ© conservĂ©).

    DoReCo

    DoReCo est une compilation de 52 corpus en accĂšs ouvert (NdR : auquelle l’auteur a contribuĂ©). La compilation a nĂ©cessitĂ© la mise en place de processus de qualitĂ© afin d’assurer la cohĂ©rence de l’ensemble et de fournir un certain nombre de garanties quant aux qualitĂ©s du corpus.

    Les langues dans DoReCo

    Une premiĂšre qualitĂ©, et l’une des originalitĂ©s de DoReCo, est de proposer un alignement temporel est trĂšs fin. La durĂ©e de chaque phonĂšme, de chaque morphĂšmes, de chaque mot (ici suivant la dĂ©finition de la personne Ă  l’origine du corpus, car la dĂ©finition d’un mot n’a rien d’une Ă©vidence) et enfin de chaque groupe de souffle est fournie. Une deuxiĂšme qualitĂ© a Ă©tĂ© de s’assurer que pour l’ensemble des retranscriptions, chacun des termes et des morphĂšmes possĂšde une glose, c’est-Ă -dire qu’ils possĂšdent une explication linguistique.

    La compilation totalise une centaine d’heures d’enregistrements audio, en grande majoritĂ© des narrations monologiques. À noter que les corpus de la compilation sont accĂšs ouvert, via une licence Creative Commons, mais que les droits d’utilisation varient d’un corpus Ă  l’autre. Les donnĂ©es sont accessibles aux formats d’ELAN : .eaf, de Praat : . TextGrid, TEI.xml, et.csv.

    Multi-CAST

    Multi-CAST est Ă©galement une compilation de 18 corpus de documentation de langues diffĂ©rentes. Les textes annotĂ©s via le logiciel ELAN. Contrairement Ă  DoReCo, l’alignement temporel des annotations n’est pas rĂ©alisĂ© de maniĂšre prĂ©cise, mais manuellement, par les personnes Ă  l’origine du corpus, Ă  l’échelle de l’énoncĂ©. Les textes sont Ă©galement en grande majoritĂ© des narrations monologiques. L’originalitĂ© de cette compilation de corpus vient du fait que les textes contiennent trois couches d’annotation particuliĂšres : GRAID, Grammatical Relations and Animacy in Discourse, (voir), puis RefIND et ISNRef (Referent Indexing in Natural Language Discourse, voir Schiborr et al. 2018).

    La page d’accueil de Multi-Cast

    Cette compilation de corpus est aussi disponible dans plusieurs formats. XML Ă©videmment, puisque c’est le format natif d’ELAN, mais aussi TSV et il existe Ă©galement un paquet pour R. Tout cela est disponible via la licence CC-BY 4.0.

    Conclusion

    J’espĂšre que vous avez apprĂ©ciĂ© cette introduction Ă  la documentation des langues Ă  travers les logiciels libres. L’idĂ©e est surtout d’attiser la curiositĂ©, car il reste Ă©videmment encore de nombreux aspects ou points Ă  discuter et Ă  approfondir. La prochaine fois que j’aborderai le thĂšme de la documentation linguistique ici, j’espĂšre que ça sera pour prĂ©senter mon application basĂ©e sur Django pour faire de la lexicographie.

    Il y a Ă©galement un autre sujet sur lequel j’aimerais bien Ă©changer ici prochainement : la question des licences des donnĂ©es collectĂ©s et la nĂ©gociation lorsque l’on travaille avec des personnes Ă  tradition orale. Si ouvrir l’accĂšs aux donnĂ©es de recherche et aux corpus peut sembler ĂȘtre une Ă©vidence pour certains, il ne faut pas oublier que souvent, les chercheurs et chercheuses de terrain collectent des informations personnelles, que la connaissance n’est pas forcĂ©ment considĂ©rĂ©e comme un bien public et les enregistrements, notamment les narrations, qui ne sont pas forcĂ©ment perçues comme des fictions, sont souvent couverts par des droits locaux. Enfin, ouvrir ses donnĂ©es de recherche, si c’est permettre Ă  d’autres de rĂ©utiliser ses donnĂ©es, requiert beaucoup de travail de la part des linguistes, c’est une tĂąche longue, ingrate et surtout peu valorisĂ©e. Alors qu’il est de plus en plus prĂ©caire d’ĂȘtre chercheur en sciences humaines, il est aussi difficile de demander Ă  ces chercheurs et chercheuses de consacrer une grande partie de leur temps Ă  des tĂąches qui ne leur permettront pas de se constituer un CV, nĂ©cessaire si l’on souhaite avoir un poste stable (c’est-Ă -dire plus de deux ans).

    Label sans IA : ce texte a Ă©tĂ© rĂ©digĂ© sans aucun aide de la part d’une LLM.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Sortie de GIMP 2.99.18 (version de développement)

    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
      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
      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 - démonstration de GIMP 2.99.18
      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.

      Aligner sur les boßtes englobantes et Aligner à équidistance - démonstration de GIMP 2.99.18
      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
      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 ! đŸ’ȘđŸ„ł

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      ❌