Journal GnomeScan 0.0.2

Posté par (page perso) .
Tags : aucun
0
26
juin
2006
Salutations,

Je fourni aujourd'hui la version 0.0.2 de mon projet SoC : GnomeScan. Ce projet vise à remplacer xsane dans le bureau Gnome. Pour cela, j'écrit la bibliothèque libgnomescan qui utilise SANE, la bibliothèque libgnomescanui rassemblant les widgets pour manipuler les objets de libgnomescan, et flegita, une petite application pour scanner.

Cette version permet de choisir le périphérique, de scanner une image et de l'enregistrer dans un fichier. Juste assez pour que ça soit testable. J'aimerai bien recevoir des retour sur l'interface, les bugs, etc. C'est avec joie que je receverai vos conseil et vos idée pour une super interface de scannerisation pour Gnome.

Flegita restera simple. La prochaine étape est de fournir un widget de prévisualisation. Et de compléter la gestion des options par la même occasion.

Je me demande si ce serait une bonne idée de proposer une liste d'action « Enregistrer », « Imprimer », « Envoyer par courriel », etc. dans flegita, qui décidera de l'action et de résolution de l'image. « Enregistrer » et « Envoyer par courriel » utilisera la résolution de l'écran tandis que « Imprimer » utilisera une plus grande résolution (300 ou 600 ppp). Qu'en pensez-vous ?

Il y aura un plug-in Gimp pour une interface plus complexe (choix manuel de la résolution, compression, couleurs, etc.).

Les liens :
1. Téléchargements: http://bersace03.free.fr/pub/GNOME/Scan/Releases
2. Captures d'écrans : http://bersace03.free.fr/pub/Images/Captures/Gnome/Scan/Fleg(...)
3. L'article plus technique en anglais : http://gnome-scanning.blogspot.com/2006/06/annoucing-gnomesc(...)

J'ai l'intention de vous tenir au courant des améliorations en appuyant plus sur le côté interface que technique afin de ne pas encombrer le site avec des détails techniques sur un projet parmis d'autres.

Voilà.
  • # Addendum: rapporter une bogue.

    Posté par (page perso) . Évalué à 5.

    J'oubliai, si vous trouvez une bogue, contactez-moi à l'adresser bersace03 ad laposte.net . Ce serait chouette de préfixer le courriel avec [gnome-scan] ou un truc du genre.

    Merci.
  • # Pas envoyer par courriel

    Posté par . Évalué à 6.

    J'ai des fonctions similaires sur le scanner de mes parents, on fait exprès de ne pas utiliser le "envoyer par e-mail" à cause de la grosse résolution de la pièce jointe.

    Je dirais « Enregistrer » utilisera la résolution de l'écran ok et
    « Envoyer par courriel » utilisera une résolution telle que l'image scannée sera moins lourde que [x] ko, réglable dans les préférences et étant 500ko par défaut.

    Mieux, laisser le choix à l'utilisateur dans les préférences, avec des préréglages :
    * "petit" (100ko)
    * "normal" (500ko), par défaut
    * "gros" (750ko)
    * "taille réelle"
    * "haute résolution".
    * Personnalisée

    Parce que bon, les pièces jointes d'1 ou 2 mega, c'est pas génial.
    • [^] # Re: Pas envoyer par courriel

      Posté par (page perso) . Évalué à 3.

      C'est clair qu'il faut bien prendre garde à la taille des fichier.

      À priori, une résolution de 96ppp ne sera pas très lourde ! Je viens de faire le test avec le tract RATP de la fête de la musique. En résolution 1:1 sur écran le fichier png pèse 462Ko, 452Ko avec pngcrush et 174Ko avec pngnq. C'est raisonnable !

      Si Flegita compresse en PNG et passe la moulinette à pngnq, je pense que c'est faisable d'utiliser la résolution de l'écran. Ce qui est dommage, c'est que je ne peux pas prédire la taille de l'image compressée. Envoyer une image au ration 1:1 à l'Écran, c'est vraiment un bon point pour une appli. si en plus elle s'occupe d'optimiser l'espace c'est encore mieux pour l'utilisateur !

      Qu'en pensez-vous ?
      • [^] # Re: Pas envoyer par courriel

        Posté par . Évalué à 3.

        Dans ce cas là, si la taille finale est trop importante (supérieure à la limite fixée dans les préférences) :
        "L'image scannée a une taille de xxx mega-octets, ce qui peut-être volumineux pour un envoi par e-mail. Désirez-vous en envoyer une copie de taille réduite ?"


        Avec une liste de choix :
        * "Afficher l'image scannée"
        * "Afficher la copie réduite" (un coup de transform d'imagemagic pour avoir des dimensions inférieure)
        * "Envoyer quand même"
        * "Envoyer la copie"
        * "Enregistrer l'image scanée pour l'éditer manuellement"

        D'une manière générale, il est très important que la résolution considérée pour l'envoi par e-mail ne soit pas systèmatiquement celle fixée arbitrairement par l'utilisateur pour l'enregistrement en local (genre 300 dpi) si ce choix lui est laissé.
      • [^] # Re: Pas envoyer par courriel

        Posté par (page perso) . Évalué à 3.

        "je ne peux pas prédire la taille de l'image compressée"

        tu dois pouvoir approximer... Gimp sait le faire au moment de la sauvegarde...
      • [^] # Re: Pas envoyer par courriel

        Posté par . Évalué à 1.

        Je n'ai pas de scanner, mais en lisant ce commentaire, me vient quelques questions/suggestions.

        Pourquoi vouloir compresser en png ? Le png, c'est bien pour le noir et blanc, ou alors pour les images couleurs codées sur 256 couleurs (en fait, je me base sur les perf du GIF dont le png est proche. Si je dis une connerie sur le png faites moi signe, peut etre que cela differe plus que ce que j'imagine). Cette limitation a 256 couleurs est intrinsèque à l'algo, et ce format d'image ne convient donc pas du tout pour la photo.

        Donc, pourquoi utiliser le png plutot que le jpeg qui est infiniment meilleur pour les photos couleurs (à taille équivalente) ?

        Ensuite, le mieux est surement de proposer le choix, genre :
        "Compression photo" ou "Compression affichette".

        Voila, c'est les questions que je me posais à la lecture des commentaires.
        • [^] # Re: PNG / JPG

          Posté par (page perso) . Évalué à 3.

          Tu dis une connerie : PNG fait beaucoup mieux que GIF : couleurs 32bits, donc avec gestion de la transparence, plus forte compression, qui est non-destructive. Le JPG fait de la compression destructive. Donc aucun des deux n'est le format absolu. Je dirais qu'il faut demander à l'utilisateur s'il veut numériser du texte, une photo, ou un mix des 2. Et automatiquement Choisir respectivement PNG, JPG, ou mode avancé pour le dernier, où on choisit le format avec une description non-informatique.

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: PNG / JPG

            Posté par . Évalué à 2.

            Je me pose une question : est-il possible pour un scanner de scanner une diapositive ou un autre objet en conservant l'information de transparence ?

            Par exemple, si on scanne une paire de lunettes, les verres resteraient transparents.

            BeOS le faisait il y a 15 ans !

            • [^] # Re: PNG / JPG

              Posté par . Évalué à 3.

              Scanner des diapos, c'est possible.
              Certains scanner propose la fonctionnalité, avec un support spécial diapo (ou négatifs photos). Y a un rétro-éclairage blanc il me semble, et donc tu obtiens l'image, un peu comme ce que tu as chez les medecins pour regarder les radios.
              Auncun besoin de détection des zones transparentes pour scanner une diapo.

              au passage, sur les diapos ou les négatifs photos, il n'y a pas vraiment de couche alpha (transparence). La transparence d'une diapo traduit la luminosité et non la transparence de l'image. On n'obtient pas une photo (ou une projection) transparente, même si le négative comporte une zone transparente, mais en revenche plus une zone de la diapo est transparente, plus l'image finale est lumineuse/claire (et inversement pour les négatifs).




              Pour le scan de transparence, à ma connaisance, il n'existe pas de scanner (grand public en tout cas) le permettant. Faire un système de scan prenant en compte la transparence, c'est un peu compliqué parce-que il faut un capteur pour la couleur et la luminosité (le capteur normal), et un autre capteur pour l'opacité (de l'autre coté de l'objet, ou avec un jeu de miroir pour détecter la quantité de lumière passant au travers de l'objet.).


              Par contre, tu peux réussir à retrouvé la transparence en utilisant lors du scan un fond d'une couleur particulière, comme ça se fait au cinéma avec les fond bleu ou vert pour faire des incrustations (on voit ça dans les making-of par exemple). Mais je connais pas de logiciel permetant de prendre ça facilement en compte au niveau des scanners. Le problème de ce système c'est que tu as une couleur dédiée pour la transparence. Donc si dans ton image tu retrouve cette couleur, la zone paraitra transparente, et donc ça peut demander des retouches à la mano. Et je ne sais pas à quel point tu peut avoir des variations dans la transparence (savoir si c'est totalement transparent ou pas du tout, c'est facile : si tu retrouve la couleur exactement, c'est transparent, si tu la retrouve pas du tout c'est opaque. Mais si c'est opaque à 50 ou 70%, c'est plus compliqué).
              Avec Gimp ou Photoshop, il y a moyen de traitée ce genre de choses, mais ça demande du boulot, et du savoir faire.
            • [^] # Re: PNG / JPG

              Posté par . Évalué à 2.

              Je me pose une question : est-il possible pour un scanner de scanner une diapositive ou un autre objet en conservant l'information de transparence ?


              Une opération équivalente à cela serait d'utiliser GIMP avec Filtres -> Couleur -> Couleur vers Alpha et choisir le blanc (couleur de fond du scanner).
              Cela va remplacer tout ce qui est blanc par de la transparence (et les tons proches par quelque chose de moins transparent...)
          • [^] # Re: PNG / JPG

            Posté par . Évalué à 2.

            Ok, merci de m'avoir corrigé. Comme je me basais sur la mauvaise équivalence png=gif, ca fausse tout.

            Donc si je comprends bien, le png fait avec la couleur ce que fait le gif avec le noir et blanc (compression non destructive) .

            Ceci dit, cela confirme quand meme le fait qu'il vaut mieux laisser le choix de la compression suivant qu'on numérise une photo ou pas.
  • # suggestion

    Posté par . Évalué à 10.

    Un truc qui serait sympa mais j'imagine que tu as d'autres priorités pour le moment, ça serait de pouvoir sélectionner plusieurs zones à scanner, histoire d'enregistrer plusieurs images en une seule fois.

    Cela serait une fonctionnalité utile notamment pour scanner plusieurs photos d'un coup. L'idéal serait même d'offrir la possibilité d'une selection automatique via la détection des bords des différentes photos et correction automatique de la rotation (parceque bien positionner les photos sur la vitre du scanner c'est pas évident).

    Comme ça par exemple tu mets 4 photos dans ton scanner, tu lances avec l'option qui va bien et pouf, tu as 4 images sélectionnées automatiquement (et sans avoir à corriger plus tard la rotation). Le tout en une seule étape et sans avoir a retravailler sous Gimp. Franchement le genre de fonctionnalité qui me simpifierait la vie. Par contre c'est pas forcément évident à coder.

    Voilà c'était juste une suggestion en passant.
    • [^] # Re: suggestion

      Posté par . Évalué à 4.

      Une autre suggestion-en-passant : la gestion des boutons en façade du scanner.

      Cf http://lea-linux.org/cached/index/Trucs:Utiliser_les_boutons(...)

      En fait il s'agit surtout de prévoir de lancement direct en ligne de commande, pour lancer le scan et l'impression/l'envoi d'email/la sauvegarde/... dans la bonne résolution. Reste plus ensuite qu'à correctement configurer le script buttonpressed.sh (cf article lea-linux).
      • [^] # Re: suggestion dbus

        Posté par . Évalué à 4.

        Oui, et pourquoi pas une interface dbus pour plus tard (communication inter-applications). Il serait alors simple de rajouter une fonction "numériser" dans un client de messagerie instantannée par exemple. "Je t'envoie le sujet du devoir pour hier", clic sur "numériser un document", puis sur "envoyer le fichier à glandu@jabber.org".

        Bon, peut-être que je rêve là.
    • [^] # Re: suggestion

      Posté par (page perso) . Évalué à 2.

      C'est une super idée.

      Je verrais si je peux implémenter un truc pareil lorsque j'en serai à coder un plugin pour gthumb.

      Il y a aussi Larry Ewing (Aka lewing, embauché par Novell) qui travaille sur f-spot. Il semble vouloir faire une passerelle C# du libgnomescan et peut-être libgnomescanui afin de faire un plugin pour f-spot. Peut-être qu'il implémentera ce genre de fonctionnalité intelligente.
  • # Ne pas répéter les erreurs :)

    Posté par (page perso) . Évalué à 2.

    Salut Étienne,

    ne répète pas les erreurs de libgnomeprint(ui) : dans ta documentation d'API, inclus deux trois exemples simples pour lancer les développeurs qui voudraient utiliser ta lib :)
    • [^] # Re: Ne pas répéter les erreurs :)

      Posté par (page perso) . Évalué à 2.

      Salutations,

      Merci du conseil. Je pensais que libgnomeprintui avait aussi de nombreux problème qui ont par exemple pousser Linus Thorvald à une citation mémorable. :)

      Bon, dans l'état actuel, c'est clair que je vais pas trop documenté, bien que toute les fonctions ai au moins un commentaire. Flegita est suffisament simple pour être un bon tuto, il fait 99 ligne pour la version 0.0.2 !

      Je penserai à produire de la doc.

      Étienne.
  • # bonne idée!

    Posté par (page perso) . Évalué à 2.

    Bravo pour la démarche il est clair que XSane fait franchement tâche sous Gnome...

    Du coup personnellement j'utilises kooka bien plus convial à mon goût.
    Histoire de comparer ce que j'aime / n'aime pas avec kooka:
    + interface globalement simple
    + en particulier selectionner une partie de l'image est très simple
    + prévisualisation de la taille du fichier

    - le fichier est enregistré dans une galerie qu'il faut après exporter (pas trouvé comment le changer si c'est possible)
    - look KDE alors que je suis sous Gnome (bon c'était évident!)

    Je viens d'essayer de compiler sous Ubuntu Dapper masi cela n'a pas marché je t'envois le config.log par mail - je n'ai pas réussi à voir d'où venait l'erreur.

    Au configure j'ai l'erreur suivante:
    ./configure: line 21323: ./po/POTFILES.in: No such file or directory
    • [^] # Re: 0.0.2.1

      Posté par (page perso) . Évalué à 2.

      Salutations,

      Oui, j'ai des soucis avec les autotools.

      J'ai publié une version qui semble-t-il fonctionne bien. la 0.0.2.1.

      Lien direct sur l'archive : http://bersace03.free.fr/pub/GNOME/Scan/Releases/gnomescan-0(...)

      Désolé pour la gêne.
      • [^] # Re: 0.0.2.1

        Posté par (page perso) . Évalué à 1.

        pas de soucis il n'y a aucune gêne!
        La version 0.0.2.1 fonctionne sans soucis une fois le paquet libsane-dev installé.

        Pour info - si cela est utile - le scan a marché sans problèmes avec mon scanner HP PSC 2355.

        Une idée en passant: si un curseur de résolution est implémenté à l'avenir je suggère de l'appeler "qualité de l'image" car "résolution" n'est pas très explicite pour un non spécialiste je trouve.

        Merci et bon courage pour la suite!
  • # Page projet

    Posté par (page perso) . Évalué à 5.

    Vu la vive réactivité du public, je pense qu'il faut que tu fasse évoluer ta gestion du projet.

    A mon avis, il te faut ouvrir une page projet sur Gna ( http://gna.org/ ). C'est rapide (1~2 jours) et tu te retrouve avec une gestion de conf (CVS sou SVN entre autre), une page web projet, des annonces, des mailing-listes...

    Si tu veux un coup de main pour ce genre de truc, contacte-moi, j'en ai fait plein des pages projet.

    De même, je viens de constater que ton projet n'est pas référencé sur FreshMeat ( http://freshmeat.net/ ). Avec ce site, tu peux annoncer toutes tes "release". Audience et visites assurés.
    • [^] # Re: Page projet

      Posté par (page perso) . Évalué à 5.

      J'y ai pensé, mais c'est encore trop tôt. D'abord, dans le cadre du projet Google SoC, je doit être seul à coder, donc, bzr en local me suffit pour le moment. Ensuite, à la fin du SoC, le code à des chance de partir dans le CVS de Gnome.

      J'utilise le wiki de Gnome etc. J'ai l'intention d'intégrer le plus ce projet à Gnome et non d'être un projet satellite.

      Merci.

      Étienne.
      • [^] # Re: Page projet

        Posté par (page perso) . Évalué à 2.

        OK, je ne connaissais pas les contraintes de SoC.

        Etudie néanmoins la diffusion via FreshMeat. Cela te permettra de récolter des utilisateurs/testeurs, denrée fort utile pour les logiciels libres.
  • # Postez vos idées

    Posté par (page perso) . Évalué à 2.

    ... sur http://live.gnome.org/GnomeScanning/Ideas

    Ça me permettra de faire le tri et d'implémenter ce qui est interressant.

Suivre le flux des commentaires

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