Thank you for the files. We’ll investigate the issue.
Regards,
Svetlana G.
I had already mentioned the problem, in fact PL5 takes the parent keywords as a keyword when they are only there to make a hierarchy.
It would be necessary to have the choice to consider the parent keywords as a keyword or not.
Dear Andre @akirstein ,
If I process your Raw to jpg or to NIK as tiff or JPG → I do not have this issue:
So we should have a deeper investigation. Could you, please, also provide a sidecar for this RAW image + a screenshot of the Keywords palette when this RAW is selected + logs (%UserProfile%\Documents\DxO PhotoLab 5 logs).
Please, upload the via upload.dxo.com and let us know when ready.
P.S. And I forgot to ask you which OS do you use?
Thank you
Regards,
Svetlana G.
Svetlana: I tested the same roundtrip with and image with metadata applied in Photo Magic Plus 6. Opened and processed the RAW without any other action in Photolab 5 than opening the file. Finally exporting a JPEG that I as a last step opened in PM Plus 6 again and that works perfectly fine as long as you don´t do any editing at all in Photolab!!!
This is my workflow and it has worked both with both Photolab 4 and 5. So Photolab reads the XMP correctly when exporting JPEG, TIFF or DNG to disk and even ghosted IPTC-fields you can´t see in Photolabs limited IPTC-form gets exported correctly! The new thing is that we now also can see that data (or most of it since the IPTC Image-elements in Photolab don´t seem to be the same as the ones I use in PM Plus forms ) 
You can read the whole story in message 58 above.
The initial import of XMP do not populate the keyword table with the keywords used on the images. To make that to happen we have to look up the topfolder in the folder and index it. A few have complained about the keyword mess when using hiararchies and I can understand that to some extent BUT I think it looks like it works as it should if I don´t use and I don´t. So in fact I´m fine with the keywords. So this might be something to think of for now. More about a hiararchy test later.
I also have another thing to say. I have used hiararchies a short while when I initially tested PM Plus. It has an interface to import and export hierarchical keyword vocabularies. So I just downloaded a tabseparated hierarchical keyword file and imported it. When I used it I found that when I wanted to add a keyword I got the whole hierarchy just like in Photolab 5! And I really didn´t mind. Isn´t that the very idea with hierarchical keywords. If I select a hierarchy like Transportation - Boat or Car it might be good to get a theme level available when searching? Well I didn´t go there because of the maintenance time it took to populate the list with things I needed. I went for a stricly non-hierarchical keyword list and today I´m very pleased with that decision.
It is really important to think through who you are targeting with your mark up. If you want your metadata to follow your images in to Wiki Commons, Windows, Mac OS or you happen to send it to other systems with certain demands you might use a special vocabulary standardised for these purposes. If you are leaving Lightroom and have used hierarchical keywords there and want to migrate to Photolab 5 or later you will get disappointed until DXO opens a Photolab interface to make imports of tab separated hierarchical keyword vocabularies possible and before that you have to solve some of the strange things that happen when metadata are sent back and forward of some users to other DAM-software for example. I think it might be a good ideá to call Camera Bits because it doesn´t look good when hierarchical metadata is sent to Photo Mechanic Plus 6.
1 Like
Svetlana: I have done some testing cirkulation metadata between Photo Mechanic Plus 6 and Photolab 5. I hope it reveals a few of the odd things I think is going on with the metadata exchange. In this test I have broken rule of not having bidirectional metadata flows. I strongly recommend that anyone that uses other metadata editing software together with Photolab never updates either metadata or any other metadata in Photolab. If you do that you won´t have any problems what I have seen at least if you stick with a flat non-hierarchical keyword look up table
Step 1 step 1:
The whole hiararchy created in Photolab 5 and all levels applied to Image:
Test nivå 1, Test nivå 2, Test Nivå 3
Case 1.2:
Metadata saved with File – Metadata – Write to XMP
Result in Photo Mechanic:
Test nivå 1, Test nivå 2, Testnivå 3, Test nivå 1 | Test nivå 2, Test nivå 1 | Test nivå 2 | Testnivå 3
Case 1.3:
Metadata reimported with File – Metadata – Read
Result in Photolab 5:
Test nivå 1, Test nivå 2, Test Nivå 3
Case 1.4:
Reindexing the folder where the image is stored (when there already is a list created)
Reindexing normally create a keyword list from the images keyword metadata if there is no list present originally
Result in Photolab 5:
Test nivå 1, Test nivå 2, Test Nivå 3
Case 2.2:
Hiararchy: Test nivå 1, Test nivå 2, Test Nivå 3 created in Photolab 5
Case 2.2a:
Only Test Nivå 3 applied to Image
Keyword field emptied in PM Plus 6 before export
Metadata saved with File – Metadata – Write to XMP
Result in Photo Mechanic:
Nothing was exported!!!
Case 2.2b:
The whole Test nivå 1, Test nivå 2, Test Nivå 3 hiararchy was applied
Keyword field emptied in PM Plus 6 before export
Metadata saved with File – Metadata – Write to XMP
Result in Photo Mechanic:
Test nivå 1, Test nivå 2, Test Nivå 3
Case 2.3:
Metadata reimported with File – Metadata – Read
Result in Photolab 5:
Test nivå 1, Test nivå 2, Test Nivå 3
Case 2.4:
Reindexing the folder where the image is stored (when there already is a list created)
Reindexing normally create a keyword list from the images keyword metadata if there is no list present originally
Result in Photolab 5:
Nothing is happening with the list and the hiararchy
My conclusion:
Photolab only exports the whole hiararchy
Nothing is exported if the whole hiararchy isn´t exported
An import of XMP-data doesn´t seem to populate the keyword file in this case if there is one already and doesn´t affect the hiararchy I created in the keyword list either but it might with for exemple a lot of images marked with a Lightroom hiararchy.
I also hope you will update the “Preference” with a possibility to chose whether Photolab or an external metadata editor shall be the master metadata system. If someone chose another master than Photolab writing of metadata should be inactivated and the IPTC-fields in Photolab should be inactivated too.
If the user prefers to use Photolab as master Photolab has to write to the XMP-files.
It shall also always read the the XMP-files or the embedded metadata in JPEG, TIFF and DNG (regardless which system is the master) when the user opens a folder for editing and update the database with that data. The files whether XMP-sidecars or the XMP-compatible files like JPEG, TIFF or DNG shall always be the real master container of data. That is our safety belt and life insurance. Don´t make the same mistakes like Adobe has done with Lightroom making writing to XMP an option by default.
1 Like
Hello @Stenis,
Thank you for such a detailed feedback. Let me attract @alex attention to it.
Regards,
Svetlana G.
Good! Surprisingly enough I think you have done a lot right already with PhotoLibrary but still have a few flaws - as expected really with 1.0. The system works fine for me now though with Photo Mechanic Plus as a the absolute master of the metadata and that I NEVER EVER update anything at all in Photolab. If I index the topfolder of my metadata silo Photolab also indexes the lot and creates a sorted keyword list with the number of hits to the right. Do every one know they have too?
One thing I have noticed is that I sometimes get an empty keyword list when opening Photolab. The solution for that has been to select the topfolder of my folder hiararchy right click it and click “Refresh”. Maybee you have to look into this and perform an auto refresh. I think it might not be obvious to all to do that by themselves. I was positively surprised that you display in the resent searches list the number of hits and where it found them (by keywords, the file name or by the IPTC-tagging)
So my conditions for the integration with PM Plus 6 is for the moment as follows:
- PM Plus has to strictly own the metadata ( File - Metadata - Write ought to be disabled in Photolab with an external DAM as a master in order to prevent bidirectional updates and unsync)
- Only use non-hiararchical keywords
- No updates what so ever by EXIF or IPTC-elements in Photolab PhotoLibrary
- Import of metadata to Photolab by File - Metadata - Read after updating metadata in a folder in PM Plus
- Indexing topfolder of your image folder silo from within Photolab to populate keyword table
- Some times a “refresh” of the topfolder is necessary in Photolab to see the keyword
- XMP seems to be read automatically by Photolab when opening a RAW and exporting for example a JPEG. So this works already fine and do so even in Photolab 4. Don´t mess with that.
- You have to make a reindex of the same image folder in PM Plus efter exporting new JPEG-files to it from Photolab to bee in synk
Conditions for using Photolab as a master of metadata:
- Don´t ever use File - Metadata - Read! (ought to be disabled with Photolab as a master)
- Use non-hiararchical keywords
- To be sure to update the XMP-files or embedded metadata in JPEG - TIFF or DNG, select all images you have updated in the work session and export with File - Metadata - Write. (until we are deadly sure DxO kan guarantee they always update the XMP automatically)
- Unlike Lightroom the default always has to be writing to XMP automatically when updating metadata in PhotoLibrary
1 Like
Just played with the new Lr masking and not sure, yet anyway, what it brings that I cannot do in PL5 (other than the AI stuff). It is quite possible that I am missing something during my familiarisation process but irrespective of that it does show how PhotoLab has progressed. Well done!
Look here Svetlana, Joanna and others concerned about how to handle hiararchic keywords :
Below is an image of what Camera Bits call a dialog for maintaining “Structured Keywords”.
Please note the selected structure of three levels.
The interesting thing is that you can add the lowest (mother) by just klick "Add Keyword. If you chose “Add Path” instead you get the whole structure “People - Family - Mother” and it looks like People, Family, Mother in the Keyword-field in the Photo Mechanic Plus field in the metadata info form.
My point here is that I think it´s an impossible strategy to try to “reverse engineer” the keyword content in the images with the keywords from say Photo Mechanic or Lightroom to create a structured keyword hiararchy in Photolab, when you index the topfolder in order to index all of the images in one shot.
If you want to migrate from say Lightroom you have first to write all metadata to XMP-sidecars from Lightrooms catalog you have created with the use of the structured list in Lightroom, because it´s not done by default. In order to make it possible to import tab separated textfiles from Lightroom with a hiararchy DXO will have to make it possible both to import and export such keyword vocabulary files. There is no such feature today in Photolab PhotoLibrary from what I know. The buttons down to the right in the form namned Merge, Load and Save is performing just these tasks in Photo Mechanic Plus. This vocabulary I have imported from the net but I´m not using it because I felt a flat keyword structure is much more effective for me in PM Plus. It´s easiest though to export it to maintain the structures in a texteditor and then import it again.
DxO have to provide a feature like that to make it possible for Lightroom users or really any other user to migrate without problems. They have to be able to use the vocabulary all their images already are tagged with, even for the new images they will create.
If DxO provides a solution like that people will have much easier to leave Lightroom to start using PhotoLibrary instead. Both Lightrooms archive and PhotoLibrary are really entry level Photo Asset Management Systems that are comparably simple integrated sulutions and both with tehir own limitations. The good though is that since XMP is the DAM metadata Lingua Franca it´s pretty easy to scale up if you want somthing more powerful and more flexible like Photo Mechanic Plus. It´s faster, more effective, more scalable and flexible and will even let you have an unlimited number of catalogs that easily can be searched in any kombination at the same time. With Lightroom and PhotoLibrary you are stuck with one catalog at the time in applications with a lot of compromises when it comes to speed.
To migrate a level you just have to reindex your topfolder with Photo Mechanic instead and import the vocabulary you have used in Lightroom or Photolab 5 and you need to configure a couple of forms too with corresponding IPTC-elements. That might be a blow to Adobe in the long run but not to DXO since Photolab 5 and Photo Mechanic already today is a perfect match (if you use flat keyword lists and hopefully there will be possible to import structured vocabularies a little later even from Lightroom).
I know Photo Mechanic can scale even more when it is used as a metadata editor in Enterprise DAM environments like the norwegian FotoWare Enterprise DAM. Photoware has their own PC software (Fotostation) for metadata editing but some replace it with the both cheaper and faster, more flexible and more effective Photo Mechanic Plus. DxO and Camera Bits has a lot to gain by some better cooperation for increased interoperability and the ability to be able to offer a joint plan for upscaling Lightroom just can´t match.
1 Like
Dear Svetlana
My apologies for the late reply. Been buried at work and could not get back to this.
I have uploaded a new file where the same thing has happened. What I did before opening any file is to totally delete all my keywords from the DxO database and then start from scratch to read them in again. This cleaned up a lot of old keywords and I have noticed DxO library now shows only the keywords added and not the parents which is good. However, when I read the file back into IMatch I find the child keyword is added again as a parent. Please see the screenshots of IMatch added. Digging into this a bit more I realise this only happens when I go from RAW to NIK and then save as a JPEG. If I convert the RAW straight into a JPEG then this problem does not exist. I tried the above on a few other photos and the corruption only occurs in IMatch when you use NIK Collections.
However, I have discovered another problem and that is the synonym for my keyword “goose” being “geese” is added as a new keyword instead of staying as a synonym. Obviously DxO does not recognise the ability to add synonyms and if I am correct then this will be an issue for many.
Hope this helps and appreciate your input.
Regards
Andre
2 Likes
Hi Svetlana
Just saw your other question - I am using Windows 10.
Andre
1 Like
I have another keyword integration issue here with “structured keywords” in Photo Mechanic Plus 6. In PM Plus 6 you have the possibility to use “,” (comma) as a separator between keywords (default) or tabseparation wich is displayed as an “I”, just to make it more complicated.
On top of that I have to mention I´m not an american or an englishman accustomed to use “,” (comma) as a list separator. I´m from Sweden and in Sweden the list separator standard is “;” (semicolon). In that regard I have more in common with people speaking Urdu in Pakistan or Pashto in Afghanistan. I mention this because these standards are a real mess too - just look in the country specifik settings in Windows if you will get some input on this. For the record I always use english keywords and comma since nothing else works world wide on the net and I use an english Windows and Photolab installed in english too. The reason for that is to be able to get support with tech issues from the whole world instead of just from Sweden.
Well look at the image below of the structured keyword form in PM Plus 6. In the lower left there is a separator ckeckbox. If that is checked PM Plus will use a “non standard keyword tabseparation sign” (“I”) instead of a comma. If you have forgotten how an export of a structured keyword looked från Photolab 5 PictureLibrary, take another look below. I interpreted that as tabseparation was used for the very structure and comma for the keyword separation and both the structure and the keywords was exported.
Test nivå 1, Test nivå 2, Testnivå 3, Test nivå 1 | Test nivå 2, Test nivå 1 | Test nivå 2 | Testnivå 3
In PM Plus it will look either like Test nivå 1, Test nivå 2, Testnivå 3 or Test nivå 1 | Test nivå 2 | Testnivå 3 (if the Separator checkbox is checked).
The conclusion of this is that you shall NEVER EVER send XMP-data both ways between Photolab and Photo Mechanic because that will create a total mess of your keywords in PHoto Mechanic. If you use Photo Mechanic together with Photolab Photo Mechanic has to be the owner of the metadata until DxO and Camera Bits have managed to harmonize this. Also have in mind that Photo Mechanic IS NOT one of the applications that adapt automatically to Windows country specific settings. Comma will always be the default until you decide differently under Edit - Preferences - IPTC/XMP, where you can change the list separator to semicolon if you have too or if you check the “Seoparator” checkbox.
Hello @Stenis ,
In PL we accept | or >/< for the hierarchy and a comma ‘,’ is used for validation (same as enter).
Regards,
Svetlana G.
I know but in PM plus you can get an “I” as a separator between the keywords structure AND a comma between the actual keywords. It’s a big difference between what you export when exporting a structured set and what PMPlus does when the “Stuctured keyword” box and keywords are selected there. In PM plus you get a structure OR just a bunch of keywords separated by either comma or “I”.
How it looked after export from Photolab in keyword field in PM Plus after File - Metadata -Write: Test nivå 1, Test nivå 2, Testnivå 3, Test nivå 1 | Test nivå 2, Test nivå 1 | Test nivå 2 | Testnivå 3
How it looked in the same field in PM Plus after selecting the same structure: Test nivå 1, Test nivå 2, Testnivå 3 OR Test nivå 1 | Test nivå 2 | Testnivå 3 (if the Separator checkbox is checked).
It is two different sets here that can’t be exchanged between the applications without causing problems.
From Photolab comes a structure AND a set of keywords. From PM Plus comes just a structur OR a set of keywords. That’s a big difference.
I would like to know exactly how it ought to look. What is really the standard for structured keyword handling? You developers of the integration between different applications will have to take it there regardless of which company you work for and regardless of which application you develop. We don’t seem to be there yet.
To reverse engineer a keyword list from the keywords used in the images seems to work for non-structured keywords in Photolab but seems to be a much more difficult task with the structured ones. Since it seems to look so different in just Photolab and PM Plus as examples it doesn’t seem to be a good ide’a to try to reverse engineer structured metadata from other applications.
The notation you highlight in your screenshot is something that @KeithRJ brought a few months ago.
I would dare to assert that this is not a PL5 problem but a PM problem.
I know it is something that PM allows but it is not something that seems to be part of MWG or XMP guidelines.
By using the pipe symbol when writing to the xmp-dc:subject tag, you are not writing a hierarchy, you are simply writing a single keyword that happens to contain pipe symbols.
It is standard for hierarchical keywords to be written, separated by the pipe character, to the xmp-lr:hierarchicalSubject tag and for each of the keywords mentioned in the hierarchy to be written individually to the xmp-dc:subject tag…
<dc:subject>
<rdf:Bag>
<rdf:li>Fruit</rdf:li>
<rdf:li>Orange</rdf:li>
<rdf:li>Satsuma</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Fruit</rdf:li>
<rdf:li>Fruit|Orange</rdf:li>
<rdf:li>Fruit|Orange|Satsuma</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
What PM appears to allow is to “combine” both keyword and hierarchy definition in just the xmp-dc:subject tag…
<dc:subject>
<rdf:Bag>
<rdf:li>Fruit|Orange|Satsuma</rdf:li>
</rdf:Bag>
</dc:subject>
From extensive research, I would say this is non-standard, causes confusion and should be avoided if compatibility with other DAMs is envisaged.
I believe PM allows this option in the belief that PM is going to be the sole manager of keywords. If you plan on using PL5, or any other DAM as well as PM, to avoid compatibility problems, I would untick the checkbox in this screenshot.
1 Like
Thank you for the prompt reply. I agree totally with your conclusion. PM is the problem here and mix both structure and keywords in the same XMP-element. Your code example here is very enlighting.
The pipe character is not a character I expect to find as a separator between keywords in a keyword-element/field. It convinced me even more to stick to non-structured keywords when integrating with Photolab 5. That seems to work fine and I don’t want any problems så I will strictly stick to my one way flow from PM Plus to Photolab. I don’t think the implementation of structured keywords is any good in PM since it’s just too ineffective and cumbersome to use too. That’s the main reason though for me to use the non-structured keywords because they work really good and effective in PM.
1 Like
Joanna, when thinking it over again neither of Photolab 5 or PM Plus makes it correctly. When updating XMP with File - Metadata - Write, Photolab put both the structure and the keywords in the same keyword-element in PM Plus. Photalab puts the data there and PM Plus allows it without any complaints.
Test nivå 1, Test nivå 2, Testnivå 3, Test nivå 1 | Test nivå 2, Test nivå 1 | Test nivå 2 | Testnivå 3
Since all elements except the IPTC are ghosted in both products it´s not all that transparent what activity is going on in the other XMP-elements behind the screen - if there is any.
After more than two years writing my own software, I have realised that standards are a good thing, if only we could figure out which is the right standard and how to interpret it.
Which leads me to state what I believe about the MWG guidelines:
The key factor for me is how the mwg-kw:Keywords tag is written. This is not something that many apps use but I have found its structure useful in determining what goes where.
First, here is the full structure as recorded in an XMP file…
This is how MWG expects a hierarchy to be defined and, in addition to that, each of the keywords mentioned in any of the hierarchies listed here needs to be written to the xmp-dc:subject tag…
<dc:subject>
<rdf:Bag>
<rdf:li>Fruit</rdf:li>
<rdf:li>Orange</rdf:li>
<rdf:li>Satsuma</rdf:li>
</rdf:Bag>
</dc:subject>
Of course, Adobe don’t use the mwg-kw:Keywords tag, preferring instead their own xmp-lr:hierarchicalSubject tag instead of the mwg-kw:Hierarchy structure.
And this is where we find that various different apps have decided to interpret this structure in different ways.
Take the example of only wanting to record the Satsuma part of the hierarchy Fruit|Orange|Satsuma.
Instead of replicating the full hierarchy that would be found in the mwg-kw:Hierarchy structure, some are happy to just write…
<dc:subject>
<rdf:Bag>
<rdf:li>Fruit</rdf:li>
<rdf:li>Orange</rdf:li>
<rdf:li>Satsuma</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Fruit|Orange|Satsuma</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
And I have even seen some who write only…
<dc:subject>
<rdf:Bag>
<rdf:li>Satsuma</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Fruit|Orange|Satsuma</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
The problem with these partial records is that they severely limit searching.
The easiest way to search for single keywords is to look in the xmp-dc:subject tag. If all the levels of a xmp-lr:hierarchicalSubject tag are written there, it makes it very simple to have a flexible search that can search for the hierarchical keyword Fruit|Orange|Satsuma by just specifying Fruit AND Orange AND Satsuma.
On the other hand, if we want to search for all images that contain Orange, regardless of whether it is in a hierarchy or not, the last short form precludes that, unless you deconstruct the hierarchical subject.
The not-so-short form does include Orange in the subject tag, but doesn’t include its hierarchical context in relation to Fruit unless we, once again, deconstruct the hierarchical subject.
I always write out the full hierarchy for all levels of any keywords mentioned as well as including them in the subject tag. That way, I have not yet found an app that cannot reliably read the XMP files my app generates. What is more, I can search for any combination of keywords, simply, with either AND or OR predicates.
Unfortunately, because PL5 uses the hierarchical definition of a keyword for searching, it can only find files that contain exactly Fruit|Orange and not those that contain other variations like Enterprise|Telecommunication|Orange, Colour|Orange or just Orange and, at present, it cannot combine search keywords with anything other than an AND predicate.
We can but hope this will change soon.
1 Like
Returning to the original theme of this thread, I’ve checked what Lightroom’s new masks can do.
Find one result here: