Utiliser-Lightroom
Général => Lightroom : questions générales => Discussion démarrée par: michel_d le 01 octobre 2012 à 18:31
-
Au risque d'enfoncer une porte ouverte (mais je n'ai rien trouver avec le moteur de recherche) : existe-t-il un bench plus ou moins standard pour mesurer les performances de LR sur une configuration donnée ?
Si non, quelqu'un serait-il intéressé d'essayer d'en bâtir un ?
-
Pour compléter ma question, je viens de trouver ceci : http://www.michaeldeleon.net/macbook-pro-2012-vs-2009-lightroom-4-benchmarks/ (http://www.michaeldeleon.net/macbook-pro-2012-vs-2009-lightroom-4-benchmarks/).
Ca peut servir de base mais pour que ce soit reproductible il faudrait constituer un lot d'images test.
-
Pour compléter ma question, je viens de trouver ceci : http://www.michaeldeleon.net/macbook-pro-2012-vs-2009-lightroom-4-benchmarks/ (http://www.michaeldeleon.net/macbook-pro-2012-vs-2009-lightroom-4-benchmarks/).
Ca peut servir de base mais pour que ce soit reproductible il faudrait constituer un lot d'images test.
Bonjour Michel,
Ta question est intéressante. Mais il faut se méfier des résultats lorsque l'on ne dispose pas des conditions de test et surtout des réglages de la machine afin d'optimiser ses performances. Ton lien présente un test qui a le mérite de présenter ces éléments comme la taille des aperçus...
Chez Clubic, j'ai trouvé cela: http://www.clubic.com/processeur/processeur-intel/article-487908-9-ivy-bridge.html
Il faudra juste aller à la section LR4. Et c'est en français.... ;)
C'est une bonne nouvelle Clubic vient d'intégrer LR4 à ses tests. Nous savons quel boitier, combien de RAW et les développement effectués à l'import.... Donc pratiquement reproductible. Nous pouvons leur faire confiance.
-
Merci Cyril pour ce lien fort intéressant (pourquoi chercher loin ce qu'on peut trouver près de chez soi ;))
Je suis bien d'accord avec toi sur la nécessité de définir très rigoureusement les conditions de test pour que le bench soit reproductible. C'est justement cela qui serait intéressant, car nous avons souvent (sur ce forum par exemple) des discussions sur les performances de LR, soit par rapport à une plate-forme hardware, soit par rapport à une amélioration comme un SSD, soit par rapport à des versions différentes de LR, soit par rapport à des réglages de paramètres, etc.
Disposer d'un benchmark assez représentatif du travail d'un photographe et aisément reproductible serait utile pour étayer ces discussions et surtout améliorer les performances de notre outil.
Serais-tu intéressé par le sujet ? Si oui, on pourrait essyer de bâtir cela à deux. Ca ne doit pas être bien sorcier; c'est surtout une question de méthode et de rigueur.
-
Oui Michel, on peut bâtir cela. C'est une idée très excitante qui devrait intéresser pas mal de monde.
Je ne dispose que de deux plateformes sous windows. Mais ce qu'il nous est possible de faire est de définir:
1 les conditions de test (définition des fichiers, nombre et format, taille d'aperçu, paramètres de développement à l'import, réglage de LR etc)
2 L'organisation des disques (externe, SSD, organisation du cache et des partitions, etc) et l'architecture en elle même (mémoire, processeur etc).
3 Le flux de travail (import en DNG, copie ou ajout, export vers un HDD externe ou interne etc)
Je vais y réfléchir afin de poser sur la table les éléments que je pense nécessaire. On comparera avec les tiens.
-
Super :)
Cyril, en lisant tes réponses je réalise que j'ai mal formulé ma question. Quand je parlais de benchmark je ne visais pas un tableau de résultats donnant les performances de LR avec telle ou telle plate-forme. Je visais plus modestement
l'outil permettant de mesurer les performances de LR dans un contexte donné de manière reproductible.
Il n'est donc pas du tout nécessaire dans mon esprit de disposer de plusieurs plateformes; il suffit que chacun en dispose d'une. Ensuite, si les gens sont intéressés par le sujet, d'autres pourront faire tourner le bench sur leur plate-forme et nous pourrons éventuellement tenir à jour un tableau des résultats.
Le programme de travail que tu proposes répond donc parfaitement à ma question. J'ajouterai un 4ème point qui est de fournir une base de photos de référence. Peu importe la qualité de ces photos; il faut simplement qu'elles soient libres de droits et qu'elle ne pose aucun problème de confidentialité. Je ne sais pas si on peut trouver cela facilement (sachant qu'il faut des RAW); le plus simple est peut-être de la fabriquer.
@+[/list][/list]
-
Ok Michel,
Je pensais également prendre une base fixe et connue de RAW, car c'est le meilleur choix pour comparer. Peu importe le sujet, ce qui compte c'est la définition des images. Il y a bien la base d'image Kodack qui sert au test de dématricage mais je ne sais pas si elles sont libres de droit. Chacun de nous pouvons fournir une dizaine d'image ( Capteur CMOS APS-C 18 millions de pixels pour ma part). Donc cela ne m'inquiet pas plus que cela.
Je ne pensais pas non plus au tableau de résultat mais essayais de fixer les bases du contexte. En effet réaliser un tableau de résultat signifierait que l'on dispose d'un panel de plate forme. C'est pour cela que j'ai donné ma restriction sur cette question.
Quant à l'outil, tu souhaites voir développer un programme? Je ne comprends pas!
-
J'ai cru remarquer que les fichiers sont plus ou moins lourds selon qu'ils représentent des scènes unies ou aux couleurs et contrastes variées.
Il serait bon sans doute aussi de définir une procédure de création des fichiers:
Réglage des appareils, plage dynamique, sujet etc...
-
Bonsoir Cyril,
Nous sommes complètement en phase.
Quand je parlais d'outil je voulais simplement opposer le résultat (tableaux) au dispositif qui produit les résultats. Mais en pratique ce dont je parle c'est exactement ce que tu décris :
- une base de photos
- des conditions de mesures précises (par exemple : anti-virus arrêté, implantation du catalogue et du cache camera raw, répartition des disques, etc.)
- un flux de travail strictement défini.
Il faudra aussi permettre à l'utilisateur de décrire assez précisément la configuration utilisée : processeur, mémoire, disques, SSD, etc.
Comme base de départ voici un résumé des 2 benchmarks cités plus haut :
1. Benchmark de Michael Deleon :
- Redémarrez le Mac/PC.
- Ouvrir un nouveau catalogue Lightroom vierge.
- Importer 100 fichiers raw.
- N’appliquer aucun réglage de développement
- Première mesure :
- Sélectionner tout et cliquer sur Bibliothèque > Aperçus > supprimer les aperçus 1:1 (juste au cas où Lightroom aurait déjà construit des prévisualisations)
- Ensuite, sélectionner tout et cliquer sur Bibliothèque > Aperçus > Rendu des aperçus 1:1
- Démarrer le chronométrage.
- Arrêter le chronomètre lorsque le texte sous la barre de progression indique que la tâche terminée.
- Deuxième mesure (exportations) :
- Sélectionnez les 100 images.
- Exporter vers le disque dur interne (à préciser : même disque ou disque séparé)
- Pas de renommage de fichier
- JPEG qualité 100
- espace colorimétrique sRGB
- pas de redimensionnement
- 300 dpi
- aucune netteté de sortie
- Cliquez sur exporter et démarrer le chronomètre
- Arrêter le chronomètre lorsque le signal sonore retentit
- Répétez l'opération pour vérifier vos résultats (combien de fois ?)
2. Benchmark de Clubic :
- mesure du temps nécessaire pour exporter une centaine de photographies au format RAW (issues d'un Nikon D90) au format JPEG avec l'application de divers filtres (netteté, correction de l'objectif, etc). Les résultats sont exprimés en secondes.
Commentaire :
Le bench de Clubic me semble un peu restreint (leur objectif n'est pas de benchmarker LR mais de benchmarker les processeurs); celui de Michael Deleon est un peu plus riche. Cependant je pense qu'il ne faut pas exclure les réglages de développement qui sont au coeur de l'utilisation de LR; je pense même qu'il faudrait introduire un certain nombre de corrections locales très consommatrices de CPU.
(à suivre ...)
-
Michel,
Je pense que pour tester les performances d'une voiture , il faille appuyer à fond sur l'accélérateur.
Dans cette optique, pour tester Lightroom, il va falloir lui faire exécuter une série de tâche soit à l'import, soi à l'export ou les deux. Je pensais à la conversion DNG à l'import , tâche qui consomme du cycle processeur et qui influencera le résultat du chronométrage. C'est juste une idée....puisque cette conversion fait partie du flux normal du photographe.
Le protocole de Michel Deleon me parait bien. C'est celui que j'avais déjà pratiqué, sans le savoir, lors de mes tests il y a quelques moi sur ma nouvelle et ancienne plateforme (LR3).
Il y a d'autres personnes qui s’intéressent à la question: http://forum.nikonpassion.com/index.php?topic=42508.msg%msg_id%
J'insiste sur le fait que la série d'image importe peu. Pourvu qu'elle soit issu de boitiers récents et qu'elles soient en RAW. Donc peu importe le sujet, ce qui compte c'est que ce soit toujours la même base qui soit utiliser dans les tests. Je pense que 15 à 20 RAW devraient suffire.
Il sera nécessaire de contrôler l'exécution auto des applications (msconfig pour seven). Chez mac je ne sais pas. Sinon le redémarrage ne servira pas à grand chose.
Sous seven, on veillera à ne pas désactiver les coeurs. J'en parlerai plus tard.
On veillera à ne pas overclocker les composants afin d'avoir un résultat plus probant.
-
J'ai cru remarquer que les fichiers sont plus ou moins lourds selon qu'ils représentent des scènes unies ou aux couleurs et contrastes variées.
Il serait bon sans doute aussi de définir une procédure de création des fichiers:
Réglage des appareils, plage dynamique, sujet etc...
Oui le poids des images est dépendant du sujet qu'elle représentent. La procédure de création de fichier me parait franchement inutile. Ce que l'on veux c'est un nombre fixe de RAW issu de boitiers récents et représentatif des photos de monsieur tout le monde. Donc peu importe le sujet, mais de disposer d'un lot connu de photos (étalon) afin de procéder au chronométrage lors du travail dans LR.
-
Michel,
On entretient notre discussion ici devant tout le monde, car il y a sûrement quelques bonnes idées qui peuvent surgirent.
Afin de rendre accessible le test au plus grand nombre, et afin de conserver ce caractère reproductible, je pensais :
- Qu'il faille créer un preset de développement et ainsi s'affranchir des multiples coups de pinceau, variables d'un utilisateur à un autre, car on le sait que cette retouche locale va être déterminante dans le résultat final.
Dans ce preset, on y mettra les développements généraux, représentatifs du travail normal d'un photographe et des retouches locales. À l'export, chacun aura la certitude d'être sur le même pied d'égalité.
- Que la structure de disque interne doit être simple. Tout le monde ne possède pas de second disque dur interne, de disque externe, etc. Je préconise de mettre le cache sur le disque aux côtés du catalogue et de l'application. On fournira le fichier de configuration du catalogue et de lightroom si nécessaire. Cette configuration sera évidemment temporaire pour le benchmark.
Nous serons sûrs que le test sera reproductible et facilement réalisable par l'ensemble de la communauté.
Qu'en penses-tu?
Cyril
-
Bonsoir Cyril et bonsoir aux autres !
C'est vrai que ce fil ressemble un peu à une conversation privée, mais je suis assez convaincu que le sujet doit intéresser pas mal de monde à en juger par le nombre de fil ou de post où il est question de performances.
Je suis tout à fait d'accord avec toi pour automatiser le développement afin de s'affranchir des façons de faire des utilisateurs. L'idée d'un preset est certainement très bonne car elle permettra aussi de faire des variantes du bench avec, par exemple, plus ou moins d'usage de la retouche locale. De mon côté j'ai essayé d'avancer aujourd'hui sur une première maquette du bench. Je n'avais pas pensé au preset; j'ai donc intégré les réglages de développement dans les images. Ainsi lorsqu'on importe les images le catalogue se charge de ces réglages et il n'y a aucune intervention de l'utilisateur. Le bench est donc complètement reproductible. En revanche c'est ridgide; impossible de modifier les réglages de développements comme avec un preset.
Je suis d'accord aussi sur la nécessité d'une structure de disques simples. Dans ma maquette j'ai supposé que l'utilisateur avait 2 disques : un pour le système et un pour les données. Mais là aussi on pourra imaginer des variantes, ce qui pemettra de benchmarker l'effet de telle ou telle structure de disques. Quand on voit les discussions auxquelles l'impact d'un SSD sur les perf de LR a donné lieu, on peut penser qu'un tel bench aura de l'intérêt.
Il me reste un peu de travail pour que ma maquette soit utilisable. Dès qu'elle est prête je la poste ici. Sans doute ce soir.
(à suivre...)
-
Voici en PJ la maquette que je propose.
Cyril peux-tu la tester et faire tes commentaires ?
A demain :)
-
Bonjour Michel et bravo pour ce travail.
Dans un premier temps j'ai réalisé les test à trois reprises avec des temps sensiblement identiques ( pas de programme en arrière tâche). Ce test a été réalisé sur un disque dur interne mécanique (SATA 2 mode IDE). Je réaliserai d'autres tests sur un SSD interne (Sata3 Mode AHCI) et un disque externe (USB3 7200 t/min).
Avant de te joindre les résultats, je voudrais revenir sur 3 petits points de ton tuto:
-Il faudra ajouter , lors de l'import, sélectionner le dossier où se trouvent les originaux .
Section 2.2 8, il faudra rajouter Sélectionnez "Purger tous les aperçus".
Et enfin, section 2.2 12 Faire un clic droit sur les images sélectionnées et choisir la commande "exporter".
Ce sont de tout petits détails mais il faut que le débutant puisse suivre à la lettre cet excellent tuto.
Mes temps sur HDD classique interne: Test 1 Test 2 Test 3
T1 = 45 s T1=45s T1=44 s
T2 =2 min 15 s T2= 2 min 15 s T2= 2 min 15
T3 = 2 min 17 s T3= 2 min 20 s T3= 2 min 20
Config : Intel I7 2600K + 8 Go mémoire version LR 4.1.
Il sera intéressant de réaliser le prochain test avec la nouvelle version 4.2.
Mais ce qui m’intéresse c'est de comparer ces résultats avec ceux que je réaliserai sur un SSD beaucoup plus performant que mon vieux HDD.
Cette semaine est chargée professionnellement, je demande juste un petit délai pour la suite.......
PS: Je ne suis pas arrivé a accéder à ton tableau.
-
Merci beaucoup Cyril.
Je vais intégrer toutes tes remarques dans une V2, mais comme je suis en train de faire un upgrade de mon PC (plus modeste que toi, je me suis limité à un i5) je ne le ferai pas aujourd'hui. C'est d'ailleurs cet upgrade qui a motivé ma question initiale sur le benchmark.
Tes mesures sur l'impact du SSD seront très intéressantes car de mon côté l'impact du SSD est plutôt négatif ! Mais il faut dire que ma carte mère date de Mathusalem (je la change bien sûr) et qu'elle gère très mal les SSD (tu t'en souviens sans doute).
Concernant le tableau tu ne risquais pas d'y accéder, je ne l'ai pas enore fait ! ;-)
@+
-
Acte 2: test sur un SSD SATA 3 (mode AHCI) puce NANDFORCE dernière génération. Le must en terme de débit (je sature le SATA3 en lecture)
Config: l'OS et LR 4.1 sur un SSD dédié.
Le catalogue, les aperçus et les images sur une partition dédiée d'un second SSD physique (le même que le premier)
Cf Acte 1 pour les autres tests ci-avant
J'ai obtenu rigoureusement les mêmes temps (à la seconde près) pour les 3 tests: T1=44s, T2= 2min 19 et T3 =2min 18 et quasi la même chose que pour un disque classique.
Premières considérations: J'ai remarqué que l'anti-virus ne jouait pas contre les performances de LR. J'avais effectivement omis de la désactiver dans le premier test sans que le résultat en soit affecté. Ceci est lié au mufti-coeur du I7. Cela était à prévoir.
En travaillant sur un vieux HDD mécanique SATA2 ou sur un SSD dernière génération il n'y a aucune amélioration. Cela signifie que le débit d'instruction sortant du pipeline du processeur est inférieur aux temps d'écriture du disque le moins rapide. Autrement dit, LR monopolise toute la puissance du processeur et les calculs sont longs, avec pour résultat une saturation des bus SATA peu probable.
J'avais déjà constaté cela, et il semble que ce soit confirmé chez moi.
L'acte 3 se déroulera avec LR 4.2. Il sera intéressant de voir les progrès réalisé avec cette mise à jour dans les mêmes conditions de test. Rendez vous pour ce troisième test....
Cyril
-
Salut Cyril; ces résultats me semblent extrêmement intéressants et confirment mes impressions. Il est très difficile de juger ce genre de chose sans mesure; les discussions qui ont eu lieu ici même sur l'impact d'un SSD sur les performances de LR en sont la preuve. L'avantage du Benchmark est de donner une réponse objective.
En ce moment je termine la mise en route de mon i5 et je n'ai donc pas du tout travaillé au bench. Je le ferai dans quelques jours : intégration de tes remarques et préparation d'un tableau pour les résultats (sans doute dans Google drive).
Ensuite il faudrait peut-être réfléchir à une mesure de la fluidité des outils de retouche locale dans le module développement. Mais je n'ai pas trop d'idée pour l'instant car il me semble obligatoire de faire intervenir l'utilisateur, ce qui crée un biais. A moins d'utiliser un logiciel de simulation de dialogue homme-machine; je sais que ça existe, mais je n'en connais pas.
Bonne journée à tous.
Michel
-
Bonjour Cyril, bonjour à tous,
J'ai apporté quelques améliorations de détail au texte du protocole de mesure qui passe en V2. J'ai surtout préparé un formulaire (Google) pour faciliter la saisie des résultats et leur synthèse. Tu le trouveras ici : https://docs.google.com/spreadsheet/viewform?formkey=dHNmbTdjTlFQNlNiNVRmZUpIakV4bnc6MQ#gid=0 (https://docs.google.com/spreadsheet/viewform?formkey=dHNmbTdjTlFQNlNiNVRmZUpIakV4bnc6MQ#gid=0).
Si tu as un peu de temps, pourrais-tu le tester et me dire ce qu'il faut améliorer pour rendre la saisie la plus simple et la plus facile pour les utilisateurs.
Rien ne presse car je pars en voyage pour 3 semaines. Je reprendrai donc le sujet fin novembre. On pourra j'espère lancer alors un appel à une campagne de mesures générale ! ;)
Quelques commentaires sur les mesures que je viens de faire sur ma nouvelle configuration (Intel Core i5 à 3600 MHz avec 8 Go de RAM) :
- comme toi je ne constate aucune amélioration en utilisant un SSD ni pour le catalogue, ni pour le cache camera raw, ni pour les images.
- de même je ne constate pas de différences entre un disque 7200 rpm et un velocyraptor à 10 000 rpm.
- la seule chose qui semble avoir un peu d'effet est le fait de répartir le catalogue, le cache camera raw et les images sur plusieurs axes.
- LR4.2 semble calculer systématiquement le rendu 1:1 de la première photo du lot au moment de l'importation, ce que ne faisait pas LR4.1. Du coup le temps T1 est allongé, mais T2 est raccourci d'autant. Au total LR4.2 a exactement les mêmes temps que LR4.1.
- la purge des aperçus ne me semble pas fonctionner très bien. Il est donc important de démarrer avec un catalogue et un cache camera raw vierge.
- Voici mes résultats :
- LR4.1 : T1 = 0'52" T2 = 1'50" T3 = 1'56"
- LR4.2 : T1 = 1'07" T2 = 1'44" T3 = 1'53"
Michel
-
Vos résultats confirment (hélas) ce que j'avais synthétisé dans un post il y a plus de 6 mois, et qui avait été passablement conspué à l'époque ::)
-
Je m'en souviens François Xavier :)
L'intérêt de disposer d'un protocole de bench standard c'est que chacun peut le refaire chez lui. Ca calme les esprits ;)
-
Je n'étais pas la il ya six mois...Aurais commandé un SSD pour rien ?
-
Je n'étais pas la il ya six mois...Aurais commandé un SSD pour rien ?
Non il te sera utile pour d'autres tâches....
-
Ok MIchel je regarde ça dès que possible. Bon séjour.....
-
Bonjour, je viens d'enregistrer 3 tests différents sur le document en ligne. Ces trois tests sont réalisés sur des combinaisons de disques différentes (cache , catalogue).
Je reviendrais sur mes commentaires bientôt mais je peux d'or et déjà dire que la version 4.2 augmente le temps d'import de façon significative, et que le SSD n'apporte aucun gain pour le catalogue et le cache.
En tout cas dans le contexte où j'ai réalisé les tests dans le module bibliothèque. On verra par la suite si le retouches locales et le SSD influencent les scores....
@ Michel,
Ton formulaire est vraiment bien fait, rajoute juste la 4.3........ ;)
Cyril
-
et que le SSD n'apporte aucun gain pour le catalogue et le cache.
Ce n'est pourtant pas ce qui a été constaté en interne par les développeurs Lightroom et pas mal d'autres testeurs du logiciel, même si le gain reste modéré. Personne n'a jamais dit qu'on doublerait les performances en utilisant un SSD.
-
et que le SSD n'apporte aucun gain pour le catalogue et le cache.
Ce n'est pourtant pas ce qui a été constaté en interne par les développeurs Lightroom et pas mal d'autres testeurs du logiciel, même si le gain reste modéré. Personne n'a jamais dit qu'on doublerait les performances en utilisant un SSD.
Bonjour Gilles,
Pour recadrer le test par rapport aux conclusions générales de l'équipe Adobe, je dirais que le test est basé sur un import et copie de dng, d'application de réglage auto à l'import , de la création d'aperçu 1:1 et d'export en jpeg. Je ne suis même pas allé dans le module développement.
Par conséquent, mes conclusions restent axées sur le test qui n'est pas un test global.
C'est vrai le SSD ne double pas les performances, tu l'as écris toi-même sur ton blog . Ce n'est pas non plus ce que je suggérais
Je me permet de reprendre la remarque d'un membre il y a quelques temps:
J'ai lu l'article sur computer-darkroom qui montre que l'utilisation du SSD n'apporte pas grand chose côté perfo pur à l'import / export...
Par contre, je comprends que si je place mon catalogue/preview sur mon SSD, le ressenti sera qd même perceptible dans la navigation du catalogue (affichage des vignettes etc...)
Le test est basé sur un chronométrage entre un lancement de tâche et la fin effective de celle-ci. Cela ne tient pas compte du ressentie en terme de rapidité d'affichage des vignettes qui de toute façon est inférieure à la durée de la tâche elle même. Ce que je veux dire c'est que si l'affichage est plus rapide avec un SSD, cela ne sera de toute façon pas prit en compte dans le chrono.
Par contre en import en mode copie et en export, on écrit des données sur les disques. Le test que j'ai réalisé comparait un disque interne 7200t/min (SATA) et un SSD. Vu les débits des premiers, l'impact n'a pas été mesuré.
-
et que le SSD n'apporte aucun gain pour le catalogue et le cache.
Ce n'est pourtant pas ce qui a été constaté en interne par les développeurs Lightroom et pas mal d'autres testeurs du logiciel, même si le gain reste modéré. Personne n'a jamais dit qu'on doublerait les performances en utilisant un SSD.
Bonjour Gilles,
Pour recadrer le test par rapport aux conclusions générales de l'équipe Adobe, je dirais que le test est basé sur un import et copie de dng, d'application de réglage auto à l'import , de la création d'aperçu 1:1 et d'export en jpeg. Je ne suis même pas allé dans le module développement.
Par conséquent, mes conclusions restent axées sur le test qui n'est pas un test global.
C'est vrai le SSD ne double pas les performances, tu l'as écris toi-même sur ton blog . Ce n'est pas non plus ce que je suggérais
Je me permet de reprendre la remarque d'un membre il y a quelques temps:
J'ai lu l'article sur computer-darkroom qui montre que l'utilisation du SSD n'apporte pas grand chose côté perfo pur à l'import / export...
Par contre, je comprends que si je place mon catalogue/preview sur mon SSD, le ressenti sera qd même perceptible dans la navigation du catalogue (affichage des vignettes etc...)
Le test est basé sur un chronométrage entre un lancement de tâche et la fin effective de celle-ci. Cela ne tient pas compte du ressentie en terme de rapidité d'affichage des vignettes qui de toute façon est inférieure à la durée de la tâche elle même. Ce que je veux dire c'est que si l'affichage est plus rapide avec un SSD, cela ne sera de toute façon pas prit en compte dans le chrono.
Par contre en import en mode copie et en export, on écrit des données sur les disques. Le test que j'ai réalisé comparait un disque interne 7200t/min (SATA) et un SSD. Vu les débits des premiers, l'impact n'a pas été mesuré.
Ok, dans ce cas, on est d'accord !
-
Bonjour,
Comment retrouve t'on le tableau des l'ensemble des mesures?
Une synthèse?
merco.
-
Bonjour,
Comment retrouve t'on le tableau des l'ensemble des mesures?
Une synthèse?
merco.
Bonjour Hitman,
La synthèse des résultats n'est pas encore faite puisque la campagne de mesure n'a pas démarrée. Nous avons validé un certains nombres d'aspect sur le test, Michel se charge de la construction du formulaire on-line et par la suite de l'enregistrement des tâches de retouche locale automatisées. Nous vous tiendrons au courant.