Une question concernant les fichiers JPG : les fichiers récupérés d'un
appareil numérique sont, le plus souvent, déjà au format JPEG.
Après un traitement logiciel, en quelle "qualité JPEG" est-il préférable de
sauvegarder ?
Si l'on choisit 100%, la taille du fichier peut être multipliée par 5.
Si l'on choisit 80-90 %, est-ce que cela signifie forcément que la qualité
finale est de 0,8 (compression appareil) x 0,8 (compression du logiciel) ?
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:41e3169a$0$31776$
Pierre CHAUVEAU a dit ça :
dans le premier groupe : 2=3<>1 dans le second : 4=5 et biensur : 4<>3
tu as donc en fait 3 algos différents sur les 5 images que tu m'as transmis.
--
Apparemment mon post d'hier au soir n'est pas passé. Je reprends.
J'ai refait mes tests, je confirme ce que j'ai trouvé.
Dans tes équations/inéquations, rien ne montre que 1<>5. Si alors 1=5 (qui reste quand même à démontrer), alors ma proposition est exacte.
Quel écarts (en LSB) trouves-tu entre les fichiers ? Pour moi, c'est limité à 2 LSB.
Cordialement.
Pierre.
HyperDupont
Pano wrote:
80% de 13.5 = 10.8. Je ne retrouve pas 1.8 Mo. Y a comme un défaut.
Il n'y a pas de "défaut". En fait, 1,8 Mo est la taille du fichier JPEG de l'appareil photo : je ne connais pas son taux de compression. J'ai cité 80 % pour illustrer le calcul 0,8*0,8...
Pour recentrer le débat :
- je pars d'une image Jpeg de taille 1,8 Mo provenant d'un appareil photon umérique - j'utilise un outil de retouche et je veux sauvegarder le fichier au format Jpeg. Sur DCE par ex., au moment de la sauvegarde, j'ai le choix entre plusieurs "qualités" : 100%, par ex., qui génère alors un fichier de...5,2 Mo, 85 % qui génère un fichier de 830 Ko, etc.
Les réponses "quantitatives" n'ont pas de sens. Le format jpg est un format de compression **destructif**. Décompresser du jpg de l'appareil pour affichage dans PSP ou toshop, ce **n'est_pas** reconstituer l'image bitmap telle que perçus par le capteur, ou plutôt déjà déduite du "raw" capteur par le processeur entre capteur et mémoire. Chaque décompression/recompression perd de l'info, c'est la rançon de l' "efficacité" du format jpg par rapport au zip par exemple (zipper une image de 28MO -24*36 quasi cadré 100% scanné à 2700ppi donnera un zip de 14 à 26MO, parfois plus, selon la complexité de l'image et son nombre de couleurs effectives, en fait on ne comprimera que les zones saturées ou très sous-ex, seules zones où des valeurs de couleur se répètent).
On peut simplement dire qu'il est inutile de conserver après traitement une image avec un taux de perte inférieur à celui qu'elle avait **avant** d'être affichée, le gain étant des données "inventées" et qui le seront à chaque décompression à partir du fichier tel que sorti de l'APN. Cela ne veut pas dire qu'il faut que l'image traitée ait la même taille quand on l'enregistrera en jpg. Dans l'idéal il faudrait chercher **avant traitement** le coeff de compression qui donne la même taille, puis traiter et utiliser ce taux au moment de l'enregistrement. En effet, tout relevage de contraste local augmente à paramétrage égal la taille finale du jpg, toute diminution (ex: tout type de suppression de bruit :dépoussiérage, ou mise au noir/mise au blanc sur critère de seuil) diminue l'information globale, donc le volume final à "perte" égale en jpg, comme d'ailleurs il rend l'image zippable plus efficacement en augmentant le taux de données "répétées").
-- Posté via http://www.webatou.net/ Usenet dans votre navigateur ! Complaints-To:
Pano wrote:
80% de 13.5 = 10.8. Je ne retrouve pas 1.8 Mo. Y a comme un défaut.
Il n'y a pas de "défaut".
En fait, 1,8 Mo est la taille du fichier JPEG de l'appareil photo : je ne
connais pas son taux de compression.
J'ai cité 80 % pour illustrer le calcul 0,8*0,8...
Pour recentrer le débat :
- je pars d'une image Jpeg de taille 1,8 Mo provenant d'un appareil photon
umérique
- j'utilise un outil de retouche et je veux sauvegarder le fichier au format
Jpeg. Sur DCE par ex., au moment de la sauvegarde,
j'ai le choix entre plusieurs "qualités" : 100%, par ex., qui génère alors
un fichier de...5,2 Mo, 85 % qui génère un fichier de 830 Ko, etc.
Les réponses "quantitatives" n'ont pas de sens. Le format jpg est un
format de compression **destructif**.
Décompresser du jpg de l'appareil pour affichage dans PSP ou toshop, ce
**n'est_pas** reconstituer l'image bitmap telle que perçus par le capteur,
ou plutôt déjà déduite du "raw" capteur par le processeur entre capteur
et mémoire. Chaque décompression/recompression perd de l'info, c'est la
rançon de l' "efficacité" du format jpg par rapport au zip par exemple
(zipper une image de 28MO -24*36 quasi cadré 100% scanné à 2700ppi
donnera un zip de 14 à 26MO, parfois plus, selon la complexité de l'image
et son nombre de couleurs effectives, en fait on ne comprimera que les
zones saturées ou très sous-ex, seules zones où des valeurs de couleur se
répètent).
On peut simplement dire qu'il est inutile de conserver après traitement
une image avec un taux de perte inférieur à celui qu'elle avait **avant**
d'être affichée, le gain étant des données "inventées" et qui le seront à
chaque décompression à partir du fichier tel que sorti de l'APN.
Cela ne veut pas dire qu'il faut que l'image traitée ait la même taille
quand on l'enregistrera en jpg.
Dans l'idéal il faudrait chercher **avant traitement** le coeff de
compression qui donne la même taille, puis traiter et utiliser ce taux au
moment de l'enregistrement. En effet, tout relevage de contraste local
augmente à paramétrage égal la taille finale du jpg, toute diminution (ex:
tout type de suppression de bruit :dépoussiérage, ou mise au noir/mise au
blanc sur critère de seuil) diminue l'information globale, donc le volume
final à "perte" égale en jpg, comme d'ailleurs il rend l'image zippable
plus efficacement en augmentant le taux de données "répétées").
--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To: abuse@webatou.net
80% de 13.5 = 10.8. Je ne retrouve pas 1.8 Mo. Y a comme un défaut.
Il n'y a pas de "défaut". En fait, 1,8 Mo est la taille du fichier JPEG de l'appareil photo : je ne connais pas son taux de compression. J'ai cité 80 % pour illustrer le calcul 0,8*0,8...
Pour recentrer le débat :
- je pars d'une image Jpeg de taille 1,8 Mo provenant d'un appareil photon umérique - j'utilise un outil de retouche et je veux sauvegarder le fichier au format Jpeg. Sur DCE par ex., au moment de la sauvegarde, j'ai le choix entre plusieurs "qualités" : 100%, par ex., qui génère alors un fichier de...5,2 Mo, 85 % qui génère un fichier de 830 Ko, etc.
Les réponses "quantitatives" n'ont pas de sens. Le format jpg est un format de compression **destructif**. Décompresser du jpg de l'appareil pour affichage dans PSP ou toshop, ce **n'est_pas** reconstituer l'image bitmap telle que perçus par le capteur, ou plutôt déjà déduite du "raw" capteur par le processeur entre capteur et mémoire. Chaque décompression/recompression perd de l'info, c'est la rançon de l' "efficacité" du format jpg par rapport au zip par exemple (zipper une image de 28MO -24*36 quasi cadré 100% scanné à 2700ppi donnera un zip de 14 à 26MO, parfois plus, selon la complexité de l'image et son nombre de couleurs effectives, en fait on ne comprimera que les zones saturées ou très sous-ex, seules zones où des valeurs de couleur se répètent).
On peut simplement dire qu'il est inutile de conserver après traitement une image avec un taux de perte inférieur à celui qu'elle avait **avant** d'être affichée, le gain étant des données "inventées" et qui le seront à chaque décompression à partir du fichier tel que sorti de l'APN. Cela ne veut pas dire qu'il faut que l'image traitée ait la même taille quand on l'enregistrera en jpg. Dans l'idéal il faudrait chercher **avant traitement** le coeff de compression qui donne la même taille, puis traiter et utiliser ce taux au moment de l'enregistrement. En effet, tout relevage de contraste local augmente à paramétrage égal la taille finale du jpg, toute diminution (ex: tout type de suppression de bruit :dépoussiérage, ou mise au noir/mise au blanc sur critère de seuil) diminue l'information globale, donc le volume final à "perte" égale en jpg, comme d'ailleurs il rend l'image zippable plus efficacement en augmentant le taux de données "répétées").
-- Posté via http://www.webatou.net/ Usenet dans votre navigateur ! Complaints-To:
Papy Bernard
Slt, D'"HyperDupont"
Les réponses "quantitatives" n'ont pas de sens. Le format jpg est un format de compression **destructif**.
Dans l'idéal il faudrait chercher **avant traitement** le coeff de compression qui donne la même taille, puis traiter et utiliser ce taux au moment de l'enregistrement.
Avec PaintShop, après chargement de l'image, la solution consiste "enregistrer sous" *.JPG et Options/Optimiser et jouer du curseur jusqu'à avoir un poids de fichier approchant de celui du fichier original et de noter le facteur de compression correspondant. Il semblerait qu'un facteur de 95 sous PaintShop soit monnaie courante pour les fichiers d'APN. JpegOptimizer est plus immédiat mais demande à ce que la correspondance soit faite avec son programme de traitement d'images préféré.
-- A+ Papy Bernard (RTCien malgré lui)
Slt,
D'"HyperDupont"
Les réponses "quantitatives" n'ont pas de sens. Le format jpg est un
format de compression **destructif**.
Dans l'idéal il faudrait chercher **avant traitement** le coeff de
compression qui donne la même taille, puis traiter et utiliser ce taux au
moment de l'enregistrement.
Avec PaintShop, après chargement de l'image, la solution consiste
"enregistrer sous" *.JPG et Options/Optimiser et jouer du curseur jusqu'à
avoir un poids de fichier approchant de celui du fichier original et de
noter le facteur de compression correspondant.
Il semblerait qu'un facteur de 95 sous PaintShop soit monnaie courante pour
les fichiers d'APN.
JpegOptimizer est plus immédiat mais demande à ce que la correspondance soit
faite avec son programme de traitement d'images préféré.
Les réponses "quantitatives" n'ont pas de sens. Le format jpg est un format de compression **destructif**.
Dans l'idéal il faudrait chercher **avant traitement** le coeff de compression qui donne la même taille, puis traiter et utiliser ce taux au moment de l'enregistrement.
Avec PaintShop, après chargement de l'image, la solution consiste "enregistrer sous" *.JPG et Options/Optimiser et jouer du curseur jusqu'à avoir un poids de fichier approchant de celui du fichier original et de noter le facteur de compression correspondant. Il semblerait qu'un facteur de 95 sous PaintShop soit monnaie courante pour les fichiers d'APN. JpegOptimizer est plus immédiat mais demande à ce que la correspondance soit faite avec son programme de traitement d'images préféré.
-- A+ Papy Bernard (RTCien malgré lui)
Faelan
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:41e30a56$0$31804$
Par contre, j'ai fait la comparaison pixel à pixel entre chacun de ces fichiers : aucun écart, ils sont strictement identiques quand aux données images.
Salut Pierre, je doute de ce résultat, sauf si en effet les algos sont rigoureusement identiques.
voici le protocole de comparaison d'image que j'utilise : (sous PSP6, ou soft permettant les traitements décrits)) 1/ traitement arithmétique : soustraction de l'image originale et de l'image
sauvegardée. 2/ solarisation de l'image obtenue avec seuil réglé au plus bas (niveau 1).
La différence entre les deux images apparait de façon évidente : Si la l'opération est "réussie", l'image apparait noir. Si elle est moyenne ou mauvaise, la "trame" de l'image réapparait sur fond noir.
c'est imparable !
Il y a des choses amusantes quand on compare les logiciels.
Un jour, il y a un ou deux ans, je devais réduire des photos à moins de 10K.
J'ai réduit la taille à 400X300, puis j'ai essayé de descendre en dessous des 10K avec Irfanview. Pour certaines photos, impossible. A un certain moment, la qualité diminuait, mais la taille se stabilisait à 15-16K. J'ai alors pris PSP7 (à l'époque), et j'ai pu descendre en dessous de 10K sans problème et avec une qualité d'image correcte. (Attention, il ne s'agit pas d'un test exhaustif et scientifique : seulement d'une expérience isolée avec quelques photos particulières et les versions de soft de l'époque).
Même pour un format standard, il y a donc des différences d'algorithmes entre les softs, et certaines de ces différences jouent manifestement sur la qualité et la performance de compression....
-- F.
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de
news:41e30a56$0$31804$626a14ce@news.free.fr...
Par contre, j'ai fait la comparaison pixel à pixel entre chacun de ces
fichiers : aucun écart, ils sont strictement identiques quand aux
données images.
Salut Pierre,
je doute de ce résultat, sauf si en effet les algos sont rigoureusement
identiques.
voici le protocole de comparaison d'image que j'utilise :
(sous PSP6, ou soft permettant les traitements décrits))
1/ traitement arithmétique : soustraction de l'image originale et de
l'image
sauvegardée.
2/ solarisation de l'image obtenue avec seuil réglé au plus bas (niveau
1).
La différence entre les deux images apparait de façon évidente :
Si la l'opération est "réussie", l'image apparait noir.
Si elle est moyenne ou mauvaise, la "trame" de l'image réapparait sur fond
noir.
c'est imparable !
Il y a des choses amusantes quand on compare les logiciels.
Un jour, il y a un ou deux ans, je devais réduire des photos à moins de 10K.
J'ai réduit la taille à 400X300, puis j'ai essayé de descendre en dessous
des 10K avec Irfanview. Pour certaines photos, impossible. A un certain
moment, la qualité diminuait, mais la taille se stabilisait à 15-16K.
J'ai alors pris PSP7 (à l'époque), et j'ai pu descendre en dessous de 10K
sans problème et avec une qualité d'image correcte.
(Attention, il ne s'agit pas d'un test exhaustif et scientifique : seulement
d'une expérience isolée avec quelques photos particulières et les versions
de soft de l'époque).
Même pour un format standard, il y a donc des différences d'algorithmes
entre les softs, et certaines de ces différences jouent manifestement sur la
qualité et la performance de compression....
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:41e30a56$0$31804$
Par contre, j'ai fait la comparaison pixel à pixel entre chacun de ces fichiers : aucun écart, ils sont strictement identiques quand aux données images.
Salut Pierre, je doute de ce résultat, sauf si en effet les algos sont rigoureusement identiques.
voici le protocole de comparaison d'image que j'utilise : (sous PSP6, ou soft permettant les traitements décrits)) 1/ traitement arithmétique : soustraction de l'image originale et de l'image
sauvegardée. 2/ solarisation de l'image obtenue avec seuil réglé au plus bas (niveau 1).
La différence entre les deux images apparait de façon évidente : Si la l'opération est "réussie", l'image apparait noir. Si elle est moyenne ou mauvaise, la "trame" de l'image réapparait sur fond noir.
c'est imparable !
Il y a des choses amusantes quand on compare les logiciels.
Un jour, il y a un ou deux ans, je devais réduire des photos à moins de 10K.
J'ai réduit la taille à 400X300, puis j'ai essayé de descendre en dessous des 10K avec Irfanview. Pour certaines photos, impossible. A un certain moment, la qualité diminuait, mais la taille se stabilisait à 15-16K. J'ai alors pris PSP7 (à l'époque), et j'ai pu descendre en dessous de 10K sans problème et avec une qualité d'image correcte. (Attention, il ne s'agit pas d'un test exhaustif et scientifique : seulement d'une expérience isolée avec quelques photos particulières et les versions de soft de l'époque).
Même pour un format standard, il y a donc des différences d'algorithmes entre les softs, et certaines de ces différences jouent manifestement sur la qualité et la performance de compression....
-- F.
Alf92
FiLH a dit ça :
Je passe sur cette réaction puérile, c'était une boutade, t'as marché dedans.
ça porte bonheur...
-- Cordialement, Alf92
FiLH a dit ça :
Je passe sur cette réaction puérile, c'était une boutade, t'as marché
dedans.
Je passe sur cette réaction puérile, c'était une boutade, t'as marché dedans.
ça porte bonheur...
-- Cordialement, Alf92
Alf92
Faelan a dit ça :
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:41e30a56$0$31804$
Par contre, j'ai fait la comparaison pixel à pixel entre chacun de ces fichiers : aucun écart, ils sont strictement identiques quand aux données images.
Salut Pierre, je doute de ce résultat, sauf si en effet les algos sont rigoureusement identiques.
voici le protocole de comparaison d'image que j'utilise : (sous PSP6, ou soft permettant les traitements décrits)) 1/ traitement arithmétique : soustraction de l'image originale et de l'image
sauvegardée. 2/ solarisation de l'image obtenue avec seuil réglé au plus bas (niveau 1).
La différence entre les deux images apparait de façon évidente : Si la l'opération est "réussie", l'image apparait noir. Si elle est moyenne ou mauvaise, la "trame" de l'image réapparait sur fond noir.
c'est imparable !
Il y a des choses amusantes quand on compare les logiciels.
Un jour, il y a un ou deux ans, je devais réduire des photos à moins de 10K.
J'ai réduit la taille à 400X300, puis j'ai essayé de descendre en dessous des 10K avec Irfanview. Pour certaines photos, impossible. A un certain moment, la qualité diminuait, mais la taille se stabilisait à 15-16K. J'ai alors pris PSP7 (à l'époque), et j'ai pu descendre en dessous de 10K sans problème et avec une qualité d'image correcte. (Attention, il ne s'agit pas d'un test exhaustif et scientifique : seulement d'une expérience isolée avec quelques photos particulières et les versions de soft de l'époque).
Même pour un format standard, il y a donc des différences d'algorithmes entre les softs, et certaines de ces différences jouent manifestement sur la qualité et la performance de compression....
Salut,
la taille mini de 10~15Ko que tu obtenais correspondait à des données relatives à l'image (JPG), et surtout à divers infos contenu dans le fichier (Exif ou autres...)
-- Cordialement, Alf92
Faelan a dit ça :
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de
news:41e30a56$0$31804$626a14ce@news.free.fr...
Par contre, j'ai fait la comparaison pixel à pixel entre chacun de
ces fichiers : aucun écart, ils sont strictement identiques quand
aux données images.
Salut Pierre,
je doute de ce résultat, sauf si en effet les algos sont
rigoureusement identiques.
voici le protocole de comparaison d'image que j'utilise :
(sous PSP6, ou soft permettant les traitements décrits))
1/ traitement arithmétique : soustraction de l'image originale et de
l'image
sauvegardée.
2/ solarisation de l'image obtenue avec seuil réglé au plus bas
(niveau
1).
La différence entre les deux images apparait de façon évidente :
Si la l'opération est "réussie", l'image apparait noir.
Si elle est moyenne ou mauvaise, la "trame" de l'image réapparait
sur fond noir.
c'est imparable !
Il y a des choses amusantes quand on compare les logiciels.
Un jour, il y a un ou deux ans, je devais réduire des photos à moins
de 10K.
J'ai réduit la taille à 400X300, puis j'ai essayé de descendre en
dessous des 10K avec Irfanview. Pour certaines photos, impossible. A
un certain moment, la qualité diminuait, mais la taille se
stabilisait à 15-16K.
J'ai alors pris PSP7 (à l'époque), et j'ai pu descendre en dessous de
10K sans problème et avec une qualité d'image correcte.
(Attention, il ne s'agit pas d'un test exhaustif et scientifique :
seulement d'une expérience isolée avec quelques photos particulières
et les versions de soft de l'époque).
Même pour un format standard, il y a donc des différences
d'algorithmes entre les softs, et certaines de ces différences jouent
manifestement sur la qualité et la performance de compression....
Salut,
la taille mini de 10~15Ko que tu obtenais correspondait à des données
relatives à l'image (JPG), et surtout à divers infos contenu dans le fichier
(Exif ou autres...)
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:41e30a56$0$31804$
Par contre, j'ai fait la comparaison pixel à pixel entre chacun de ces fichiers : aucun écart, ils sont strictement identiques quand aux données images.
Salut Pierre, je doute de ce résultat, sauf si en effet les algos sont rigoureusement identiques.
voici le protocole de comparaison d'image que j'utilise : (sous PSP6, ou soft permettant les traitements décrits)) 1/ traitement arithmétique : soustraction de l'image originale et de l'image
sauvegardée. 2/ solarisation de l'image obtenue avec seuil réglé au plus bas (niveau 1).
La différence entre les deux images apparait de façon évidente : Si la l'opération est "réussie", l'image apparait noir. Si elle est moyenne ou mauvaise, la "trame" de l'image réapparait sur fond noir.
c'est imparable !
Il y a des choses amusantes quand on compare les logiciels.
Un jour, il y a un ou deux ans, je devais réduire des photos à moins de 10K.
J'ai réduit la taille à 400X300, puis j'ai essayé de descendre en dessous des 10K avec Irfanview. Pour certaines photos, impossible. A un certain moment, la qualité diminuait, mais la taille se stabilisait à 15-16K. J'ai alors pris PSP7 (à l'époque), et j'ai pu descendre en dessous de 10K sans problème et avec une qualité d'image correcte. (Attention, il ne s'agit pas d'un test exhaustif et scientifique : seulement d'une expérience isolée avec quelques photos particulières et les versions de soft de l'époque).
Même pour un format standard, il y a donc des différences d'algorithmes entre les softs, et certaines de ces différences jouent manifestement sur la qualité et la performance de compression....
Salut,
la taille mini de 10~15Ko que tu obtenais correspondait à des données relatives à l'image (JPG), et surtout à divers infos contenu dans le fichier (Exif ou autres...)
-- Cordialement, Alf92
Alf92
Pierre CHAUVEAU a dit ça :
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:41e3169a$0$31776$
Pierre CHAUVEAU a dit ça :
dans le premier groupe : 2=3<>1 dans le second : 4=5 et biensur : 4<>3
tu as donc en fait 3 algos différents sur les 5 images que tu m'as transmis.
--
Apparemment mon post d'hier au soir n'est pas passé. Je reprends.
J'ai refait mes tests, je confirme ce que j'ai trouvé.
Dans tes équations/inéquations, rien ne montre que 1<>5. Si alors 1=5 (qui reste quand même à démontrer), alors ma proposition est exacte.
Quel écarts (en LSB) trouves-tu entre les fichiers ? Pour moi, c'est limité à 2 LSB.
après test : 1<>5. pas de quantification possible avec ma méthodologie de test, juste la constation.
-- Cordialement, Alf92
Pierre CHAUVEAU a dit ça :
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de
news:41e3169a$0$31776$626a14ce@news.free.fr...
Pierre CHAUVEAU a dit ça :
dans le premier groupe : 2=3<>1
dans le second : 4=5
et biensur : 4<>3
tu as donc en fait 3 algos différents sur les 5 images que tu m'as
transmis.
--
Apparemment mon post d'hier au soir n'est pas passé. Je reprends.
J'ai refait mes tests, je confirme ce que j'ai trouvé.
Dans tes équations/inéquations, rien ne montre que 1<>5. Si alors 1=5
(qui reste quand même à démontrer), alors ma proposition est exacte.
Quel écarts (en LSB) trouves-tu entre les fichiers ? Pour moi, c'est
limité à 2 LSB.
après test : 1<>5.
pas de quantification possible avec ma méthodologie de test, juste la
constation.
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:41e3169a$0$31776$
Pierre CHAUVEAU a dit ça :
dans le premier groupe : 2=3<>1 dans le second : 4=5 et biensur : 4<>3
tu as donc en fait 3 algos différents sur les 5 images que tu m'as transmis.
--
Apparemment mon post d'hier au soir n'est pas passé. Je reprends.
J'ai refait mes tests, je confirme ce que j'ai trouvé.
Dans tes équations/inéquations, rien ne montre que 1<>5. Si alors 1=5 (qui reste quand même à démontrer), alors ma proposition est exacte.
Quel écarts (en LSB) trouves-tu entre les fichiers ? Pour moi, c'est limité à 2 LSB.
après test : 1<>5. pas de quantification possible avec ma méthodologie de test, juste la constation.
-- Cordialement, Alf92
Alf92
Alf92 a dit ça :
dans le premier groupe : 2=3<>1 dans le second : 4=5 et biensur : 4<>3
tu as donc en fait 3 algos différents sur les 5 images que tu m'as transmis.
--
Apparemment mon post d'hier au soir n'est pas passé. Je reprends.
J'ai refait mes tests, je confirme ce que j'ai trouvé.
Dans tes équations/inéquations, rien ne montre que 1<>5. Si alors 1=5 (qui reste quand même à démontrer), alors ma proposition est exacte.
Quel écarts (en LSB) trouves-tu entre les fichiers ? Pour moi, c'est limité à 2 LSB.
après test : 1<>5. pas de quantification possible avec ma méthodologie de test, juste la constation.
à ta demande, j'ai refait le test. je me suis trompé dans l'appellation de mes fichiers résultant des tests. je trouve donc (après double vérification) : 1=4=5 (http://frpn.free.fr/1&5.gif) 2=3 2<>1 je retombe bien sur tes résultats. 1000 excuses !
-- Cordialement, Alf92
Alf92 a dit ça :
dans le premier groupe : 2=3<>1
dans le second : 4=5
et biensur : 4<>3
tu as donc en fait 3 algos différents sur les 5 images que tu m'as
transmis.
--
Apparemment mon post d'hier au soir n'est pas passé. Je reprends.
J'ai refait mes tests, je confirme ce que j'ai trouvé.
Dans tes équations/inéquations, rien ne montre que 1<>5. Si alors 1=5
(qui reste quand même à démontrer), alors ma proposition est exacte.
Quel écarts (en LSB) trouves-tu entre les fichiers ? Pour moi, c'est
limité à 2 LSB.
après test : 1<>5.
pas de quantification possible avec ma méthodologie de test, juste la
constation.
à ta demande, j'ai refait le test.
je me suis trompé dans l'appellation de mes fichiers résultant des tests.
je trouve donc (après double vérification) :
1=4=5 (http://frpn.free.fr/1&5.gif)
2=3
2<>1
je retombe bien sur tes résultats.
1000 excuses !
dans le premier groupe : 2=3<>1 dans le second : 4=5 et biensur : 4<>3
tu as donc en fait 3 algos différents sur les 5 images que tu m'as transmis.
--
Apparemment mon post d'hier au soir n'est pas passé. Je reprends.
J'ai refait mes tests, je confirme ce que j'ai trouvé.
Dans tes équations/inéquations, rien ne montre que 1<>5. Si alors 1=5 (qui reste quand même à démontrer), alors ma proposition est exacte.
Quel écarts (en LSB) trouves-tu entre les fichiers ? Pour moi, c'est limité à 2 LSB.
après test : 1<>5. pas de quantification possible avec ma méthodologie de test, juste la constation.
à ta demande, j'ai refait le test. je me suis trompé dans l'appellation de mes fichiers résultant des tests. je trouve donc (après double vérification) : 1=4=5 (http://frpn.free.fr/1&5.gif) 2=3 2<>1 je retombe bien sur tes résultats. 1000 excuses !
-- Cordialement, Alf92
Philippe LAGARDE
Chaque décompression/recompression perd de l'info,
Ben non, justement (si pas de modif). La partie "compression" du JPEG est non destructive. C'est le seuillage qui l'est.
Cordialement,
-- Philippe LAGARDE www.mise-en-lumiere.org
Chaque décompression/recompression perd de l'info,
Ben non, justement (si pas de modif). La partie "compression" du JPEG est
non destructive. C'est le seuillage qui l'est.
