Compression d'images (identiques) dans les tables de données JMPJMP permet de stocker des images dans une colonne de données.
Même le stockage de la même image 1000 fois est ultra rapide et ne pose aucun problème pour la mémoire du PC.
Mais enregistrer le fichier sur le disque dur prend du temps — et beaucoup d'espace !
L'activation de la compression GZ ne change rien :
Essayez-le : pourquoi la compression GZ ne fonctionne-t-elle pas ?
dt = new table("test", add rows(1000),Compress File When Saved( 1 ), new column ("img", Expression));
myIMg= New Image(open("https://apod.nasa.gov/apod/image/2603/NGC1300-LRGB_1024.jpg"));
:img[1] = myImg;
// add the image to row 1
dt << save("$temp\test1.jmp");
wait(0);
Show(File Size( "$temp\test1.jmp" ));
// add the image to every row
for each row(
:img=myImg
);
wait(0);
lastImg= new image(:img[1000]);
last image << scale(0.2);
ex = New Window( "Modal Dialog example",
Modal,
V List Box(
Text Box( "Wow, very fast! this is the image in row 1000:" ),
Picture Box (last image),
Text Box( "do you have enough time/space to save the data table?" ),
H list Box (Button Box ("OK",bb<< close window()),bb = Button Box("cancel", bb<< close window();stop();)),
)
);
dt << save("$temp\test2.jmp");
wait(0);
Show(File Size( "$temp\test2.jmp" ));
Automatisation et scriptageOrganisation du contenuRe: Compression d'images (identiques) dans les tables de données JMPAvant l'enregistrement des fichiers, pourquoi JMP est-il si rapide ?
Pour l'utilisateur, il semble qu'une image soit enregistrée sur chaque ligne :
Mais JMP ne stocke qu'une référence à l'image originale. En modifiant sa taille, on découvre le lien :
names default to here(1);
dt = new table("test", add rows(10),Compress File When Saved( 1 ), new column ("img", Expression));
myIMg= New Image(open("https://apod.nasa.gov/apod/image/2603/NGC1300-LRGB_1024.jpg"));
:img[1] = myImg;
// add the image to every row - as a "reference"
for each row(
:img=myImg
);
wait(0);
// add the image to row 4 - as a new image
:img[4] = new image(myImg);
// change on e of the images
image2 = :img[2];
image2 << scale(0.5);
// ... changes all the images - because all of them are links to the same image
Show(image2 << get size);
Show(myImg << get size);
Show(:img[3] << get size);
// all of them? not row 4
Show(:img[4] << get size);
Re: Compression d'images (identiques) dans les tables de données JMPLa même astuce s'applique lorsque des tableaux contenant des images sont empilés.
Osez ! Vous pouvez empiler des milliers de colonnes et obtenir des milliers d'images dupliquées : ce sont des clones qui ne consomment pas de mémoire.
Mais n'osez pas sauver la table empilée !
Names Default to Here(1);
dt = Open( "$SAMPLE_DATA/Big Class Families.jmp" );
dtstack = dt << Stack(
columns( :height, :weight )
);
:picture[1] << scale(5);
Show(:picture[1] << get size);
Show(:picture[2] << get size);
Re: Compression d'images (identiques) dans les tables de données JMP...et tenez compte des dommages collatéraux.
Elles sont moins évidentes qu'on ne le pense.
Names Default to Here(1);
dt = Open( "$SAMPLE_DATA/Big Class Families.jmp" );
Show(dt:picture[1] << get size);
dt sub = dt<< Subset( All rows, Selected columns only( 0 ) ); // non-linked subset
dt stack = dt << Stack(
columns( :height, :weight )
);
dt stack:picture[1] << scale(0.1);
Show(dt stack:picture[1] << get size);
Show(dt stack:picture[2] << get size);
Show(dt:picture[1] << get size);
Show(dt sub:picture[1] << get size);
Re: Compression d'images (identiques) dans les tables de données JMPLe format JPG est déjà une compression optimisée. Souvent, la compression de données aléatoires, compressées ou chiffrées peut entraîner une augmentation de la taille des données au lieu d'une réduction, car la compression trouve peu d'éléments à compresser et des en-têtes et des données de gestion sont ajoutés autour des données compressées. Certes, le tableau de données « enregistre » l'image binaire sous forme de blob base64 dans un champ de type chaîne de caractères de la colonne, mais pour la compression gzip, elle apparaît toujours comme des données majoritairement aléatoires.
La véritable question, à poser au support technique de JMP (et donc au développeur de la table de données), est la suivante : pourquoi ne pas enregistrer une seule copie et les références au lieu de copies identiques ? Je suppose également que le chargement de la table enregistrée aura un impact sur la mémoire, car les tables sont désormais probablement distinctes. Si la table de données sait qu'elle est identique en mémoire, pourquoi ne conserve-t-elle pas cette identité lors de l'enregistrement ?
Re: Compression d'images (identiques) dans les tables de données JMP[ 00296024 ]
-> "
Il n'est pas surprenant que JMP ne compresse pas une table de données de manière à optimiser l'efficacité du stockage des images. Il semble que tout fonctionne correctement.
Re: Compression d'images (identiques) dans les tables de données JMPEn effet, l'option la plus simple serait la suivante : JMP reconnaît que les images sont identiques et utilise cette information lors de l'enregistrement du fichier.
Il semblerait qu'en mémoire, JMP utilise une sorte de « pointeur », et que plusieurs pointeurs pointent vers la même image. -> coll lors de la génération du tableau.
Lorsque JMP enregistre le fichier, il utilise les pointeurs et se contente d'images identiques, les enregistrant une par une.
Cependant, j'ai été surpris de constater que l'algorithme de compression de la colonne n'identifiait pas les doublons et ne les stockait pas efficacement.
Mon IA suggère que JMP utilise un ancien mécanisme de compression avec une petite fenêtre de décompression (JMP mentionne gz dans ses préférences). Dans ce cas, la première image se trouvera hors de la fenêtre de décompression lors de l'analyse de la seconde.
Suggestion de l'IA :
Le passage à un schéma de compression plus moderne (zstd / lzma ?) pourrait conduire non seulement à une amélioration significative de la compression de plusieurs images identiques, mais aussi à une meilleure compression d'autres types de colonnes.
Re: Compression d'images (identiques) dans les tables de données JMPLe développeur est au courant du problème et m'a indiqué qu'il l'étudie. La prise en charge des images n'était pas initialement prévue dans les tables de données JMP ; il s'agit d'une fonctionnalité relativement récente (datant d'une dizaine d'années). Je pense que lors de l'ajout de cette prise en charge, cela a été fait de cette manière afin d'éviter toute modification du format de fichier .jmp et d'assurer la rétrocompatibilité. Pour les anciennes versions de JMP, les images apparaissent comme des chaînes de caractères. Cela permet également de créer une table avec des images à partir de scripts. La résolution de ce problème nécessitera probablement une mise à jour du format de fichier .jmp. Il pourrait être envisagé de stocker l'image en interne, comme pour les données catégorielles ou les listes à cocher, et de préférence via une conversion binaire plutôt que base64.
C'est formidable que vous débusquiez ces problèmes afin que nous puissions les corriger. En fin de compte, nous souhaitons des performances optimales et une utilisation efficace de la mémoire dans JMP.
Le volume de données ne cesse de croître.
Re: Compression d'images (identiques) dans les tables de données JMPÇa a l'air super.
Merci pour cette discussion ouverte et ces idées pertinentes
Notre objectif commun est de faire de JMP le meilleur possible : robuste, complet et raffiné.
Il devrait rester le meilleur outil d'analyse au monde. … Et avec l'essor rapide de l'IA, la concurrence va s'intensifier !
Re: Compression d'images (identiques) dans les tables de données JMPExceller: Conteneur relationnel (déduplication des images via des pointeurs).
JMPFlux de données plat (images binaires dupliquées par ligne).
— D'après Gemini 3.1 Pro
