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.
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
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:
-
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 -
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. -
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:subject
and 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
Aaaarrgghhhh!!! George, what are you doing to me? 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:keywords
or xmp-dc:subject
tags, 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âŠ
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.
@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!