[diapublications dans deux groupes, suivi vers fcolc seul, mais
il vaudrait peut-être mieux choisir fcal -- changez le suivi si
ça vous semble préférable]
Bonjour,
J'ai numérisé des recueils de partitions afin d'en faire des PDF
imprimables pour un ensemble vocal(¹). Le scanner me permet de
numériser les pages deux par deux, et il crée un PDF d'une page
par scan (sauf une fois où, sans que je comprenne pourquoi, il
a mis deux résultats de scan dans un PDF de deux pages).
Bref, pour un recueil de 7 pages, j'obtiens par exemple quatre PDF
contenant ceci :
Je voudrais savoir ce que vous me conseilleriez, sur Linux, pour le
faire le plus simplement possible. Vu que certains recueils peuvent
avoir beaucoup de pages, si c'était possible avec un outil en ligne
de commande plutôt qu'avec un cliquodrome ce serait encore mieux
(mais si ça n'existe pas, tant pis).
Pour fixer les idées, voici un exemple d'un PDF obtenu en sortie de
numérisation : <http://www.cjoint.com/15mi/EEvxS4BptI5_doc49.pdf>.
Cordialement,
--
Olivier Miakinen
Note (¹) : Pour ceux qui s'en inquièteraient, ce n'est pas illégal. En
effet, l'ensemble vocal a signé une convention avec la SEAM permettant,
avec un abonnement dépendant du nombre de choristes, d'acheter une seule
partition et d'en faire autant de photocopies qu'il y a de choristes :
<http://www.seamfrance.fr/les-conventions/chorales/>.
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à partir des JPEG, pdfTeX est probablement le plus simple.
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en début et en fin de PDF).
-> 79 687 d.png
$ convert c.jpg c.pdf -> 114 949 d.pdf
Ça semble incohérent.
Je suppose qu'il y a une coquille (convert d.png d.pdf). L'écart PNG-PDF est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas contenir de PNG tel quel et convert passe par un intermédiaire, peut-être du JPEG (convert d.png d.jpg pourrait nous renseigner).
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 28 mai 2015, Nicolas George a écrit :
-> 897 805 c.jpg
$ convert c.jpg c.pdf
-> 900 078 c.pdf
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour
stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à
partir des JPEG, pdfTeX est probablement le plus simple.
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est
assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en
début et en fin de PDF).
-> 79 687 d.png
$ convert c.jpg c.pdf
-> 114 949 d.pdf
Ça semble incohérent.
Je suppose qu'il y a une coquille (convert d.png d.pdf). L'écart PNG-PDF
est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas
contenir de PNG tel quel et convert passe par un intermédiaire, peut-être
du JPEG (convert d.png d.jpg pourrait nous renseigner).
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à partir des JPEG, pdfTeX est probablement le plus simple.
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en début et en fin de PDF).
-> 79 687 d.png
$ convert c.jpg c.pdf -> 114 949 d.pdf
Ça semble incohérent.
Je suppose qu'il y a une coquille (convert d.png d.pdf). L'écart PNG-PDF est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas contenir de PNG tel quel et convert passe par un intermédiaire, peut-être du JPEG (convert d.png d.jpg pourrait nous renseigner).
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Nicolas George
Lucas Levrel , dans le message , a écrit :
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en début et en fin de PDF).
Oui, mais pour que ce soit le cas, il faut que l'outil soit spécifiquement prévu pour. Un outil de manipulation d'image de base va décomprimer l'image d'entrée, oublier que c'était du JPEG, puis décider arbitrairement d'un format pour stocker le bitmap dans le PDF.
Je suppose qu'il y a une coquille (convert d.png d.pdf). L'écart PNG-PDF est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas contenir de PNG tel quel et convert passe par un intermédiaire, peut-être du JPEG (convert d.png d.jpg pourrait nous renseigner).
Pourtant si, le PDF supporte la compression du PNG, via FlateDecode. Il ne faut pas faire confiance à ImageMagick.
Lucas Levrel , dans le message
<alpine.LSU.2.10.1505281006170.4299@coulomb.u-pec.fr>, a écrit :
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est
assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en
début et en fin de PDF).
Oui, mais pour que ce soit le cas, il faut que l'outil soit spécifiquement
prévu pour. Un outil de manipulation d'image de base va décomprimer l'image
d'entrée, oublier que c'était du JPEG, puis décider arbitrairement d'un
format pour stocker le bitmap dans le PDF.
Je suppose qu'il y a une coquille (convert d.png d.pdf). L'écart PNG-PDF
est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas
contenir de PNG tel quel et convert passe par un intermédiaire, peut-être
du JPEG (convert d.png d.jpg pourrait nous renseigner).
Pourtant si, le PDF supporte la compression du PNG, via FlateDecode. Il ne
faut pas faire confiance à ImageMagick.
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en début et en fin de PDF).
Oui, mais pour que ce soit le cas, il faut que l'outil soit spécifiquement prévu pour. Un outil de manipulation d'image de base va décomprimer l'image d'entrée, oublier que c'était du JPEG, puis décider arbitrairement d'un format pour stocker le bitmap dans le PDF.
Je suppose qu'il y a une coquille (convert d.png d.pdf). L'écart PNG-PDF est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas contenir de PNG tel quel et convert passe par un intermédiaire, peut-être du JPEG (convert d.png d.jpg pourrait nous renseigner).
Pourtant si, le PDF supporte la compression du PNG, via FlateDecode. Il ne faut pas faire confiance à ImageMagick.
Lucas Levrel
Le 28 mai 2015, Olivier Miakinen a écrit :
Mais j'ai aussi un autre problème : les fichiers images (pbm d'abord, puis JPEG ou PNG ensuite), sont notablement plus gros que le PDF d'origine, et le PDF résultant l'est encore plus !
Je pense que tu n'aurais pas ce problème avec les outils que je t'ai indiqués. Mais tu n'aurais pas la possibilité de tourner les pages. Pour ça il faudrait un code TeX avec des includegraphics, c'est plus lourd, mais vu que tu fais déjà une série d'opérations manuelles par page... Et puis tu n'aurais plus que trois étapes : déterminer les angles de rotation, écrire le source, compiler. La troisième étant triviale et la seconde pouvant se faire avec l'aide des gentils participants de fctt !
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 28 mai 2015, Olivier Miakinen a écrit :
Mais j'ai aussi un autre problème : les fichiers images (pbm d'abord,
puis JPEG ou PNG ensuite), sont notablement plus gros que le PDF
d'origine, et le PDF résultant l'est encore plus !
Je pense que tu n'aurais pas ce problème avec les outils que je t'ai
indiqués. Mais tu n'aurais pas la possibilité de tourner les pages. Pour
ça il faudrait un code TeX avec des includegraphics, c'est plus lourd,
mais vu que tu fais déjà une série d'opérations manuelles par page... Et
puis tu n'aurais plus que trois étapes : déterminer les angles de
rotation, écrire le source, compiler. La troisième étant triviale et la
seconde pouvant se faire avec l'aide des gentils participants de fctt !
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Mais j'ai aussi un autre problème : les fichiers images (pbm d'abord, puis JPEG ou PNG ensuite), sont notablement plus gros que le PDF d'origine, et le PDF résultant l'est encore plus !
Je pense que tu n'aurais pas ce problème avec les outils que je t'ai indiqués. Mais tu n'aurais pas la possibilité de tourner les pages. Pour ça il faudrait un code TeX avec des includegraphics, c'est plus lourd, mais vu que tu fais déjà une série d'opérations manuelles par page... Et puis tu n'aurais plus que trois étapes : déterminer les angles de rotation, écrire le source, compiler. La troisième étant triviale et la seconde pouvant se faire avec l'aide des gentils participants de fctt !
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Olivier Miakinen
Bonjour,
Le 28/05/2015 09:28, Nicolas George m'a répondu :
Quel format me conseilles-tu ? En particulier, est-ce que ceux qui reliront mes PDF créés à partir d'images dans un format autre que JPEG n'auront pas de problèmes, même s'ils sont sur Windows ou Mac ?
Habituellement mon format de prédilection pour les images est le PNG, mais comme Nicolas Richard m'avait donné des exemples en JPEG je n'ai pas cherché plus loin.
Je pense que tu aurais besoin de te documenter un peu sur la différence entre image bitmap et image vectorielle, et ensuite sur la différence, pour les images bitmap, pour les formats compressés avec pertes et les formats sans pertes (compressés ou non compressés).
Certainement, je ne demande qu'à apprendre. J'ai toujours pensé que le JPEG est un format de compression d'image bitmap avec pertes, le PNG un format de compression d'image bitmap sans pertes, et le PBM un format d'images bitmap non compressées. Quant aux images vectorielles, je n'y connais rien du tout, mais je pensais naïvement que ça ne pouvait pas être utile pour représenter le résultat d'une numérisation par scanner.
J'ajoute que, vu que le but de la manœuvre est de donner une partition musicale lisible et pas de reproduire fidèlement une œuvre picturale, il ne me semblait pas très grave d'utiliser un format avec pertes plutôt qu'un format sans pertes.
Maintenant, si je raconte n'importe quoi, je serai bien sûr ravi que tu partages tes connaissances pour me sortir de l'inculture où je végète. ;-)
Tu sembles manquer de bases théoriques pour bien comprendre ce que tu fais.
C'est très probable, et je suis le premier à souhaiter comprendre tout ce que j'utilise, tels que les différents formats d'image et bien sûr avant tout la structure d'un fichier PDF. Si tu as des docs à me conseiller j'en serai ravi. Cela dit, indépendamment de l'intérêt intellectuel qu'il y a à comprendre comment ça marche, si j'avais des recettes de cuisine que je ne comprends pas mais qui donnent le bon résultat, ce serait déjà très appréciable pour les autres membres du chœur qui ne cherchent rien d'autre qu'avoir les partitions à imprimer avant la répétition...
Comme format intermédiaire, il faut utiliser un format sans pertes. Si l'espace disque occupé temporairement n'est pas un problème, un format sans compression comme PNM fera parfaitement l'affaire.
Ok, dont PBM pour du noir et blanc.
$ pdfimages -j a.pdf b -> 2 109 453 b-000.pbm
Soit 5120*3296/8+13. Le format PBM n'effectue aucune compression.
Oui, logique.
$ convert b-000.pbm c.jpg -> 897 805 c.jpg
Tu peux obtenir un fichier beaucoup plus gros en ajoutant « -quality 100 » et un fichier beaucoup plus petit en ajoutant « -quality 10 ».
Ok.
$ convert c.jpg c.pdf -> 900 078 c.pdf
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à partir des JPEG, pdfTeX est probablement le plus simple.
Je veux bien, mais je n'y connais strictement rien à TeX ni à LaTeX. Est-ce qu'il suffit d'une commande du style 'pdftex *.jpg foo.pdf' ou bien il faut écrire un fichier TeX (quoi que ça puisse vouloir dire) ?
$ convert b-000.pbm d.png -> 79 687 d.png
Apparemment, le PNG compresse assez mal ce genre d'image. Il y a des formats plus adaptés aux images scannées. En général, on les appelle TIFF, mais c'est un fourre-tout pour cinquante formats différents.
Ok.
$ convert c.jpg c.pdf -> 114 949 d.pdf
Ça semble incohérent.
Erreur de copier-coller : c'était 'convert d.png d.pdf'.
Mais bon, j'ai compris grâce à toi que 'convert' de ImageMagick n'est pas le bon outil. Merci déjà pour ça. Il me reste à savoir comment faire autrement (pdfTeX ?)
Ah, j'ai aussi le curieux résultat suivant après pdfimages -j :
Les dimensions 1224x792 deviennent 5120x3296, soit 4,18 fois plus en X et 4,16 fois plus en Y !
Ça, c'est parfaitement normal, c'est parce que tu utilises un outil inadapté au PDF.
J'allais protester que l'outil utilisé était 'pdfimages -j', mais juste avant de l'écrire je viens de réaliser que c'est 'identify' l'outil inadapté au PDF.
Bon, donc les dimensions 5120x3296 sont les seules qui aient un sens.
Le PDF est un format vectoriel, il n'a pas de taille en pixels, il n'a même pas de pixels. Il a une taille physique, en centimètres (ou en pouces, peu importe). Mais comme ImageMagick est un outil bitmap, il invente une grille de pixels, avec une finesse arbitraire.
La densité choisie par ImageMagick par défaut change de version en version, mais avec les données que montres, on dirait que tu as une double page au format « Letter », soit 2×8,5 pouces par 11, qu'ImageMagick utilise une densité de 72 pixels par pouce et que le fichier contient des images scannées à 300 pixels par pouce avec un peu d'arrondi.
Oui, c'est parfaitement cohérent. Bien vu ! Et la valeur d'environ 4,16 ou 4,18 que j'avais constatée correspond à 300/72 ~~ 4,1667
-- Olivier Miakinen
Bonjour,
Le 28/05/2015 09:28, Nicolas George m'a répondu :
Quel format me conseilles-tu ? En particulier, est-ce que ceux qui
reliront mes PDF créés à partir d'images dans un format autre que
JPEG n'auront pas de problèmes, même s'ils sont sur Windows ou
Mac ?
Habituellement mon format de prédilection pour les images est le
PNG, mais comme Nicolas Richard m'avait donné des exemples en JPEG
je n'ai pas cherché plus loin.
Je pense que tu aurais besoin de te documenter un peu sur la différence
entre image bitmap et image vectorielle, et ensuite sur la différence, pour
les images bitmap, pour les formats compressés avec pertes et les formats
sans pertes (compressés ou non compressés).
Certainement, je ne demande qu'à apprendre. J'ai toujours pensé que le
JPEG est un format de compression d'image bitmap avec pertes, le PNG
un format de compression d'image bitmap sans pertes, et le PBM un format
d'images bitmap non compressées. Quant aux images vectorielles, je n'y
connais rien du tout, mais je pensais naïvement que ça ne pouvait pas
être utile pour représenter le résultat d'une numérisation par scanner.
J'ajoute que, vu que le but de la manœuvre est de donner une partition
musicale lisible et pas de reproduire fidèlement une œuvre picturale,
il ne me semblait pas très grave d'utiliser un format avec pertes
plutôt qu'un format sans pertes.
Maintenant, si je raconte n'importe quoi, je serai bien sûr ravi que
tu partages tes connaissances pour me sortir de l'inculture où je
végète. ;-)
Tu sembles manquer de bases
théoriques pour bien comprendre ce que tu fais.
C'est très probable, et je suis le premier à souhaiter comprendre tout
ce que j'utilise, tels que les différents formats d'image et bien sûr
avant tout la structure d'un fichier PDF. Si tu as des docs à me
conseiller j'en serai ravi. Cela dit, indépendamment de l'intérêt
intellectuel qu'il y a à comprendre comment ça marche, si j'avais
des recettes de cuisine que je ne comprends pas mais qui donnent le
bon résultat, ce serait déjà très appréciable pour les autres membres
du chœur qui ne cherchent rien d'autre qu'avoir les partitions à
imprimer avant la répétition...
Comme format intermédiaire, il faut utiliser un format sans pertes. Si
l'espace disque occupé temporairement n'est pas un problème, un format sans
compression comme PNM fera parfaitement l'affaire.
Ok, dont PBM pour du noir et blanc.
$ pdfimages -j a.pdf b
-> 2 109 453 b-000.pbm
Soit 5120*3296/8+13. Le format PBM n'effectue aucune compression.
Oui, logique.
$ convert b-000.pbm c.jpg
-> 897 805 c.jpg
Tu peux obtenir un fichier beaucoup plus gros en ajoutant « -quality 100 »
et un fichier beaucoup plus petit en ajoutant « -quality 10 ».
Ok.
$ convert c.jpg c.pdf
-> 900 078 c.pdf
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour
stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à
partir des JPEG, pdfTeX est probablement le plus simple.
Je veux bien, mais je n'y connais strictement rien à TeX ni à LaTeX.
Est-ce qu'il suffit d'une commande du style 'pdftex *.jpg foo.pdf' ou
bien il faut écrire un fichier TeX (quoi que ça puisse vouloir dire) ?
$ convert b-000.pbm d.png
-> 79 687 d.png
Apparemment, le PNG compresse assez mal ce genre d'image. Il y a des formats
plus adaptés aux images scannées. En général, on les appelle TIFF, mais
c'est un fourre-tout pour cinquante formats différents.
Ok.
$ convert c.jpg c.pdf
-> 114 949 d.pdf
Ça semble incohérent.
Erreur de copier-coller : c'était 'convert d.png d.pdf'.
Mais bon, j'ai compris grâce à toi que 'convert' de ImageMagick n'est
pas le bon outil. Merci déjà pour ça. Il me reste à savoir comment
faire autrement (pdfTeX ?)
Ah, j'ai aussi le curieux résultat suivant après pdfimages -j :
Les dimensions 1224x792 deviennent 5120x3296, soit 4,18 fois plus en X
et 4,16 fois plus en Y !
Ça, c'est parfaitement normal, c'est parce que tu utilises un outil
inadapté au PDF.
J'allais protester que l'outil utilisé était 'pdfimages -j', mais juste
avant de l'écrire je viens de réaliser que c'est 'identify' l'outil
inadapté au PDF.
Bon, donc les dimensions 5120x3296 sont les seules qui aient un sens.
Le PDF est un format vectoriel, il n'a pas de taille en pixels, il n'a même
pas de pixels. Il a une taille physique, en centimètres (ou en pouces, peu
importe). Mais comme ImageMagick est un outil bitmap, il invente une grille
de pixels, avec une finesse arbitraire.
La densité choisie par ImageMagick par défaut change de version en version,
mais avec les données que montres, on dirait que tu as une double page au
format « Letter », soit 2×8,5 pouces par 11, qu'ImageMagick utilise une
densité de 72 pixels par pouce et que le fichier contient des images
scannées à 300 pixels par pouce avec un peu d'arrondi.
Quel format me conseilles-tu ? En particulier, est-ce que ceux qui reliront mes PDF créés à partir d'images dans un format autre que JPEG n'auront pas de problèmes, même s'ils sont sur Windows ou Mac ?
Habituellement mon format de prédilection pour les images est le PNG, mais comme Nicolas Richard m'avait donné des exemples en JPEG je n'ai pas cherché plus loin.
Je pense que tu aurais besoin de te documenter un peu sur la différence entre image bitmap et image vectorielle, et ensuite sur la différence, pour les images bitmap, pour les formats compressés avec pertes et les formats sans pertes (compressés ou non compressés).
Certainement, je ne demande qu'à apprendre. J'ai toujours pensé que le JPEG est un format de compression d'image bitmap avec pertes, le PNG un format de compression d'image bitmap sans pertes, et le PBM un format d'images bitmap non compressées. Quant aux images vectorielles, je n'y connais rien du tout, mais je pensais naïvement que ça ne pouvait pas être utile pour représenter le résultat d'une numérisation par scanner.
J'ajoute que, vu que le but de la manœuvre est de donner une partition musicale lisible et pas de reproduire fidèlement une œuvre picturale, il ne me semblait pas très grave d'utiliser un format avec pertes plutôt qu'un format sans pertes.
Maintenant, si je raconte n'importe quoi, je serai bien sûr ravi que tu partages tes connaissances pour me sortir de l'inculture où je végète. ;-)
Tu sembles manquer de bases théoriques pour bien comprendre ce que tu fais.
C'est très probable, et je suis le premier à souhaiter comprendre tout ce que j'utilise, tels que les différents formats d'image et bien sûr avant tout la structure d'un fichier PDF. Si tu as des docs à me conseiller j'en serai ravi. Cela dit, indépendamment de l'intérêt intellectuel qu'il y a à comprendre comment ça marche, si j'avais des recettes de cuisine que je ne comprends pas mais qui donnent le bon résultat, ce serait déjà très appréciable pour les autres membres du chœur qui ne cherchent rien d'autre qu'avoir les partitions à imprimer avant la répétition...
Comme format intermédiaire, il faut utiliser un format sans pertes. Si l'espace disque occupé temporairement n'est pas un problème, un format sans compression comme PNM fera parfaitement l'affaire.
Ok, dont PBM pour du noir et blanc.
$ pdfimages -j a.pdf b -> 2 109 453 b-000.pbm
Soit 5120*3296/8+13. Le format PBM n'effectue aucune compression.
Oui, logique.
$ convert b-000.pbm c.jpg -> 897 805 c.jpg
Tu peux obtenir un fichier beaucoup plus gros en ajoutant « -quality 100 » et un fichier beaucoup plus petit en ajoutant « -quality 10 ».
Ok.
$ convert c.jpg c.pdf -> 900 078 c.pdf
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à partir des JPEG, pdfTeX est probablement le plus simple.
Je veux bien, mais je n'y connais strictement rien à TeX ni à LaTeX. Est-ce qu'il suffit d'une commande du style 'pdftex *.jpg foo.pdf' ou bien il faut écrire un fichier TeX (quoi que ça puisse vouloir dire) ?
$ convert b-000.pbm d.png -> 79 687 d.png
Apparemment, le PNG compresse assez mal ce genre d'image. Il y a des formats plus adaptés aux images scannées. En général, on les appelle TIFF, mais c'est un fourre-tout pour cinquante formats différents.
Ok.
$ convert c.jpg c.pdf -> 114 949 d.pdf
Ça semble incohérent.
Erreur de copier-coller : c'était 'convert d.png d.pdf'.
Mais bon, j'ai compris grâce à toi que 'convert' de ImageMagick n'est pas le bon outil. Merci déjà pour ça. Il me reste à savoir comment faire autrement (pdfTeX ?)
Ah, j'ai aussi le curieux résultat suivant après pdfimages -j :
Les dimensions 1224x792 deviennent 5120x3296, soit 4,18 fois plus en X et 4,16 fois plus en Y !
Ça, c'est parfaitement normal, c'est parce que tu utilises un outil inadapté au PDF.
J'allais protester que l'outil utilisé était 'pdfimages -j', mais juste avant de l'écrire je viens de réaliser que c'est 'identify' l'outil inadapté au PDF.
Bon, donc les dimensions 5120x3296 sont les seules qui aient un sens.
Le PDF est un format vectoriel, il n'a pas de taille en pixels, il n'a même pas de pixels. Il a une taille physique, en centimètres (ou en pouces, peu importe). Mais comme ImageMagick est un outil bitmap, il invente une grille de pixels, avec une finesse arbitraire.
La densité choisie par ImageMagick par défaut change de version en version, mais avec les données que montres, on dirait que tu as une double page au format « Letter », soit 2×8,5 pouces par 11, qu'ImageMagick utilise une densité de 72 pixels par pouce et que le fichier contient des images scannées à 300 pixels par pouce avec un peu d'arrondi.
Oui, c'est parfaitement cohérent. Bien vu ! Et la valeur d'environ 4,16 ou 4,18 que j'avais constatée correspond à 300/72 ~~ 4,1667
-- Olivier Miakinen
Benoit Izac
Olivier Miakinen <om+ writes:
- tu rognes à 2050 en mettant %03d.jpg pour la sortie.
Pas mal du tout ! Mais où trouver la doc de toutes les syntaxes permises ? J'en ai trouvé un peu sur la page suivante mais ce ne sont que des exemples :
<http://www.imagemagick.org/script/command-line-processing.php> ... en entrée... convert image-%d.jpg[1-5] ... permet de lire les fichiers... image-1.jpg image-2.jpg image-3.jpg image-4.jpg image-5.jpg
... en sortie... convert ... image-%d.jpg ... permet d'obtenir les fichiers... image-0.jpg image-1.jpg image-2.jpg </>
Je n'ai pas trouvé la documentation (c'est touffu) mais le code source est là : <http://trac.imagemagick.org/browser/ImageMagick/branches/ImageMagick-6.9.1/magick/image.c#L1535>
-- Benoit Izac
Olivier Miakinen <om+news@miakinen.net> writes:
- tu rognes à 2050 en mettant %03d.jpg pour la sortie.
Pas mal du tout ! Mais où trouver la doc de toutes les syntaxes
permises ? J'en ai trouvé un peu sur la page suivante mais ce ne
sont que des exemples :
<http://www.imagemagick.org/script/command-line-processing.php>
... en entrée...
convert image-%d.jpg[1-5]
... permet de lire les fichiers...
image-1.jpg
image-2.jpg
image-3.jpg
image-4.jpg
image-5.jpg
... en sortie...
convert ... image-%d.jpg
... permet d'obtenir les fichiers...
image-0.jpg
image-1.jpg
image-2.jpg
</>
Je n'ai pas trouvé la documentation (c'est touffu) mais le code source
est là :
<http://trac.imagemagick.org/browser/ImageMagick/branches/ImageMagick-6.9.1/magick/image.c#L1535>
- tu rognes à 2050 en mettant %03d.jpg pour la sortie.
Pas mal du tout ! Mais où trouver la doc de toutes les syntaxes permises ? J'en ai trouvé un peu sur la page suivante mais ce ne sont que des exemples :
<http://www.imagemagick.org/script/command-line-processing.php> ... en entrée... convert image-%d.jpg[1-5] ... permet de lire les fichiers... image-1.jpg image-2.jpg image-3.jpg image-4.jpg image-5.jpg
... en sortie... convert ... image-%d.jpg ... permet d'obtenir les fichiers... image-0.jpg image-1.jpg image-2.jpg </>
Je n'ai pas trouvé la documentation (c'est touffu) mais le code source est là : <http://trac.imagemagick.org/browser/ImageMagick/branches/ImageMagick-6.9.1/magick/image.c#L1535>
-- Benoit Izac
Olivier Miakinen
Le 28/05/2015 10:11, Lucas Levrel répondait à Nicolas George :
-> 897 805 c.jpg
$ convert c.jpg c.pdf -> 900 078 c.pdf
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à partir des JPEG, pdfTeX est probablement le plus simple.
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en début et en fin de PDF).
Oui, en effet.
-> 79 687 d.png
$ convert c.jpg c.pdf -> 114 949 d.pdf
Ça semble incohérent.
Je suppose qu'il y a une coquille (convert d.png d.pdf).
Exactement.
L'écart PNG-PDF est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas contenir de PNG tel quel et convert passe par un intermédiaire, peut-être du JPEG (convert d.png d.jpg pourrait nous renseigner).
convert d.png d.jpg -> 897 805 d.jpg
cmp -l c.jpg d.jpg -> rien (les fichiers sont identiques à l'octet près)
Le 28/05/2015 10:11, Lucas Levrel répondait à Nicolas George :
-> 897 805 c.jpg
$ convert c.jpg c.pdf
-> 900 078 c.pdf
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour
stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à
partir des JPEG, pdfTeX est probablement le plus simple.
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est
assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en
début et en fin de PDF).
Oui, en effet.
-> 79 687 d.png
$ convert c.jpg c.pdf
-> 114 949 d.pdf
Ça semble incohérent.
Je suppose qu'il y a une coquille (convert d.png d.pdf).
Exactement.
L'écart PNG-PDF
est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas
contenir de PNG tel quel et convert passe par un intermédiaire, peut-être
du JPEG (convert d.png d.jpg pourrait nous renseigner).
convert d.png d.jpg
-> 897 805 d.jpg
cmp -l c.jpg d.jpg
-> rien (les fichiers sont identiques à l'octet près)
Le 28/05/2015 10:11, Lucas Levrel répondait à Nicolas George :
-> 897 805 c.jpg
$ convert c.jpg c.pdf -> 900 078 c.pdf
Je n'ai aucune idée de la compression qu'ImageMagick utilise par défaut pour stocker un bitmap dans un PDF. Pour fabriquer le fichier PDF fiablement à partir des JPEG, pdfTeX est probablement le plus simple.
Il me semble que le PDF peut embarquer du JPEG tel quel. Du coup c'est assez logique d'avoir un PDF juste un peu plus gros (le blabla habituel en début et en fin de PDF).
Oui, en effet.
-> 79 687 d.png
$ convert c.jpg c.pdf -> 114 949 d.pdf
Ça semble incohérent.
Je suppose qu'il y a une coquille (convert d.png d.pdf).
Exactement.
L'écart PNG-PDF est nettement plus gros que JPEG-PDF, vraisemblablement le PDF ne peut pas contenir de PNG tel quel et convert passe par un intermédiaire, peut-être du JPEG (convert d.png d.jpg pourrait nous renseigner).
convert d.png d.jpg -> 897 805 d.jpg
cmp -l c.jpg d.jpg -> rien (les fichiers sont identiques à l'octet près)
Olivier Miakinen
Le 28/05/2015 10:19, Nicolas George a écrit :
[...] Il ne faut pas faire confiance à ImageMagick.
C'est, je crois, le point essentiel qui ressort de cette discussion.
Le 28/05/2015 10:19, Nicolas George a écrit :
[...] Il ne faut pas faire confiance à ImageMagick.
C'est, je crois, le point essentiel qui ressort de cette discussion.
[...] Il ne faut pas faire confiance à ImageMagick.
C'est, je crois, le point essentiel qui ressort de cette discussion.
Olivier Miakinen
Le 28/05/2015 10:25, Lucas Levrel m'a répondu :
Mais j'ai aussi un autre problème : les fichiers images (pbm d'abord, puis JPEG ou PNG ensuite), sont notablement plus gros que le PDF d'origine, et le PDF résultant l'est encore plus !
Je pense que tu n'aurais pas ce problème avec les outils que je t'ai indiqués.
Je cite ton article :
============================================================== Mettons que tu aies scan1.pdf à scan4.pdf
for i in {1..4} do pdfcrop --bbox '0 0 500 842' scan$i.pdf page$i_a.pdf pdfcrop --bbox '500 0 1000 842' scan$i.pdf page$i_b.pdf done pdfjoin page*.pdf -o fini.pdf ============================================================== Question : comment je détermine les valeurs 500, 1000 et 842 ?
Mais tu n'aurais pas la possibilité de tourner les pages.
... ce qui est aussi un problème.
Pour ça il faudrait un code TeX avec des includegraphics, c'est plus lourd,
... de plus, je ne connais strictement rien à TeX.
mais vu que tu fais déjà une série d'opérations manuelles par page... Et puis tu n'aurais plus que trois étapes : déterminer les angles de rotation, écrire le source, compiler. La troisième étant triviale et la seconde pouvant se faire avec l'aide des gentils participants de fctt !
Quant à la première, je ne sais pas plus comment déterminer les angles de rotation (deux par PDF) que déterminer les paramètres du --bbox.
Bref, je persiste à penser que c'est trop difficile de ne pas passer par des images individuelles que je sais lire et traiter avec GIMP.
Le 28/05/2015 10:25, Lucas Levrel m'a répondu :
Mais j'ai aussi un autre problème : les fichiers images (pbm d'abord,
puis JPEG ou PNG ensuite), sont notablement plus gros que le PDF
d'origine, et le PDF résultant l'est encore plus !
Je pense que tu n'aurais pas ce problème avec les outils que je t'ai
indiqués.
Je cite ton article :
============================================================== Mettons que tu aies scan1.pdf à scan4.pdf
for i in {1..4}
do pdfcrop --bbox '0 0 500 842' scan$i.pdf page$i_a.pdf
pdfcrop --bbox '500 0 1000 842' scan$i.pdf page$i_b.pdf
done
pdfjoin page*.pdf -o fini.pdf
==============================================================
Question : comment je détermine les valeurs 500, 1000 et 842 ?
Mais tu n'aurais pas la possibilité de tourner les pages.
... ce qui est aussi un problème.
Pour
ça il faudrait un code TeX avec des includegraphics, c'est plus lourd,
... de plus, je ne connais strictement rien à TeX.
mais vu que tu fais déjà une série d'opérations manuelles par page... Et
puis tu n'aurais plus que trois étapes : déterminer les angles de
rotation, écrire le source, compiler. La troisième étant triviale et la
seconde pouvant se faire avec l'aide des gentils participants de fctt !
Quant à la première, je ne sais pas plus comment déterminer les angles
de rotation (deux par PDF) que déterminer les paramètres du --bbox.
Bref, je persiste à penser que c'est trop difficile de ne pas passer
par des images individuelles que je sais lire et traiter avec GIMP.
Mais j'ai aussi un autre problème : les fichiers images (pbm d'abord, puis JPEG ou PNG ensuite), sont notablement plus gros que le PDF d'origine, et le PDF résultant l'est encore plus !
Je pense que tu n'aurais pas ce problème avec les outils que je t'ai indiqués.
Je cite ton article :
============================================================== Mettons que tu aies scan1.pdf à scan4.pdf
for i in {1..4} do pdfcrop --bbox '0 0 500 842' scan$i.pdf page$i_a.pdf pdfcrop --bbox '500 0 1000 842' scan$i.pdf page$i_b.pdf done pdfjoin page*.pdf -o fini.pdf ============================================================== Question : comment je détermine les valeurs 500, 1000 et 842 ?
Mais tu n'aurais pas la possibilité de tourner les pages.
... ce qui est aussi un problème.
Pour ça il faudrait un code TeX avec des includegraphics, c'est plus lourd,
... de plus, je ne connais strictement rien à TeX.
mais vu que tu fais déjà une série d'opérations manuelles par page... Et puis tu n'aurais plus que trois étapes : déterminer les angles de rotation, écrire le source, compiler. La troisième étant triviale et la seconde pouvant se faire avec l'aide des gentils participants de fctt !
Quant à la première, je ne sais pas plus comment déterminer les angles de rotation (deux par PDF) que déterminer les paramètres du --bbox.
Bref, je persiste à penser que c'est trop difficile de ne pas passer par des images individuelles que je sais lire et traiter avec GIMP.
Nicolas George
Olivier Miakinen , dans le message <mk80ir$14i3$, a écrit :
Certainement, je ne demande qu'à apprendre. J'ai toujours pensé que le JPEG est un format de compression d'image bitmap avec pertes, le PNG un format de compression d'image bitmap sans pertes, et le PBM un format d'images bitmap non compressées.
Oui, c'est bien ça.
Quant aux images vectorielles, je n'y connais rien du tout, mais je pensais naïvement que ça ne pouvait pas être utile pour représenter le résultat d'une numérisation par scanner.
En théorie, oui. En pratique, les formats bitmap ne sont pas pratiques quand il y a plusieurs pages, les outils sont mauvais pour les imprimer en pleine page, etc., donc les scanners produisent un PDF, pour avoir plusieurs pages et stocker la taille physique de manière fiable. Chaque page est juste une seule image bitmap qui occupe toute la place, et stockée de manière plus efficace que des millions de carrés colorés côte à côte.
J'ajoute que, vu que le but de la manoeuvre est de donner une partition musicale lisible et pas de reproduire fidèlement une oeuvre picturale, il ne me semblait pas très grave d'utiliser un format avec pertes plutôt qu'un format sans pertes.
Ce serait un argument pertinent si ça t'apportait quelque chose de travailler avec un format à pertes comme format intermédiaire, mais tel quel, tu n'y gagnes rien, donc autant utiliser la solution propre.
Olivier Miakinen , dans le message <mk80ir$14i3$1@cabale.usenet-fr.net>,
a écrit :
Certainement, je ne demande qu'à apprendre. J'ai toujours pensé que le
JPEG est un format de compression d'image bitmap avec pertes, le PNG
un format de compression d'image bitmap sans pertes, et le PBM un format
d'images bitmap non compressées.
Oui, c'est bien ça.
Quant aux images vectorielles, je n'y
connais rien du tout, mais je pensais naïvement que ça ne pouvait pas
être utile pour représenter le résultat d'une numérisation par scanner.
En théorie, oui. En pratique, les formats bitmap ne sont pas pratiques quand
il y a plusieurs pages, les outils sont mauvais pour les imprimer en pleine
page, etc., donc les scanners produisent un PDF, pour avoir plusieurs pages
et stocker la taille physique de manière fiable. Chaque page est juste une
seule image bitmap qui occupe toute la place, et stockée de manière plus
efficace que des millions de carrés colorés côte à côte.
J'ajoute que, vu que le but de la manoeuvre est de donner une partition
musicale lisible et pas de reproduire fidèlement une oeuvre picturale,
il ne me semblait pas très grave d'utiliser un format avec pertes
plutôt qu'un format sans pertes.
Ce serait un argument pertinent si ça t'apportait quelque chose de
travailler avec un format à pertes comme format intermédiaire, mais tel
quel, tu n'y gagnes rien, donc autant utiliser la solution propre.
Olivier Miakinen , dans le message <mk80ir$14i3$, a écrit :
Certainement, je ne demande qu'à apprendre. J'ai toujours pensé que le JPEG est un format de compression d'image bitmap avec pertes, le PNG un format de compression d'image bitmap sans pertes, et le PBM un format d'images bitmap non compressées.
Oui, c'est bien ça.
Quant aux images vectorielles, je n'y connais rien du tout, mais je pensais naïvement que ça ne pouvait pas être utile pour représenter le résultat d'une numérisation par scanner.
En théorie, oui. En pratique, les formats bitmap ne sont pas pratiques quand il y a plusieurs pages, les outils sont mauvais pour les imprimer en pleine page, etc., donc les scanners produisent un PDF, pour avoir plusieurs pages et stocker la taille physique de manière fiable. Chaque page est juste une seule image bitmap qui occupe toute la place, et stockée de manière plus efficace que des millions de carrés colorés côte à côte.
J'ajoute que, vu que le but de la manoeuvre est de donner une partition musicale lisible et pas de reproduire fidèlement une oeuvre picturale, il ne me semblait pas très grave d'utiliser un format avec pertes plutôt qu'un format sans pertes.
Ce serait un argument pertinent si ça t'apportait quelque chose de travailler avec un format à pertes comme format intermédiaire, mais tel quel, tu n'y gagnes rien, donc autant utiliser la solution propre.
Lucas Levrel
Le 28 mai 2015, Olivier Miakinen a écrit :
Je cite ton article :
============================================================== > Mettons que tu aies scan1.pdf à scan4.pdf
for i in {1..4} do pdfcrop --bbox '0 0 500 842' scan$i.pdf page$i_a.pdf pdfcrop --bbox '500 0 1000 842' scan$i.pdf page$i_b.pdf done pdfjoin page*.pdf -o fini.pdf ============================================================== > Question : comment je détermine les valeurs 500, 1000 et 842 ?
Ah oui. En ouvrant le pdf avec gv, on a un pointeur dont les coordonnées sont indiquées sur le côté. Les dimensions sont en points (je ne sais plus si c'est 72 ou 72,27 points par pouce, mais pour ce que ça change ici...).
Pour ça il faudrait un code TeX avec des includegraphics, c'est plus lourd,
... de plus, je ne connais strictement rien à TeX.
Tu as bien découvert un certain nombre de commandes dans ce fil, ce ne sont pas quatre ou cinq commandes TeX qui vont te faire fuir ! :-)
Quant à la première, je ne sais pas plus comment déterminer les angles de rotation (deux par PDF)
Toujours avec ta méthode. Gimp sait ouvrir du PDF.
Bref, je persiste à penser que c'est trop difficile de ne pas passer par des images individuelles que je sais lire et traiter avec GIMP.
Vu que Gimp peut ouvrir du PDF, ma méthode répond à ces critères. ;-) Tu coupes en images avec les pdfcrop, tu ouvres les pages avec Gimp pour mesurer les angles, tu les écris au fur et à mesure « là où il faut » dans le source tex, et zou !
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 28 mai 2015, Olivier Miakinen a écrit :
Je cite ton article :
============================================================== > Mettons que tu aies scan1.pdf à scan4.pdf
for i in {1..4}
do pdfcrop --bbox '0 0 500 842' scan$i.pdf page$i_a.pdf
pdfcrop --bbox '500 0 1000 842' scan$i.pdf page$i_b.pdf
done
pdfjoin page*.pdf -o fini.pdf
============================================================== >
Question : comment je détermine les valeurs 500, 1000 et 842 ?
Ah oui. En ouvrant le pdf avec gv, on a un pointeur dont les coordonnées
sont indiquées sur le côté. Les dimensions sont en points (je ne sais plus
si c'est 72 ou 72,27 points par pouce, mais pour ce que ça change ici...).
Pour
ça il faudrait un code TeX avec des includegraphics, c'est plus lourd,
... de plus, je ne connais strictement rien à TeX.
Tu as bien découvert un certain nombre de commandes dans ce fil, ce ne
sont pas quatre ou cinq commandes TeX qui vont te faire fuir ! :-)
Quant à la première, je ne sais pas plus comment déterminer les angles
de rotation (deux par PDF)
Toujours avec ta méthode. Gimp sait ouvrir du PDF.
Bref, je persiste à penser que c'est trop difficile de ne pas passer
par des images individuelles que je sais lire et traiter avec GIMP.
Vu que Gimp peut ouvrir du PDF, ma méthode répond à ces critères. ;-)
Tu coupes en images avec les pdfcrop, tu ouvres les pages avec Gimp pour
mesurer les angles, tu les écris au fur et à mesure « là où il faut » dans
le source tex, et zou !
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
============================================================== > Mettons que tu aies scan1.pdf à scan4.pdf
for i in {1..4} do pdfcrop --bbox '0 0 500 842' scan$i.pdf page$i_a.pdf pdfcrop --bbox '500 0 1000 842' scan$i.pdf page$i_b.pdf done pdfjoin page*.pdf -o fini.pdf ============================================================== > Question : comment je détermine les valeurs 500, 1000 et 842 ?
Ah oui. En ouvrant le pdf avec gv, on a un pointeur dont les coordonnées sont indiquées sur le côté. Les dimensions sont en points (je ne sais plus si c'est 72 ou 72,27 points par pouce, mais pour ce que ça change ici...).
Pour ça il faudrait un code TeX avec des includegraphics, c'est plus lourd,
... de plus, je ne connais strictement rien à TeX.
Tu as bien découvert un certain nombre de commandes dans ce fil, ce ne sont pas quatre ou cinq commandes TeX qui vont te faire fuir ! :-)
Quant à la première, je ne sais pas plus comment déterminer les angles de rotation (deux par PDF)
Toujours avec ta méthode. Gimp sait ouvrir du PDF.
Bref, je persiste à penser que c'est trop difficile de ne pas passer par des images individuelles que je sais lire et traiter avec GIMP.
Vu que Gimp peut ouvrir du PDF, ma méthode répond à ces critères. ;-) Tu coupes en images avec les pdfcrop, tu ouvres les pages avec Gimp pour mesurer les angles, tu les écris au fur et à mesure « là où il faut » dans le source tex, et zou !
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
