Hello,

[Contexte]

Bon je pense que je vais choquer tout le monde (ou quasi tout le monde :p), mais au passage de mon K1 j'ai continué à shooter en JPEG car:
 - j'ai toujours eu des photos en jpeg: j'ai commencé avec des reflex argentiques dont je faisais numériser les négatifs (en jpeg) et je post-traitais directement ces jpegs
 - au passage au numérique (K5) j'ai continué à utiliser le format jpeg
 - au passage du K1 idem
 - je trouve cela suffisant en "qualité" car je n'aime pas forcément les photos ultras parfaites au pixel (et j'ai toujours pas compris le réel intérêt du RAW (non faut pas me taper :p))

Malheureusement (et je plains ceux qui shoot en RAW), je suis passé de jpeg de taille (poids) moyenne de 7Mo en APS-C (K5) à des jpeg de 18Mo en plein format (K1). Remarque mon K1 fait aussi des photos de 7Mo quand j'utilise des objectif non FF.

Bref n'ayant pas envie de stocker des tera et des tera (et des tera et des tera et... ) de photos "brut" (i.e. des jpeg de 18Mo), je commence déjà par supprimer toutes les photos ratés / sans intérêts. Mais même après cette étape, en une soirée de photo de paysages à Paris par exemple, il me reste une 50aine de photos (ce qui est peu) qui me prends 845Mo (ce qui est énorme je trouve)!

[Sujet]

Tout ca pour dire que, étant aussi un gros geek, je me suis codé un petit programme (en Java) qui me recompresse les photos en jouant sur la qualité de compression Jpeg (pour ceux qui ne le savent pas, l'algorithme de compression au format jpeg a en paramètre d'entrée une valeur de qualité / compression: plus on compresse, plus on perd de l'information et l'image devient sale, mais moins l'image pèse lourd; paramètre que l'on retrouve dans tous les programmes de traitement photo lors de la sauvegarde en jpeg (sauf dans ms paint :p)).

[Jpeg Optimizer]

[Description]

Que fait exactement mon programme:
 - il teste toutes les compressions possibles de 50, 60,... à 90% de qualité (pas de 10), puis de 91, 92,... à 99% (pas de 1) (je suppose que le K5, K1,... sauvegarde en qualité 100% donc je ne re-teste pas le 100%)
 - a chaque fois le programme compare les deux images "visuellement" (calcule simple de la moyenne de la distance de chaque composante RGB de chaque pixels des 2 images), et si la différence est trop grande, j'essaye une meilleurs qualité, sinon je sauvegarde (en conservant les données EXIF!).

Pour info, sur mon jeu de test (mes 50 photos), je passe de 845Mo à 118Mo d'espace disque; soit 727Mo d'économisé (soit 86% d'espace disque sauvé).

[Screnshot]



[Résultats]

Un petit résultat où mon programme a trouvé qu'il fallait utiliser une qualité de "50%" en paramètre à la compression jpeg.

Photo originale (ici taille 10%, en png sans perte) qui fait 14.5Mo (en jpeg sur mon disc dur):
(oui c'est mon chat)



Résultat photo compressée (ici taille 10%, en png sans perte), qui ne fait plus que 1.4Mo sur mon disc dur:




Voyez vous une différence entre les 2 photos?

Bon ok, en taille réduite de 10%, c'est impossible à voir (sauf si j'avais compressé comme un goret).
Je mets donc un détails à 100% des 2 photos pour estimer la perte éventuelle de détails (je vous laisser juger):

Photo original (toujours sauvegardé ici en png sans perte pour ne pas fausser le test):




Et détails de la photo compressée (toujours sauvegardé ici en png sans perte pour ne pas fausser le test):



[Remarques]

Comme vous pouvez le voir sur le screenshot de mon programme, chaque photo n'est pas compressée avec le même facteur (pour certaines 65% de qualité suffit, pour d'autres il faut garder 80% etc), c'est un peu le but de mon programme, sinon je mettrai tout à 70% et basta (il me semble que c'est ce que utilise ms paint comme valeur du paramètre).

Comme je l'ai dit, pour la photo de mon chat, le programme à trouvé qu'il suffisait de 50% en paramètre de compression jpeg. Ca parait très peu et en plus il ne teste qu'à partir de cette valeur... ca se trouve avec 40% ou moins ca aurait été acceptable aussi comme résultat.

Mon calcule de diff est le plus basique qu'il soit.
J'ai évidemment essayé en codant les calculs plus complexes qui sont fait notamment en imagerie (comme celui du calcul du Delta-E, qui se base lui sur un autre espace colorimétrique que ce RGB super basique, un qui est plus proche de la perception humaine), mais ca prenait trop trop trop de temps à calculer.

[Améliorations]

Améliorations futures:
 - Du coup tester toutes les compressions possibles à partir de 0%? Car j'avais mis 50 en seuil sans aucun espoir que cela pouvait suffire!
 - Faire une recherche dichotomique du facteur de compression (au lieu de cet espèce de brut force) parce que là ca prend un temps non négligeable mine de rien!
 - Avoir la possibilité de resizer les photos (mais ca je ne suis pas bien sur de l'intéret de réduire la taille largeur/hauteur).


[Conclusion]

Alors qu'en pensez vous?
Utile? Inutile?
Des idées d'améliorations?

Effectivement ça semble intéressant pour ceux qui utilisent le jpeg, je ne crois pas que les logiciels du commerce proposent d'optimiser automatiquement la compression.
La méthode dichotomique me paraît indispensable pour gagner du temps.

Sur tes photos en 1920x941 on voit peu de différences, le niveau de détail ne change pas.

@Ultri: d'où le fait que j'ai mis les grandes photos détaillées...

@tryphon4: oui je vais bosser la dessus.

Mes fichiers DNG issus du K-1 pèsent entre 45 et 50Mo chacun mais personnellement je n'imagine pas travailler en jpeg pour 3 raisons:
- Le jpeg est un format "avec perte", même en qualité 100% il y a de la perte par rapport au fichier RAW (DNG ou PEF).
- la balance des blancs est bien plus facile à corriger en RAW
- le fichier RAW est codé sur 14 bit, le jpeg est codé sur 8 bit, il y a donc moyen de récupérer beaucoup d'informations d'une zone sous-exposée ou sur-exposée en RAW alors qu'en jpeg on récupère uniquement du bruit ou des artefacts.

Ceci dit, le jpeg est intéressant pour archiver les photos après traitement quand on veut économiser de la place.

Hop j'ai mis à jour mon petit soft:
 - Recherche sur l'ensemble de la plage 0-99 (100 est par défaut la version qui sort de l'appareil, je ne reteste pas).
 - Recherche par dichotomie. Comme il y a maxi 100 possibilités (de 0 à 99 inclut), ça fait en tout est pour tout toujours 7 tests à faire (O log(n); en base 2).
 - Un petit bug de supprimé

Je vais rajouter la possibilité de voir les résultats en accolant 2 parties de photos.


Sur mes 82 photos, je gagne déjà quasiment 1Go d'espace de stockage!

Sympa, tu comptes distribuer ce soft une fois finalisé?

Si ca intéresse, je peux le fournir oui!

Plutôt de l'avis de Tryphon4 en ce qui concerne l'utilisation du RAW. 
Cependant, je trouve l'idée de ton soft de compression très bonne !

Bon voila, j'ai pris un peu de temps, j'ai optimisé certains calculs, j'ai rajouté un Viewer, j'ai packagé le tout et...

C'est dispo sur github (source + binaire):
https://collicalex.github.io/JPEGOptimizer/

Comme c'est codé en java, ca doit fonctionner quelque soit le système d'exploitation (Windows, Mac OSX, Linux, Unix, SunOS, ...). Faut juste avoir le JRE d'installé.

C'est capable de remplacer directement vos photos (si source = destination). Pour plus de sécurité, je conseille de mettre un répertoire destination différent au début, sait on jamais :p

Vous pouvez me faire vos retours: bugs, suggestions,...

Merci, ça peut être utile!

Bon et pour ceux qui codent un peu en java, je viens de coder une "lib" (une class) pour extraire les meta data EXIF des JPEG, que je partage ici : https://github.com/collicalex/JExifLib/

Je l'utiliserai dans mon outils (JPEGOptimizer) pour que le viewer de comparaison avant/après affiche les images dans le bon sens (tag exif Orientation).