> Nik Software (plug in Photoshop-Lightroom-Aperture) devient gratuit

[Julian]

JPEG ou TIFF. Utiliser un plugin Nik depuis DxO n'est pas compliqué:

1. Clic-droit sur l'image | Exporter vers une application
2. Choisir la version standalone du plugin, par exemple : C:\Program Files\Google\Nik Collection\Silver Efex Pro 2\Silver Efex Pro 2 (64-Bit)\Silver Efex Pro 2.exe
3. Procéder aux autres réglages et exporter.

Les plugin peuvent-ils s'utiliser en standalone... de base, c'est à dire, comme le nom l'indique, sans passer par DXO, PS etc ...

En suivant le cheminement que tu indiques,
par exemple : C:\Program Files\Google\Nik Collection\Silver Efex Pro 2\Silver Efex Pro 2 (64-Bit)\Silver Efex Pro 2.exe
cela ouvre PS.

Aurais je manqué quelque chose lors de l'installation (où je lui ai indiqué PS) ?
Je viens d'y revenir, et il impose (à la rubrique "Applications hôtes compatibles") un choix entre PS, Bridge ou Lightroom. Il ne me propose pas DXO qui est pourtant installé sur mon PC.

Je suis toujours en Windows XP.

J'ai à présent, dans mes filtres sur Photoshop, 2 sous répertoires :

A – Nick Collection, avec
- Dfine2,
- Sharpener Pro 3 Raw
- Sharpener Pro 3 Output
- Viveza 2
B – Nivk Softwaez, avec :
- Color Efex Pro 4,
- HDR Efex Pro 2
Par rapport au lien de téléchargement, il manque:
- Analog,
- Silver Efex

[maboullette]

Etant utilisateur de DxO, les Upoints de Viveza m'intéressent, via Photoshop Elements, dont j'ai une vieille version qui pourrait être remplacée par une plus récente.
Mais comme il ne faut pas rêver à une compatibilité avec DxO, je pense, que je souhaite garder comme outil de base pour la "derawtisation", est ce qu'une utilisation sur des JPEG exportés de DxO est pertinente ?

le plus pertinent,  serait de faire une exportation en Tiff  pour une utilisation des plugins sur le tiff et transformation en Jpeg ensuite ...

[ChatOuille]

J'ai essayé et chez moi ça marche. Tu dois exporter vers une application, choisir le dossier et puis le fichier exe (Silver Efex Pro 2.exe), pas le Silver Efex Pro 2.8bf.

[Samoreen]

par exemple : C:\Program Files\Google\Nik Collection\Silver Efex Pro 2\Silver Efex Pro 2 (64-Bit)\Silver Efex Pro 2.exe
cela ouvre PS.

Non. Vous avez sélectionné le plugin, pas l'exécutable. D'où l'intérêt de régler l'Explorateur Windows pour qu'il affiche les extensions. Ça évite les confusions.

[gimly]

marche aussi sur affinity photo 

[THG]

Permets-moi de douter fortement. Très fortement.

Il y a eu tellement de mouvements de centralisation / décentralisation des traitements dans la - courte - histoire de l'informatique que ca devrait rendre humble sur des affirmations pareilles.

Eh bien continue à en douter, que veux-tu que je te dise ? On aura l'occasion d'en reparler ;-)

[nicolas-p]

Ou, par exemple  : depuis quelques jours, Lightroom Web permet d'indexer et de faire de la recherche sur le contenu d'images. Les solutions et algos mis en place pour ça demandent tellement de ressources et sont si coûteux qu'il n'est pas envisageable de les installer en local.

J'en ai une petite expérience avec mes logiciels professionnels dans mon travail sur des clients légers fonctionant en citrix avec des énormes serveurs reliés en très haut débit :on nous avait annoncé mont et merveilles.
Jamais eu autant de bug crash plantage  pertes de données  etc... j'en passe alors que les débits en filaire sont d'un tout autre niveau qu'une  connexion à domicile...
L'équipe informatique s'arrache parfois les cheveux  et à demi mot reconnait l'énorme bourbier que représente cette solution pourtant très abouti en terme de performance et d'accès réseau pour des données volumineuses qui sont nettement plus accessible en local

C'est exactement le même principe qu'un cloud limité en interne et je manipule des images (format DICOM) tous les jours. (Plusieurs giga )

Entre la théorie et la vrai vie... vive le local.

Et le matos informatique avec lequel je travail se compte en millions d'euros. ..

[Samoreen]

Il y a eu tellement de mouvements de centralisation / décentralisation des traitements dans la - courte - histoire de l'informatique que ca devrait rendre humble sur des affirmations pareilles.

J'abonde. Je fais partie de la génération qui a abordé l'informatique (chez Big Blue) en travaillant avec des terminaux (les 3270 pour ceux à qui ça parle). Pas de micro-ordinateurs à l'époque. Une très grosse machine quelque part dans la nature et des terminaux "stupides" sur le bureau. L'arrivée du traitement local sur les PCs a été un véritable soulagement même si on a dans un premier temps gardé le contact avec les ordinateurs centraux grâce aux fameux émulateurs 3270. Le fait d'être constamment dépendant d'un traitement éloigné est une énorme contrainte (surtout parce que l'on est dépendant de la charge qui varie en fonction de la demande des autres utilisateurs). Ceux qui ont connu les heures d'attente derrière les imprimantes géantes raccordées à l'ordinateur central me comprendront.

Même si la technologie a évolué, les fondamentaux restent les mêmes. Maintenant que l'utilisateur a connu la maîtrise locale de son environnement, il ne renoncera jamais plus complètement à son indépendance. Que les applications locales fassent appel à des services éloignés est une idée acceptable, voire souhaitable. C'est d'ailleurs ce qui va probablement se passer mais ça nécessite des taux de transferts sur Internet qui sont impossibles sans la fibre accessible à tous (alors qu'il y a encore des masses d'utilisateurs dont la connexion atteint un débit en upload qui tourne autour de 512K).

Mais l'idée d'applications qui transformeraient nos PCs en terminaux stupides ne fera pas florès.

[THG]

Mais l'idée d'applications qui transformeraient nos PCs en terminaux stupides ne fera pas florès.

J'ai beau chercher dans ce fil, mais nulle part je ne vois cette idée.

[THG]

Prenons l'exemple de l'indexation de visages : on sait que celle-ci peut plomber la réactivité de l'ordinateur sur laquelle elle tourne en tâche de fond. Pourquoi ne pas envisager de confier cette tâche à un service en ligne, et de "redescendre" l'information ainsi créée en local ? On a déjà quelque chose de ce genre avec la géolocalisation inversée qui, il est vrai, ne brasse pas des To de données.

Et l'identification des visages n'est qu'un début, dès lors qu'on peut identifier et indexer des visages, on peut le faire avec n'importe quoi, y compris sur des notions subjectives comme la couleur, la luminosité, les formes. Si on ajoute à cela la création automatique de mots-clés ou de description sous forme de texte du contenu de l'image, je pense qu'il sera plus judicieux de confier cela à un service en ligne plutôt qu'en local et, de toute façon, le prix d'une licence d'un logiciel d'auto-tag est hors de portée d'un individuel et même d'un faiseur d'images professionnel.

Alors, bien sûr, tout le monde n'a pas le débit qu'il faut, mais tout le monde n'a pas la machine qu'il faut. Et, malheureusement, je pense que cela ne doit pas empêcher les éditeurs de logiciels d'avancer. Dans le cas de Lr, les mêmes problèmes avaient été évoqués à la sortie de Lightroom Mobile... hors, vu le taux d'adoption et d'utilisation très élevé - qui a dépassé les prévisions les plus optimistes - on se rend compte que, au final, ce n'est pas un frein.

[nicolas-p]

ok pour des données de petit volumes (mots clé, indexation,tag etc...) cela peut très bien fonctionner vu les débits faibles et cela parait pertinent.(bien que ceux qui par sécurité veulent séparer leur machine de travail du web en seront privés)

pour le développement raw et la retouche enligne ce n'est pas demain la veille que cela pourra se faire de manière aussi fluide qu'avec une station...
le traitement en local hormis dans des solutions inabordables (serveurs en parallèle faisant du calcul avec mutualisation) à encore de beaux jours devant lui quoi qu'en dise les éditeurs de logiciels quels qu'ils soient

[baséli]

Nous avons surtout réagi sur l'idée que c'était trop coûteux pour tourner en local, ce qui est à mon avis une idiotie. Qu'il y ait des services qui trouvent une rentabilité dans le cloud est un tout autre sujet: le nier serait aussi une idiotie.

[THG]

ok pour des données de petit volumes (mots clé, indexation,tag etc...) cela peut très bien fonctionner vu les débits faibles et cela parait pertinent.(bien que ceux qui par sécurité veulent séparer leur machine de travail du web en seront privés)

pour le développement raw et la retouche enligne ce n'est pas demain la veille que cela pourra se faire de manière aussi fluide qu'avec une station...
le traitement en local hormis dans des solutions inabordables (serveurs en parallèle faisant du calcul avec mutualisation) à encore de beaux jours devant lui quoi qu'en dise les éditeurs de logiciels quels qu'ils soient

c'est faire peu de cas de la technologie des aperçus dynamiques :-)

[THG]

Nous avons surtout réagi sur l'idée que c'était trop coûteux pour tourner en local, ce qui est à mon avis une idiotie. Qu'il y ait des services qui trouvent une rentabilité dans le cloud est un tout autre sujet: le nier serait aussi une idiotie.

c'est sûr, à 100 000 USD la licence, c'est pas très coûteux pour un usage local...

[Samoreen]

...
Alors, bien sûr, tout le monde n'a pas le débit qu'il faut...

D'accord globalement avec ce que tu expliques mais pour les tâches que tu cites, un débit en upload conséquent est indispensable. Pour que le système éloigné puisse faire le boulot, il faut bien qu'il ait accès aux données. Ce n'est pas du tout la même chose qu'avec Lightroom Mobile où les quantités de données sont relativement limitées. Et même dans ce cas, on voit bien, si on monitore l'activité réseau du processus Lightroom, que la synchronisation du PC vers le serveur n'est pas du tout instantanée. L'agent de synchro est sollicité en permanence. Ce n'est pas très grave vu que l'on utilise rarement LR sur son PC et Lightroom Mobile en même temps.

Par contre, pour un traitement éloigné, le contexte est différent. On demande l'exécution d'une fonction sur son poste de travail et il faut que ça réponde rapidement. Et comme tu le dis, plus rapidement que si on demandait le même traitement en local, sinon ça ne sert à rien (en tous cas pour l'utilisateur - voir plus bas). Et là, même pour les professionnels suréquipés, les infrastructures ne sont pas là (même si en France nous sommes bien plus gâtés qu'aux US). Si l'application est bien faite, on peut envisager un traitement asynchrone (on peut faire autre chose pendant que la tâche se termine) mais les utilisateurs travaillent le plus souvent en séquence.

Ce qui n'empêche pas bien sûr de commencer à travailler sur le sujet.

Ajoutons à cela un élément non technique : vu les mœurs qui se développent sur Internet, les utilisateurs n'ont pas forcément envie de balancer toutes leurs images vers des serveurs qu'ils ne maîtrisent pas. On a bien compris que les affirmations rassurantes des uns et des autres ne sont pas toujours sincères (euphémisme). Les états se dirigent vers un contrôle généralisé de ce qui transite sur le web. Quand on voit ce qui se passe simplement au niveau de l'utilisation de ces données au niveau marketing, on imagine les possibilités si les institutions s'en mêlent.

En aparté, je note que l'actualité nous montre qu'aujourd'hui les marketeurs sont plus efficaces que les états sur l'utilisation du big data. Les services de renseignements devraient prendre des cours auprès de Google et consorts. Quand ça sera fait, j'aurais encore moins envie de confier mes traitements à des services que je ne contrôle pas.

[nicolas-p]

c'est faire peu de cas de la technologie des aperçus dynamiques :-)

oui c'est vrai... je les avais oubliés ceux-la.

[THG]

D'accord globalement avec ce que tu expliques mais pour les tâches que tu cites, un débit en upload conséquent est indispensable. Pour que le système éloigné puisse faire le boulot, il faut bien qu'il ait accès aux données. Ce n'est pas du tout la même chose qu'avec Lightroom Mobile où les quantités de données sont relativement limitées. Et même dans ce cas, on voit bien, si on monitore l'activité réseau du processus Lightroom, que la synchronisation du PC vers le serveur n'est pas du tout instantanée. L'agent de synchro est sollicité en permanence. Ce n'est pas très grave vu que l'on utilise rarement LR sur son PC et Lightroom Mobile en même temps.

Par contre, pour un traitement éloigné, le contexte est différent. On demande l'exécution d'une fonction sur son poste de travail et il faut que ça réponde rapidement. Et comme tu le dis, plus rapidement que si on demandait le même traitement en local, sinon ça ne sert à rien (en tous cas pour l'utilisateur - voir plus bas). Et là, même pour les professionnels suréquipés, les infrastructures ne sont pas là (même si en France nous sommes bien plus gâtés qu'aux US). Si l'application est bien faite, on peut envisager un traitement asynchrone (on peut faire autre chose pendant que la tâche se termine) mais les utilisateurs travaillent le plus souvent en séquence.

Ce qui n'empêche pas bien sûr de commencer à travailler sur le sujet.

Ajoutons à cela un élément non technique : vu les mœurs qui se développent sur Internet, les utilisateurs n'ont pas forcément envie de balancer toutes leurs images vers des serveurs qu'ils ne maîtrisent pas. On a bien compris que les affirmations rassurantes des uns et des autres ne sont pas toujours sincères (euphémisme). Les états se dirigent vers un contrôle généralisé de ce qui transite sur le web. Quand on voit ce qui se passe simplement au niveau de l'utilisation de ces données au niveau marketing, on imagine les possibilités si les institutions s'en mêlent.

En aparté, je note que l'actualité nous montre qu'aujourd'hui les marketeurs sont plus efficaces que les états sur l'utilisation du big data. Les services de renseignements devraient prendre des cours auprès de Google et consorts. Quand ça sera fait, j'aurais encore moins envie de confier mes traitements à des services que je ne contrôle pas.

On est globalement d'accord, même si ma perception des choses est plutôt côté "utilisateur", alors que ton point de vue s'enrichit aussi de ton expérience technique dans le domaine.

Quant aux services de renseignement, sans vouloir donner dans la théorie de la conspiration, j'ai quand même du mal à croire que ça ne discute pas à haut niveau avec les leaders industriels, et qu'il n'existe pas de "black programs", à l'instar des programmes d'avions espions et furtifs des années 60 - 70 - 80, dont même le financement n'apparaissait pas dans les documents officiels.

[THG]

oui c'est vrai... je les avais oubliés ceux-la.

et c'est là-dessus que repose le système d'indexation de contenu de l'image de Lr Web.

[nicolas-p]

Ajoutons à cela un élément non technique : vu les mœurs qui se développent sur Internet, les utilisateurs n'ont pas forcément envie de balancer toutes leurs images vers des serveurs qu'ils ne maîtrisent pas. On a bien compris que les affirmations rassurantes des uns et des autres ne sont pas toujours sincères (euphémisme). Les états se dirigent vers un contrôle généralisé de ce qui transite sur le web. Quand on voit ce qui se passe simplement au niveau de l'utilisation de ces données au niveau marketing, on imagine les possibilités si les institutions s'en mêlent.

En aparté, je note que l'actualité nous montre qu'aujourd'hui les marketeurs sont plus efficaces que les états sur l'utilisation du big data. Les services de renseignements devraient prendre des cours auprès de Google et consorts. Quand ça sera fait, j'aurais encore moins envie de confier mes traitements à des services que je ne contrôle pas.

oui. les photos par exemple de mon entourage (pourtant pas classés secret-défense ) je n'ai aucune envie qu'elles puissent circuler sur le web.

[baséli]

c'est sûr, à 100 000 USD la licence, c'est pas très coûteux pour un usage local...

Meuh non, coûteux au sens large, en ressources au sens large, (€, mémoire, CPU, temps de calcul, énergie, etc) comme le disent les techniciens.

Quand au prix d'un logiciel , c'est purement conventionnel. Il suffit d'en vendre en nombre au grand public pour faire baisser le prix unitaire. Rien d'impossible.

[baséli]

c'est sûr, à 100 000 USD la licence, c'est pas très coûteux pour un usage local...

Et pis y'a un type qui a écrit dans un autre fil "à n'en douter, cette technologie arrivera un jour dans Lr desktop ;-)"

Alors tu vois, tu as tort. 

[sebs]

Bon bin merci les gars: vous avez développé les points que j'avais évoqué au début:

- problème du transit des données: la technologie suivrait-elle un jour? Moi j'ai un adsl assez "basique": ça me prendrai combien de jour rien que pour uploader ma collection de photos? Et l'équivalent de l'importation dans LR quand j'ai fait 10Go de photos? Déjà quand je met dans google drive ou dropbox environ 100Mo, faut pas être pressé...
De plus, à l'heure d'aujourd'hui, au niveau du coût pour l'utilisateur, l'achat d'un ordi "local" est rentabilisé par rapport à un abonnement en fibre à vitesse maxi (en tout cas en Suisse, je ne connais pas les prix des FAI en France...).
- problème de la confidentialité.

- d'autre part, je trouverai ça pas écolo, car pour que tout cela tourne il faudrait des quantités astronomiques de fibre et autres routeurs pour booster la puissante d'internet, +des quantités décuplées de stockage sur les serveurs: ça coûte en matériaux de fabrication, et en électricité pour alimenter tout ça 24h/24h. C'est un peu comme si on faisait nos courses "normalement", et ensuite on envoye par coursier tout ça chez le traiteur, qui lui prépare notre repas, qui ensuite nous est relivré par coursier...

- enfin, il y a aussi le problème de fiabilité/pérénisation: moi je ne prends pas le risque de confier des données + payer un abonnement pour une appli, sachant qu'une entreprise peut couler, être rachetée, être attaquée (cyber-attaque), et que je perde quelque chose que je préfère alors avoir en local pour avoir la main dessus.
Il y a un fil sur le problème des virus qui cryptent les données et demandent ensuite de payer pour les récupérer. Si un tel virus contamine un fournisseur d'apps, cette boite devrait payer combien de millions, au cas où ils n'aient pas de solution pour tout remettre en ordre et déveroller?
Moi je préfère avoir mes backups à moi  et pouvoir revenir en arrière comme je veux.

[Ilium]

Je pense qu'il n'y aura plus de développement, en tout cas dans sa forme actuelle.

Faut pas rêver : on est à une période charnière et, à terme, toutes les apps vont monter dans le Web, ce qui a un avantage certain : la possibilité de mettre en œuvre des algos impossibles à implanter sur une station de travail locale, en raison du coût et de la puissance exigée.

Ayez confiance brave gens, on veille sur vous...

Qui est en faveur du cloud  Certaines sociétés passent au full cloud. Ca permet de limiter fortement les infrastructures et coûts associés dans les sites.

Et ça nécessite d'avoir confiance dans son opérateur et des quantités de données raisonnables faute de quoi on dépensera en bande passante ce qu'on aura économisé en stockage. 2 détails.
Et sans parler du coup des logiciels dont le modèle pourra gaiement passer à l'abonnement avec tout ce que ça implique en terme de coûts.

THG ne parlait pas que de stockage, mais de puissance de calcul, à terme, on ne pourrait avoir dans les mains qu'une machine assez limité et les calculs lourds seraient fait dans le cloud.
Rare sont les personnes à avoir besoin d'une grosse puissance de calcul H24, mais on attend toujours trop longtemps le résultat...

Sachant que nos ordis passent plus 80% de leur temps CPU à roupiller, pas sûr que ce modèle soit indispensable.

[MBe]

En tout cas pour Nik Collection. C'est gratuit maintenant

https://plus.google.com/+NikCollection/posts

Et ca marche avec LR et PS

Question de débutant : cette collection effectue le traitement sur le raw ou plutôt sur un tiff?

[Samoreen]

Question de débutant : cette collection effectue le traitement sur le raw ou plutôt sur un tiff?

TIFF ou JPEG. Ces modules ne sont pas des dématriceurs.