A propos des projets

[mam]

Bj,
j'ai créé pléthore de listes de projets.
Or, j'ai changé récemment de disque dur et j'ai déplacé toutes mes photos sur ce disque.
J'ai gardé l'arborescence. Seule la lettre du nouveau disque a changé.


Et voila que DXO ne trouve plus mes photos patiemment regroupées dans les listes. Il a donc perdu tous les liens...
- Que faire ?
- Avez-vous un moyen que dxo retrouve ses petits ? ( ex: petite applis qui mouline et remet tout en ordre...)
Je ne me revois pas, passer toutes mes photos en revue et recréer mes listes manuellement,

DXO me propose de recréer a la main tous les liens rompus... solution bete et méchante !

Avez-vous deja eu besoin de traiter ce problème, et si oui, comment l'avez-vous résolu ?

Help !
Merci de vos réponses
Cdlt

[rsp]

C'était le truc à ne pas faire, comme changer le nom d'un répertoire de photos depuis l'explorateur... toutes choses que j'ai moi aussi faites, dans l'ignorance des débuts. Il faut les déplacer depuis l'explorateur de PL.
Est-il envisageable de remettre la lettre originelle de l'ancien DD au nouveau DD ?
Si ce n'est pas le cas, ceux qui connaissent les bases de données SQL (celle de PL est de ce type) pourraient t'aider : Pat91 par exemple s'il passe par là. Moi je suis nul en cette science.

[Arlecchino]

Est-il envisageable de remettre la lettre originelle de l'ancien DD au nouveau DD ?

Windows ou mac ?

Sur Windows c'est : fenêtre recherche, puis taper "gestion des disques" dans la fenêtre sélectionner le disque avec la lettre à changer, clic droit "modifier la lettre du lecteur" petite fenêtre qui s'ouvre, cliquer sur modifier, rentrer la lettre voulu et c'est bon.

https://blog.alphorm.com/modifier-lettre-disque-windows-11#:~:text=Comment%20choisir%20une%20nouvelle%20lettre,puis%20cliquez%20sur%20%27Modifier%27.

[mam]

Bj, merci pour ta réponse.

- Rien ne dit dans les doc DXO du danger de se genre de changement. IL serait souhaitable que DXO communique sur le sujet.
- Oui, je peux remettre la lettre. (Je n'ai pas touché a l'arborescence d'origine).

Cette procédure pourrait-elle fonctionner ?
- je sauvegarde ma Bd
- je quitte DXO8
- je change la lettre de mon Disque Dur pour la mettre en conformité avec la base de donnée sauvegardée. (Windows va modifier la Bd)
- j'ouvre DX8
- je restore la Bd (que Windows n'a pas pu modifier)

J'ai peur de faire une Con***rie.


Merci de votre aide

[Arlecchino]

Je connais pas DXO, donc je ne peux pas te répondre, des connaisseurs de ce logiciel seront plus apte à te répondre, je sais que ça avait marché avec mon logiciel de catalogage de vidéos, mais bon rien à voir...

[Samoreen]

...Pat91 par exemple s'il passe par là. Moi je suis nul en cette science.

Ici, je suis Samoreen. J'ai déjà répondu à mam via un intermédiaire qui a un compte Facebbok. Même question, même réponse. Les projets sont structurés dans la BD autour des identifiants des images qui changent à chaque fois que le dossier est réindexé. Il n'y a aucune utilisation du chemin d'accès ou de la lettre disque. Donc, à moins de développer du code SQL pour rapprocher une sauvegarde de la BD et la nouvelle (et je ne connais personne qui ait envie de faire ça), il n'y a aucun moyen de récupérer les projets perdus.

Je donnerai pour info un peu plus de détails plus tard dans la soirée.

[Samoreen]

Pour info, donc, la réponse qui avait été envoyée à Mam (avec quelques fautes de frappe corrigées).

Concernant ce problème de projets Photolab, j'ai déjà eu l'occasion de m'y confronter ayant été obligé de reconstruire complètement la base de données. J'ai perdu tous mes projets dans la foulée et je n'ai pu les reconstruire que parce qu'ils étaient tous basés sur des collections Lightroom. Dans ce cas il y a un moyen de les construire dans Photolab. Sinon, autant le dire tout de suite, il n'y a pas d'autre solution que de reconstruire à la main. J'explique pourquoi...

Dans la BD, les projets sont définis dans 2 tables : Projects et ProjectsItems.

La table Projects contient essentiellement, pour chaque projet, identifiant du projet, dates de création et de dernière modification, nom du projet et identifiant du projet parent s'il s'agit d'un sous-projet.

La table ProjectsItems contient en tout et pour tout 3 colonnes :

ItemID : C'est la liste en vrac de toutes les images de la BD qui sont incluses dans un projet quelconque. Elles sont listées par identifiant et il n'y a aucune notion de chemins d'accès là-dedans. Le chemin d'accès est lié à l'identifiant dans une autre table de la BD. Si une image appartient à plusieurs projets, elle apparaît autant de fois dans la liste qu'il y a de projets concernés, avec un ProjectID différent. Pas très optimisé comme schéma.

ProjectID : Pour chaque image, le projet dans lequel elle est incluse.

InsertionOrder : ordre de classement.

On comprend donc rapidement que tout tient non pas grâce à des chemins d'accès (dont on n'a aucune trace) mais grâce aux identifiants numériques des images. De plus ces identifiants ne sont pas de type UUID (c'est-à-dire des valeurs uniques qui ne pourront pas être attribuées à nouveau) mais des entiers ordinaires. Rien que ça, c'est une erreur de conception majeure. Ça veut dire que l'identifiant d'une image peut être réattribué à une autre image dans certaines circonstances : reconstruction de la base de données, ré-indexation d'un ou de la totalité des dossiers.

À partir du moment où les photos ont été déplacées lors du changement de disque, leurs identifiants ont été changés (les dossiers ont été réindexés) et les 2 tables citées ci-dessus ne contiennent plus aucune donnée valide. Le fait d'avoir adapté la lettre du disque et d'avoir conservé l'arborescence initiale n'aura servi à rien puisque, comme indiqué ci-dessus, c'est la table Items qui fait l'association entre ItemId et chemin d'accès et qu'elle a été complètement reconstruite lors de la première ouverture des dossiers après le déplacement des images (ce qui a provoqué une réindexation).

Conclusion : c'est fichu.

La structure de la BD de Photolab est extrêmement rustique (pour être sympa) surtout comparée à celle de Lightroom. Si c'était un devoir d'élève d'école informatique, je l'aurais assez sévèrement noté. Surtout qu'aucun mécanisme de sauvegarde des projets n'est proposé. Sauvegarder la BD ne sert à rien dans ce cas, on l'a vu. Ils auraient pu au moins mettre en place une sauvegarde permettant d'enregistrer la structure des projets et le chemin d'accès aux images associées afin de permettre une restauration dans le cas où la lettre du disque et l'arborescence auraient été conservés par l'utilisateur. Ce n'était pas compliqué à faire mais... même pas.

On pourrait éventuellement écrire du code SQL qui irait faire des comparaisons entre une sauvegarde de la BD avant la migration et la BD actuelle afin de retrouver les bons ItemIDs mais ce seraient des heures de développement pour du code qui ne servira pas souvent. Et ce serait plus long que de refaire les projets à la main.

[rsp]

Merci d'avoir remis la réponse ici, ça pourra servir à d'autres aussi...
Parmi les trucs qui me semblent débiles, il y a l'absence de l'appartenance à un projet dans les DOP ou les XMP. Cela permettrait au moins de les reconstruire lors d'une réindexation.
Ce qui est étrange c'est que le mode projet était (quasiment) le seul utilisable au début pour traiter des images dans DOP (sauf erreur de ma part). Qu'il soit aussi merdique est encore plus surprenant.

[Samoreen]

Parmi les trucs qui me semblent débiles, il y a l'absence de l'appartenance à un projet dans les DOP ou les XMP.

D'un côté la définition d'un projet doit être enregistrée dans un support indépendant des images. La BD, donc. Mais rien n'empêchait effectivement d'"accrocher" une image donnée à un identifiant de projet. Ça permettrait de reconstituer l'ensemble par un simple scan de la totalité des XMP/DOP. C'est d'ailleurs par là que j'avais commencé à chercher quand j'ai perdu mes propres projets.

J'ajouterai à ma synthèse ci-dessus que la possibilité de récupérer ou pas dépend également de la séquence de "remise en route" après le remplacement du disque. Si PL a été ouvert au moins une fois avant le changement de lettre du disque, il n'y a vraiment rien à faire, je pense. Si le changement de lettre a été fait avant la première relance, c'est plus aléatoire. Ça va dépendre de l'ordre d'ouverture des dossiers et/ou de l'ordre dans lequel la réindexation a été demandée par clic-droit sur le dossier. On peut tout réindexer en une passe depuis le dossier racine (si on a une arborescence unique) ou dossier par dossier au fur et à mesure des besoins. Selon cet ordre, les IDs affectés seront différents. Idéalement (mais c'est impossible), il faudrait réouvrir les dossiers dans l'ordre où ils ont été ouverts avant le changement de disque depuis la dernière reconstruction de la BD. Entre ces 2 possibilités extrêmes, c'est fondamentalement une question de chance.

La seule bonne solution (mais visiblement ce point a été oublié), c'est la possibilité de sauvegarder les projets en enregistrant non pas les identifiants des images mais leur chemin d'accès. Et de préférence en mode texte, de telle manière que si la lettre du disque n'est pas conservée, une simple édition du fichier de sauvegarde permettent de recréer des infos valides.

[Samoreen]

De plus ces identifiants ne sont pas de type UUID (c'est-à-dire des valeurs uniques qui ne pourront pas être attribuées à nouveau) mais des entiers ordinaires.

Une petite précision, pour lever toute ambiguïté. Dans la table Items, il y a bien un UUID attribué à chaque image. Mais il n'est pas utilisé dans la gestion des projets.

[mam]

Bonsoir,

Bon, c'est donc râpé pour récupérer les billes.

DXO doit savoir les 'déficiences' de leur BD.
- Mais envisagent-ils de la corriger ?

Les utilisateurs doivent savoir aussi...

Question : quelle est la procédure pour ne pas tout perdre lors d'un changement de PC ?

Merci encore pour vos avis éclairés.

Cdlt

[ccaphotographies]

Je n'ai jamais compris l'utilité des projets. Je gère les photos et leurs répertoires via l'explorateur de l'OS, et PL n'est là que pour le traitement. C'est bien plus simple et sécurisé.

[rsp]

Je n'ai jamais compris l'utilité des projets. Je gère les photos et leurs répertoires via l'explorateur de l'OS, et PL n'est là que pour le traitement. C'est bien plus simple et sécurisé.

Je ne m'en sers plus que momentanément pour la création d'un livre photo. Là, je trouve ça utile. Du coup ils peuvent être supprimés une fois le livre imprimé.

[rsp]

Bonsoir,

Bon, c'est donc râpé pour récupérer les billes.

DXO doit savoir les 'déficiences' de leur BD.
- Mais envisagent-ils de la corriger ?

Les utilisateurs doivent savoir aussi...

Question : quelle est la procédure pour ne pas tout perdre lors d'un changement de PC ?

Merci encore pour vos avis éclairés.

Cdlt

J'ai mis mes photos sur un NAS. J'ai pu passer d'un Mac à un PC puis un autre PC sans rien perdre. Mais ça ne résout pas le problème pour les projets si tu passes de Mac à PC car les BDD sont différentes. Si tu ne changes pas d'OS, une sauvegarde sur l'ancien puis restauration de BDD sur le nouveau permet de changer de machine si t'es photos sont sur un disque séparé.

[Samoreen]

Question : quelle est la procédure pour ne pas tout perdre lors d'un changement de PC ?

J'ai bien peur que la réponse à cette question soit également décevante en ce qui concerne les projets. Il y a encore 2 ou 3 petites choses à apprendre à ce sujet. J'explique d'abord comment je coordonne mes données entre mon PC et mon PC portable...

Quand je veux partir avec mon PC portable en utilisant les mêmes données que sur mon PC, je déclenche une synchronisation entre mon PC et un disque externe (photos, base de données, catalogue LR, etc.). Je branche ce disque sur le portable et tout est réglé de telle manière que les chemins d'accès soient strictement identiques sur les 2 systèmes. Et effectivement quand je lance LR ou DPL, tout se passe comme si j'étais sur le PC, à l'exception des projets qui s'affichent avec un point d'interrogation sur chaque image. Pourquoi ?

Quand on change de disque ou de machine, DPL ne se soucie pas vraiment de la lettre du disque mais de son UUID (chaque disque possède par fabrication un identifiant unique). Ce qui signifie en fait qu'un disque externe ou un nouveau disque ou le disque d'un nouveau PC ou MAC, sont considérés comme contenant des répertoires nouveaux, encore inconnus de DPL, même s'ils contiennent les mêmes fichiers organisés de la même manière. Pour les photos, on arrive à s'en sortir et la manip que j'ai décrite ci-dessus arrive à fonctionner après quelques ajustements. Pour les projets, ça ne fonctionne pas, pour les raisons que j'ai expliquées plus haut. Ça induit d'ailleurs d'autres inconvénients que j'ai exposés dans un fil sur le forum DxO (en anglais, désolé) : https://forum.dxo.com/t/photolab-database-corrupting-itself/41337/1.

De plus, et là je manque de détails, les UUIDs affectés aux images et aux dossiers dans la BD sont probablement générés via l'interface de programmation du framework Microsoft .Net sur lequel est bâti Photolab. Je n'ai pas d'infos précises sur le fait que ces UUIDs soient générés en tenant compte de divers identifiants hardware (dont ceux des disques). Je ne pense pas que cette info ait été publiée par Microsoft mais je dirais que la probabilité est élevée. Ce qui complique encore les affaires et peut expliquer le problème que j'ai exposé dans le fil sus-nommé du forum DxO.

Pour moi, la gestion des projets a été ajoutée sans réelle étude approfondie, suite à quelques demandes insistantes. Probablement un travail de stagiaire.

Je peux me tromper mais je ne vois donc aucune manip simple permettant de conserver l'ensemble des projets dans les circonstances que nous avons décrites : changement de disque, changement de PC, etc. Ce qui confirme la nécessité d'un processus de sauvegarde/restauration des projets qui soit indépendant du hardware. Probablement pas une priorité pour DxO.

Bon courage pour la reconstruction manuelle des projets.

[Frank29]

Les projets ne sont sauvegardés que dans la bdd, ce qui implique la perte de ceux-ci en cas de changement de PC où même de problème sur la bdd.
Depuis très longtemps, des demandes sont faites pour que cette info soit aussi sauvegarder dans les *.dop mais aucun retour de DxO pour cela, cela ne devrait pas être compliqué à intégrer au *.dop.
Pour contourner ce problème je me sers de mots clés en tant que projets.

[Samoreen]

Et effectivement quand je lance LR ou DPL, tout se passe comme si j'étais sur le PC, à l'exception des projets qui s'affichent avec un point d'interrogation sur chaque image. Pourquoi ?

Dans cette situation, il est intéressant de noter que bien qu'un point d'interrogation m'indique pour chaque image que le fichier est introuvable, la fenêtre affichant les propriétés de l'image qui s'ouvre quand je survole le point d'interrogation indique bien le bon chemin d'accès (le fichier existe bien à l'endroit indiqué). Et, cerise sur le gâteau, si je clique sur le point d'interrogation, la photo s'affiche quand même mais le point d'interrogation reste dans le strip et un message indique toujours que le traitement n'est pas possible parce que le fichier n'existe pas. Il faut donc à chaque fois, pour chaque image, corriger l'emplacement et comble de perversité, le chemin d'accès qui est sélectionné quand la boîte de dialogue de sélection s'ouvre... c'est le chemin d'accès correct (il n'y en a pas d'autre).

Je ne conseille cependant pas de faire cette manip dans le cas où l'on fait une synchronisation inverse (PC Portable vers PC). Dans ce cas, le problème se posera quand on voudra ouvrir les projets sur le PC.

Avec Lightroom, pas de problème puisque la synchro est basée sur la date de dernière modification enregistrée dans le XMP et la date enregistrée dans le catalogue.

À mon très humble avis, cette anomalie est la démonstration qu'un des principes de base dans la conception des bases de données n'est pas respecté : jamais 2 sources différentes pour la même information (je ne parle pas de sauvegarde).

OK. J'arrête là pour la technique. La partie DAM de Photolab a toujours été problématique et le problème évoqué ici n'en est qu'une des manifestations. Je reste donc partisan d'une utilisation de Photolab uniquement depuis un DAM externe (Lightroom, Bridge, digiKam, iMatch, Photo Supreme, MyLio...).

[ccaphotographies]

Je ne m'en sers plus que momentanément pour la création d'un livre photo. Là, je trouve ça utile. Du coup ils peuvent être supprimés une fois le livre imprimé.

Exact... Mais personnellement comme j'exporte tout en jpg dans apple photo, et c'est via apple photo que je gère mes "projets" d'impression, de mise en page ou de constitution des galeries web.

[rsp]

Exact... Mais personnellement comme j'exporte tout en jpg dans apple photo, et c'est via apple photo que je gère mes "projets" d'impression, de mise en page ou de constitution des galeries web.

J'ai un PC, je vais voir ce que je peux faire avec Photos hop Éléments. Mais je trouve pratique de pouvoir, pour certaines images, créer une CV et faire quelques ajustements supplémentaires avant impression.

[restoc]

Petite question de retardataire :

DPL8 ( je n'a pas vérifié pour les autres) propose une sauvegarde de la BD et a priori sur un autre support. Si on s'y prend "avant" n'est il pas envisageable que les projets et tout ce qui est liè le soient correctement sur le nouveau support ?
A priori une sauvegarde doit identifier le UUID du disque destinataire et passeulement  sa lettre du disque qui peut être changée selon les utilisations.

Peut être je rêve que ce n'est pas aussi pire ...

[Pieloe]

Petite question de retardataire :

DPL8 ( je n'a pas vérifié pour les autres) propose une sauvegarde de la BD et a priori sur un autre support. Si on s'y prend "avant" n'est il pas envisageable que les projets et tout ce qui est liè le soient correctement sur le nouveau support ?

Je prendrais le pari
Sinon, pourquoi sauvegarder ?

[Samoreen]

Si on s'y prend "avant" n'est il pas envisageable que les projets et tout ce qui est liè le soient correctement sur le nouveau support ?

A priori, non. Je réexplique... La BD courante conserve les infos d'identification des disques actuellement installés. Si on installe cette sauvegarde sur une autre machine ou si on ajoute un nouveau disque, quand on chargera DPL, il considérera ce nouveau disque comme un nouvel espace à explorer et réindexera tout. Je détaille l'exemple pris plus haut :

1. Je copie la BD actuelle de mon PC (qui contient la définition de mes projets) sur un disque externe ainsi que les dossiers contenant les images.

2. Je connecte ce disque sur mon portable. Tout est réglé pour que la lettre du disque soit la même, pour que la BD soit stockée au même endroit et pour que l'arborescence des photos soit la même que sur le PC.

3. Je lance DPL sur le portable. Je vois bien l'arborescence de mes photos, tout à l'air de se passer normalement mais si j'ouvre un projet, il me dit que les fichiers sont introuvables, parce que l'identifiant de chaque élément du projet se réfère à un identifiant de disque qui n'est pas le disque externe que je viens de connecter mais celui de mon PC que le portable ne connaît pas. Lettre et arborescence peuvent être les mêmes, ça ne sert à rien. Il considère que c'est un autre support. Donc il me dit qu'il ne trouve pas les fichiers, bien que les chemins d'accès n'aient pas changé, tout simplement parce qu'il considère qu'il ne trouve pas le disque lui-même.

4. Pour revalider le projet, voir mon message précédent. Il faut relocaliser manuellement chaque photo.

5. Passons maintenant au pire. Si l'idée me vient de lancer une réindexation complète de mes photos (sur le disque externe connecté sur mon portable), DPL va considérer qu'il s'agit d'une nouveau dossier et, au lieu de remplacer les identifiants des images par les nouveaux, il va ajouter, pour chaque photo, une nouvelle ligne dans la table des images (qui va donc doubler de volume). On aura donc, pour chaque image, 2 lignes au lieu d'une, ayant au départ les mêmes infos mais ayant des identifiants d'image différents bien que pointant toutes les deux vers le même fichier (même chemin d'accès). Pour faire court, une ligne A pour les infos concernant la photo vue de mon PC et une ligne B pour la même photo vue de mon portable. On dit dans le jargon informatique, que DPL ne fait pas le "garbage collect" (le ramassage de poubelles).

6. Passons ensuite au pire du pire. Si je modifie une photo sur mon portable, ces modifications vont être enregistrées dans la ligne de la BD qui correspond à l'identifiant créé pour le nouveau disque (ligne B). Donc à partir de ce moment, je me retrouve dans la BD avec 2 lignes concernant la même image mais contenant des informations de correction différentes. Comme s'il y avait 2 dossiers différents contenant les mêmes images.

7. Si, au retour de ma session sur le portable, il me prend la très mauvaise idée de recopier la nouvelle version de la BD sur mon PC, je ne verrais bien sûr aucune des modifications réalisées sur le portable puisque la référence redeviendra la ligne utilisant l'identifiant du disque du PC. Je ne verrai ces modifs qu'une fois le XMP/DOP correspondant resynchronisé avec la nouvelle copie de la BD dans le sens XMP/DOP => BD.

Conclusion : l'utilisation d'un même fichier de BD sur 2 machines différentes ou le transfert des photos de disque à disque sur la même machine, même en conservant la même lettre, génère de manière automatique des incohérences irrécupérables. C'est à proscrire. Ce problème ne se pose pas si on partage un même fichier de BD entre 2 machines sur le réseau (mais ça peut en créer un autre car je pense qu'avec DPL, les accès concurrentiels ne sont pas gérés). Si on recopie ce fichier de BD partagé sur une des 2 machines, le même problème se posera.

Donc, oubliez l'idée. La BD et les projets doivent être reconstruits sur chaque machine et à chaque fois que vous changez le disque qui contient vos photos, même si vous lui donnez la même lettre. Ce qui induit une autre règle : si vous planifiez de travailler sur des machines multiples, activez toujours la génération de fichiers sidecars, prenez-en soin et synchronisez-les entre machines. Les projets eux ne sont pas synchronisables jusqu'à ce que DxO décide de mettre en place un système de sauvegarde des projets dans un fichiers éditable et adaptable,  basé sur les chemins d'accès et non pas sur les identifiants.

[Samoreen]

NB : Ce qui précède n'est pas une élucubration théorique. C'est du vécu. J'ai mis le nez dans la BD quand je me suis aperçu sur mon portable que toutes les entrées de la table Items de la BD étaient dupliquées et que, selon l'endroit d'où je "regardais" une image (PC ou portable), je ne voyais pas les mêmes corrections.

[rsp]

Sans avoir fait ce genre de manips, j'ai des photos qui sont en double, la seule différence est leur date "d'importation". J'ai soumis le pb au support.

[restoc]

Conclusion : l'utilisation d'un même fichier de BD sur 2 machines différentes ou le transfert des photos de disque à disque sur la même machine, même en conservant la même lettre, génère de manière automatique des incohérences irrécupérables. C'est à proscrire. Ce problème ne se pose pas si on partage un même fichier de BD entre 2 machines sur le réseau (mais ça peut en créer un autre car je pense qu'avec DPL, les accès concurrentiels ne sont pas gérés). Si on recopie ce fichier de BD partagé sur une des 2 machines, le même problème se posera.

Donc, oubliez l'idée. La BD et les projets doivent être reconstruits sur chaque machine et à chaque fois que vous changez le disque qui contient vos photos, même si vous lui donnez la même lettre. Ce qui induit une autre règle : si vous planifiez de travailler sur des machines multiples, activez toujours la génération de fichiers sidecars, prenez-en soin et synchronisez-les entre machines. Les projets eux ne sont pas synchronisables jusqu'à ce que DxO décide de mettre en place un système de sauvegarde des projets dans un fichiers éditable et adaptable,  basé sur les chemins d'accès et non pas sur les identifiants.

Merci de ces tests et explications fournies.

Donc on peut dire : si vous achetez DXO sachez que vous ne pourrez pas faire suivre tout votre travail sur un autre matériel si un jour vous devez changer de machine ou m^me simplement de disque dur.
Si c'est la cas c'est une tare invraisemblable à notre époque et çà pose le pb d'envisager de conserver DXO sur le moyen terme et d'en faire un coeur de système en tous les cas.

De plus en plus l'intérêt de DXO semble se réduire au dérawtiseur donc.

[rsp]

Merci de ces tests et explications fournies.
Donc on peut dire : si vous achetez DXO sachez que vous ne pourrez pas faire suivre tout votre travail sur un autre matériel si un jour vous devez changer de machine ou m^me simplement de disque dur.
Si c'est la cas c'est une tare invraisemblable à notre époque et çà pose le pb d'envisager de conserver DXO sur le moyen terme et d'en faire un coeur de système en tous les cas.
De plus en plus l'intérêt de DXO semble se réduire au dérawtiseur donc.

Restons objectifs : si on utilise beaucoup les projets, c'est un gros problème. Si on les utilise momentanément et rarement, c'est juste ennuyeux le jour où on change de machine, ou bien quand la BD doit être détruite (ça arrive parfois que la seule solution à un problème soit de détruire la BD).

[ccaphotographies]

C'est le cas sur tous les logiciels... le nombre de fois où ma BD lightroom a planté et s'est avérée irrécupérable....

[Samoreen]

Donc on peut dire : si vous achetez DXO sachez que vous ne pourrez pas faire suivre tout votre travail sur un autre matériel si un jour vous devez changer de machine ou m^me simplement de disque dur.

Il ne s'agit que des projets. Le reste suivra toujours si on migre également les XMP/DOP. Bien sûr, il y a ce problème de duplications des entrées qui fait croître inutilement la taille de la BD. D'ailleurs, ça peut tripler ou quadrupler au fur et à mesure des changements de machine ou de disque... jusqu'à ce que l'on reconstruise complètement la BD. En fait, je crois qu'il faut la considérer comme quelque chose d'éphémère par nature, vu son design. Seuls les fichiers sidecar sont vitaux.

Pendant que j'y suis, certains ce sont peut-être posé la question à 1000 € : pourquoi a-t-on ce problème sur les projets et pas sur les photos quand on ouvre leur dossier ? Quand on ouvre un dossier (sur la nouvelle machine ou le nouveau disque), DPL va automatiquement déclencher son exploration. Si c'est déjà fait, il va directement lire la fameuse ligne B dont j'ai parlé plus haut. Et là, pas d'erreur puisque l'identifiant du disque est reconnu. Pour les projets, ça ne marche pas car les images constitutives du projet ne sont référencées que par l'identifiant qu'elles avaient dans la situation précédente. Ces références devraient normalement être mises à jour au moment où DPL recalcule les nouveaux identifiants. C'est un oubli qui est extrêmement simple à corriger mais il semble que le stagiaire qui a développé la fonctionnalité "projets" ne fasse plus partie du personnel et que personne d'autre n'ait envie de mettre le nez dans ce bazar .

[restoc]

Restons objectifs : si on utilise beaucoup les projets, c'est un gros problème. Si on les utilise momentanément et rarement, c'est juste ennuyeux le jour où on change de machine, ou bien quand la BD doit être détruite (ça arrive parfois que la seule solution à un problème soit de détruire la BD).

Est on certains  qu'un changement de disque ou de carte mére ou de Cpu n'affecte que le portage/sauvedarde/conservation des assets de PT des seuls  "projets" ?

 Si tout ou partie partie des assets en plus des images (mots clés, Réglages de PT, Nik Sw, etc. est attaché au Hw sans possibilité de portage en bloc avec conservation de structure et de liens internes, (sur un autre hw imposé dorénavant tous les 12,24 ou36 mois) DXOPL ne peut alors  plus être une solution centrale mais juste un derawtiseur utilisé au coup par coup.  Ca change pas mal de choses.

Quid pour eux qui auraient en plus des projets incluant Niksw, Viewpoint ?

[Samoreen]

C'est quoi PT ? Je loupe une évidence ?

Je répondrai synthétiquement à tes questions dans la matinée.

[rsp]

Probablement post traitements.
C'est dans le .DOP et le .XMPpour ce qui concerne PL VP FP.

[Samoreen]

Est on certains  qu'un changement de disque ou de carte mére ou de Cpu n'affecte que le portage/sauvedarde/conservation des assets de PT des seuls  "projets" ?

Oui et non. Essayons de mettre en lumière les points importants...

1. La régénération de la BD provoque la perte des projets (et des recherches externes). L'absence d'informations sur les projets dans les XMP/DOP et l'absence d'un mécanisme de sauvegarde indépendant du hardware rend toute restauration impossible.

2. La réutilisation d'un fichier de BD existant (photolab.db) alors que les photos ont été transférées sur un nouveau hardware a 2 conséquences :

a. La perte de validité de la table ProjectsItems qui se réfère maintenant à un hardware qui n'est plus détectable par PL. La définition du projet est toujours là mais il faut relocaliser chaque image de chaque projet. Je note l'absence d'un mécanisme d'extension automatique de la relocalisation (Lightroom sait étendre une relocalisation à toutes les images concernées - ça marche nettement moins bien dans DPL).

b. Toutes les infos devenues invalides du fait du changement de hardware ne sont pas "garbage collectées" (éliminées) lors de la génération des nouvelles entrées dans la table Items de la BD. Il en résulte une duplication et une augmentation de la taille de la table absolument inutiles et qui se répéteront à chaque changement de hardware jusqu'à régénération de la BD.

3. Tous les réglages effectués dans Photolab, ViewPoint, FilmPack et les mots-clés sont conservés dans les DOP/XMP. Tant qu'ils existent, rien de perdu. La BD se synchronisera dessus en cas de reconstruction.

Il n'y a rien dans la BD qui soit relatif aux réglages effectués dans Nik Software. Comme tout programme externe à DPL, un plugin Nik charge un export généré par DPL (ou Lightroom ou C1 ou n'importe quel autre dématriceur capable de lancer un programme externe), effectue les modifications demandées (application de preset, modifs manuelles... et recrache un fichier correspondant à ces modifs. Un plugin externe ne conserve jamais de données spécifiques à une image donnée. Un plugin Nik ne sait même pas que Photolab existe. Il est juste capable de stocker des presets. Par contre, il peut laisser des traces éventuellement réexploitables, dans les métadonnées du fichier généré. C'est le cas des plugins Nik avec quelques limitations (option "non destructive edits"). Ces infos ne sont pas stockées dans la BD qui ne contient que les réglages relatifs à Photolab.

4. Photolab ne fournit aucun outil de maintenance de sa base de données. On peut effectivement utiliser un outil externe pour explorer cette BD, vérifier qu'elle est intègre, optimiser son contenu mais seul Photolab connaît la signification des données stockées dans cette BD. Il est donc impossible pour un outil externe de mettre en place un outil de "garbage collection" ou de vérification de la validité des données. Il y a des années que cette demande d'outil de maintenance a été faite à juste titre mais il n'y a jamais eu aucune réaction de la part de DxO sur ce point (comme sur tant d'autres). Le seul recours de l'utilisateur en cas de problème est donc la reconstruction de la BD, ce qui implique la perte des projets.

J'espère que c'est plus clair.

[rsp]

Merci encore Patrick.