Bundle Nik Software à prix compressé

[DJANK]

Bonjour,

et merci pour ces réponses, il semblerait donc préférable, lorsqu'on dispose de photoshop, d'utiliser la version complète de Nik Software.

Cordialement
Djank

[Pat91]

et merci pour ces réponses, il semblerait donc préférable, lorsqu'on dispose de photoshop, d'utiliser la version complète de Nik Software.

Oui, c'est mon humble avis. Surtout qu'au tarif FPF, la différence entre les prix des 2 versions est beaucoup moins forte.

[Olivier Chauvignat]

le terme de Plugin pour Lightroom est abusif, pour al simple et bonne raison que les "Plugins pour lightroom" n'existent pas. Si Nik utilise ce terme de "plugin" alors ils mentent. C'est une pratique mensongère et que j'apparente à de la tromperie.

Ce ne sont en fait que de simples logiciels extérieurs à LR totalement hors du flux RAW.

[Will95]

le terme de Plugin pour Lightroom est abusif, pour al simple et bonne raison que les "Plugins pour lightroom" n'existent pas. Si Nik utilise ce terme de "plugin" alors ils mentent. C'est une pratique mensongère et que j'apparente à de la tromperie.

Ce ne sont en fait que de simples logiciels extérieurs à LR totalement hors du flux RAW.

Peut être utilisent-ils se terme car il ne peuvent pas fonctionner en dehors de l'environnement "hôte" ?

[THG]

le terme de Plugin pour Lightroom est abusif, pour al simple et bonne raison que les "Plugins pour lightroom" n'existent pas. Si Nik utilise ce terme de "plugin" alors ils mentent. C'est une pratique mensongère et que j'apparente à de la tromperie.

Ce ne sont en fait que de simples logiciels extérieurs à LR totalement hors du flux RAW.

Je n'aurai pas un avis aussi tranché. Il ne faut pas oublier que ces logiciels sont compatibles avec le mécanisme de rapatriement automatique dans l'application hôte et le catalogue

Dans ce cas, la frontière entre plug-in et éditeur externe est un peu floue.

Je pense que le terme "plug-in" est utilisé plus par habitude que pour vraiment tromper les gens. D'ailleurs, il suffit de lire la documentation ou d'installer une version démo pour s'en rendre compte, mais beaucoup ne prennent même pas cette peine.

[Pat91]

le terme de Plugin pour Lightroom est abusif, pour al simple et bonne raison que les "Plugins pour lightroom" n'existent pas. Si Nik utilise ce terme de "plugin" alors ils mentent. C'est une pratique mensongère et que j'apparente à de la tromperie.

Ce ne sont en fait que de simples logiciels extérieurs à LR totalement hors du flux RAW.

Nik Software ne peut se voir reprocher d'utiliser un terme officialisé par Adobe. En ce qui concerne Lightroom, il y a bien un SDK de développement des "plugins d'export". La documentation de ce SDK décrit clairement les mécanismes de communication entre LR et le plugin qui ne saurait donc fonctionner en tant que programme externe sans la présence de LR. Donc, vu par un développeur, il s'agit bien d'un plugin et Nik Software fait avec ce qu'on leur donne comme outil.

Que ce plugin ait des possibilités très limitées (il ne permet pas d'intervenir directement sur l'image et ne s'insère pas dans le flux d'édition) ne lui retire pas sa qualité de plugin au sens général du terme. Que ces plugins d'export soient moins intéressants que les plugins de Photoshop est une autre affaire.

S'il y a un reproche à faire, ce serait plutôt à Adobe qui ne veut pas mettre en place un mécanisme qui mettrait en danger le marketing de Photoshop. C'est leur choix et cela a déjà été largement commenté. Mais les développeurs "tierce-parties" comme Nik, Topaz, onOne, etc. n'y peuvent rien.

Notons toutefois que l'écriture d'un SDK pour de "vrais" plugins LR et le développement de tels plugins impliquerait dans tous les cas un développement à neuf des plugins. Les plugins de Photoshop travaillent sur une structure de données qui n'a rien à voir avec celle qui pourrait être exposée par LR aux modules externes. Même dans le cas des RAW, les plugins de Photoshop travaillent sur une image qui est déjà sortie du module ACR et transformée en image bitmap (au sens large). Dans LR, les mécanismes d'édition sont sinon beaucoup plus complexes, du moins très différents.

[THG]

De toute manière, Tom Hogarty, à la sortie de Lr 2 en 2008, n'avait pas rejeté ni exclu la possibilité d'un SDK pour le traitement des images, ce qui implique l'ouverture du moteur de développement Camera Raw. Propos qu'il avait également tenus lors d'un échange de mails.
Et il n'a pas publiquement changé d'avis depuis.

Il faut également tenir compte de ce que demandent les utilisateurs et, j'ai eu l'occasion de le dire plusieurs fois ici, cette possibilité ne fait pas partie des réclamations les plus fortes ou les plus récurrentes.

Et, d'autre part, la décision d'ouvrir le moteur appartient à Thomas Knoll et son équipe, pas aux développeurs de Lightroom.

Au début, j'ai beaucoup milité pour ça. Depuis, j'ai changé d'avis car je pense qu'il y a plusieurs choses plus urgentes à faire :
- Rajouter ce qui manque à Lightroom.
- Améliorer les outils déjà existants.

[Olivier Chauvignat]

Je n'aurai pas un avis aussi tranché. Il ne faut pas oublier que ces logiciels sont compatibles avec le mécanisme de rapatriement automatique dans l'application hôte et le catalogue

Dans ce cas, la frontière entre plug-in et éditeur externe est un peu floue.

Je pense que le terme "plug-in" est utilisé plus par habitude que pour vraiment tromper les gens. D'ailleurs, il suffit de lire la documentation ou d'installer une version démo pour s'en rendre compte, mais beaucoup ne prennent même pas cette peine.

Appelons ca un plug-out alors

Parce que rien ne différenciera un élément qui conserve le flux raw, d'un éditeur externe.
sinon dans ce cas, exporter un psd rapatrié rend Photoshop "plug-in" de LR... et il n'y a plus aucun discernement.

[Olivier Chauvignat]

- Améliorer les outils déjà existants.

comme par exemple une interface digne de ce nom pour les réglages locaux. En s'inspirant très fortement de... de..., Nik software

[Pat91]

comme par exemple une interface digne de ce nom pour les réglages locaux. En s'inspirant très fortement de... de..., Nik software

Les U Points dans LR, ça serait idéal mais je ne suis pas certain qu'ils puissent faire ça (en tous cas, pas facilement et pas maintenant). Quand on regarde le contenu d'un XMP après retouches locales, on voit que chaque zone retouchée est définie par une suite de coordonnées (grosso modo la trajectoire de la souris ou du stylet) associée à un rayon, une zone de transition et un mode de travail.

Quand on définit un U Point dans un plugin Nik (qui travaille donc sur une bitmap, au sens programmatique du terme), il est très probable (supposition basée sur ma propre expérience) que ce U Point soit représenté par une autre bitmap en mémoire. Quand on modifie les réglages du U Point, on modifie la bitmap associée que l'on "fusionne" avec la bitmap représentant l'image en général ou le calque. C'est très grossier comme description mais ça donne une idée. En particulier, la lecture du XMP montre bien (sauf erreur de ma part) qu'en mode automasquage, les informations concernant la limite du masque ne sont pas stockées. Ce qui implique qu'elles sont recalculées à chaque fois que c'est nécessaire. Voir ci-dessous pour les performances.

Or la raison pour laquelle, dans ACR ou LR, on ne peut pas avoir de masques ni donc de manipulations associées, c'est qu'en fait, on ne fait que recalculer en permanence pour l'aperçu une bitmap résultant de l'association des données RAW et des données de correction stockées dans le catalogue et/ou le XMP. Pour résumer/simplifier : sous PS le plugin maintient une bitmap représentant les modifs utilisateurs, bitmap qu'il est facile de modifier alors que sous LR, on enregistre des actions utilisateurs qui serviront à reconstituer l'image à chaque fois qu'une modification sera effectuée. On ne touche pas aux données RAW, ce n'est pas destructif mais c'est lent et limité.

Ce qui explique d'ailleurs une partie des problèmes de performance de LR et pose très nettement les limites de cette approche en matière d'édition. C'est un mécanisme très différent qui n'est pas bien adapté aux manipulations effectuées par un plugin comme ceux de Nik. Cela explique peut-être également (en dehors des considérations marketing), la difficulté à mettre à disposition un SDK qui permettrait aux plugins sous LR une manipulation similaire à celle qu'ils réalisent sous PS.

Techniquement, il n'y a pas d'impossibilité absolue (la preuve, Bibble 5 a clairement ouvert la voie dans ce domaine mais avec des difficultés évidentes) mais ce n'est pas franchement simple. Une solution acceptable verra sans doute le jour quand nous serons tous équipés de machines encore plus performantes que celles disponibles aujourd'hui.

[Zaphod]

Tu es sur que les upoints ne sont pas recalculés en live ?
Passer par des tiffs de masquage, ça me paraitrait étrange... (ça ferait des fichiers de réglage de taille gigantesque)

[Pat91]

Tu es sur que les upoints ne sont pas recalculés en live ?
Passer par des tiffs de masquage, ça me paraitrait étrange... (ça ferait des fichiers de réglage de taille gigantesque)

Je ne dis pas ça. Je pense que les U Points doivent utiliser une bitmap qui leur est propre et sur laquelle le calcul est plus rapide (car limité à une zone bien définie). De plus, s'agissant d'une bitmap qui doit être combinée à une autre bitmap (celle de l'image principale), cela va en général très vite. Alors que sous LR, il s'agit nécessairement d'un calcul global à chaque fois (on repart de l'ensemble des données - même s'il y a probablement des optimisations).

Encore une fois, ce sont des suppositions basées sur des pratiques de programmation et sur ma compréhension de LR et de PS.

[Zaphod]

Dans les plugins Nik il est possible de sauvegarder les réglages indépendemment de l'image ou pas ?
Ou c'est uniquement ouverture + édition + sauvegarde ?

[Pat91]

Dans les plugins Nik il est possible de sauvegarder les réglages indépendemment de l'image ou pas ?

Oui, sauf dans Viveza 2. Les modalités dépendent de chaque plugin (preset, profil,...). Pour Viveza, cela présente peut-être moins d'intérêt mais je suis surpris. J'ai posé la question mais il n'y a en tous cas rien dans la doc à ce sujet.

De plus, tous ces plugins fonctionnent comme des filtres dynamiques. Les réglages sont donc modifiables après coup si on les a utilisés sur un objet dynamique.

[Olivier Chauvignat]

je parlais juste de l'interface de U-Points. pas de leur mode de fonctionnement.
Actuellement on a une interface abominable sur LR pour les régales de zone. On pourrait avoir une barette de réglages (à la "u-points") partant de "l'epingle" de la zone.

[Pat91]

je parlais juste de l'interface de U-Points. pas de leur mode de fonctionnement.
Actuellement on a une interface abominable sur LR pour les régales de zone. On pourrait avoir une barette de réglages (à la "u-points") partant de "l'epingle" de la zone.

Ah ok. Oui, dans ce cas, c'est facile. On pourrait imaginer la même interface, sans la barrette de réglage du rayon qui n'aurait pas de sens dans ce cas. Mais ces histoires de brevets logiciels sont tellement tordues (et injustifiées) qu'ils ont peut-être bien breveté l'interface également (les barrettes). Sinon, je pense que l'on aurait vu apparaître des mécanismes similaires un peu partout.

[THG]

On pourrait imaginer, en utilisant le pinceau, accéder à un menu flottant dans lequel on pourrait modifier les réglages sans avoir à retourner dans le panneau latéral droit.

Ce système serait suffisamment différent des U-points.

Pour moi, la plus grande force des U-points, c'est l'affichage du masque de corrections, en noir et blanc, qui permet de placer l'effet avec une précision inégalée, sans effort particulier. Ceux qui ont retravaillé les pétales d'une fleur, par exemple, savent de quoi je parle.