ah, c'était donc ca

maintenant, ca semble marcher mieux, j'ai du rouge et du vert

je testerai cette image demain, mais j'ai déja essayé de compresser un fichier mpg de 250 mo avec paq8p récemment et je n'ai gagné que quelques centaines de ko dessus; a mon avis, il ne pourrait pas faire un résultat inférieur sur cette vidéo convertie en image

dnob,
tu dois pouvoir formatter tes donnes pour etre compression friendly.
Si ton logiciel n'a pas d'algo de compression de champs scalaire 3d mais un algo de compression de champs de scalaire 2d. il est probablement preferable d'essayer de replier tes donnes 3d en 2d en utilisant une technique de type Z-order plutot que de lui filer tes donnes brut.

Sinon pour la generation, il est peut etre preferable d'utiliser lrand48 plutot que rand()

bon, résultat de la nuit dernière: d'une image de 268 mo, paq8p a fait une archive de 178 mo, et la décompression a redonné l'image d'origine.

ouais, il commence a faiblir, là

lrand48... est-ce que ca existe sous windows? ils en parlent surtout pour linux

hé au fait, j'ai une question

quelles sont les limites du format bitmap?

j'ai crée une image de 16000x12000 pixels avec mon programme d'images aléatoires, je peux l'ouvrir, mais pas une image de 20000x20000, la visionnette d'images intégrée a windows me dit qu'il ne peut pas ouvrir le fichier

Je pense que bitmap est limite par ce que tu peux stocker comme taille de l'image.
Dans l'entete tu as 4 octets pour stocker la taille du fichier donc ca fait 4Go. 4 octets (signe) pour stocker la largeur (max 2 milliard) et pareil pour la hauteur. Le signe des entiers est utilise pour donner le sens de l'image

Je pense plutot que ton image 20000x20000 ca fait 4.10^8 pixels et qu'a 3 octect le pixel ca au moins fait 1.2 Go.donc probablement il n'arrive pas a faire le rendu en temps reel.

Tu parle bien de l'apercu windows en miniature ? Si oui,
C'est assez stupide, ca veut dire qu'il charge toute l'image pour faire l'apercu alors que tu dois pouvoir te permettre de ne prendre que les pixels dont tu as besoin. C'est trivial si les donnes ne sont pas compresse et ca m'a l'air facil avec une compression RLE (bien que ca oblige a lire tout le fichier une fois).

oui, 1.2 go, et c'est bien l'apercu qui bug

merci du conseil pour la compression RLE, mais je sais pas si c'est possible à mettre en place, vu qu'après, je suis censé déverser les octets d'un fichier dans les données des pixels de l'image

mon but est juste de détourner les routines de compression du bitmap de paq8p, je dois donc pouvoir faire des images de deux go maximum, mais tant pis pour l'apercu qui bug si le fichier bitmap est encore valide

probablement tu ne veux pas faire de RLE, ca ne doit pas bien s'appliquer sur un jeu de donnes aleatoire. et ca va meme probablement augmenter la taille de ton fichier.

Est-ce que tu as fait des benchmark pour voir dans quelle mesure tes bitmap se compressaient mieux que les fichiers que tu mets dedans avec le même algorithme ?

Est-ce qu'il n'est pas possible de forcer l'heuristique utilisée par paq8p lorsque tu lui fournit un fichier (pour ne pas avoir à t'embêter avec cette encapsulation) ?

j'ai déja essayé de compresser des bitmaps aléatoires (j'en suis pas encore a l'encapsulation ) et ca donnait des résultats satisfaisants... le moins bon, c'était 50%, absolument rien a voir avec les quelques ko que je gagnais a compresser des fichiers vidéo de 300 mo

sinon, pour forcer l'heuristique, je sais pas, ca risque d'être compliqué, ils fournissent bien le code source de paq8p mais je n'y comprend pas grand-chose

Oui, mais est-ce que tu as déjà essayer de compresser des fichiers aléatoires généré exactement de la même manière que tes bitmap (à la limite, le même fichier, mais avec une autre extension et peut-être sans son en tête).

Les fichiers vidéo sont déjà compressés (presque toujours) et donc évidemment, il reste peu de chose à faire. C'est donc normal de ne rien gagner. Tu peut faire le test inverse en renommant tes vidéo en .bmp et en leur rajoutant un en tête de bitmap, et tu verras que ça ne sera pas mieux (en tout cas, j'en suis presque sûr).

j'ai fini la premiere version qui veut bien fonctionner de mon convertisseur fichiers2bmp, une espèce de préalpha buggée qui gère même pas l'opération inverse mais qui a suffi pour réaliser un test de compression.

et c'est dnob700 qui l'emporte! ca compresse rien du tout

voici le code source si ca peut être utile a quelqu'un (enregistrez l'image et renommez l'extention en .c )

http://www.noelshack.com/com/voir/010309/main010026.jpg

mais faut quand même que je voie s'il compresse mieux les fichiers convertis en bmp plutôt que les normaux, ou s'il le fait plus vite, etc