Myriad Blog 1.3.0 Thursday, Jul 24th, 2014 at 10:27am 

Technical Tuesday, Jul 1st, 2014 at 05:03pm
Linux : Dépendances... et cuisine

 
Une utilisatrice de Linux, experte en la matière, nous a fait remarquer que, depuis l'abandon du paquet de compatibilité ia32-libs par les distributions Ubuntu/Mint, il était très difficile, voire impossible,  d'installer Harmony Assistant sur un tel Linux en 64 bits.
 
Harmony est, et compte bien rester, une application 32 bits. Outre le fait qu'une version 64 bits n'amènerait absolument aucun gain de rapidité, de fonctionnalité ou de compacité (au contraire), une migration vers du 64 bits nécessiterait au bas mot plusieurs mois de développement non stop, tout cela pour obtenir au final une application qui fonctionne presque aussi bien qu'avant.
 
Windows ou MacOS permettent de faire fonctionner les applications 32 bits sur les versions 64 bits du système sans que l'utilisateur (ou le programmeur) ne le remarque. Ca fonctionne, et on avait fini par s'y habituer. Et voici qu'arrive Linux.  
 
Pour que l'application fonctionne, il lui faut la version 32 bits des bibliothèque du système qu'elle utilise. Ces bibliothèques, appelées dépendances, ne sont pas installées par défaut, et leur installation, d'après ce que l'utilisatrice Linux nous a dit, pourrait perturber la stabilité du système tout entier, voire le corrompre irrémédiablement.
 
Le tournant que nous avons pris avec ACAM-Winter vise justement à  réduire les dépendances de l'application au strict minimum, de manière a faciliter le processus d'installation.
La version en cours de développement n'a plus besoin, pour fonctionner, que des bibliothèques 32 bits (i386) suivantes :
 
- libc6 : fonctions de bases du programme
- libasound2 : ALSA, le gestionnaire de son
- libx11-6 : X11, l'interfaçage graphique
- libfreetype6 et libfontconfig1 : gestion des polices de caractères
- et probablement libcups2 : gestion des imprimantes
 
Nous essayons encore de réduire.
 
Mais l'utilisatrice nous a fait comprendre que beaucoup de Linuxiens rechigneraient à installer une quelconque application 32 bits sur leur système 64 bits, car le risque de conflit et de problème serait trop important, quel que soit le nombre de dépendances.
 
Cela nous inquiète. Car si cela s'avérait vrai, étant donné que la part des installations 64 bits de Linux ne cesse d'augmenter, cela pourrait assez rapidement remettre en question l'existence même de la version Linux.
by Olivier Guillion
 3 comments.

Technical Friday, Jul 18th, 2014 at 04:57pm
Linux et les formats graphiques

 
Dans le cadre du développement d'Acam-Winter, nous cherchons à minimiser les bibliothèques nécessaires au fonctionnement du programme.
Dans nos programmes ainsi que dans ACAM lui-même, nous avons besoin de visualiser (et parfois d'écrire) des fichiers graphiques dans les formats les plus courants:
BMP, GIF, JPG, PNG et TIFF

Afin de ne pas être tributaires du système, nous avons décidé d'incorporer directement dans ACAM-Winter les modules de codage/décodage de ces formats.
 
Il nous fallait donc trouver un ou plusieurs fichiers sources qui satisfassent aux exigences suivantes, dans l'ordre:
 

    1- Être écrit en C
     
    2- Être automome, c'est-à-dire n'ayant pas besoin d'une bibliothèque additionnelle (ZLIB, etc)
     
    3- Être portable, afin de pouvoir être compilé sans difficulté sous n'importe quel système.
     
    4- Être court, pour ne pas ajouter plusieurs méga-octets à chacun de nos programmes utilisant ACAM
     
    5- Être facile d'emploi : nous avons seulement besoin de convertir des images brutes en 32 bits (RGBA) depuis et vers le format graphique.  
    Nous n'avons pas besoin d'aller fouiller au fin fond des métadonnées du format, ou de travailler avec des palettes de couleurs ou des données EXIF.
     
    6- Pouvoir travailler en mémoire et pas sur fichier afin de pouvoir convertir nos images brutes sans passer par un fichier temporaire
     
    7- Permettre l'utilisation de ces fichiers sources dans une application commerciale à sources fermés sans devoir payer des droits

Nous n'avons pas de contrainte de rapidité (à condition de rester dans le domaine du raisonnable)  
 
Dans ce cadre, nous avons évalué, souvent téléchargé, et parfois compilé divers projets.  
Voici ce que nous avons pu en tirer jusque là:

  • Format PNG / libpng : très répandue et utilisée, une bibliothèque complète, très complète, trop peut-être. En fait de bibliothèque, c'est plus proche de la bibliothèque d'Alexandrie que du Bibliobus de Rebire-Chioulet.
    Il semble que cela occupe plusieurs centaines de kilo-octets, et que son utilisation nécessite plusieurs jours de bûchage de doc.
     
  • Format JPG / libjpeg : Même chose que ci-dessus.
     
  • Format TIFF / libtiff : Même chose que ci-dessus. La complexité du méta-format TIFF nous amène à nous demander si le jeu en vaut la chandelle, et s'il ne vaudrait pas mieux faire l'impasse sur ce format, somme toute peu utilisé, plutôt que nous embêter avec.
     
  • Format PNG / LodePng : excellente bibliothèque, constituée d'un seul fichier source, très court. Pas très rapide mais on s'en fiche. En gros, possède tous les atouts.
     
  • Multi-formats (jpg, png, bmp, tga, psd, gif, hdr, pic) / stb_image : Très compacte, livrée sous un format étrange (tout en fichier C "header" .h), il ne manquerait que le tiff, si le module de sauvegarde était aussi complet, ce qui n'est pas le cas.
    Ne peut créer que des fichiers png, bmp et tga, et encore sous forme de fichier seulement (voir point 6 ci-dessus). Avec une astuce de programmation, nous avons pu lui faire générer les données dans un bloc mémoire. Il manque cependant pas mal de formats
     
  • Format JPG (encodage) / jpegEnc : Court et simple d'utilisation, fait ce qu'il dit, c'est-à-dire de l'encodage jpeg. Peut être utilisé en complément de stb_image ci-dessus.
     
  • Format GIF / giflib : En cours d'évaluation par nos soins. Satisfait a priori aux critères, bien qu'apparemment un peu compliqué pour un format si simple. Pourrait être utilisé en complément de stb_image ci-dessus?
     
  • Format BMP / nous-même : le format BMP est déjà supporté en natif dans ACAM. Nous n'avons donc a priori pas besoin de bibliothèque pour l'utiliser. Mais notre implémentation est partielle, donc un module plus complet ne nuirait pas.
     
  • Multi-formats / libgd : prometteur et compact, après tentative de compilation il semble que ce module nécessite l'installation de libpng, libjpg, libtiff, etc pour fonctionner. Hors sujet pour nous, donc.

 
Pour l'instant, nous avons compilé et incorporé LodePng, stb_image (seul ce dernier devrait rester, car il gère plus de formats que LodePng), jpegEnc et giflib (pas encore testé). Faute de solution acceptable, nous avons renoncé pour l'instant à prendre en compte le format TIFF.
 
Avec tout ceci, nous devrions pouvoir lire et écrire en format BMP, GIF, JPG, PNG, ainsi que TGA, ainsi que lire en format PSD, HDR et PIC, sans avoir besoin de quoi que ce soit de la part du système.
 
La lecture PNG avec masque d'opacité a été testée, dans le futur sélecteur de fichier ACAM-Winter (les icônes apparaissant dans cette boîte sont des images PNG):
 

 
Bon week-end à tous !
by Olivier Guillion
 3 comments.


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Dev News
Technical
Mood
Memories
Myriad Life
To be seen
30 previous days
Apr 2006
May 2006
Jun 2006
Jul 2006
Aug 2006
Sep 2006
Oct 2006
Nov 2006
Dec 2006
Jan 2007
Feb 2007
Mar 2007
Apr 2007
May 2007
Jun 2007
Jul 2007
Aug 2007
Sep 2007
Oct 2007
Nov 2007
Dec 2007
Jan 2008
Feb 2008
Mar 2008
Apr 2008
May 2008
Jun 2008
Jul 2008
Aug 2008
Sep 2008
Oct 2008
Nov 2008
Dec 2008
Jan 2009
Feb 2009
Mar 2009
Apr 2009
May 2009
Jun 2009
Jul 2009
Aug 2009
Sep 2009
Oct 2009
Nov 2009
Dec 2009
Jan 2010
Feb 2010
Mar 2010
Apr 2010
May 2010
Jun 2010
Jul 2010
Aug 2010
Sep 2010
Oct 2010
Nov 2010
Dec 2010
Jan 2011
Feb 2011
Mar 2011
Apr 2011
May 2011
Jun 2011
Jul 2011
Aug 2011
Sep 2011
Oct 2011
Nov 2011
Dec 2011
Jan 2012
Feb 2012
Mar 2012
Apr 2012
May 2012
Jun 2012
Jul 2012
Aug 2012
Sep 2012
Oct 2012
Nov 2012
Dec 2012
Jan 2013
Feb 2013
Mar 2013
Apr 2013
May 2013
Jun 2013
Jul 2013
Aug 2013
Sep 2013
Oct 2013
Nov 2013
Dec 2013
Jan 2014
Feb 2014
Mar 2014
Apr 2014
May 2014
Jun 2014
Jul 2014
Jul 23rd, 2014 at 11:03pm 
Comment from
Jul 23rd, 2014 at 05:03pm 
Article from Didier Guillion
PDFtoMusic 1.4.3
Jul 22nd, 2014 at 10:53pm 
Comment from Cri-Cri
Le triolet
Jul 22nd, 2014 at 04:59pm 
Article from Olivier Guillion
Harmony 9.6 étape 697
Jul 22nd, 2014 at 04:59pm 
Article from Olivier Guillion
Harmony 9.6 étape 697
Jul 21st, 2014 at 05:08pm 
Article from Didier Guillion
PDFtoMusic 1.4.3
Jul 20th, 2014 at 08:22pm 
Comment from musikus
Jul 19th, 2014 at 09:44pm 
Comment from Olivier Guillion
nicht füttern...
Jul 19th, 2014 at 09:44pm 
Comment from Olivier Guillion
nicht füttern...
Jul 18th, 2014 at 11:02pm 
Comment from

Top of page
Last update:  (c) Myriad 2013