Image Optimizer

[Shadow]

Le gros soucis ici, c'est que la bibliothèque de pb pour la
compression LZMA est moins bonne que avec 7Zip

[Marc56]

J'ai déjà posté surement un de mes code d'ailleurs ici.

http://www.purebasic.fr/french/viewtopi ... =9&t=14850

[Micoute]

Quand on est accroc, on ne lâche pas prise aussi facilement !

[Marc56]

Tous les mathématiciens, et groupes d'études sur la compression ont mis leur travail en attente de la nouvelle découverte...
Sais-tu au moins, Shadow que les formats JPG et PNG sont déjà des formats compressés ?
Sais-tu que comme tout format compressé il y a plusieurs niveaux de compression ? Donc si tu décompresses un png puis le recompresse avec un autre taux tu auras forcément une taille différente si tu n'a pas relevé le taux original ?
Sais-tu qu'on peut compresser plusieurs fois le même fichier, mais que:
1. On n'y gagne que quelques faibles % à chaque passage
2. Au bout d'un certain nombre de passage le fichier est inutilisable ?
Sans vouloir te décourager, tu as plus de chance de gagner 2 fois de plus au loto que de trouver un nouvel algo de compression en procédant comme tu le fais. Mais qui sait...
Fais des tests objectifs en partant d'une image non-compressée (ex: BMP) puis compare tes résultats avec ceux des algo existants (JPG, PNG)

Un peu de lecture:
https://fr.wikipedia.org/wiki/Compression_d'image
https://fr.wikipedia.org/wiki/Portable_Network_Graphics
https://fr.wikipedia.org/wiki/Compression_fractale

[Patrick88]

le meilleur format de compression ? c'est McKay qui l'a inventé, bien sûr

http://www.stargate-pegasus.com/sga-tec ... cle-2.html

sinon Chuck Norris a surement pondu un algorithme encore plus performant... faut pas déconner ...

Pat

[blendman]

En Png, on peut facilement réduire les images en réduisant le nombre de couleur (sans perte de qualité si on se débrouille bien).
En jpg, c'est un format compressé, donc plus c'est compressé, plus tu perds de la qualité.

J'ai créé un utilitaire PNG reductor qui permet de diminuer le poids d'une image en réduisant considérablement le nombre de couleurs (rgb et canal alpha), et ça fonctionne très bien. En plus l'image obtenue est utilisable telle quelle (dans un jeu ou une application graphique) car ça reste du png .
Toi c'est surtout pour stocker les images (voire les envoyer par email) ?
Mais à ce moment-là, en faire un zip ne suffit-il pas tout simplement ?

[Shadow]

Salut à tous.

Marc56, oui je sais mais j'aime bien faire ça et j'apprends !

blendman, non pas pour envoyer ni quoi que se soit, juste essayer de compresser le plus possible
une image avec une perte de 0 si possible ou alors que se ne se vois pas en zoomant.

Par exemple une méthode qui fonctionne du tonnerre de dieu que certain programme utilise déjà:
Prendre toutes les valeurs R, G, B, A et les mettre soit:

Tous en Pair si ya plus de valeur pair dans l'image
Tous Impair si ya plus de valeur Impair dans l'image

Sinon tu met tout en Pair et basta.
C'est pas tous pardi !

Quand ta fais ça tu divise toutes les valeurs obtenu par 2 l'or du codage
et tu multiplie par 2 au décodage.

Bien sur il faut que les valeurs soit Pair pour faire ça sinon ça fonctionne pas car plus
de perte avec les Impair car ya des décimales qu'il faut arrondir !

La perte est de au pire, 1 R ou / et 1 V ou / et 1 B ou / et 1 A
Ex:

R125, V159, B240, A255 = R124, V158, B240, A254
Diviser par 2 = R62, V79, B120, A127

Comme ceci, la qualité de l'image est encore ni quel
et tu ne vois rien même au zoomant !

On note cependant qu'il y a des valeurs Impair maintenant !

Alors tu peu encore remettre tous en Pair Ou Impair mais y aura encore plus de perte !
Avec un calcule tu peu t'en tirer pour tenter de retrouver la valeur initiale mais pas sur !

Alors tu peut diviser par 4 au lieux de 2, ou 8 etc.

Plus tu va diviser et plus tu aura de perte et plus la qualité de l'image
serra détérioré mais plus tu perdra en taille de l'image !

Tous se que je sais sur les images, c'est avec mes expériences !
Le binaire, et les bases, je l'ais est aussi appris avec mes expériences !

[venom]

Apres pour ce qui est de la compression, 7zip peut facilement se piloté via l'invité de commande. Donc par conséquent, peut facilement ce piloté via purebasic. A voir si on a le droit de trimballer 7zip avec son programme. Comme ça sa evite a l'utilisateur de s'en charger.

Apres si c'est sa, autant ziper directement l'image sans la transformer en txt







@++

[Shadow]

Ah mais ça n'as rien a voir là !
Tu ne peut pas ziper une image, je veux dire que ça ne donnera rien.

Pour 7zip, je ne sais pas mais 7zip est gratuit donc à mon avis oui ?

[Marc56]

Yes, but you are required to specify in your documentation (1) that you used parts of the 7-Zip program, (2) that 7-Zip is licensed under the GNU LGPL license and (3) you must give a link to http://www.7-zip.org, where the source code can be found.

http://www.7-zip.org/faq.html#developer_faq

[Shadow]

Marc56, en français ça aurais été encore mieux !

Oui, mais vous devez spécifier dans votre documentation ( 1 ) que vous avez utilisé des parties du programme 7-Zip , ( 2 ) que 7-Zip est sous la licence GNU LGPL et (3 ), vous devez donner un lien vers http : //www.7-zip.org , où le code source peut être trouvée.

Merci.

Spock, pourtant je peux te certifier que cela fonctionne à merveille !
Et tu as raison, sauf que une fois fais ça, tu as bien
la preuve par toi même que cela fonctionne !

As tu essayé au moins ?
Je pense que oui.

Si tu fais ça, l'image de sortie prends moins de place, pourquoi ?
Parce que tu n'utilise théoriquement plus que 7 bits par valeur et non plus 8 !

255 = 11111111
255 / 2 (Ont arrondis toujours au plus bas) = 127 = 1111111

Sur une image 24 Bits qui fais 1000 x 1000, la taille logique est de 1000 x 1000 x 3 (Largeur x Hauteur x 3 Octets (RGB))
soit un totale de 3 Millions D'octets, ou 1000 x 1000 x 3 x 8 (Bits) = 24 000 000 de Bits ! (24 Bits par couleur)

Sur une image 24 Bits qui fais 1000 x 1000, la taille logique est de 1000 x 1000 x 4 (Largeur x Hauteur x 4 Octets (RGB))
soit un totale de 4 Millions D'octets, ou 1000 x 1000 x 4 x 8 (Bits) = 32 000 000 de Bits ! (32 Bits par couleur)

Sur une image RGB de 16 Bits par couleur, le calcule est ainsi:

Ont divise les valeurs RGB ou RGBA par 4: 255 / 4 = 63 (On arrondis toujours au plus bas)
Soit une valeur de 4 Bits par composante, 16 au totale !

Donc la taille de l'image est théoriquement diviser par 2 ici.

Évidement, faire ça fais perdre de la qualité car il y a de la perte l'or de la division !
Regardez:

255 / 2 = 127 (On arrondis toujours au plus bas)
127 x 2 = 254, Ici ont à perdus 1 Point mais on n'y vois que du feu !
7 Bits par Composante, soit un totale de 21 Bits pour une image 24 Bits et 28 Bits pour une image 32 Bits.

255 / 4 = 63 (On arrondis toujours au plus bas)
63 x 4 = 252, Ici ont à perdus 3 Point, (On ne vois pas trop la différence à ce point mais un peu quand même) !
6 Bits par Composante, soit un totale de 18 Bits pour une image 24 Bits et 24 Bits pour une image 32 Bits.

255 / 8 = 31 (On arrondis toujours au plus bas)
31 x 8 = 248, Ici ont à perdus 7 Point, (On vois la différence à ce point, l'image est moins net) !
5 Bits par Composante, soit un totale de 15 Bits pour une image 24 Bits et 20 Bits pour une image 32 Bits.

255 / 16 = 15 (On arrondis toujours au plus bas)
16 x 16 = 240, Ici ont à perdus 15 Point, (On vois vraiment la différence à ce point, l'image est dégradé) !
4 Bits par Composante, soit un totale de 12 Bits pour une image 24 Bits et 16 Bits pour une image 32 Bit.

Etc.

Je suis étonné que tu ne sache pas ça Spock toi qui est calé en prog

[Micoute]

Tout le monde n'est pas spécialiste de l'image !

[Shadow]

Je ne suis pas un spécialiste Micoute !

[falsam]

Je ne suis pas un spécialiste Micoute !

[Bill Gates]

Marc56, en français ça aurais été encore mieux !

Oui, mais vous devez spécifier dans votre documentation ( 1 ) que vous avez utilisé des parties du programme 7-Zip , ( 2 ) que 7-Zip est sous la licence GNU LGPL et (3 ), vous devez donner un lien vers http : //www.7-zip.org , où le code source peut être trouvée.

Merci.

Spock, pourtant je peux te certifier que cela fonctionne à merveille !
Et tu as raison, sauf que une fois fais ça, tu as bien
la preuve par toi même que cela fonctionne !

As tu essayé au moins ?
Je pense que oui.

Si tu fais ça, l'image de sortie prends moins de place, pourquoi ?
Parce que tu n'utilise théoriquement plus que 7 bits par valeur et non plus 8 !

255 = 11111111
255 / 2 (Ont arrondis toujours au plus bas) = 127 = 1111111

Sur une image 24 Bits qui fais 1000 x 1000, la taille logique est de 1000 x 1000 x 3 (Largeur x Hauteur x 3 Octets (RGB))
soit un totale de 3 Millions D'octets, ou 1000 x 1000 x 3 x 8 (Bits) = 24 000 000 de Bits ! (24 Bits par couleur)

Sur une image 24 Bits qui fais 1000 x 1000, la taille logique est de 1000 x 1000 x 4 (Largeur x Hauteur x 4 Octets (RGB))
soit un totale de 4 Millions D'octets, ou 1000 x 1000 x 4 x 8 (Bits) = 32 000 000 de Bits ! (32 Bits par couleur)

Sur une image RGB de 16 Bits par couleur, le calcule est ainsi:

Ont divise les valeurs RGB ou RGBA par 4: 255 / 4 = 63 (On arrondis toujours au plus bas)
Soit une valeur de 4 Bits par composante, 16 au totale !

Donc la taille de l'image est théoriquement diviser par 2 ici.

Évidement, faire ça fais perdre de la qualité car il y a de la perte l'or de la division !
Regardez:

255 / 2 = 127 (On arrondis toujours au plus bas)
127 x 2 = 254, Ici ont à perdus 1 Point mais on n'y vois que du feu !
7 Bits par Composante, soit un totale de 21 Bits pour une image 24 Bits et 28 Bits pour une image 32 Bits.

255 / 4 = 63 (On arrondis toujours au plus bas)
63 x 4 = 252, Ici ont à perdus 3 Point, (On ne vois pas trop la différence à ce point mais un peu quand même) !
6 Bits par Composante, soit un totale de 18 Bits pour une image 24 Bits et 24 Bits pour une image 32 Bits.

255 / 8 = 31 (On arrondis toujours au plus bas)
31 x 8 = 248, Ici ont à perdus 7 Point, (On vois la différence à ce point, l'image est moins net) !
5 Bits par Composante, soit un totale de 15 Bits pour une image 24 Bits et 20 Bits pour une image 32 Bits.

255 / 16 = 15 (On arrondis toujours au plus bas)
16 x 16 = 240, Ici ont à perdus 15 Point, (On vois vraiment la différence à ce point, l'image est dégradé) !
4 Bits par Composante, soit un totale de 12 Bits pour une image 24 Bits et 16 Bits pour une image 32 Bit.

Etc.

Je suis étonné que tu ne sache pas ça Spock toi qui est calé en prog

No petit bouricow...
un unsigned char ( 0 to 255 ) prendra toujours 1 octets en memory , your "optimisation" viens du compresseur jpeg : https://fr.wikipedia.org/wiki/JPEG#La_compression_JPEG , il y a plus de same colors , le jpeg pack les colors en bloc , paweil avec le png. ton progwamme a la rigeur , met les images plus darkness, c'est tout.