Reprise du message précédent :
ben vu qu'on peut lire, non, je pense que c'est juste une limitation qu'impose le moteur, car les devs ont estimé qu'il s'agissait d'une hérésie
 
ceci dit, j'aurais bien aimé faire le test pour voir
(d'un autre côté, vu mes disques ça n'aurait pas été concluant, puisque le gain lié au volume lu aurait été totalement anéanti par les CPU et la vitesse des HD : bi Piii 933 avec des disques U3W 10ktrm...)

Peut etre (et meme certainement) qu'une compression qui rox pourrait ramener des fichiers d'une taille de 512 To a celle d'un bit (apres des centaines de compression) mais le seul probleme c qu'il n'y a que 2 fichiers de 512 To qui pourront etre traité de la sorte ...    
 
les autres 2-2^512To iront se faire foutre

 
Pour quoi faire ?
 
En math souvent la preuve de l'existence suffit .

je suis pas daccord avec Legreg
il est impossible de comprimer a un bit !
un bit ne donnera jamais que 2 resultats (peut importe la taille et les valeurs de ces resultats)
 
si ca donne plus de deux resultats alors il est impossible de savoir quel est le bon

Ca serait pas du au fait le moteur SQL Serveur s'interfacerait directement avec disk.sys (mode bloc quoi) ?

2^512To-2 plutôt
En effet, ne tolérer que deux instances de fichiers serait une solution à la compression absolue.

 
Si tu passes encore sur ce sujet, tu peux prouver au monde qu'il se trompe et gagner un peu de blé : http://prize.hutter1.net/

  Pas nécessairement, si la structure est bien pensée. Exemple : une image raster de 18 Go (compressée!), il faut combien de temps sur une bécane de base pour afficher, disons, les 50000 pixels pile poil au centre, d'après toi ?

C'est tout à fait possible de réduire n'importe quel fichier à une taille de 1 bit, il faut seulement utiliser un executable de décompression différent à chaque fois

tout dépend de la compression utilisée.
et tout dépend du format de l'image (bitmap, vertoriel, avec ou sans calques).
 
juste parceque je suis méga relou parceque et que j'ai toujours raison (j'ai des bas de contention, je te rassure ) je vais te donner ZE exemple qui tue la vie.
 
prenons le cas d'un jeu.
 
on va dire "Open Transport Tycoon Deluxe" (ou OpenTTD) http://www.openttd.org
 
je peux jouer sur une carte qui fait 2048x2048 cases isométriques.
 
si je génère une capture d'écran "géante" (toute la carte) au format PNG, j'obtiens une image en 131 008 x 65 504 pixels.
http://www.tt-forums.net/viewtopic.php?t=28016
 
ok, j'ai un superbe fichier de 883 325 405 bytes (soit presque 900 Mo)
 
non compressé, ça donnerait 8 581 548 032 bytes (groumpf)
 
maintenant, dans le jeu, je fais "save as"
ça me génère un fichier d'environ 1 Mo
 
ça prends quelques secondes à le réouvrir, et je retrouve le jeu (et donc l'image de la carte) dans l'état exact où je l'ai sauvegardé
 
implicitement, on peut donc parler de sauvegarde d'un format d'image (certes, bien particulier, mais bon)
 
on peut parfaitement appliquer ceci à tous les jeux utilisant des sprites, ou en 3D, des textures. on utilise par ce biais un format de compression infiniment meilleur que tout ce qu'on peut imaginer avec n'importe quel autre format
 
et il s'agit bien d'une compression : on a les données non compressées : la carte du jeu. on a les données compressées (partie qui change avec le contenu à sauvegarder) : le fichier de sauvegarde. on a un dictionnaire : les sprites, et l'entête du fichier de sauvegarde, qui indique par exemple la taille de la carte ainsi que quels sprites utiliser (OpenTTD peut utiliser plusieurs jeux de sprites différents).
 
j'ai donc ici une image de presque 10 Go non compressée, que je suis capable de sauvegarder et recharger en quelques secondes, avec un ration de compression d'environ 1/10000.
 
en PNG, où le ratio est déjà de 1/10, ça prend environ 30 secondes à écrire, et plus de 15 minutes à relire.
 
 
autre exemple. ton image de 15 Go non compressé représente une fractale. elle est donc compressible en quelques bytes : la formule, la résolution d'affichage, la profondeur de calcul. pour charger une zone précise, il suffit de ne calculer la formule que sur des valeurs bornées des indices. là on arrive à une compression au ration encore plus impressionnant, puisqu'il est de l'ordre de 1/1000000000
JPEG possède d'ailleurs un format interne de sauvegarde reposant sur cette approche, qui permet d'arriver à de très bons résultat : FIF (Fractal Image Format). Après un premier dégrossage avec les algos classiques du format JPG, ce format va tenter de générer une série de fractales permettant de retrouver les informations correspondant "au plus proche" aux données de l'image. cela permet d'obtenir de très bons taux de compression, pour une déterrioration faible (au contraire, dans certains cas, on peut même gagner en qualité : par exemple, une forme géométrique remarquable sera généralement reconnue, et le passage au format fractale permet de zoommer dessus plusieurs dizaines de fois sans avoir le moindre crénelage).
ce format est aussi très rapide à décompresser (par contre d'une lenteur abominable à générer, ça fait un peu comme Seti@Home : 2 heures de calcul pour compresser 2 Mo quand on utilise les paramètres de compression à fond )
 
 
je ne parle pas, enfin, des formats WMF, EMF, AI et autres, qui permettent de stocker des images au format vectoriel. on peut alors enregistrer des images de plusieurs milliards de pixels de dimensions en quelques Ko (tout comme on peut avoir plusieurs Go pour une image de quelques pixels de dimensions ). il va de soit que les fichiers texte en vue d'une impression graphique ou papir n'échappent pas à la règle : quelques pages de texte, rendu sous forme d'image en 300dpi, on arrive vite à quelques Mo ou Go avec un format d'image. un simple soft d'OCR permet d'ailleurs de faire le rendu inverse, ce qui montre bien qu'il s'agit d'un format de compression comme un autre.

En l'occurrence, JPEG2000 NPJE "de base"
 
Mais ça marche aussi avec du bête TIFF de 4 Go (devenant ~700 Mo après compression deflate avec horizontal differencing).
 
Et, bien sûr, je n'évoque pas toutes les "pouilleries" que tu cites (style carte d'un jeu à la noix, ou "image" à motif régulier, ou image qui est en fait une fractale ou je ne sais quoi). Je te parle d'images de la vie courante, en l'occurrence de scans (!) de cartes routières ou d'images satellite de la Bourgogne
 
Au fait, tu as pas répondu : combien de temps, d'après toi, pour dire la couleur du pixel central d'une image de 280000 mpix ?

jpeg ou tiff, tout comme PNG, BMP RLE et GIF (ainsi que tous les formats compressés d'image "bitmap" ) utilisent des algos avec bitrate non constant.
ainsi, il est impossible de charger une zone précise sans tout décompresser.
je dirais, vu la taille, que ça peut aller de plusieurs minutes à plusieurs heures. ça dépend toujours de beaucoup de choses la qualité de compression, la vitesse de la machine, la quantité de ram et la vitesse des HD...
 
sinon, pour ce qui est de scans de cartes, à la base, des cartes c'est ni plus ni moins que des courbes. il doit y avoir des outils d'OCR capable de vectoriser ce type d'informations je pense. ça vous ferait sacrément gagner en qualité d'image et en volume d'information
 
(je ne parle même pas des temps d'affichage )

Pour le tif de 4 Go (deflate), environ 3 secondes sur un Celeron M 1.5 GHz (vive le laptop 1er prix ).
Pour du wavelet, sur un fichier 280000 mpix de 18 Go (image satellite), faut compter 7-8 secondes la première fois pour afficher la zone de son choix au niveau de zoom de son choix. Par la suite c'est quasi instantané.
 
Et ce sont toujours des algos à bitrate non constant, bien sûr. D'où ma remarque sur l'importance cruciale à l'usage, de la structuration des données.
 
Latence = pique nique douille...

bah essaie avec PNG.
parceque là je suis sur le cul.
 
moi avec mon PNG de 131 008 x 65 504 (8 bits) je dois attendre 15 minutes pour que photoshop me l'ouvre...
 
apparement, soit j'ai un méga problème avec mon pc, soit png c'est de la daube en branche pour les grosses images

Il a une autre possibilité, que je confirme,  photoshop est une grosse daube.

 
Avec un produit Adaube, difficile de s'attendre à mieux

PNG est (Antp, si tu me lis, pardon du terme, mais je le dis dans un contexte particulier) un format merdique, comme qui dirait "trop basique" pour ce qui est de la compression de raster. Le tiff/deflate fait aussi bien (voire mieux, parfois) avec de nombreux avantages supplémentaires, y compris en terme de performances et d'ergonomie.
Aucun intérêt d'essayer avec le PNG donc, ou le bon vieux JPeg, qui souffrent de limitations d'origine en terme d'efficacité ou de taille max.
 
(Ensuite, faut que l'implémentation côté logiciels suive... avec des outils style Photoshop, codés pour ne supporter que 10 ou 20% des fonctionnalités d'un format, ça aide pas...)

Et encore Photoshop ça va, Fireworks de Macromedia est encore pire lorsqu'il s'agit d'ouvrir des gros trucs

ça je suis d'accord, mais paint.exe plante quand j'ouvre une image de 900 Mo

bin surtout que photoshop doit étendre d'office en 8:8:8:8, et que si t'as pas assez de pages mémoires libres, tu swappes.

Non, Photoshop ouvre l'image dans le format original. Il faut passer manuellement en RVBT, CMJN ou autre. Ceci dit, s'il garde une image non compressée complète en mémoire, alors il swape forcément : j'ai pas 8 Go de RAM
 
Ceci dit, une fois que PS a ouvert l'image et généré une vie à 0,001% (histoire que ça tienne en plein écran sur mon 24" ) je peux me déplacer dans l'image, zoomer et faire tout ce que je veux très rapidement (par contre faut pas que je touche à un effet ou à un filtre, sinon proutch )

il est vrai que si ton image était en 8bits monochrome oui.
mais si elle était en 8bits palettisé pour faker du monochrome, je pense que c'est plus judicieux de dépacker l'image en 8:8:8:8.
 
de toutes façons c'est pas très pertinent de reprocher à un soft de modification de ramer dans ce genre de situation (8Go en 8bits, 31Go en 32bits ARGB, c'est pas adressable linéarement etc... et c'est débile de manipuler d'un traite un document exécédent largement en magnitude les ressouces de la machine)
 
bref...
 
----
 
et pour l'exemple de OTTD, c'est pas de la compression (le jeu sérialise ses structures c'est tout).

J'ai l'impression que les soft ne sont pas fait pour gérer ce genre d'images Par défaut, ils essayent de l'afficher en entier à l'écran, sans se soucier de la taille, ce qui est évidemment portnawak

c'est pas ça.
si tu veux pouvoir rééllement "modifier" une image, il faut avoir ses pixels d'atteignable quelque soit la situation.
 
c'est pas comme un moteur de visualisation qui peut se servir de cohérence spaciale ou du format de l'image pour réduire au minimum l'emprunte mémoire ou la quantitée de donnée à lire/décompresser.
 
si tu prends une image 1024k x 1024k satellite dans un format atteingable ou tu as une granularité de positionnement, tu peux faire un lecteur qui se démerde bien vis à vis de ta fenêtre de vision.
 
mais à partir du moment ou tu peux appliquer un traitement qui peut faire des accès aléatoires dans l'image, bof, une image de 8~32Go c'est déjà bien que ça se lise sur une machine 32bits...

 
C'est ce que l'on appelle un traitement out-of-core, un concept qui a du voir le jour à peu près en même temps que l'informatique, http://www.google.com/search?q=out+of+core
 

tout à fait, et c'était ce qu'on était obligé de se taper sous DOS avec ses segments de 64Ko de merde.

Pas vraiment, les algos out-of-core traitent un cas plus général ou les temps d'accès aux données sont des ordres de magnitude plus élevés que les accès locaux (et plus restreints), ce qui n'est pas le cas avec l'adressage segmenté.

oui, enfin ça me rapelle du vieux code que j'avais vu qui cherchait à faire des rotations d'image via des seeks dans un bmp (ça m'avait fait rire)