Scanners : une nouvelle version de sane et un rapide tour d'horizon

Posté par (page perso) . Modéré par tuiu pol.
Tags :
25
28
avr.
2010
Matériel
SANE est l'acronyme de Scanner Access Now Easy (Accès au scanner à présent facile).

Une nouvelle version, la 1.0.21 vient de sortir. Parmi les nouveautés :
  • Trois nouveaux backends (kodak, kvs1025 pour Panasonic et p5 pour Primax PagePartner) ;
  • 224 nouveaux modèles gérés ;
  • Prise en charge de HAL et udev mis à jour ;
  • Uniformisation des noms;
  • Compilation facilitée sur des architectures peu courantes;
  • Mise à jour de la documentation;
  • Correction de bugs et multiples améliorations de détail.

La liste des 1777 matériels référencés est particulièrement importante car elle montre que de trop nombreux matériels ne peuvent pas fonctionner hors de la configuration Windows avec laquelle ils ont été vendus. C'est un déni d'interopérabilité.
Il est donc important de consulter cette liste avant l'acquisition d'un scanner. Toutefois, certains modèles non gérés par les backends de SANE fonctionnent fort bien sous Linux avec des pilotes fournis par le constructeur. C'est le cas des imprimantes multifonction de HP où le pilote est installé en même temps que l'imprimante. C'est pourquoi la compatibilité doit être recherchée sur openprinting.org. Le cas d'Epson est un peu différent car les pilotes Epkowa sont réalisés par Avasys, une filiale d'Epson.

Sane peut être utilisé avec de nombreux frontends. On peut citer scanimage, scangui ou Xsane qui est l'interface graphique la plus utilisée. Il ne faut pas oublier le très commode xsane-gimp qui permet de scanner et importer un document depuis Gimp avec Fichier -> Créer -> Xsane: Device dialog...

NdM : Merci à ille qui avait proposé un article sur sane 1.0.21. Note : Comme indiqué en anglais sur la page d'accueil de sane, il manque deux fichiers dans l'archive tar.gz de sane-backends v1.0.21.
Il faut donc télécharger en plus sane-backends-1.0.21-i18n.patch et l'appliquer aux sources :

cd sane-backends-1.0.21
patch -p1 < sane-backends-1.0.21-i18n.patch

Ensuite configure et make comme d'habitude.

Dans une configuration Mandriva 2010, on trouve :
# rpm -qa "*sane*"
sane-backends-1.0.20-8.1mdv2010.0
xsane-0.996-3mdv2010.0
xsane-gimp-0.996-3mdv2010.0
lib64sane-hpaio1-3.9.12-1mdv2010.0
lib64sane1-1.0.20-8.1mdv2010.0
lib64ksane0-4.3.5-0.4mdv2010.0
sane-frontends-1.0.14-7mdv2010.0
sane-backends-iscan-1.0.20-8.1mdv2010.0

Heureusement, les dépendances gérées par urpmi font que ça s'installe tout seul.
  • # Scan en réseau

    Posté par . Évalué à 2.

    En parlant d'Epson, j'ai justement eu une imprimante multifonctions, il y a peu, la SX400 je crois.

    J'ai testé de scanner avec SANE par le réseau et sous Linux mais je n'y suis pas parvenu. L'imprimante est reliée à un petit boîtier en USB et ce boîtier dispose d'un port RJ45 et d'une antenne Wifi.

    Sur MacOS, il faut se connecter à ce boîtier par son IP et hop, on numérise. Je n'ai pas réussi sous Linux par le réseau tandis qu'en USB, cela fonctionne.

    S'il y a des personnes qui ont réussi à scanner par le réseau et aurait un tutoriel sous le coude, je suis preneur.

    • [^] # Re: Scan en réseau

      Posté par . Évalué à 4.

      Salut dest,
      Question peut être bête : es tu sûr d'avoir choisi le bon driver ?
      Je demande ça car sur le site de avasys c'est un peu le bronx, on dirait un site de pilotes pour windows, et n'ayant plus l'habitude il m'est arrivé plus d'une fois de me gourrer (surtout si l'epson fait partie d'une classe et n'a pas directement son modèle répertorié).

      La sx400 fait partie de la classe, de la famille "NX400/SX400/SX405/TX400/TX409".
      Pour le scan en réseau ça fonctionne sans problème chez moi (un autre modèle) avec leur "Image Scan for Linux" (qui est par aileurs très simple et confortable d'emploi). Pour ton modèle, y aussi un "questionnaire", choisir : "network print/scan direct to printer/scan" je sais pas si ça change qq chose... ?)

      Doit être sympa ce modèle...
      • [^] # Re: Scan en réseau

        Posté par . Évalué à 2.

        Salut Tankey !

        Je t'avoue que ce n'est plus très frais dans ma tête parce que ça fait quelques mois que je m'en suis occupé.

        Autrement oui, j'ai été sur leur site et même installé leur deb mais ça ne fonctionne pas.

        En désespoir de cause, j'ai même contacté le support technique qui n'a rien fait d'autre que de me rediriger vers la page d'Avasys.

        Autant l'impression en réseau, c'est simple et ça fonctionne rapidement mais alors le scan en réseau, c'est une autre paire de manches.

        Si vous êtes plusieurs à plébisciter (c'est peut-être un peu fort) le site d'Avasys, alors j'ai peut-être loupé une étape.

        Et t'as raison Tankey, c'est clairement un site qui a un look & feel de driver Windows.
        • [^] # Re: Scan en réseau

          Posté par Anonyme . Évalué à 3.

          Un petit coup de Wireshark pour voir si la requête de scan part au scanner ?
          Peut-être essayé aussi de comparer avec les requêtes effectuées depuis Mac OS X ?

          Ça ne résoudra pas le problème en tant que tel, mais ça permettra de savoir si le boulot essaye de faire son job au moins.
          • [^] # Re: Scan en réseau

            Posté par Anonyme . Évalué à 1.

            Jamais posté quand on est fatigué
            '... ça permettra de savoir si le pilote essaye de faire son job ...'
    • [^] # Re: Scan en réseau

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

      Salut,

      Je cherche ce genre de matériel, quel est le modèle ?

      Il manque seulement un support réseau plus complet à Sane !
  • # Un protocole commun

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

    Je crois qu'il manque surtout un protocole commun, pour les scanners. Après tout, commander un scanner, c'est :
    – Salut scanner, tu as quoi comme réglages disponibles ?
    – Alors, on peut choisir ma définition, parmi 100, 200 et 300 dpi, on peut aussi choisir le temps d'exposition, et puis aussi…
    – Super, alors envoie-moi l'image entre (0, 0) et (42, 12) en 100 dpi à telle exposition…
    – Voilà !
    – Merci, maintenant, l'image entre (1, 2) et (41, 10) en 300 dpi…
    – Voilà !

    Ce n'est pas comme s'il y avait besoin de d'avantage de spécificités…
    • [^] # Re: Un protocole commun

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

      "Ah ouiii mais moi vous comprenez, je suis un constructeur bien meilleur que les autres. J'ai du matériel qui numérise super bien, et si je fais confiance à la plèbe pour gérer mes merveilleux scanners ça ne va pas aller du tout. Tu comprends, j'ai la gestion de l'envoi par email, le stockage des images dans la mémoire du scanner, le bouton Windows pour photocopier, et parfois l'introducteur automatique de documents. Alors votre pilote standard, ça me fait bien rigoler."

      Ils disent exactement pareil pour les imprimantes, alors qu'un vieux pilote pourri en PCL ou PS fonctionne parfaitement (oui bon, pas avec le recto-verso, la sélection des bacs, etc. Mais l'impression tout court c'est tout de même 95% du besoin).

      Et puis franchement, j'imagine que je suis fabriquant de scanners. Je file la doc, je file les source de mon premier pilote... et désormais je n'ai plus _jamais_ à coder un pilote. Je fais mon job de fabricant, je fais des économies, ça me fait de la pub. Et je me demande bien comment mes concurrents sont assez stupides pour ne pas avoir fait la même chose.
      • [^] # Re: Un protocole commun

        Posté par . Évalué à 3.

        Parce qu'eux non plus n'ont pas envie de licencier tous leurs développeurs ?
        Et c'est aussi comme les cycles des dentifrices ou shampooings.

        Mais c'est vrai que dans l'ensemble, ça pue de la gueule et ça a le cheveu terne. Donc autant les mettre dehors.

        ( Comment ? Quoi ? Comprends pas ! Provocation ? Rhoo ! Mais ça ne veut rien dire ! )
        ( La provocation, je veux dire )
        ( Pas la gestion d'une troupe de développeurs deux en un )

        Et toi, tu scannes ou tu trimes ? ^.^
      • [^] # Re: Un protocole commun

        Posté par . Évalué à 3.

        Histoire de pinailler.

        En entreprise (l'essentiel de l'usage des imprimantes), un driver "bien configuré" permet de faire du recto-verso et de sauver des arbres (les expérimentations montrent que les impressions en recto seul sont alors très rares, l'économie de papier approche les 50%).

        Un driver qui gère les bacs permet d'imprimer par défaut sur du papier recyclé et de conserver le beau papier blanc pour les impressions "importantes".

        Moralité : un driver qui fait plus sur du PCL/PS est nécessaire pour être éco-durable-compliant.

        BeOS le faisait il y a 15 ans !

        • [^] # Re: Un protocole commun

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

          les expérimentations montrent que les impressions en recto seul sont alors très rares
          Sur notre parc d'environ 60 imprimantes et multifonctions avec recto-verso, nous avons moins de 5% d'impression sur deux faces. C'est même plutôt du genre 0% sur 50 d'entre elles :-)
          Les imprimantes sont configurées en double. Une en recto, une en recto-verso. Pour des raisons "pratiques" les impressions sont par défaut en recto. Presque personne ne souhaite le recto-verso par défaut. Je n'ai pas compris pourquoi (de même que tout le monde est en majuscules dans les logiciels de compta et de gestion, gros mystère).
          • [^] # Re: Un protocole commun

            Posté par . Évalué à 3.

            > Pour des raisons "pratiques" les impressions sont par défaut en recto. Presque personne ne souhaite le recto-verso par défaut. Je n'ai pas compris pourquoi (de même que tout le monde est en majuscules dans les logiciels de compta et de gestion, gros mystère).

            - Quand un tableau est coupé on peut le lire quand même d'un coup d'œil en posant les feuilles cote à cote.

            - Le verso sert de brouillon quand il n'y a pas de cahiers fournit en nombre suffisant.

            Pour la compta, je ne sais pas, une hypothèse : des gens de la compta travaillent peut être avec des portables ou des claviers sans pavé numérique (d'où le caps-lock enclenché pour avoir les chiffres toujours dispo peut être) ?
        • [^] # Re: Un protocole commun

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

          J'ai pas compris en quoi on ne pouvait pas aussi standardiser la gestion du recto-verso. Quelqu'un pour m'expliquer ?
          • [^] # Re: Un protocole commun

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

            Il parlait sans doute de l'émulation manuelle du recto-verso : imprimer les faces paires, retourner, imprimer les faces impaires.

            Inutilisable en entreprise, où des travaux d'impressions sont lancés à la chaîne par plusieurs personnes, de toute façon.
            • [^] # Re: Un protocole commun

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

              Inutilisable en entreprise, où des travaux d'impressions sont lancés à la chaîne par plusieurs personnes, de toute façon.

              Et où deux fois sur trois l'impression traîne dans le bac jusqu'à ce que quelqu'un vienne faire le ménage.
      • [^] # Re: Un protocole commun

        Posté par . Évalué à 3.

        Et puis franchement, j'imagine que je suis fabriquant de scanners. Je file la doc, je file les source de mon premier pilote... et désormais je n'ai plus _jamais_ à coder un pilote. Je fais mon job de fabricant, je fais des économies, ça me fait de la pub. Et je me demande bien comment mes concurrents sont assez stupides pour ne pas avoir fait la même chose.

        ça ne marche pas comme modèle. Quand tu fabriques un matos tu es obligé de fournir un pilote et de le maintenir. Tu ne peux pas te permettre de dépendre de quelqu'un d'autre et d'attendre son bon vouloir pour que ton produit soit fonctionnel.
        Je le vois bien déjà dans le monde pro en s'adressant à des boîtes qui font du dev. On a essayé de juste fournir le matos avec les API les docs pour permettre à nos clients de développer selon leurs spécificités sur notre matos. Résultat:
        « - ah vous ne fournissez pas de pilote ?
        - euh non mais vous avez des exemples.»
        Ils essaient et peu de temps après ils appellent le support parce que ça ne fonctionne pas. Tu te tapes donc beaucoup de support pour réussir à faire fonctionner leur code. Bref au final on écrit des pilotes complets que l'on maintient et c'est bien plus simple comme cela.
        Donc penser que l'on peut fabriquer du matos sans jamais avoir à coder des pilotes me semble une utopie. Mais cela n'empêche pas de fournir les moyens pour ceux qui veulent coder leur propre version bien sur.
        • [^] # Re: Un protocole commun

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

          En même temps, pour une imprimante PostScript, ça ne coûte pas bien cher d'écrire un PPD. Et ensuite, ça ne coûte plus rien puisqu'il n'y a aucune raison de le modifier.
        • [^] # Re: Un protocole commun

          Posté par . Évalué à 6.

          Sauf que si ça respecte le standard, le pilote a déjà été écrit il y a 10 ans et ton scanner marche avec !
        • [^] # Re: Un protocole commun

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

          J'ai pourtant précisé: je file les source de mon premier pilote
      • [^] # Re: Un protocole commun

        Posté par . Évalué à 1.

        On pourrais imaginer que dans les drivers il y ait autre chose que le simple envoie d'un postcript, mais également toute la gestion de étalonnage des couleurs, d'analyse de l'image pour economiser de l'encre etc etc.
        Je dis ca j'en sais rien, mais déporter tous ces calculs vers le pc plutôt que dans l'imprimante me parait pertinent.
        Je dis pas qu'ils le font attention, mais si c'était le cas ca expliquerait pourquoi non, ils ne peuvent pas rendre les drivers aussi 'simple'
    • [^] # Re: Un protocole commun

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

      Le dialogue est un peu plus compliqué : taille du scanner (ils ne sont pas tous A4 !), coordonnées de la zone à scanner, résolution disponible, résolution demandée...

      Il y a bien TWAIN voir http://www.twain.org/ : Selon http://www.sane-project.org/intro.html ce protocole a le défaut de ne pas séparer l'interface avec le matériel de l'interface avec l'utilisateur. Grave défaut, à vrai dire que de ne pas séparer backend et frontend car le fondement de l'interopérabilité consiste à spécifier les interfaces.
      • [^] # Re: Un protocole commun

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

        Il n'est pas « un peu plus compliqué » : les coordonnées de la zone à scanner et la résolution, je les ai inclus dans mon exemple. La taille numérisable, non, en effet, c'est un oubli. Mais bref, ce n'est pas très compliqué, comme échange.
    • [^] # Re: Un protocole commun

      Posté par . Évalué à 4.

      Est-ce certain que tous les scanners fournissent une interface de si haut niveau ? Ni y en a-t-ils pas qui déportent tout le pilotage des déplacements sur la machine hôte ?
      • [^] # Re: Un protocole commun

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

        Je dirai que non (au doigt mouillé) vu que la tendance est à la "boîte-noirisation" du matériel pour n'exposer qu'une interface de relativement haut niveau.
        • [^] # Re: Un protocole commun

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

          AMA ça dépend de la gamme de scanner.

          Pour le vulgus scanner commun, la tendance est à l'abaissement des coûts, et l'électromécanique vendue doit être minimale, avec des capacités en calcul et stockages très réduites... tout est alors dans le driver sur la machine cliente, et le matériel a une interface de très bas niveau.

          Pour le (très) haut de gamme, ça doit être un morceau d'intelligence de photocopieur numérique extrait pour n'en retenir que le scanner, et dans ce cas en effet l'interface fournie est plus balèze.
          • [^] # Re: Un protocole commun

            Posté par . Évalué à 4.

            J'ai l'expérience d'un appareil pour particulier (commun il y a 10 ans) : AGFA "Snapscan Touch". Il est bien reconnu par Sane et donne des résultats assez satisfaisants.

            Cependant, ça sent l'ingénierie inverse et l'approximation. De fait, sous Windows, j'obtenais le scan en une passe à la résolution de 150 dpi. Désormais, c'est par paliers de 1,5 cm (au jugé) qu'il avance. De temps en temps, le retour du chariot à la position rangée fait un bruit relativement fort, qui m'inquiétait fut un temps, mais visiblement, le scanner marche toujours aussi bien. De plus le CPU consommé est plus conséquent que sous Windows (AMD 500 Mhz sous Win à l'époque (je n'ai pas le souvenir de mes constats de l'activité CPU) ; P3 650 Mhz sous Fedora 9 désormais (Gkrellm m'indique que 85 % du CPU est consommé, en gros) car j'observe que la moindre opération pendant le scan peut générer une pause dans l'activité mécanique du scanner, ce qui n'était pas le cas sous Win, mais cet artéfact peut provenir de l'OS pour partie.

            L'interface xsane est assez ergonomique à mon goût.

            Enfin, les résultats, au final, sont parfaits, à ceci près qu'il m'est arrivé (très rarement) d'observer un petit décalage parasite sur le résultat du scan, lors d'un de ces arrêts du chariot intempestifs sur une action logicielle gourmande sur le PC. Ceci dit, j'ignore ce genre de conséquence néfaste de l'artéfact dans mon usage courant. Je l'ai bien observé et il ne me gène pas pour ce que je fais. Lorsque je veux un très bon résultat, en poussant par exemple à 300 dpi, je veille à ne pas m'activer sur le "vieux" PC qui pilote le scanner et éventuellement je contrôle le résultat (travail laborieux, quand même).

            Bravo à (aux) l'auteur(s) de sane/xsane, en tout cas.
            • [^] # Re: Un protocole commun

              Posté par . Évalué à 2.

              Je m'étais pourtant relu, mais j'y reviens un chouilla, en considérant que mon expérience largement détaillée pourra aider d'autres utilisateurs.

              Précision sur le retour du chariot à la position rangée qui fait un bruit relativement fort : c'est en butée que ça se produit, dans environ 0,01 % des cas (oui, j'aime bien mon scanner), et encore !

              J'écris que la moindre opération pendant le scan peut générer une pause dans l'activité mécanique du scanner. Ce n'est donc pas systématique (à l'usage, je sais bien quelle activité va déclencher cet arrêt, et je le répète, ça m'indiffère) et c'est bien sûr fonction de la relativement faible puissance du PC qui pilote.

              voilà.
  • # HAL?

    Posté par . Évalué à 6.

    Prise en charge de HAL et udev mis à jour

    Il me semble que HAL est sur le point de disparaitre. J'espere que la mise a jour en question est une preparation a sa mort annonce.
    • [^] # Re: HAL?

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

      J'espère au contraire que HAL ne va pas disparaître trop vite dans Sane. Sinon, comment faire pour le mettre à jour sur une Debian woody (stable depuis fin 2008), quand on achète un nouveau scanner? ou sur une RedHat 3, 4 ou 5? ou sur ... etc.? sans parler d'un tas de systèmes embarqués, impossible à mettre à jour comme ça.
      Ça n'a aucun sens ce que tu dis. En milieu professionnel on a besoin de technologies supportées longtemps. La rétro-compatibilité est nécessaire.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: HAL?

        Posté par . Évalué à 4.

        c'est une bonne remarque en effet. Je dois avouer que je n'y avais pas pense mais j'espere tout de meme qu'il y a du boulot pour que cela fonctionne aussi sans HAL car TOUTES les distributions sont en train de travailler pour s'en debarasser.

        En meme temps par rapport a ta remarque sur l'embarque je croyais que justement c'etait une des raisons de la mort annonce de HAL.
        • [^] # Re: HAL?

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

          Excuse-moi, à me relire, c'était un peu agressif.

          Pour l'embarqué, je parlais de ce qui est déjà en place, et qui ne peut (ou alors difficilement) être totalement mit à jour par les dévs. Mais à bien y réfléchir, c'était assez stupide de ma part.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: HAL?

            Posté par . Évalué à 2.

            Excuse-moi, à me relire, c'était un peu agressif.

            pas grave je ne suis pas (trop) succeptible.

            Un remarque je ne suis pas sur que l'embarque et un sane c'est tres compatible maintenant c'est vrai que l'on peut imaginer un des mini ordi sous android avec sane installe (je ne sais pas du tout si cela pourrait fonctionner c'est une hypothese) mais me servir de mon telephone pour brancher mon scanner je trouve que c'est un peu pousse. Mais je suis un vieux c... et pour moi un telephone cela doit avant tout me permettre de ... telephoner pas de faire le cafe!!!!
  • # Un meilleur support que sous widows

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

    En fait, avec plus de 1700 scanners supportés directement plus ceux pour lesquels les fabricants fournissent des pilotes, on en arrive à un bien meilleur support des périphériques de ce type que sur l'OS concurrent pour les postes de travail. Qui n'a pas été appelé en renfort de nombreuses fois pour des problèmes comme : mon scanner acheté il y a deux ans ne fonctionne pas avec mon nouvel ordi sous wintrucXY alors qu'il fonctionnait parfaitement sous fenêtresZHPW…

    Au final, ces politiques imbéciles des constructeurs finissent par favoriser le libre. Au troisième changement de scanner — à qualité constante puisque les progrès dans le domaine sont loin d'être notables ces dix dernières années — pour cause de problèmes de pilotes, la plus part des gens finissent par écouter la petite voix qui leur susurre de changer de voie. Pourquoi ne pas essayer un système d'exploitation qui évite toute cette pollution, ces dépenses, ces efforts inutiles et qui en plus ne coûte rien ? Après tout ?
    • [^] # Re: Un meilleur support que sous widows

      Posté par . Évalué à 4.

      Je pertinente, mon scanner mustek, dont la résolution et la qualité est largement suffisante pour mon usage personnel (ce qui revient à dire qu'il numérise des feuilles A4 lisibles) n'a de drivers que pour windows 95-98 et 2000.

      Pourtant il rend toujours le même service depuis des années sur mes machines puisqu'elles sont équipées d'un OS propre.
      • [^] # Re: Un meilleur support que sous widows

        Posté par . Évalué à -2.

        Mon scanner espon gt7000 (datant d'avant 2000) fonctionne toujours sous Windows Seven...
        Certes ca a pas ete out of the box, mais j'ai pas du taper de ligne de commande non plus.
        Ton OS propre par contre, j'arrive pas a faire marcher une vieille webcam chinoise dessus....

        Bref....balle au centre.
  • # Minolta scan dual II

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

    1700 scanners annoncés, mais pas tous fonctionnels, ou alors j'ai rien compris.
    Je m'acharne depuis 10 ans, à faire fonctionner un scan dual II avec sane.
    Depuis quelques années il est annoncé comme fonctionnel mais je n'ai jamais réussi à obtenir une image.
    Si quelqu'un y est arrivé, je suis preneur de toute info.
    • [^] # Re: Minolta scan dual II

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

      C'est ton scanner qui est mort :o
    • [^] # Re: Minolta scan dual II

      Posté par . Évalué à 4.

      Quand j'ai acheté mon scan dual II, j'ai aussi bataillé un bon bout de temps avec sane avant de pouvoir en sortir quelque chose.

      De mémoire, il fallait allumer le scanner porte fermée, lancer une commande sane qui l'initialise, ouvrir la porte et insérer le porte négatifs, et entrer la commande sane qui va bien pour numériser.

      Désolé, je n'ai rien de plus précis et il est possible que je me trompe... De toute façon, j'ai abandonné sane après trois essais tellement c'était mal fichu et les interfaces mauvaises. Ça a peut-être changé depuis, mais VueScan est infiniment meilleur à tous points de vue pour scanner des négatifs, à l'époque (il y a 1 an) en tout cas.
      • [^] # Re: Minolta scan dual II

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

        VueScan est infiniment meilleur à tous points de vue pour scanner des négatifs

        C'est bien mon avis aussi, et j'ai beaucoup de mal à comprendre une telle différence de qualité et d'ergonomie.
        Je refuse de croire que les dèvs de sane soient moins compétents que Hamrick mais ça y ressemble quand même fortement...
        • [^] # Re: Minolta scan dual II

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

          Peut être que Hamrick a signé des accords avec les constructeurs pour avoir accès aux spécifications ?

          On a le même truc avec turboprint qui propose des drivers pour imprimantes pour Linux.
          • [^] # Re: Minolta scan dual II

            Posté par . Évalué à 1.

            Si tu regardes pour les scanners récents j'ai l'impression que sieur Hamrick ne développe plus de pilote mais utilise soit les pilotes du constructeur soit sane, non?
          • [^] # Re: Minolta scan dual II

            Posté par . Évalué à 2.

            Le problème n'est pas tant le support des divers modèles de scanners que l'ergonomie de l'interface et la possibilité d'avoir un workflow correct pour scanner plus d'un négatif à la fois.
  • # Pas besoin de drivers

    Posté par . Évalué à 3.

    Les scanners réseaux professionnels utilisent généralement SMB/FTP ou l'e-mail avec SMTP pour envoyer les documents scannés. L'avantage est que cela ne nécessite aucun driver et donc permet de scanner vers n'importe quelle plateforme.
    • [^] # Re: Pas besoin de drivers

      Posté par . Évalué à 2.

      Et puis qui dit réseau dit partage et donc il vaut mieux être devant le scanner pour lancer une numérisation que devant son ordinateur...
    • [^] # Re: Pas besoin de drivers

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

      Ce ne sont plus de vulgaires scanners, car il y a dans ces machines tout le nécessaire pour traiter les données brutes en pdf, jpeg, tiff, couleur ou n&b, etc.

      On est loin du simple scanner à plat du particulier
    • [^] # Re: Pas besoin de drivers

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

      Moi, au boulot, ce sont les photocopieurs qui scannent donc plus de scanner !

      Je vois pas trop l'intérêt d'un << scanner professionnel >> sauf dans le cadre d'un atelier de reprographie.
  • # Tour d'horizon

    Posté par . Évalué à 3.

    Merci beaucoup pour ce tour d'horizon. Ca fait le 2e en peu de temps et c'est bien sympa à lire.

    En effet pour ma part je n'utilise pas de scanner, mais si je dois parler Linux autour de moi, c'est toujours sympa de pouvoir répondre à quelqu'un qui me demande "il est bon le support des scanners" ?
    • [^] # Re: Tour d'horizon

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

      c'est toujours sympa de pouvoir répondre à quelqu'un qui me demande "il est bon le support des scanners" ?

      Sauf qu'en général, par support des scanners, les gens incluent généralement la solution d'OCR qui va avec, et c'est là qu'est l'OS...
      • [^] # Re: Tour d'horizon

        Posté par . Évalué à 2.

        Bof, les gens qui utilisent l'OCR sont une minorité.

        La plupart des gens qui ont un scanner, c'est pour garder une copie électronique de papiers importants pour les envoyer par email et/ou de faire des photocopies à la maison.
        • [^] # Re: Tour d'horizon

          Posté par . Évalué à 2.

          Justement, une copie électronique avec recherche de texte dans le PDF, c'est typiquement ce dont j'ai besoin...
          Du coup, j'ai une VirtualBox windows pour faire tourner mon scanner/imprimante HP. C'est juste un overkill (en plus le soft est bien pourrave. Heureusement que l'OCR est là)

Suivre le flux des commentaires

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