perte qualité ?

Az Sam avait soumis l'idée :

"JmG" <JMGB@antipourrielsLACASE.COM> a écrit dans le message de news:
1h2whe8.fcrtbs1i1m67eN%

Quand tu vois comment sont disposés les pixels avant/après la
compression JPEG déjà, ensuite, quand tu vois comment ils sont disposés
(en très fort grossissement) avant et après rotation, tu te dis
(enfin... moi, je me dis :) qu'une re-compression ne sera pas anodine.

voici un essai sur votre discussion :

ici, un fichier enregistrer en jpg 90% par irfanview sur la base d'un
original jpg de mon apn : http://www.hostimage.org/img/3185218.jpg = F1

ici, le fichier (F1) du dessus apres 200rotation 90° a droite par irfanview
(intitulee rotation sans perte, il y a ecrasement systematique) puis
reenregistrement par irfanview en JPG 90% :
http://www.hostimage.org/img/085298531.jpg = F2

enfin, toujours le premier fichier (F1) enregistrer cette fois 50 fois de
suite en jpg 90% par irfanview :
http://www.hostimage.org/img/88301346.jpg = F3

vous voyez des differences ?

quelques chiffres :
F1 = 353 043 octets
F2 = 353 142 octets
F3 = 352 992 octets

merci, ça confirme mes affirmations et ça n'entache en rien ce que
disent les autres puisque jean pierre roche parle de destruction
seulement sur les parties retravaillées et pas sur les autres.
mais pour les rotations, ça confirme merci.
bien le bonhomme de neige sans neige.
a la vue, on voit rien, et ce n'est pas ces quelques octets en moins
sur tant de rotations qui vont nous emmerder non?.
A+

--
A+ tiens nous au courant, ce serait COOL ;-)

olivier B. <bon@anttippub-chez.com> wrote:

je te dit qu'une compression derriere une autre ne change rien en jpeg.

ben ça dépendrait pas, tout de même un peu, du taux de compression
choisi, non ?!


A+ !


NoNo.

--
Anyway The Wind Blows...

Jean-Pierre Roche <jpierreroche@sanspub.invalid> wrote:

Penses-tu que depuis 15 ans je ne me sois pas posé une seule question?
Alors, je ne suis pas spécialiste des technos de compression, mais j'ai
déjà eu la curiosité -oui- de voir ce que donnaient différentes
compressions sur différentes images, oui.

J'espère bien que tu as essayé ! Mais quand on ne sait pas
ce qu'on cherche on essaie parfois sans trouver...

Certes, mais en même temps, ici, on parle de "compression destructive"
donc, ça aide un peu à trouver ce qu'on cherche, hein! :)

Le JPEG est destructeur, point-barre.
Personne n'a jamais dit que *toutes* opérations étaient soumises à
destruction par le JPEG, dans ce fil.

Voir à ce sujet, le copié/collé que j'ai fait dans un autre post

Je l'ai lu...
Je te renvoie, du coup à ce lien
<http://www.library.cornell.edu/preservation/tutorial-french/presentatio
n/table7-1.html>
qui est un tableau reprenant les formats graphiques et leurs
particularités.

Bo, je ne cherche pas du tout à entrer dans une bataille de "liens pour"
"liens contre" mais juste... comme toujours, il n'y a pas qu'une seule
voie.
J'espère que personne n'osera affirmer ici que Cornell University n'est
pas une source fiable... :)

En passant, il y a des alinéas dans ce tableau, en voici un extrait:

**********DÉBUT DE CITATION*********
[3] Le format original JPEG comprend un mode non destructif, mais la
plupart des applications ne l'ont jamais supporté. Certains fichiers
appelés JPEG non destructifs sont en fait des fichiers non JPEG dans un
paquetage JFIF. Il existe de nouvelles spécifications concernant le JPEG
non destructif (JPEG-LS) mais elles ne sont pas encore finalisées. ISO
SC29/WG1, "JPEG - Information Links."
[4] Visuellement non destructif se réfère à des techniques de
compression elles-mêmes destructrices, mais qui prennent en compte les
caractéristiques de la vision humaine afin de créer des images
virtuellement indistinguables de leurs formes non compressées.
**********FIN DE CITATION**********

Par ailleurs, sur la page même de JPEG ORG (en Anglais pas contre)
<http://www.jpeg.org/jpeg/index.html>
on peut lire:

*********DÉBUT DE CITATION********
After creating the JPEG standard described above, the committee started
to look at some of the criticisms of the existing standard. High
amongst these was the poor quality (and lack of integration) of lossless
coding in the standard. With this in mind, the committee developed the
JPEG-LS standard - ISO/IEC IS 14495-1 | ITU-T Recommendation T.87.
*********FIN DE CITATION*********

En gros, ça dit qu'ils se sont penchés sur les critiques faites sur ce
standard, l'une des plus importante étant la mauvaise qualité (et le
manque d'intégration) du code non destructif de ce standard!


Et si l'on clique sur le lien JPEG-LS STANDARD on peut lire ça:

**********DÉBUT DE CITATION************
After the success of the series of JPEG standards, the committee decided
it was appropriate to revisit the lossless coding mode within JPEG.
This mode had been a late addition to the standard, and in the baseline
form of JPEG (not using arithmetic coding) the algorithm used was not
really close to 'state of the art' techniques. In addition, it really
was not closely related to the block based DCT techniques which
characterised the lossy compression that had become the norm. Looking
at user requirements, particularly those of the medical imaging business
which was concerned about potential large errors being introduced
through lossy compression, the scope of the new standard was defined as
effective lossless and near lossless compression of continuous-tone,
grey scale and colour still images. By near lossless, it was agreed
that a scheme was needed that guaranteed a maximum error between the
original image data and the reconstructed image data.
**********FIN DE CITATION**********

En gros, ça dit bien que la destruction des pixels étaient très
importantes (particulièrement pour ce qui est de l'imagerie médicale) et
qu'on était loin de l'état de l'art en ce domaine.


*********SUITE DE CITATION*******
A number of contenders for a suitable algorithm were proposed, and the
committee carried out an extensive set of measurements to determine the
best contender. The winner of these objective tests was agreed to be
the LOCO algorithm from HP Labs, whose web site offers extensive
documentation and sample code. As well as being the leading contender,
HP and Mitsubishi both agreed to offer their patents on a royalty and
license fee free basis, ensuring that implementors would hopefully not
need to make any payments to implement the new standard. As well as
offering effective compression, the algorithm was also relatively easy
to implement efficiently in PC software, and produces fast code.

A major side effect of undertaking this standards activity was that some
of the other contenders such as CALIC, FELICS, and Ricoh's CREW
algorithm in particular had some very attractive features - for
example, in the ability to provide a single codestream which could
provide lossy and lossless images without additional processing.
Although outside the direct scope of JPEG-LS, these features and the
discussions they provoked directly led to the development of the
architectural approach of the new JPEG 2000 standard.
***************FIN DE CITATION*************

Donc, le JPEG 2000 est le standard qui contient, actuellement, le
meilleur code "non destructeur" pour ce qui est du JPEG.

Nous ne sommes plus fraiment dans le cadre du JPEG dont nous parlions
ici, ou alors, il aurait fallu préciser que nous parlions du JPEG 2000
spécfiquement, je pense.

Non?

Pas l'enregistrement.

Dans le cas de la rotation sans pertes, si. Car, en fait, il
n'y a pas de recompression.

Ecoute... fait un test.
Prend une image contenant un fort contraste.
Enrgistre là une fois en JPEG.
Rouvre-la.
Ne change rien.
Enregistre-la sous un autre nom, toujours en JPEG (donc tu n'as fait
aucune transformation).
Rouvre la et constate que la répartition des pixels, dans la zone de
fort contraste, n'est plus la même que sur le premier JPEG que tu avais.

Il y a donc bien eu un changement entre les 2 JPEG alors même que tu
n'as fait *aucune* manip toi-même dessus.

1/ ils sont des vendeurs d'abord, donc optimistes, pas menteurs.

Non là ce n'est pas un point sujet à controverse ou
interprétation : sans perte c'est sans perte !

2/ Ils parlent de rotation (et encore, uniquemnt à 90° et là, je ne suis
pas sûr qu'ils précisent ce fait, hein?!), pas d'enregistrement.

Si si c'est bien précisé : c'est une fonction spéciale et ne
peut fournir *que* des rotations à 90° !

Ha... bon... ok, dans ce cas...

Néanmoins, ce que je j'indique sur le test ci-dessus est vrai aussi.
Alors?

Et bien vas y... explique-nous donc, puisque le JPEG n'est pas
destucteur ni rien, pourquoi tu t'emmerdes à stocker du RAW, 100 fois
plus lourd, abscond à mettre en oeuvre, pas géré par plein de softs,
etc...

D'abord je n'ai pas dit que le jpeg était sans pertes mais
que certaines opérations sur une image jpeg pouvaient l'être...
Pour le raw c'est simple : 12 bits (4096 niveaux) contre 8
(256 niveaux) la différence est évidente...

Certes, mais ce n'est pas un réglage obligatoire du RAW.
Rien ne t'empêche de stocker du RAW 8 bits.
Mais bon... je suis d'accord avec toi sur ce point évidemment.

Si tu corriges
une image raw tu peux sortir une image 8 bits avec un
histogramme sans trou, si tu corriges une image 8 bits
(généralement jpeg) tu as un "beau" histogramme en peine.

Ben oui... justement... :)

A part ça le raw c'est une image monochrome et c'est toi qui
décide de la façon de la décoder en couleur : température de
couleur, espace couleur, etc Alors qu'une photo jpeg ou tiff
tu ne peux que lui appliquer des corrections desctructrices.
Et aussi certaines fonctions spéciales comme la correction
du vignettage ou la transformation d'une image "fish-eye" en
rectilinéaire. J'en passe...

Nous sommes d'accord.
Et puisqu'en plus, le JPEG est destructif, ça n'ajoute rien de bon,
évidemment. :)


--
Le génie fait ce qu'il doit.
Le talent fait ce qu'il peut.
*Virer les minuscules pour me répondre*

CrazyGuitarist <virtuose1nospam@free.fr> wrote:

a la vue, on voit rien, et ce n'est pas ces quelques octets en moins
sur tant de rotations qui vont nous emmerder non?.

C'est sûr... mais dire que la rotation d'un JPEG n'apporte aucune
destruction n'est quand même pas juste, donc.

Après qu'on se contente -ou pas- d'une "petite" perte de qualité, à
*chaque* fois qu'on manipule/ré-enregistre un JPEG appartient à chacun.

Beaucoup se contentent de photos sorties d'un GSM "photo" aussi. ;->


--
Le génie fait ce qu'il doit.
Le talent fait ce qu'il peut.
*Virer les minuscules pour me répondre*

Donc, le JPEG 2000 est le standard qui contient, actuellement, le
meilleur code "non destructeur" pour ce qui est du JPEG.

Nous ne sommes plus fraiment dans le cadre du JPEG dont nous parlions
ici, ou alors, il aurait fallu préciser que nous parlions du JPEG 2000
spécfiquement, je pense.

Non?

Non :

Extrait de l'aide de XnView :
Le format de fichier JPG permet un style particulier de
transformation : des transformation sans pertes, qui ne vont
perdre aucune information de l'image. Si vos fichiers sont
au format JPG, alors il est possible de les faire tourner et
effectuer un effet miroir sans perte. C'est particulièrement
intéressant pour les images provenant d'appareil photos
numériques ou de scanner avec lesquels l'orientation de
l'image (vertical/paysage) n'est pas toujours exacte et doit
être corrigée.

Attention, les transformations JPEG sans perte ne
s'effectuent pas commme les autres transformations et effets
dans la mémoire vive mais modifient directement les fichiers
d'origine.

J'ajoute :
Ces opérations sont basées sur le fait que format jpeg
utilise des blocs de 8 X 8 pixels et qu'on peut en changer
l'orientation sans décompression/recompression donc sans
pertes. Il n'y a donc pas de chargement de l'image en
mémoire comme l'indique l'aide. C'est seulement, en quelque
sorte, l'indication de l'ordre de chargement des blocs qui
est modifié. Ce principe est utilisé par les apppareils
photos numériques avec un capteur d'orientation...

Certes, mais ce n'est pas un réglage obligatoire du RAW.
Rien ne t'empêche de stocker du RAW 8 bits.

Oulala... grosse confusion entre le raw de toshop et les raw
des apn, deux choses qui n'ont absolument rien à voir ! Le
raw d'un apn ce sont les données *natives* issues du
capteur. Donc leur structure et leur profondeur (en bits)
sont des données liée à ce capteur : généralement 12 bits
sur les modèles sérieux mais on pourrait voir du 10 bits
(les appareils utilisant un capteur 10 bits n'offrent pas de
réaliser du raw) et il existe au moins un capteur 14 bits.

--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...

http://jpierreroche.free.fr/