Rotation de jpeg sans perte

Mais peut on utiliser ce logiciel dans le cas ou nos images ne sont
pas issue d'un nikon?

Oui, il lit les NEF (Raw de Nikon), les TIF (mais pas tous) et les JPEG

Et as tu remarqué une difference de taille de fichier?

sur un essai : image d'origine 2 641 ko, image retournée : 2637 ko

Nikon view fait partie de la liste des applications qui utilisent la
librairie jpegtran dont on t'a parlé plus haut

Merci d'avance

De rien
--
Georges Solignac

"Macatack" <bienvu@noos.fr> a écrit dans le message de news:
4159c650$0$26368$79c14f64@nan-newsreader-07.noos.net...

C'est vous qui aviez raison.
Il y a d'abord une petite perte d'octets. Puis un cycle sur 4 rotations.

Je cherche encore, plutôt que de dire des âneries.
fp

En même temps ça represente une petite perte ds mon cas autour de 1.5%...
mais impossible de savoir exactement que represente t'elle, les EXIF etant
conservé...

Oui , j'ai correspondu avec l'auteur de XnView, Pierre-e Gougelet (suite à
votre intervention), cette perte initiale semble être inhérente à l'algo de
rotation sans perte "Jpengtran" qui n'est pas tout à fait sans perte.

Puis, allez sur le forum http://www.xnview.com/ et téléchargez la version
bêta. Très bonne surprise, en ce qui concerne mes "revendications" exposées
sur ma page :
http://www.contactphoto.fr.st/technique/rotation

Tout ça un peu... grâce à moi !!! ;o)))

@+
fp
www.fplanglois.com

Le Thu, 23 Sep 2004 13:50:38 +0200, Macatack a écrit :

Je ne veux aucune perte d'information car certaines sont à destination
professionnelle.

Je me suis amusé à faire les tests avec quatre logiciels : jpegtran,
xnview (qui normalement utilise jpegtran), photfiltre et Gimp.

J'ai pris une photo en 600x400 que j'ai sauvegardé au format jpeg sous
Gimp avec qualité à 100% c'est à dire compression minimale.

J'ai ensuite fait une rotation de 90° sens horaire avec les 4 logiciels
et j'ai sauvegardé pour gimp et photofiltre avec le taux de compression
minimal à savoir qualité à 100%. Pour xnview j'ai juste demandé la
rotation et pour jpegtran j'ai demandé jpegtran -rotate 90.

J'ai ensuite ouvert les fichiers sous Gimp, la référence et les 4
rotations. Sous Gimp, j'ai fait la rotation anti-horaire de 90° des
fichiers de rotation. Ensuite j'ai ajouté un calque sur le fichier de
référence pour faire la différence entre le fichier de référence et
chaque rotation par un outil.

En tout premier lieu j'ai vérifié que copier/coller ne générait pas
d'écart ; j'ai donc copier ma référence par Ctrl-C et coller en tant
que nouveau N. J'ai ensuite copier ce nouveau pour le coller dans le
calque de différence et la différence est nulle (histogramme
diff_reference.jpg ; tous les histogrammes sont présentés en
logarithmique afin d'augmenter la surface à visualiser).

Ensuite j'ai vérifié que faire des rotations (sans sauvegarde) sous Gimp
ne génèrent pas d'écart. J'ai donc fait une rotation de mon nouveau
fichier N et refait une rotation en sens inverse (les effets des deux
rotations pourraient s'annuler, mais bon, je ne sais pas comment
vérifier). La différence est nulle (histogramme diff_rotation.jpg).

Les seules différences que je vais donc voir sont issues de la
rotation/sauvegarde (sauvegarde pour gimp et photofiltre). J'ai donc
répété 4 fois l'opération et j'obtiens les 4 histogrammes :
diff_jpegtran.jpg, diff_photofiltre.jpg, diff_xnview.jpg et diff_gimp.jpg.

Avant de tirer des conclusions, si vous avez des remarques à faire,
n'hésitez pas. J'ai déjà mon idée sur la chose :-)

La page des histogrammes est ici avec la photo de référence :
<URL:http://speccini.free.fr/temporaire/rotation/>

Attention environ 300 ko à charger.

--
Stephan Peccini
Nature : <URL:http://nature.tesenca.info>
Seurasaari : <URL:http://seurasaari.tesenca.info>

Stephan Peccini wrote:

Je ne veux aucune perte d'information car certaines sont à destination
professionnelle.

Je me suis amusé à faire les tests avec quatre logiciels : jpegtran,
xnview (qui normalement utilise jpegtran), photfiltre et Gimp.

Quel courage pour répondre à un intervenant hargneux qui ne
daignera même pas te remercier :)

(couic de la demonstration intéressante et compliquée)

Il y a infiniment plus simple avec ImageMagick:

Pour comparer deux images, par exemple l'original et la même après 4
rotations de 90° ou bien +90° suivi de -90°:

composite -compose Difference image1.jpg image2.jpg difference.tif

La différence des images "image1.jpg" et "image2.jpg" se trouve
dans "difference.tif" (je la mets dans un tif pour être certain
qu'il n'y ai pas de gag de compression après coup).
Il suffit de verifier que c'est bien une image noire.

Cela dit chez moi, *pour une image sans données exif* et
*ayant une table de Huffman optimisée*, le resutat par jpegtran
d'une rotation +90 puis +270 est *identique à l'original au bit près*,
donc aussi en taille. Mais St Thomas n'est pas obligé de me croire et
peut continuer à polluer tous les forum de la terre.

--
F.J.

François Jouve wrote:

Je me suis amusé à faire les tests avec quatre logiciels : jpegtran,
xnview (qui normalement utilise jpegtran), photfiltre et Gimp.

Quel courage pour répondre à un intervenant hargneux qui ne
daignera même pas te remercier :)

de plus, macatack serait il sous mac ?

mais, stephan, comme d'hab, nous invite à la reflexion, et c'est tant mieux

--
daniel.patin et non pas marcel.dugenou
(quoique, il y a des jours, je me demande....)

Le Wed, 29 Sep 2004 10:31:12 +0200, François Jouve a écrit :

Cela dit chez moi, *pour une image sans données exif* et
*ayant une table de Huffman optimisée*, le resutat par jpegtran
d'une rotation +90 puis +270 est *identique à l'original au bit près*,
donc aussi en taille.

J'ai fait la même chose et j'obtiens le même résultat. Je me suis donc
dit, je génère un fichier avec jpegtran :

jpegtran -rotate 90 -optimize test_reference.jpg > test_r_1.jpg

test_r_1.jpg devient ma référence

jpegtran -rotate 270 -optimize test_r_1.jpg > test_r_2.jpg
jpegtran -rotate 90 -optimize test_r_2.jpg > test_r_3.jpg

test_r_3.jpg et totalement identique à test_r_1.jpg, c'est exact.

Mais si je prends test_r_1.jpg et test_r_2.jpg et que je fais la
comparaison après en avoir retourné une dans gimp, j'ai exactement la
même différence que dans mes essais : diff_jpegtran !

Où se trouve le problème ? Est-ce Gimp qui introduit un changement lors
de la rotation pour faire la différence ? Ou est ce jpegtran qui
introduit des différences dans les étapes intermédiaires d'une rotation
mais qu'à l'arrivée les écarts se compensent après une rotation
complète ?

Pour vérifier cela, j'ai donc sauvegardé mon test_r_1.jpg en tif. J'ai
ensuite fait faire une rotation de 90° sous gimp et j'ai sauvegardé sous
test_r_2.tif. Ensuite j'ai ouvert les deux fichiers tif, j'ai fait une
rotation de -90° et j'ai fait la différence entre entre les deux calques
et là il n'y a pas d'écart : c'est le noir absolu ! Donc une rotation
sous gimp ne génère pas d'écart.

Où est le problème ? Je pencherait plus pour jpegtran, mais j'ai quand
même un doute. (j'espère être clair dans ce que je dis)

--
Stephan Peccini
Nature : <URL:http://nature.tesenca.info>
Seurasaari : <URL:http://seurasaari.tesenca.info>

"Stephan Peccini" <stephan@tesenca.info> a écrit dans le message de news:
pan.2004.09.29.08.11.46.259584@tesenca.info...

Je ne veux aucune perte d'information car certaines sont à destination
professionnelle.

Je me suis amusé à faire les tests avec quatre logiciels : jpegtran,
xnview (qui normalement utilise jpegtran), photfiltre et Gimp.

À ce sujet, voici un extrait d'un dialogue avec l'auteur de XnView.
Je pense que ça peut vous intéresser.
Les EXIF ne sont pour rien dans la perte.

La discussion complète (avec de bonnes nouvelles: une réponse dans XnView à
ma vieille demande de rotation sans perte sur l'EXIF de rotation) est sur le
forum -partie française- du site www.xnview.com.
/************************************************************************************************************************************/
fplanglois a écrit:
Utilisateur fervent de Xnview et utilisateur de la librairie graphique GFL
SDK pour mon programme Renomme, je commets de temps en temps de petits
tutoriels concernant la photo numérique.
Dans l'un d'eux, je conseille XnView pour la rotation Jpeg sans perte,
notamment pour sa capacité à conserver l'intégralité des infos EXIF avec la
rotation (reste mon voeu de remettre à l'endroit, la balise EXIF de
rotation).
www.contactphoto.fr.st/technique/rotation

Merci, et la gestion de l'info EXIF rotation est dans la 1.74.
Citation:
Un intervenant de fr.rec.photo.numerique, m'informe que chez lui (version
1.70.4), à chaque rotation, l'image perd quelques octets. Sur ma version
1.68.1, je ne constate rien de tel.

Ceci est normal, la rotation sans perte n'est pas totalement sans perte.
Elle se fait sur des blocs, donc quelques pixels peuvent etre supprimés.
Pierre.


fplanglois a écrit:
Depuis le temps que je prétends que le sans perte est totalement sans perte,
pour vu que les dimensions de l'image soient des multiples de 8.

Oui exact.
Citation:
Je viens de réaliser successivement des rotations "sans perte" sur le même
JPEG. On voit que le poids en octets retombe sur des valeurs de manière
cyclique.

Original :2 852 565 octets
Puis à chaque fois une rotation :
2 798 315 octets
2 796 421 octets
2 798 350 octets
2 796 351 octets
2 798 315 octets
2 796 421 octets
2 798 350 octets
2 796 351 octets
2 798 315 octets
2 796 421 octets
Après la perte initiale, on retombe sur un cycle de 4.

Je pense que cela vient de l'arrangement des blocs et la compression
huffman.
Pierre.

fplanglois a écrit:
Vous utilisez bien les librairies les algorithmes de
http://www.ijg.org
Puisque XnView apparaît dans la liste des utilisateurs de la "Lossless
jpegtran"
http://sylvana.net/jpegcrop/losslessapps.html
Dans l'affirmative, la rotation doit être la même avec tous ces logiciels ?

Oui, ç la meme chose, donc pareil pour tous les logiciels.
/************************************************************************************************************************************/

Le Wed, 29 Sep 2004 12:37:40 +0200, fplanglois a écrit :

fplanglois a écrit:
Depuis le temps que je prétends que le sans perte est totalement sans perte,
pour vu que les dimensions de l'image soient des multiples de 8.

Ce qui m'inquiète c'est ce que j'obtiens qui montre qu'à partir de ma
photo en 600x400 j'ai un écart avec la rotation de jpegtran. Enfin je
pense ...

Je viens de réaliser successivement des rotations "sans perte" sur le même
JPEG. On voit que le poids en octets retombe sur des valeurs de manière
cyclique.
Après la perte initiale, on retombe sur un cycle de 4.

Eh oui 90° + 90° + 90° + 90° me donne aussi une photo identique mais
pas pour les intermédiaires.

--
Stephan Peccini
Nature : <URL:http://nature.tesenca.info>
Seurasaari : <URL:http://seurasaari.tesenca.info>

Stephan Peccini wrote:

fplanglois a écrit:
Depuis le temps que je prétends que le sans perte est totalement sans perte,
pour vu que les dimensions de l'image soient des multiples de 8.

Ce qui m'inquiète c'est ce que j'obtiens qui montre qu'à partir de ma
photo en 600x400 j'ai un écart avec la rotation de jpegtran. Enfin je
pense ...

En fait si j'ai bien compris tu ouvres dans gimp la photo originale et la photo
tournée par jpegtran, puis tu tournes la photo originale avec gimp (en
memoire sans sauver), puis tu compares les 2. Et il y a une différence.

Au lieu de montrer l'histogramme, peux-tu montrer le résultat, éventuellement
en boostant à mort le contraste pour voir où ça se passe.

Je viens de réaliser successivement des rotations "sans perte" sur le même
JPEG. On voit que le poids en octets retombe sur des valeurs de manière
cyclique.
Après la perte initiale, on retombe sur un cycle de 4.

Eh oui 90° + 90° + 90° + 90° me donne aussi une photo identique mais
pas pour les intermédiaires.

En fait c'est l'essentiel il me semble. Le but est de ne pas perdre
d'information. Si en 4 opérations successives on retombe sur la même
image au pixel près, c'est bien qu'aucune information n'est perdue
dans la bagarre. Le reste n'est que coupage de cheveux en 4 sans
grand intérêt.

--
F.J.

Le Wed, 29 Sep 2004 13:50:34 +0200, François Jouve a écrit :

En fait c'est l'essentiel il me semble. Le but est de ne pas perdre
d'information. Si en 4 opérations successives on retombe sur la même
image au pixel près, c'est bien qu'aucune information n'est perdue
dans la bagarre. Le reste n'est que coupage de cheveux en 4 sans
grand intérêt.

Je ne suis pas d'accord. En exagérant : f(x)=1/x ; f(f(x))=x n'implique
pas que que l'on a la même information avec une seule application de f().

Ce que montre ton test est que :
rotation(rotation(fichier, A1), A2) donne le même fichier quand A1+A1 = 0
modulo 360°. Il n'y a peut-être pas perte d'information au sens où on
peut la récupérer après application d'autres rotations.

Je viens de faire la même opération que celle que je décrit mais avec
une image carrée et symétrique, en fait un carré noir centré sur fond
blanc. Je l'ai transformée par jpegtran et ensuite la comparaison dans
gimp ne me donne aucune différence après avoir fait faire une rotation
de 90°. Et avec le même protocole, j'ai une différence sur ma photo de
référence. Donc il y a un problème quelque part.

--
Stephan Peccini
Nature : <URL:http://nature.tesenca.info>
Seurasaari : <URL:http://seurasaari.tesenca.info>