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.
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 …
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 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.
…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.
I believe the idea of so doing is so that you can add metadata to virtual copies, not just to the single XMP for the RAW. And, for those who detest the database, it makes sense.
No reason the application could not write to the single XMP. There’s little reason to have separate metadata for Virtual copies (it’s the same photo). Notes on processing could be a separate field stored in .dop and database.
Making complex and unreliable what should be simple and straightforward.
Well, if I understand correctly, Lr writes adjustments to the XMP. Are you suggesting that PL does the same? It would inflate the size of the XMP and possibly make them unwieldy and take more time to read and search.
No, you didn’t understand correctly, Joanna. I didn’t say anything about adjustments, which live very happily in .dop files. I said all metadata belongs in .xmp files. I also accounted for speed in searches and other data reading:
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.
When a photographer decides to edit the metadata of an image, the milliseconds it takes to read an .xmp file from an SSD are of no consequence. There would be no need to reread .xmp files just to perform a search. A photographer should be able to force a reread of the .xmp files. Or PhotoLab could do so intelligently by keeping timestamps on modifications of the .xmp files in the database. When PhotoLab detects that the .xmp files have been modified since the data was stored in the database that could trigger a background read of the .xmp files in that folder.
There are ways to keep metadata up to date and in sync. Simplifying sync means avoiding it by making a single version canonical. The canonical version of metadata should always be the .xmp sidecar as that’s where the other well-behaved photo applications which manage metadata store metadata.
@StevenL I’ve just solved most of your issues with metadata sync and inconsistency in the metadata between applications. I’ll accept a working version of PhotoLab 5 on Mojave as payment. You’re welcome.
From some test I did this evening it seems PL5 uses dop sidecar as the primary source for metadata, but this is crazy. When reading dop from PL4 there is no rating/keyword so every developed photo gets its rating set to 0
xmp sidecar should be the primary source, then if PL wish to save also to its database (and dop) ok, but in any case it should never overwrite the xmp unless the user changes rating/keywords from Photolab. In this case PL should update the xmp,database (and dop).
2 Likes
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
38
Alec, I have just one comment:
When having another DAM-system as metadata owner it’s not a good idea to allow Photolab to update the XMP. That should exclusively be left to the external metadata owner. Photolab shall in that case only read XMP and ought to be configurable to let the user chose whether Photolab shall be the master or not. If a user choses to use an external DAM instead of PhotoLibrary the File -Metadata - Write ought to be inactivated in order to block bidirectional metadata flows. En the IPTC and EXIF-fields in PhotoLibrary out to greyed ut and inactivated.
I’d like it be possible for write/edit capability to be disabled/enabled in preferences. That said, I disagree about not allowing Photolab to edit data. The whole point of portable XMP data is for all the applications to touch the metadata without changing its structure.
Of course, the mess with hierarchical keywords which you and @Joanna are exploring in detail (very informative posts, thank you both) indicate no cross-compatibility between any of the major players. It makes me happy that I’ve avoided hierarchical keywords. When I saw Adobe push for them in Lightroom I knew ahead of time it was a death trap of the Microsoft “Embrace, Extend, Extinguish” kind.
Outside of hierarchical keywords, most tags should be shareable among major applications. Title/headline, description/caption, creator, location, event, etc. I’d enjoy the opportunity to be able to occasionally title and caption images in Photolab while doing most of the metadata batching in Photo Mechanic. Of course I’ll never get the chance as DxO offers next to no support for macOS (OS -1 is not support, it’s a kick in the face, DxO has fallen in my opinion into the category of non-professional hobbyist software with this policy).
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
40
Alec, there seems still to be some operability problems between Photolab 5 and Photo Mechanic and that´s why I am really reluctant to start updating from both applications despite I use flat keywords in both. I wonder still what Photolab means with having some EXIF-elements open lik the rating. Photo Mechanic is strictly IPTC still. Just one example. I also would like to be able to disable write/edit in “Preferences” and I also would like to have it optionally to allow a keyword list built during indexing of the files. You have to be able to turn that off if you use structured keywords and for those who does it should be possible to import tabseparated files like we can do in Photo Mechanic and Lightroom. If you have two programs that integrate it is a must to be able to migrate even the keyword list.
Personally I see no problems just maintaining everything only in PM Plus. When developing the images in Photolab 5 and exporting to derivates like JPEG-files Photolab 5 handles the metadata perfectly fine.
Sorry to hear about your compatibility problems with Mac and Photolab.
I don’t know about PM, but most software no longer directly reads or writes EXIF tags, since they are considered legacy and “deprecated” in favour of XMP tags. PL5 reads and writes XMP:Rating.
And, although you say PM deals exclusively with IPTC, there isn’t a true IPTC tag for rating.
XMP:Rating maps to:
XMP-acdsee:Rating
XMP-dex:Rating
XMP-iptcExt:Rating
XMP-prism:Rating
XMP-xmp:Rating.
So, in writing XMP:Rating you are, in fact writing an IPTC tag but, in fact, the XMP-iptcExt:Rating tag is a structure and RatingValue is only one part of it.
I would be interested in seeing an XMP sidecar produced by PM for an image that has a rating. Could you post either the whole file or a screenshot of the part that contains the rating?
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
42
Joanna: Sure but Windows Info-tag is just using EXIF. I checked it yesterday with EXIF Tools manually. Some software doesn´t care at all about XMP just EXIF or non-embedded IPTC.
Yes, that sounds about right - not keeping up with newer standards which have deprecated such tags a long time ago. Which tag is it writing to?
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
44
ITPC is not all that new either and also have a few obsolete elements kept just of compatibility reasons.
Here to some intresting:
The number of EXIF-elements in my testfile, according to EXIF Tools, are no less than 266!
In EXIF Data Viewer i see more modest 58 supported elements that I can edit and in PhotoLibrary of Photolab there are just three open elements to my knowledge beside the elements it just displays. The rest are ghosted!
Another thing I observed is that EXIF Tools just can´t handle our scandinavian characters like ÅÄÖ and åäö at all. Quite a few other countries like Germany hos som odd characters too. That might also be a problem if working with EXIF Tools (who might work with ASCII or something. EXIF Data Viewer handle these characters perfectly fine. When I was a productmanager för Microsoft products and Windows-software a few years in the nineties at the biggest distributor in the Nordic Area of Europe. A lot of my work was to help our 200 different software vendors to adapt their softwares to the Swedish market. As an example a Windows software for emulation an IBM AS/400 could have one character set downstream (EBCDIC), an other in Windows clipboard (ANSI) and a third when typing (like ASCII). It took a few years to get the americans to understand. That´s also a reason why FotoWare doesn´t recommend to mix MAC and PC-versions of their client software Fotostation in the same company network.
Well the americans used to ask me if we really needed those strange character (like ÅÄÖ and åäö and I used to turn the mailing back excluding some of their characters asking them is they understood what I wrote. We used to say that ÅÄÖ was the biggest employer in the IT-industry in that time. Microsoft also sold Microsoft Works to small associations and their customers directly complained about they couldn´t print the paragraf signs they could see on screen, but not print before somebody (like I) rewrote the printerdrivers for them. So characters matters too.
I think we might have a chat with Kirk Baker or some other developer at Camera Bits in order to ask them to fork elements like IPTC Title/Headline, Subject/Description, Rating and Comment just to mention some of the most important. Both Lightroom and PM Plus 6 also use the Color Class-element to color tag the files in IPTC. In PM Plus we can even selecy a color schema that matches Lightroom to make metadata exchane smooth, but in PhotoLibrary that element is ghosted too. They just use rating. If Camera Bits forked the data or at least opened the EXIF namespace in XMP we could easily do it ourselves with the excellent variable-support there is in PM Plus.
So my conclusion is that it´s really a lot that can go wrong when pushing XMP-metadata both ways between any of the programs I have talked about like Photolab 5, Lightroom, Photo Mechanic and not the least with the very importand metadata viewers in Windows Image Viewer or Windows Explorer Properties Info Tab. I think it´s really important that our metadata displays correctly not just in our IPTC-centered software bot also in EXIF of compatibility reasons and I just can´t understand why this isn´t fixed a long time ago - hello Microsoft and all metadata-software manufacturers (no named (except Microsoft )and forgotten), time for some action before you fall back on the pillow!
Why don’t you work together one or more existing DAM’s (of course including IMatch) to make the connection to existing DAM’s seemingless.
Yours,
Ruud
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
46
Ruud, I have tried to do that with Camera Bits when I have experienced problems myself. In my opinion Camera Bits has the most responsive support I have ever come across since the beginning of the nineties. They really listens.
It was actually on my initiative they fixed a problem with the important Edit-function in PM Plus 6, which is a key to a smooth collaboration between PM Plus and Photolab, a potential show stopper for me. From the beginning it just could open one image at the time (a bug). Now it´s seamless with the number you decide you like to open in Photolab - select the images - right click and select the Edit in Photolab. This is extremely important since we have complaints here about how slow Photolab is to render the images in folders with maybee a tousand images. If one open the same folder in PM Plus and select a suitable number of files at the time you don´t get punished by integrated programs like Lightroom or Photolab PhotoLibrary. That speeds up the process considerably.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
47
Joanna: I tested to update the EXIF with Exif Data Viewer. After that i checked in Windows and they appeared there all of them. I updated the elements beginning with XP at the top and the rating element “Rating”. Så Windows is just leaning on those and doesn´t give a shit about either ITPC whether it is embedded in XMP or not. EXIF embedded in XMP as a namespace isn´t uset at all either.
Today my workflow works perfectly fine if we look at the one way IPTC-metadata with one restriction - the use of non-hiarchical keywords - called “structured” in PM. What I tag in PM Plus is flowing automatically from my RAW–files XMP-metadatasidecars via the process of my RAW-files in Photolab 5 and it’s export via Photolab 5 to my JPEG-files. That includes for example even the IPTC “Image data”-elements that are ghosted today in the IPTC-interface of Photolab PictureLibrary today.
BUT, despite that some of the most important IPTC-elements like Title/Headline, Caption/Description, Comment etc. are maintained in that flow, the maybee most used tools to consume that metadata in WINDOWS (all versions used now) IS NOT able to see that meyadata because it doesn’t giva shit about that data since it’s just looking at the corresponding element of the EXIF-data. Data embedded since forever in digital image-files.
So what is needed, is that all tools saving XMP needs to fork that data even to EXIF both to the EXIF-namespace in XMP and the traditional EXIF-elements in all types of XMP-kompatible image-files.
