PureBasic

Merci zorro pour ses informations, je comprends mieux.
Alors mon terme est t-il correcte ?: Lisseur de nombres.

Peut être devrais-je dire, égaliseur de nombre ?

En fait, je pense que shadow pense plutôt à un algo assez difficile qui prendrait plusieurs pixels de suite, qui en déduirait une fonction, et qui supprimerait la différence entre la courbe obtenue et la valeur des pixels. Un peu comme une DCT, peut-être... L'idée n'est pas mauvaise, instinctivement, par contre, c'est du genre coton à implémenter et normalement, on chiffre D'ABORD l'avantage qu'on peut en retirer...

fft fourier ? , bezier ?

@Case / @Zorro, vous pourriez mettre les tailles des fichiers après chaque passage de vos "moulinettes" histoire de voir le gain en "Ko" en précisant bien sur la taille de l'original.

@SPH, ces procédures de réductions de couleurs, si elles permettent de gagner sur la taille fichier pourraient être intéressantes pour ton "HTML Maker" quand tu génères tes vignettes, car si elles sont vraiment moins grosses (en Ko) le chargement des pages s'en trouverait accéléré, tout en laissant le lien vers l'image original quand tu cliques sur la miniature.

@Djes : N'étant pas matheux, je ne m'aventurerai pas sur le terrain des DCT ni des FFT, je te laisse le soin d'expliquer tout ça à Shadow


Edit : pseudo corrigé pour Case, mille excuses, je ne sais pas pourquoi j'ai mis Cage, compte tenu du fait que je te reconnais à chaque fois grâce à ton avatar "Cobra"

TazNormand a écrit :@Cage / @Zorro, vous pourriez mettre les tailles des fichiers après chaque passage de vos "moulinettes" histoire de voir le gain en "Ko" en précisant bien sur la taille de l'original.

c'est pas cage, mais case ^^
je vais afficher ca

@TazNormand

ben en fait ça va pas t'indiquer grand chose parceque

si on travail en BMP toutes les sortie auront la meme taille , car toutes les images meme si elle different dans le nombre de couleurs employées pour les dessiner
restent quand meme avec le meme nombre de pixels !

donc en BMP toutes les images garde la meme taille

ensuite si on encode en Jpg , là c'est l'algo de compression du jpg qu'on "mesure"
j'ai mis les tailles obtenues en laissant la compression minimum ...

c'est pas tres significatif , puisque c'est surtout la resolution X,y qui fait perdre du poids a une image
ensuite c'est l'algo de compression

alors c'est certains qu'on doit pouvoir obtenir de meilleurs résultat si l'image est composées "d'aplat"
que si elle est composée de pixels bien different ....

diminuer le nombre de couleur n'agit pas vraiment sur la taille d'une image.... un peu... mais bien moins que de
diminuer la resolution, et eventuellement la taille binaire : exemple passer en 16 bits au lieu de 24 bits par pixel ....

mon algo est different de celui de Case
moi je redessine l'image avec X crayons ....
alors que je pressent que l'algo de Case joue sur la taille en Bit de chaque pixels...
il aura un bien meilleur rendement que moi
mais moi, je peux generer une image n'ayant de 3 couleurs , ou 25 , ou 9

Quand je fais des test, je compare avec la taille d'un PNG et enregistrer avec GIMP car bien meilleurs algo que Window.
Voici les images:

Png Gimp:


Et là le summum en compression, en qualité 100%, Jpg:


Alors évidement, je déprime souvent, car quand je vois la taille du fichier Jpg, avec une qualité excellente de 100%, je déprime dans ma recherche car je suis toujours super loin !
Mais je percever encore et encore...

@Djes, j'ai pas compris, désolé

Note: Je pense que les connaisseur sauront de quel jeu il s’agit, ce n'est pas de la pub !

JPEG est une compression avec perte, donc déjà, ça sert pas à grand chose de compresser à 100%, 97% permet déjà de réduire pas mal la taille du fichier, 95% encore plus. De ce que j'ai pu tester sur des photos compressées via logiciels (Paint Shop, Photofiltre, xnview...) en dessous de 95% ça commence à se voir, et en dessous de 90% apparaissent de "gros" artefacts.

je déprime souvent, car quand je vois la taille du fichier Jpg

Fais différents essais de sauvegarde JPG en réglant la qualité de compression. Flags varie de 0 à 10. La sauvegarde JPG est réglé à 7 par défaut.

1850 po pas mal... Tu as fini par comprendre comment fonctionnait ce jeu à force de persévérance...

On sort du sujet mais ça date et j'ai déjà eu 10 000 po mais grâce à la vente d'écus !
Je suis pas super loin et je suis très lent.

Shadow a écrit : Alors évidement, je déprime souvent, car quand je vois la taille du fichier Jpg

Utilise le format HEIF : http://nokiatech.github.io/heif/

Mindphazer a écrit :Utilise le format HEIF

le futur format qu'Apple tente de propulser pour enterrer JPG.

C'est pour le moment hors-sujet car PureBasic n'exporte pas dans ce format. Remarque un hors sujet de plus ce n'est pas très grave sur ce topic

Si ta un lien parce que je trouve pas se que tu m'as mis là.

falsam a écrit :

Mindphazer a écrit :Utilise le format HEIF

le futur format qu'Apple tente de propulser pour enterrer JPG.

C'est pour le moment hors-sujet car PureBasic n'exporte pas dans ce format. Remarque un hors sujet de plus ce n'est pas très grave sur ce topic

Oui
Il sera utilisé à la place du jpg dans iOS 11 (de là à enterrer JPG, il y a un pas que je me garderai bien de franchir !)
Quant au hors-sujet... hum