Commentaires sur : Vitesse d’importation de Lightroom Classic vs Lightroom 6

Par : jpt

jpt — Sun, 05 Nov 2017 19:38:41 +0000

Bug suite…
lorsque en BIBLIOTHEQUE j’appuie sur la fleche droite ou gauche, c’est pas super rapide et cela » hockette » (sauts irréguliers)
En v6, v5, v4 ce bug n’existais pas

Alors que lorsque je fais cela à la souris, cad le changement d’images c’est tres rapide, bref comme la v6,5,4 sur son clavier.

C’est le meme clavier, d dur, catalogue, pc …tout pareil lors des tests

constaté aussi par d’autres cf la sur le blog d’adobe
.
.
Operating System: Win10x64
note1: de mon coté c’est win 7 de base (pas sp1) x64 bien sur, pour la précision, ce n’est donc pas lié à l’os
.
note 2: itou en fenetré pas plein ecra, et itou aussi avec meme des rendus les plus petits possibles avec la fenetre de mon écran bien sur reglé a son minima pour rentrer dans le gabarit de la creation des caches, cad 1024, low, one week dans le selecteur ad-hoc

Lightroom CC Classic 7.0.1

Hi all,
I’ve found a very strange behaviour of LR Classic CC, and I’m curious to see if it is only me or it is more widespread:
When in the Library Module looking at a single full-size picture (E), I can change to the next/previous picture by either:
- Using the left / right keyboard arrows
- Using the mousewheel

Thing is, using the mousewheel is, in my computer, enormously faster. Not « a little bit » – it is MUCH better, and suffers no lag. With the wheel, changing from one picture to the next, or 20 after, is extremely quick – instantaneous I would say – and I get to see every picture in-between as I scroll many pictures.

On the other hand, when I use the left-right arrows, changing pictures is slower, and if I quickly push (or leave pressed) right e.g. 20 times, after I take my finger up LR will still be changing from one picture to the next, and often will need quite a few seconds to catch up, still changing pictures while I’m not touching the keyboard anymore. This does not happen with the wheelmouse.

Am I the only one this is happening to? I could make a video showing the issue if needed, but I’d like to know if more people experience this behaviour.
.
…..
voila comme cela tu aura une bonne liste de bugs verifiés à donner à adobe et peut etre que comme cela, avec l’aide que tu leur apporte, ils t’offrirons enfin ton abo ce qui est un minimum vu l’aide constante que tu leur ap^porte, sinon je peut poster la bas en direct si tu veut, mais je préfere que cela soit toi qui en profite que adobe en direct
a plus

Par : Jpt

Jpt — Sun, 29 Oct 2017 19:19:53 +0000

Salut Gilles,
Merci pour ta confirmation pour la BDD changée.

Je me pose deux questions:
1) As tu aussi des fichiers *.pak dans le repertoire de Lr sur ton mac ?
.
2) Sais tu à quoi servent ces fichiers pak
exemple:
cef_100_percent.pak
……
cef_extensions.pak
Et la dll qui apparemment les gerent cad celle ci
cef_toolkit.dll
.
a

Par : Gilles

Gilles — Sun, 29 Oct 2017 10:01:53 +0000

@ Pierre,

J’utilise un écran wide gamut BenQ SW270 relié à mon MacBookPro 15″ qui lui utilise un écran UHD. Je réfléchis à l’installation d’un 3e écran.

Par : Gilles

Gilles — Sun, 29 Oct 2017 10:00:36 +0000

@ Marc, Lightroom peut générer les aperçus standard à partir des images importées en mode « fichier annexe incorporé » dans les moments creux si l’option est cochée dans les Préférences.

Par : Gilles

Gilles — Sun, 29 Oct 2017 09:58:02 +0000

@ jpt, oui la base de donnée a été optimisée pour réduire l’embonpoint et améliorer les performances.

Par : Gilles

Gilles — Sun, 29 Oct 2017 09:55:47 +0000

@ Christian

LrCC ne monopolise pas les ressources au détriment de Lr Classic, il s’agit de deux équipes différentes.

Pour les mots-clés, la limitation vient de l’incompatibilité de Lr CC avec les mots-clés hiérarchiques.

Par : Pierre

Pierre — Sun, 29 Oct 2017 09:12:43 +0000

intéressant je pense que je vais faire le pas et passer en abonnement mensuel.

Gilles, je suis intrigué, quel écran utilisez vous ?

Par : marc labro

marc labro — Sun, 29 Oct 2017 05:46:52 +0000

merci Gilles,
ce que je ne comprends pas bien c’est qu’on doit choisir les jpg incorporés OU les aperçus standards donc forcément on garde les aperçus standards sinon on perd énormément de temps après. déjà 27min au lieu de 53min c’est très bien. peut-être que ce serait bien de faire les deux en même temps donc on aurait une grille rapide et les images prêtes en arrière plan.
j’ai compris que LR réalisait les aperçus standards dans les momeents creux si on choisissait les jpg à l’import ? tu conseilles cela ?

merci
marc

Par : Pierre SCHIETTECATTE

Pierre SCHIETTECATTE — Sat, 28 Oct 2017 21:12:11 +0000

Bonsoir,
Effectivement, j’ai constaté une amélioration de la vitesse, sur une petite série d’une centaine de photos.
Il y a d’autres fonctionnalités que j’apprécie dans cette nouvelle version (abonnement LR Classic CC). Il doit sans doute y avoir des défauts de jeunesse, mais je n’en ai pas rencontré jusqu’à présent. Je suis satisfait et je trouve que cette version marque la volonté de faire évoluer doucement un produit qui semble pourtant déjà très abouti.

Par : jpt

jpt — Sat, 28 Oct 2017 02:21:12 +0000

salut Gilles,
Puisque tu est dans les tests, quelques trucs en vrac que j’ai testé de mon coté.
.
La methode des fichier de cataloguage a du profondément changer, je m’explique.
Tests faits sur LR 6 (cc)vs la version 7 CC classic.
.
J’importe (convertis) donc un catalogue de la v6 qui fait 250Mo environ (et qui est optimisé avant bien sur) vers la v7
.
Surprise…le catalogue de la v7 taille fait seulement apres QUE 146Mo (en gros).
.
Alors la clap clap, mais qd meme je m’interroge un peu.
Tout est la.
Ils ont changé quelque chose dans la structure profonde du format de la b de données .
.
Parce que forcément apres, j’ai bien sur utilisé pour voir 7Zip en utilisant la compresion maximum posible (ultra, Lzma2, 64Mb, 256 et solid dans l’ordre)
Et le ratio de compression est de environ 3% (impressionant pour un catalogue la v6) ce qui veut dire en gros 250Mo = 8Mo à archiver.
J’ai bien sur fait la meme chose avec le meme catalogue de la V7 et ici j’obtiens un ratio bien moins bon (environ 30% de mémoire) cad que pour un fichier de 150Mo je vais vers 30Mo à archiver.
.
Manip qui prouve ce changement profond de structure.
.
Tu pourra essayer cette manip si tu veut de ton coté.
.
Dans les trucs moins bien (de la 7) vers la 6.7 que j’utillisais.
Tests fait sur du JPEG et sur une grosse session jpeg (environ 500 tofs par dossier)
Et bien lorsque que je suis en mode librairie (pas dev) et que je garde mon doigt sur fleche vers la droite p ex, ca va super vite les changements d’image genre dessin animé c’est super reactif, alors que dans la v7, c’est nettement moins performant.
.
En revanche sur du raw , c’est bien moins impactant (les deuxs se valent, voir meme un avantage à la v7)

Je n’utilise pas le mode smartview pour ces tests mais le mode photo direct.
.
Dernière chose, c’est voulu ou c’est involontaire de la part de Adobe de grossir les exe lr d’une maniere incomprehensible ???
Lr 5 exe = 4Mo
Lr 6 exe = 17 Mo !!!
Lr 7 exe = 19 Mo
Le passage de Lr 5 a 6 justifie t’il (a ton avis) une multiplication par plus de 4 de l’exe ?
J’ai tout de suite compris pourquoi, en fait la veritable taille du changement de code est:
v5 4Mo (la c’estais encore propre, enfin à peu pres)
v6 Un peu plus de 4Mo qui est sa veritable taille « nettoyée »
V7 « » » » 5Mo » » » » » » » »

Voila les veritables taille que les exes doivent avoir ou devraient avoir.
.
Je continue, il est impossible d’installer la version 7 (depuis la 6.8 exactement) sur un windows 7 natif (cad PAS un SP1) et sans partir dans des délires profonds d’installation d’une palanquée de visual C
.
Sais tu que LR 7 classic CC peut parfaitement tourner sous win 7 de base (pas SP1) et sans un seul pack visual C installé.
.
Je n’y vois que deux possibilitées:
.
1) Une incompétence notoire dans la partie package OU chez dev chez adobe concernant le système windows et ses APIs
.
2) Ou la plus probable…
ecoeurer les clients à mort pour obliger à migrer sur un win 10.
.
A