Not happy with PL 5 PhotoLibrary

This is really good feature, I read the user manual before actually trying it :innocent:
Also synchronization seems to work well

1 Like

I suppose that you can answer your question by testing.

1 Like

Indeed. And I will once support help me get past a significant issue with the trial version. :frowning:

Yes it does!

But there are still other serious shortcomings with the keyword handling in the file.

can you elaborate on this? Writing metadata to files follows rules which seem to leave room for interpretation. I saw that PL, LRC, C1 and PhotoMechanic write keywords differently, but the exchange worked nevertheless in the cases that I tested using sidecar files. Apps have different default sets of metadata fields. Some of the non-overlapping fields can show up in apps that would not let you edit those fields unless they were in the input files. I have no chart of what goes where though. PM offers the widest set, but my trial has expired :face_with_raised_eyebrow:

See this thread…

I did further tests about the issue I had with the rating filter.
It seems the problem is related to the “Metadata Synchronization”, user manual doesn’t explain what this setting does but I found that when active it resets the xmp rating on photos that have a .dop sidecar (from PL 4), I am not sure this happens for all photos, I tested just a few.
Is this the expected behavior ?
Anyway just copying rating from dop to xmp (resetting an existing rating) I think should not be called “synchronization”

For now better to keep that setting un-ticked, anyway I don’t rate or set keywords from PL and probably don’t need that setting

If you have all your file folders in one hierarchy under a topfolder you can begin indexing the lot with the Index-function you can find just beside the metadata search field, just by pointing to the topfolder. If you just want to index a specific folder just point to that one. In the first case it can take hours to process all. After that you ought to see all your keywords in the keywordlist and can start using them for searches.

I was also confused first of the same reason.

When opening images in PL5 the metadata will be displayed instantly without any need to do anything (unlike in Lightroom I think) BUT, to see the used keywords and their numerics in Photolab Photo Library you have to index the files to updatae the database in Photolab.

1 Like

It works for DNG too. JPEG, TIFF and DNG are all XMP-compatible and gets the metadata written into XMP-headers.

@Stenis
I don’t know if you answered me, anyway I didn’t use the index function. I just opened a folder with some NEF files, when metadata synchronization is active all files that have a dop sidecar get the rating reset to 0 and xmp sidecar modified accordingly. I can reproduce the issue.

i stil would be happier to mark folders for indexing in a tree as active folders.
so when i in library i don’t see all non image holding folders to scroll through. i get too much folder to see i don’t need in a image edit program.
a simple “show all” checkbox can help to overcome missing folders to mark them also for indexing.

…having “favorites” for folders. Something nice to have…

4 Likes

We already have a Recent Locations list on the File menu but, unfortunately, that only shows the leaf folder, which is less than useless if you have a hierarchy of year/month/day and, of course, several leaf folders with the same day number.

The has been mentioned before and is really simple to change but still no movement :face_with_raised_eyebrow:

1 Like

i need to test it but the “syncronise action” is only done when you leave the image and selecting an other. just check en uncheck checkbox synchronise doesn’t work.
(i am very fond of more detailed control over how sync would work. i do like a hierachical data transfer setup. and “plain synchronising” isn’t that. So unless i am absolutly sure about the “chain of command” i am very carefull using “synchronise”. No affence to the builders of the DAM. I know it’s in evolving state and needs to be tested in daily use to find the loopholes and errors and prop the leakagespots.)

In order to gain control over creation and editing of sidecars, one needs to switch off all automatic actions as shown in the screenshot below. Then, control is quite granular and with the user - as is responsibility.

Granularity: Separate menu entries for read or write of .dop and .xmp sidecars.

3 Likes

Forcing users to manage metadata themselves amid confusing and unreliable results is not a solution. DxO should step up to the plate here and handle metadata sensibly. This means reading metadata from the XMP and writing the metadata back to the XMP. Metadata has no place in either the DOP file or the database.

“What? You want to undercut the database, you monster!”

No, no, no.

The database can store metadata for quick display but at any point the photographer decides to edit the metadata, the metadata must be refreshed from the XMP.

“But what if the photographer doesn’t want XMP files in the RAW photos directory?”

If a photographer uses metadata, s/he should have to live with XMP files. XMP is the standard for metadata and DxO has no business breaking standards. The same short-sighted fools who don’t want .dop files to store their editing corrections could perhaps turn off both .dop and .xmp and go entirely database driven.

When these photographers lose all their edits and metadata in a creeping database corruption incident (poor DxO support having to try to unravel the broken databases individually for these unhappy individuals: could be averted by simply requiring that data be stored in both database and sidecar) they will see the light. Ironically many of those same short-sighted individual will then bitterly blame DxO for allowing them to lose years of work. Best for DxO to make it very difficult to run database only with loud warnings along the way.

There are some right decisions to be made with the handling of metadata. A confusing mess of options which all end in the result of the loss of or inconsistency in metadata is no solution.

3 Likes

Re PLv5 doco …

Great job on the update to PL User Guide, Gilles … It’s really good to (finally) have some explanation for the Resizing Mode options … At last, I can now see the intended difference for Fit vs Rotate to Fit:+1:

Regards, John M

That’s what i proposed few months back.
along with the explanation text change to get clearer view on what’s happening.
same as the pull down menu’s:
export
export v5

export what? (when writing) or import what? (when reading)
all? or only selected? the manual would be clear about it as it seems but i don’t want to read it every time i am confused.
it should be “read selected” and “write selected”
(if that’s the action)
Simple clear and every one knows what to expect.

2 Likes

…considering that we can have more than one sidecar per image, DxO could rename the “Sidecar” menu to " .dop sidecar" in order to improve differentiation between .dop and XMP.

1 Like

Metadata should never be stored in the .dop sidecar at all which would make the housekeeping, syncing and interface much clearer and much easier.

1 Like