Cyrille BORNE et Associés

Hormis quelques tutos, depuis la redéfinition de la ligne éditoriale de mon blog, je n'ai plus rien publié sur le Libre ou Linux*. Question de priorité et de temps mais aussi, très certainement, question d'intérêt. Bref, comme Cyrille m'a généreusement invité à publier sur son blog, voilà le premier article.

— Migrer d'une distribution Linux* pour une autre n'est pas forcément la marque infâmante d'un suivisme, mode ou désillusion, comme on a pu en connaître, par le passé, avec Ubuntu ou Mandriva ou, plus récemment encore, avec Gnome 3. Pareille décision ne se prend pas forcément par opposition "philosophique" (« c'est pas libre ! ») ou à la faveur d'une légèreté de l'être (le testing à tout crin). Le fil ne suit pas toujours l'aiguille.

Pour l'indécrottable debianeux que je suis — ou étais —, c'est une nécessité professionnelle qui a motivé — urgemment — une infidélité : l'installation d'une Fedora 17. Le scénario est simple : ma Debian mixte (Testing/Sid) me pose quelques soucis depuis mon changement d'appareil photo, le Canon EOS 5D Mark III. Le format de fichier RAW du 5D Mark III est aujourd'hui mal reconnu sous GNU/Linux. Pas mieux sous… Canon à la sortie de l'appareil ! Rawstudio, Ufraw, RawTherapee… ne l'interprètent pas correctement. Trop récent. Sorti il y a quelques mois pour succéder au Mark II — véritable "star" dans le milieu de la photo —, le 5D Mark III est suffisamment cher et spécialisé pour ne pas être un gadget. Un tel appareil ne s'achète pas par erreur.

— Petite parenthèse : ce problème de reconnaissance (matériel ou format de fichier) n'est pas seulement lié à la nouveauté, comme c'est souvent le cas sous GNU/Linux. Il en est de même pour la plupart des appareils et objectifs professionnels absents, comme les optiques Carl Zeiss, malheureusement, des listes de modules de "correction des objectifs" ou les appareils Hasselblad (rien d'étonnant), les Leica de la série M (8/9 et la suite), etc., non pris en charge par gPhoto2. Deux trois exemples — mais on pourrait les multiplier — pour pointer du doigt une limite bien réelle dans le développement photographique professionnel sous GNU/Linux qui lui interdit toute pénétration massive dans ce secteur. Les raisons sont multiples et, pour certaines évidentes, mais ce n'est pas l'objet de cet article.

— Ma migration sous Fedora n'est pas du seul fait de la nouveauté même si, dans ma présentation, le problème du format RAW récent du 5D Mark III semble premier. En réalité, c'est un peu plus compliqué que ça.

— L'habitude est mauvaise conseillère. Ma machine actuelle tourne avec un processeur 64 bits mais je n'ai jamais installé dessus qu'un système 32 bits. Pourquoi ? L'offre logicielle était, jusqu'il y a peu, bien plus conséquente en 32 bits qu'en 64. Est-ce encore vrai aujourd'hui ? Je ne crois pas. Aucun de mes logiciels habituels ne manque à l'appel sous Fedora 17 64 bits. Cela était vrai, à n'en pas douter, au moment où j'ai installé, pour la première fois, Debian sur cette machine. Autant dire, qu'à ce moment-là, il ne me serait jamais venu à l'idée de m'aventurer au bout du monde avec une machine sur laquelle je n'aurais pu installer tous les logiciels dont j'avais besoin quotidiennement. Ou bien plus difficilement. Le bout du monde était aussi, dans mon cas, le sud du monde, le sud géographique, le sud économique, le sud technologique. Cette métaphore est, je crois, suffisamment explicite. Nul besoin de l'expliquer. Et puis, en définitive, jusqu'alors, je n'avais pas à me plaindre de ma Debian 32 bits.

Alors pourquoi migrer ma machine vers un système 64 bits ? Aujourd'hui, le seul dématriceur libre à prendre en charge efficacement — notion toute relative, cela va de soi — le format de fichier brut (RAW) de mon appareil c'est Darktable. Et Darktable, en 32 bits, avec des fichiers de plus de 20 mégapixels (MPx) est tout bonnement inutilisable. L'explication est sur le blog des développeurs de Darktable.

En informatique, depuis 20 ans, les ressources mémoire ont considérablement augmenté sur les ordinateurs de bureau. Pour autant, elle reste limitée du fait des exigences croissantes des applications modernes. Et Darktable est l'une de ces applications gloutonnes [BloatyApp] qui flirtent très rapidement avec les limites.

Une image de 20 MPx, sous Darktable, a besoin d'environ 300 Mo de mémoire pour être stockée. Le moindre traitement réclame deux tampons de mémoire pour chaque module, l'un pour l'entrée et l'autre pour la sortie. Plus le module est complexe, plus nombreux sont les tampons de mémoire intermédiaires nécessaires. Sans optimisation poussée, il faut de 600Mo à 3Go pour simplement stocker et traiter les données de l'image (dématriçage). Sans entrer dans le détail, Darktable doit donc disposer de 4 Go de RAM pour s'exécuter correctement.

Les développeurs de Darktable conseillent la configuration suivante : 4 Go de RAM minimum et 4 à 8 Go de partition swap afin que le système puisse stocker temporairement les données inutilisées sur le disque pour libérer de la RAM. Pour une explication de ce mécanisme appelé "swapping" voir l'article Du swappiness dans le desktop, la partie "Tu as l'âge de ton plus lointain souvenir" (complément : Libérez la mémoire : swappiness=100 ! Plus que jamais d'actualité, en ce qui me concerne).

Si, en théorie, il est possible de faire tourner Darktable correctement avec moins de RAM et sur un système 32 bits, ce défaut doit être compensé par le swapping. Cela dit, en 32 bits, il faut tout de même s'attendre à voir le système à genoux au premier traitement ! Ou peu s'en faut. Très honnêtement, avec des images de plus de 20MPx, comme c'est le cas avec les fichiers RAW du 5D Mark III, c'est tout bonnement ingérable. Outre la lenteur absolument insupportable, soit Darktable ne parvient pas à générer les miniatures des photos, qu'il remplace par de jolies têtes de mort (première image) pour signifier que les fichiers concernés ne sont pas chargés et donc intraitables, soit le fichier de sortie (en TIFF, par exemple), après traitement, est tronqué (deuxième image).

L'autre paramètre à prendre en considération, vous l'aurez deviné, c'est donc l'architecture du processeur. Selon l'architecture, 32 ou 64 bits, la quantité de mémoire gérée n'est pas équivalente. Un processeur 32 bits peut traiter 4 Go. Beaucoup plus sous GNU/Linux, avec un noyau de type PAE. Inutile de préciser que cette limitation représente, pour le développement photographique sous Darktable, une "situation critique". À cela, il faut ajouter que la taille maximale de la partition d'échange (swap) ne peut excéder 2 Go en 32 bits. Limite que l'on peut contourner, quand on est un grand guru, en dispersant les partitions d'échange sur des disques différents (appelés aussi « spindles »). Mais c'est une autre histoire.

C'est précisément cette situation critique qui m'a contraint à une installation, en dur, d'une Fedora 17 en 64 bits. Ne me demandez pas pourquoi j'ai fait le choix d'une Fedora, la réponse serait d'une banalité confondante d'autant plus qu'une Debian en 64 bits aurait très certainement fait l'affaire ; l'intégration de Darktable sous Debian 64 bits, si j'en crois certains utilisateurs, semble satisfaisante. Le besoin d'air ou de tranquillité…