Pour Gimp 2.10 que choisir : nv Carte graphique, nv processeur + de memoir

[olive36]

 Voilà mon dilemme . Depuis que je travaille en 16 avec Gimp 2.10 et darktable cela tourne un peut lentement .

Je voudrais un pt peut le bouster ...depuis un certain temps maintenant Gimp prend en charge le Gpu de la carte graphique et j'ai encore une viellle carte graphique radeon hd 5670 de 1 g ram . Mon processeur est un amd fx 8320 E et j'ai 16 giga de ram .

Qu'est ce qui serait le mieux d'après vous : 1 mettre 16 giga de ram ddr3 supplémentaire ou mettre un processeur amd fx 8370 ou encore mettre un grosse carte graphique style msi rx 480 ?

[Arnaud17]

Avant de sortir la carte de crédit il faut déterminer qui des deux fait ralentir le pc, gimp ou darktable.
j'ai toujours trouvé que gimp était passablement véloce.

[bg1000]

Faire un tour sur:
Moniteur-Ressources
Moniteur-Processus

Cela permet de voir l'utilisation des ressources, voir si tout les cœurs sont utilisés et comment la mémoire est utilisée.
BG

[bg1000]

Bonjour

Quel est la taille des fichiers pour darktable, quel est la taille des fichiers issu de GIMP?
Une image jpg de 10 Mo devient une image de 65,2Mo avec Gimp.

Un super SSD pour stocker les images ?

J'ai fait un essais avec ubuntu 18.04 16Go AMD® Phenom(tm) ii x6 1100t processor × 6 + AMD® Rs880
Darktable est utilisable même un peu plus rapide que DxO photolab.

BG

[olive36]

Merci je vais aller voir moniteur ressource et processus. Mes photos sont des raw de 14 bit donc oui c'est pas ce qu'il y a de plus légé bien sûr. Avec les PNG de mon smartphone là c'est c'est mieux bien sur. Sur ce Je vais voir ça ...et je reviens. En tout cas merci.

[olive36]

Faire un tour sur:
Moniteur-Ressources
Moniteur-Processus
comment lancer ça ? j'ai éssayer plein de truc ....mais ...

[bg1000]

Quel est ton OS ?
Es tu bien sous Linux, quel distribution ?

Essaye sous linux
Ctrl Alt T
ensuite tape dans l'invite monitor

Sinon sous windaube bouton droit dans la barre en bas, démarrer le gestionnaire de taches => processus
BG

[bg1000]

Avant de sortir la carte de crédit il faut déterminer qui des deux fait ralentir le pc, gimp ou darktable.
j'ai toujours trouvé que gimp était passablement véloce.

Si tu es sous windaube ajoute un SSD, tu y installe linux, tu installe grub sur le SSD linux, tu change dans le bios l'ordre de démarrage pour commencer sur le SSD linux.

Bien sur tu crée un point de restauration sous Win en premier et un clone de ton dd win au cas ouske.

Tu gagnera en fluidité et tu n'auras pas plein de truc qui viennent sollicité tes ressources.

BG

[remico]

Avant de changer de PC peut-être essayer d'autres distributions sans y passer un temps infini.
Au prix des disques durs en acheter un neuf et le brancher à la place, 3 partiions primaires pour trois distributions différentes.

Cela sera peut-être un après-midi ou plusieurs de perdus mais si on trouve quelque chose qui fonctionne mieux ou avec lequel on est plus à l'aise.  Ne serait-ce que pour installer Gimp 2.10.6 il suffit d'activer provisoirement le temps d'installer Gimp les dépots de testing avec Debian, Fedora, Opensuse ou Ubuntu Studio pour prendre les plus connues sur distrowatch : https://distrowatch.com/search.php?pkg=gimp&relation=equal&pkgver=2.10.6&distrorange=InLatest#pkgsearch

Pour ma part j'utilise des vieux PC et j'ai remarqué que toutes les distributions ne se valent pas question vitesse sans trop savoir le pourquoi du comment , et que toutes les installations de la même distribution non plus.

Pour gagner un peu en réactivité je choisis au début un gestionnaire de bureau léger style LXDE ou icewm  et rien d'autre. Puis j'installe Gimp, Darktable et Firefox après avoir redémarré afin d'avoir le moins de paquets installés.

[GLM]

Bonjour
Ce que dit bg1000 est plein de bon sens. Je vais apporter quelques compléments.
* Pour mémoire, commencer par nettoyer le PC, il suffit d'aller sur internet pour y trouver les façons de procéder.
* pour mémoire aussi, voir lorsque tu fais tourner Gimp s'il y a pas d'autres logiciels qui tournent en arrière plan et qui te consomme de la ressource.
* Voir si ton système de sécurité ne perturbe pas le fonctionnement
* vérifier l'état de tes disques et de ta RAM ( logiciel MemTest)
Sur des tests réalisés il y a peu de temps pour une application particulière j'obtiens les relevés suivants :
* Image de 29952x29952 Px le CPU tournait à <23%, la RAM < 68% de 20Go, la place prise par Gimp : 2.52Go alors que l'image ne faisait que 304,5 Mo
* Image de 36594x29997 Px le Cpu tournait à < 27%,  la Ram < 71%             ,                                      : 3.07Go                                                   715,4 Mo, là j'étais à la limite de l'asphyxie de la machine (Toshop CC à calé)
Ici nous sommes dans un cas extrême. pour le cas présent on pourrait appeler cela un démonstration par l'absurde.
Je me suis aperçu que Gimp ne savait pas exploiter plus de 16Go de Ram et que l'essentiel du Job se faisait par des échanges disques (2 SSD, un pour le système, l'autre pour le travail) à saturation tant en écriture qu'en lecture et d'une façon extrêmement haché. Le goulot d'étranglement se trouvait là, tout au moins sur ma machine.
En 2D mettre une carte graphique de 3D donne une puissance inutilisée et fait dépenser de l'argent pour rien. Ces grosses mémoires attelées au GPU sont là uniquement pour le raytracing qui oblige à avoir tout le projet en RAM pour traiter les shaders, rayons lumineux, ombres, ect...Actuellement seul NVIDIA répond correctement à ces exigences avec la techno CUDA (processeurs) et en multipliant leur nombre. Certains moteurs de rendu récents ne savent fonctionner qu'avec ce type de carte. Je ne vois pas ce que cette technologie a à voir avec la 2D qui n'a besoin de rien de tout ceci. (perso je fais de la 3D, avec une GTX970 qui a 1664 CUDA et 4Go il m'est arrivée d'avoir des images qui me demandent chacune 8 à 12h de calculs sur le GPU, là tu chauffes la maison, alors que sur GIMP au pire c'est quelques secondes)
Pour conforter le propos j'ai Proshow Producer de Photodex, il y a 3 ou 4 ans ils ont impliqué le GPU dans le moteur de rendu, la différence de temps et de qualité de rendu était un peu mieux mais pas significative au point d'investir un euro.
Enfin, il faut faire attention lorsque l'on change de carte graphique, qui par nature sont énergivore et nécessite un système de refroidissement conséquent. Il faut s'assurer que celui-ci entre bien dans le caisson, j'ai eu cette désagréable surprise à gérer.
J'espère que mon propos contribue positivement à ta réflexion.
Je te souhaite bon courage et de trouver ton bonheur en la matière.

[Paradis]

J'ai remarqué aussi que Gimp avait du mal avec les très grosses images, les très grands panos ect....

Sinon pour la vitesse pure, il est temps d'abandonner les Fx et autre phénom, au moins du bon Ryzen5 2600 en
amd...c'est sûr, tu verras la place.

[pense_bete]

Heurq,

comment se fait-il que je ne comprenne rien à ce que vous dites, pourtant, j'ai quelques heures de vol sur linux.

cdt

[bg1000]

comment se fait-il que je ne comprenne rien à ce que vous dites, pourtant, j'ai quelques heures de vol sur linux.

Explique alors ce qu'il faut faire

Pour moi difficile d'aller plus loin, car on ne connais pas l'OS, donc guider est difficile

BG

[Xophe]

Pour ce qui me concerne, j'ai un AMD Fx, et  j'utilise Kubuntu 18.04.  J'ai regardé ce qu'il se passe quand j'utilise Darktable, notamment l'export en JPEG. Les coeurs du CPU tournent alternativement à fond et l'utilisation mémoire ne dépasse pas les trois gigas et il faut 2 à 3 secondes pour traiter chaque image. Moralité, j'ai peut être un truc à améliorer dans l'usage de la mémoire.

Pour ce qui est de Gimp, je ne peux rien dire.
P.S. : à l'origine il y a les raw d'un K3

[Xophe]

J'ai remarqué aussi que Gimp avait du mal avec les très grosses images, les très grands panos ect....
...

A ce propos, dans la doc https://www.darktable.org/usermanual/fr/special_topics_chapter.html#darktable_and_memory :

Une exception vaut la peine d'être mentionnée. Si vous utilisez darktable pour traiter des vues panoramiques par assemblage, par exemple des TIFFs générés par le logiciel Hugin, ces images peuvent atteindre des tailles considérables. Chaque thread d'arrière-plan a besoin d'allouer suffisamment de mémoire pour garder dans ses tampons une image complète, des intermédiaires et l'image de sortie. Ceci peut rapidement conduire à un dépassement de mémoire même avec un système 64 bits bien équipé. Dans ce cas réduire à un seul le nombre de threads d'arrière-plan.

[GLM]

Si tu lis ce que j'ai écrit ci-avant j'ai passé une image de plus de 1 milliard de pixels pour asphyxier mon PC.