Keywords and IPTC

Hello.
I have just upgraded to PL6 and i began to play with keywords with hierarchical orders and i am wondering how to put the keywords in IPTC if possible keeping the hierarchical order as well. If it is possible i would love to know the way to do so with both JPG and Raw Format. Thank you for your help.

Check out this page to see how to add keywords:

The IPTC fields are meant for other things than keywords, but you could always add a Headline and/or Description in IPTC.

Keywords in Photolab are placed in an ITPC-element called “Keywords” and are nothing we need to think all that much about. In Photolab the metadata is split between EXIF (at the top) and IPTC comes after that. Keywords are handled in the IPTC-section and echoed up to the EXIF-section as well.

If you edit a RAW your metadata is stored in a parallell XMP-file and if you add metadata to a JPEG, that data is written into a header in the JPEG. The same goes for TIFF- and DNG-files.

ItÂŽs also good to ask yourself why you want to use metadata, because it will demand a great deal of work to do so. I think the metadata edit tools in Photolab 6 is pretty OK today even if they are far from top notch. Photolab is a decent generalized and cheap metadata editing tool that will do the job.

I agree with Platypus that you ought to have a wider focus then on mainly keywords and especially if you want people to find your images on the net. Keywords are mainly an internal thing in an organisation or company that has standardized on a common vocabulary of keywords or for a single photographer, but they are pretty useless out on the net because they mostly consist of common words that will drown in the common noise on the net.

It might not even be the case that all the IPTC-elements you have updated locally will get indexed by for example Google. That®s why it®s a good advice Platypus gives when stressing the importance to update Headline, Description, Copywrite and Title just to name a few but important elements. Title is especially important but sometimes neglected since it is used by Windows own File Properties in the “Information”-tab. It®s never wrong either to use descriptive file- and folder names since they use to be included in the indexes to which means that they will helt people and systems to find your images on the net - if you want to.

2 Likes

In my understanding the exif deals with the camera parameters, including the in-camera conversion to a jpg.
In the beginning an IPTC section was added to the image file containing keywords so images could be sought on a name or something else defined in that section. Later Adobe came with the xmp section and slowely the keywords where moved to there.
In pl 5.0 keywords where stored both in the iptc and xmp section. But since 5.2 or 5.3 only in the xmp section. That was done without any announcement.
Many browser rely on the iptc section, among them Irfanview.

George

The reason why i would like to store the keywords in iptc is to be sure that they will always be there not depending on a data base handled by a software and it has nothing to do with an internet tagging.
Here are 3 questions to make it clear to me; is there iptc header in raw file ?
Are the keywords automatically written in the iptc headers in PL 6 ?
Is there a way to handle a hiérarchiy level through IPTC?

Every application has itÂŽs own flavour IÂŽm afraid.
Most software doesnÂŽt write to the RAW-files directly but some do. I think Sonys Imaging Edge do and in Photo Mechanic there is an option to do it but isnÂŽt done by default.

Some applications “fork” data from IPTC both to EXIF and to XMP where IPTC has it®s own namespace and elements.

Many applications rely on IPTC but not all of them can read the IPTC from the XMP. In Photo Mechanic there is an option to write IPTC to XMP and I use that but itÂŽs not mandatory.

@YvPL5 The following was conducted with PL6.0.1

Automatic reading and writing of metadata between DxPL and the image is controlled by

4 RAW images (Panasonic RW2) had the following keywords set

a, m, b
a|m|b
a|m|b|bb
a, m, b, a|m|b

and Picmeta Pie shows the resulting metadata for the image as coming from the xmp sidecar file, DxPL only writes to a sidecar file not to the embedded metadata.

ExifPilot shows for scenario 4:-

I believe from the above that the answer appears to be no, but I would need to run tests with other software to confirm but my recollection from previous testing is the IPTC keywords are effectively the same as the ‘Dublin Core’ fields but I can’t be sure about that.

PS:- The sidecar looks like this

No. They’re written in the xmp header.

George

1 Like

Correction. It seems pl6 is writing them again in the iptc section. Both old and new keywords.

George

@George I don’t think PL6 is writing them anywhere and neither is other software they are writing to the ‘DublinCore’ (‘dc’) fields and these are being used as the IPTC ‘Keywotds’.

This is from ExifPro and old program that only “understands” the ‘dc’ fields, i.e. it will never write to the ‘hr’ fields and this is for a scenario I didn’t include above x, y, z, a|m|b

and PIE shows this as

and this is fine until that data is “processed” by an ‘hr’ aware program like DxPL when the hierarchical fields will be “moved” to the ‘hr’ fields as shown in the example above!

This is what happens when the 5 scenarios I used are fed into other programs directly and what PL5 before and after the PL5.2.0 changes were made

Worksheet 3 from Copy of meta data settings V09-01_watermarked.pdf (483.9 KB)

Hence, I don’t think any hierarchical keywords in the ‘dc’ fields will “survive” a round trip to an ‘hr’ aware program, albeit one option of Photo Mechanic leaves the hierarchical ‘dc’ fields intact!

The spreadsheet data was created by entering the

a, m, b
a|m|b
a|m|b|bb
a, m, b, a|m|b
x, y, z, a|m|b

into all of the programs shown directly and then processing those images with the applied metadata through DxPL5 before and after the PL5.2.0 changes. PL6 behaves as PL5.2.0 onwards currently with a promise from DxO that they will provide an option to revert to the pre-PL5.2.0 format in a release of PL6!?

PS:-

I used RAW for my tests so that I can inspect the xmp sidecar file but the same rules apply to JPG (and TIFF and DNG) but using embedded xmp data (which I can see via Beyond Compare but not directly)

I must say I was concentrating on simple keywords, not hierarchical.
Then pl6 writes, reads and adds them to the iptc section. Checked with Irfanview and exiftools.
This was not the situation in the last version of pl5.

George

Answers to your questions as I understand them:

  1. I see no IPTC section in the .CR2 files I checked with “exiftool -G -a -u *.cr2”
    This might be different with files written by different camera models or -brands

  2. DPL6 writes keywords to the subject and hierarchical subject tags of exported files,
    unless you choose to export metadata selectively or not at all in DPL’s output dialog.
    DPL6 writes keywords to its database and to .dop and .xmp sidecars of RAW files.

  3. Hierarchical keywords are handled differently by different applications. As far as I’ve tested, they all use the subject and hierarchical subject tags. For best interoperability of DPL with other applications, I found that one should define the hierarchy first and then add the keyword of the appropriate level by clicking on it in the Keyword List tool. This will not only add the selected keyword, but also all parent keywords, which can be a benefit for other applications.

Notes: All of the above applies to DPL6 for Mac

That is the “(ALL assigned)” rows in my spreadsheet and achieved as @platypus states

The current default for entering (an option to change this is also promised)

Selecting the empty check box in next to m results in

and we get this (if we only change the image shown)

and this if all are changed

Which happens to be identical to what Capture One creates!

But beware when using the ‘Keyword List’ I managed to select the ‘b’ from the lower (EP-RAW-01) keyword group and started to changes things dramatically!!

If I may interject here.

There is a very subtle difference between the iptc:keywords tag and the xmp-dc:subject tag.

Whereas the xmp-dc:subject tag contains a list of strings of any length, the iptc:keywords tag contains a list of strings that are limited to 64 characters. This may or may not be important, depending on the kind of information you are wanting to store.

But, as @platypus mentions, IPTC is not really the ideal place for keywords and PL6 doesn’t write to the iptc:keywords tag. IPTC also doesn’t contain any means of noting hierarchical context

I’m sorry but this is not true. They are only stored in xmp-dc:subjectand lr:hierarchicalSubject

Wow! I thought they used to be in IPTC as well but, upon checking, you are absolutely right. So kind of DxO to let us know :roll_eyes:

Aaaarrgghhhh!!! George, what are you doing to me? :crazy_face: I don’t see it writing them to the XMP sidecar. Or do you mean when exporting?


Whatever you do don’t write concatenated keywords (such as “One | Two | Three”) to either the iptc:keywordsor xmp-dc:subjecttags, in an attempt to infer hierarchical content. Such things are subject to different interpretation, depending on the software reading them. Strictly such content should be interpreted as a single word that just happens to contain delimiters.

The MWG document explicitly states that hierarchical keywords should be written the lr:hierarchicalSubject and all keywords mentioned there must also be written to the xmp-dc:subject tag.

PhotoLab doesn’t adhere to this standard, thus making it incompatible with some other software when it comes to searching.

@Joanna I understand what you are saying but the use of “all keywords mentioned” to refer to 
 what I referred to as “hierarchical components”, i.e. a, m and b as the elements (simple keywords) from a|m|b or a>m>b or b<m<a whichever you consider to the “proper” representation.

Arguably pre PL5.2.0 DxPL conformed to that rule but then broke it with PL5.2.0, now with a promise to restore the old format with PL6.?.?!

But if DxPL reverts to the pre PL5.2.0 format will it then become more compatible and if all the elements in the hierarchy are selected then does it conform (and the outputs pre and post PL5.2.0 create the same output in this case)!

What software actually writes to iptc:keywords, yours? and what else.

The software I use to display the metadata use xmp-dc:subject either because they are programmed to do that if iptc:keywords is empty or because they assume that it the only place to get it! I don’t know of any software where I can address that field directly and put data into that field!?

PS:-

I told a “lie” this is after PM added a|m|b to image two (comparing itself to itself because it is easier in Beyond Compare

with the following PM parameters

and PIE gives

After it is opened but not changed in PL6

Adding a new simple keyword in PL6 gives (PIE adopts the “rule” that sidecar data takes precedence over embedded data!)

I’ve not found any IPTC entries because I’ve NOT added anything with the IPTC sections of DPL’s Metadata palette. All of the above is in the XMP section of the output files (checked it with a hex editor to prevent interpretation)

Imo, the choice of mixing “keyword” with “subject” in IPTC’s guidelines is unfortunate, but hey’ they’re only human too


Other than that:

  • DPL does what it does and we can either use DPL to keyword our files or not.
    The main thing is to use exactly one app to write metadata to files.
    All other apps should be set to read only.

  • DPL uses “Subject” as the field label in the IPTC Content section, while IPTC seems to expect a Subject Code instead
and has it marked as “legacy” field. Panta rhei!

@platypus agreed. The reason for my “fascination” with other packages was the “legion” of posts complaining about what PL5 (then pre PL5.2.0) did to the metadata. Given that those users had been exporting with DxPL for years and not complaining! At that time PL5 matched Lightroom and IMatch (with one set of options set) for exports and had done for a number of releases (from DxPL3 I believe)!

In this case @YvPL5 explicitly wanted the IPTC keywords to hold the original hierarchical keywords, e.g. like this

But it doesn’t!

I’ve got the suspicion that we’ve overrun @YvPL5’s questions by far.

Imo, @YvPL5 's questions are not precise enough for an exact answer. Moreover, when one is beginning to add keywords, there are so many variables and iterations that details like asked above seem irrelevant to me.

Time for @YvPL5 and write something conclusive, possibly in native language too.

The problem occurs when you don’t select the entire hierarchy for a nested keyword - like this


Capture d’écran 2022-11-22 Ă  14.17.28

Selecting

Actually, it was PL5.1.3 that got it almost right


         <dc:subject>
            <rdf:Bag>
               <rdf:li>Branch</rdf:li>
               <rdf:li>Leaf</rdf:li>
               <rdf:li>Root</rdf:li>
               <rdf:li>Solo</rdf:li>
            </rdf:Bag>
         </dc:subject>
         

         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Root|Branch|Leaf</rdf:li>
               <rdf:li>Solo</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>


 except there is no need to insert the “Solo” keyword in the lr:hierarchicalSubject tag, since it has no hierarchical context.

But then PL5.3.1 switched to getting it wrong again


         <dc:subject>
            <rdf:Bag>
               <rdf:li>Leaf</rdf:li>
               <rdf:li>Solo</rdf:li>
            </rdf:Bag>
         </dc:subject>
         

         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Root|Branch|Leaf</rdf:li>
               <rdf:li>Solo</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

Not only still, unnecessarily, inserting the “Solo” keyword in the lr:hierarchicalSubject tag, but now also omitting to insert the complete flattened hierarchy for “Leaf”, as required for maximum compatibility.

All DxO has to do is to revert to the 5.1.3 behaviour and sanity will be restored. If there is a fear that the post-PL5.3 style lovers will scream and throw their rattles out of their prams, simply add a switch to the preferences.

Mine certainly doesn’t. I only use xmp tags. I haven’t looked too closely at many other DAMs but, so far, I haven’t found one that does.

From what you have said, Photo Mechanic allows keywords to be entered in the format Root|Branch|Leaf and it then parses that into a hierarchy, even though it records it as a single keyword, which is, to say the least, weird.

As you can see from your output, a|m|b is recorded as a single keyword that just happens to contain pipe characters. As far as the rest of the metadata world is concerned, whether this is interpreted as hierarchical will be entirely up to the software writer. It certainly isn’t standards-compliant and, without a doubt, confuses the heck out of some software.

At the moment, I totally agree with @platypus when he says that you should only ever use one DAM to write metadata and, if you want to be able to read it is written, you must also use the same DAM. Just because PL can read metadata written by other software doesn’t mean it is correctly interpreting it, especially hierarchical keywords and, especially, especially, non-standard formatted, so-called hierarchical, words with delimiters included.

Which brings me back to the main subject of this thread @YvPL5 - no it is not possible to record hierarchical context in IPTC metadata, period, full stop.

1 Like

@Joanna and either does Photo Mechanic when it is instructed to use a sidecar file only (image 6 given keys a, m, b, a|m|b, a|m|b|bb)!

But it does ‘Save to’ JPG including that data or so it appears!