Yes very similar. My files are renamed on import using the sql date time, they are saved into a day date based folder structure e.g. PhotoLibrary/2021/2021-05-21/2021-05-21-102427-P4527654-Tag1-Tag2-Tag3-TagN-.ORF . The sub seconds are not an issue as I keep the original camera file name, P4527654 and as yet I have never had two cameras using the same original file name on the same day let alone the same second.
I use an application to set and unset tags (a.k.a keywords) and it renames the raw files and any .dop, .xmp or ExposureX6 sidecars. I chose to use dashes as the separator rather than underscore as I read that this is what Google uses and some OS trip up on the underscore character.
DxO PL tolerates external renaming of files except where the files are in a project. It also seems that the database retains records of old file names so I delete the database from time to time. I use an application âFind any Fileâ to search my collection and this allows saved searches. It means that my collection is free of any database applications and can be read on any modern OS. As I said it works for me.
I think this is the key (pardon the pun). The keyword manager is where the battle is won and lost as far as I am concerned. Given the vagaries of keyword storage I think we have to accept that the master has to be a âsmartâ keyword dictionary that transcends any standard, or non-standard, storage of the keywords in image files. The file storage model should be a translation, to or from the dictionary.
In other words, the dictionary is the âtruthâ and the user may have the option to import, via a form of translation, from the files into the dictionary, and then export, again via a translation, to the files. Such import translations may cue off other metadata to know what to expect. This would make the handling of the A|B|C, A|B versus just A|B|C a simple choice of correct/desired translation. Though I admit thereâs a lot more to it than that and actually pulling this off would still be difficult. But translating directly from, say Adobe to PhotoLab styles, and back is the way madness lies.
But⌠the keyword manager shouldnât just stop at showing or searching a tree and allowing clicks or drags. I only work âin the treeâ when I am creating keywords, or occasionally if I am unclear what may already exist. When I am applying keywords it is a keyboard activity. This capability in LrC is what makes it all work for me.
Imagine this aircraft picture is in need of keywords. The first thing I am looking for is the registration, 9V-SQN. I will type 9V and immediately see all of the Singapore registered aircraft I have recorded before. With luck, 9V-SQN will be in the list and either by typing two or three more characters and/or arrowing down, I will pick it from the list, at which point I will get 777-200ER, 777, Boeing, and aircraft come along for the ride.
Next, I know itâs taken at Wellington so NZW is enough to get me close to NZWN. And finally, Sing is close enough to get Singapore Airlines. Something like a dozen keystrokes and/or maybe the odd click gets me my 8 keywords (including the NZWN synonym). Note that during this entire process my brain is thinking about the result and not the structure of my tree. As soon as I have to scroll a tree in search of something or type a search and then pick out of the list with a drag or double-click, it requires more concentration.
If 9V-SQN is not present, it will become apparent quickly, at which point I will take to the tree and add it under 777-200ER, simultaneously adding it to the selected photos. This is another reason the low effort for the already present keywords is a huge benefit, because adding new keywords to the hierarchy often involves research. When Iâm adding keywords to 500+ photos from an air show (a task I make myself do before processing anything), speed matters. As does not burning out from concentrating too hard.
The only time I actually spend a lot of time âin the treeâ is if I am setting up a new hierarchy or, more likely, rearranging an existing one to a new way of thinking (something I do far too often).
For me it comes down to âwhat am I most likely to think of typing?â For the airports, I just use NZWN because itâs shorter than the full name, and therefore quicker to get a unique match on typing. The IATA code is arguably slightly shorter and more likely will match quicker (all New Zealand airportsâ ICAO codes start with NZ) but Iâm just more familiar with the ICAO codes.
For New Zealand/Aotearoa, New Zealand is the lead because thatâs what I grew up calling it. For birds which have common names and MÄori names that I want to include (I donât espouse Latin names) then mostly I use the common name because, again, thatâs what Iâve grown up calling them. An exception might be the TĹŤi which arguably has the common name Parson Bird, but other than seeing it in books I donât think Iâve ever heard anyone call them that. In fact, I donât even have that as a synonym now that I think of it. I probably should for completeness.
Stenis
(Sten-à ke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
23
Oh I am glad that Photo Mechanic Plus can handle that perfectly fine already. When I export from it takes the RAW+ DOP + XMP if there is any. I think I misunderstood since we were talking about hierarchical keywords.
No problem,
itâs about managing keywords, IPTC and Exif which are written in different parts of the file set.
Exif is in rawfile, keywords and IPTC should be written in xmp and STAY there(i mean not imported and altered by a program.). and propertie file type like tiff and jpeg has containers where some/most of the data can be written.
DNG is also a container which can hold all metadata.
hierachical keywords are very difficult to view properly.
every one wants different kind of default view.
some want to see the hole string.
(which can be filling the view alot.)
search for juvenile would show:
human,male,female,juvenile.
search for male:
human,male, adult,juvenile
search for human:
human, female, male,adult,juvenile
but if we are in the folder want we to see all the keywords? or only the different ones?
so only male , female, adult and juvenile? (human is on all images so not a keyword which is selective for that folder.)
The only thing i am certain of is i want to determine which program is hierachic leader. Thatâs the autowriter and all other are autoread but command writers (change has to be confirmed)
so a split in synchronise is preferable.
write and read are two different places in DAM hierachy.
Stenis
(Sten-à ke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
25
Oxidant: There is another parallell discussion about this topic here:
âUngulates are members of the diverse clade Ungulata which primarily consists of large mammals with hooves. These include odd-toed ungulates such as horses, rhinoceroses, and tapirs; and even-toed ungulates such as cattle, pigs, giraffes, camels, sheep, deer, and hippopotamuses.â
Come on - someone had to look it up!
I didnât have to look it up for the initial post but I will admit to confirming my memory before hitting publish.
Deneice
(French photographer | PL5, Film Pack and NIK suite user)
28
The development of a Keywords management software should not be so complicated. All is question of respecting international standard to keep the compliance. The problem is that some editors (DXO is one of them) manage it with their personal recipe and here is where the trouble start.
Regarding what I discovered in this new PL5 version, I already use PL4 and once PL5 installed with the migration of my PL4 settings, I opened a picture, jpeg file keyworded with XNviewMP and DXO PL5 still show me the old keywords that was priorly written instead of the new one. Maybe because I already opened this file in PL4 and maybe because there is still a part of the database that is used to save the metadata keyword instead of the xmp or IPTC embeded file. I have no problem to read this updated file with Adobe product. For sure I tried do empty the cache but nothing changeâŚStill messy âŚ
Strong metadata feature was expected for so long time, Iâm very cooled to upgrade to PL5 for nothing more than already exist in PL4
1 Like
Stenis
(Sten-à ke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
29
Deneice: Have you tried to update metadata in Photolab 5 with File - Metadata - Read? That import use to populate the metadata-fields in PhotoLibrary. If the metadatalist is not updated to your liking try to reindex the folder you are working with or index all your folders by indexing the top-folder of your folder hierarchy.
Do you work with RAW or just JPEG? If you have a RAW and update it outside Photolab so it get it´s sidecar metadata updated it´s metadata should automatically be transferred if you export a JPEG from Photolab. With what tool did you create the JPEG? Maybe you have to look over your workflow?
I think the integration works fine for me now between my external metadata source Photo Mechanic and Photolab but I have to stick to a certain workflow and it comes with a few conditions. For example I don´t use âstructuredâ / hierarchic keywords. For the moment I´m quite pleased despite I would like the update process to more automatic than it is.
Deneice
(French photographer | PL5, Film Pack and NIK suite user)
30
I missed this option that can be automatic on other softwareâŚwith XMP files but not with Jpeg. I tested it also with Exposure X7 and On1 2021 and it failed with them, strange behaviors even with forcing a read option.
So It runs well for DXO even with structured/hierachical keywords !!!
As said Stenis, is that enough to trust in PL5 for managing our metadata ? Letâs give a chance to DXO after waiting so much and complaining about the lack of IPTC support
Thanx Stenis for this help !
Stenis
(Sten-à ke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
31
Deneice, it DOES NOT work with hierarchic keywords in an integration between Photo Mechanic and Photolab PhotoLibrary yet, but itâs fine with the plain list that Photolab builds when we index the images.
Another condition is ONE WAY workflows from the external DAM/metadata maintenance tool to Photolab OR metadata maintenance ONLY in Photolab PhotoLibrary. Only IPTC is supported and visible in Photolab really.
From what I have seen and as I use Photolab it exports the RAW-mastermetadata correctly to XMP with the above conditions when concerning keywords and that goes for JPEG, TIF and DNG-derivates too, for DNG that has been created with cameras supported by Photolab.
BUT there still doesnât seem to be any support for import and export of keyword lists to and from Photolab and that has to be fixed so people can migrate to and from Photolab if they please. Just to migrate the RAW and the XMP-files is not enough. You have to be able to migrate keyword lists too .
Other things necessary in a short term is a possibility in References to configure whether Photolab or an external tool owns the metadata to prevent two way updates. If you use an external tool for your metadata it should be possible to inaktivate the update of IPTC in Photolab and inactivate those fields.
Stenis, it seems to me that if one wants to use multiple applications for metadata itâs essential to avoid hiearchical keywords. In that case, changing title/headline, caption/description and adding a few more keywords shouldnât do any harm.
Your thoughts on touching metadata in PhotoLab 5 if one avoids hierarchical keyword structure?
Stenis
(Sten-à ke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
33
You will always take a risk updating from two directions. From what I can see today the flow works perfectly fine if I append metadata to my 25 elements in Photo Mechanic and then open the images in Photolab 5, edit the images and export them for example in JPEG. If I open that JPEG in PM Plus and compare it, it´s 100% in sync with the master RAW XMP in PM Plus ⌠BUT when I look in the IPTC-elements in PhotoLibrary I can see that the four elements under âIPTC Imageâ which in PM Plus are labelled âLocation Taken and Shownâ and by the way are seven!, are empty there!!! The elements in PM Plus are called: Sublocation, City, State, Country, Country Code, World Region and Location ID. I´m not sure an export of XMP-data to PM Plus with âFile - Metadata - Writeâ would be correct and not just because three of the fields are missing. We also know PM Plus are forking some data to other namespaces and things like that are very tricky to grasp and some metadata consumers like Windows 10 also is using a hidden hierarchy when reading metadata and in that case EXIF is priority and not EXIF namespace in XMP and not IPTC either.
With that said I still appreciate what DXO has done in PhotoLibrary because I still can use the imported keywords from my RAW XMP to search for images to work with in Photolab, but I never touch the metadata in PhotoLibrary in Photolab 5. Maybe some users will find it convenient to edit the metadata in Photolab too but doing so you are on your own because DXO and a lot of third party metadata tool manufactorers are really not in sync yet with their interoperability.
Capture One has some sort of two way sync with Lightroom like Photolab has too but there has been written things about that too. Besides it takes some resources and affect speed it´s still like 1.0. Photolab PhotoLibrary is also 1.0 if we shall be fare. It´s a completely different system in Photolab 5 than in version 4.
DXOâs approach to keywords aside for the moment, based on my experience i am always wary of multiple software programs developed by different companies reading and modifying the same data.
Mark
Stenis
(Sten-à ke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
35
Mark and Alec: Here you have a link to a two way metadata communication setup example between Capture One and Photo Mechanic Plus and a little different but simular discussion afterwords.
Another thing to think about is that a two way flow really complicates the integration (as you can see by this example and you expose yourselves in worst case for a substantially more expensive solution both to develop/configure and maintain. The risks also increases that something gets out of sync after upgrades of one or both your integrated applications.
DxO Photolab is incapable of adding GPS data afaik. Itâs also incapable of comparing two or more images side by side.
And why not using AI like Excire to make keywords easier? One possible answer: In European rivers are neither parrots nor dolphins to be seen when ducks and the tail of a goose merganser are shown in a picture. But still, that alone is a hell of fun, no?
So, for keywords Excire, for GPS Graphic Converter, for image comparison and rating Capture One (which then leads to more funnier âerrorsâ) and for a bit of noise reduction DxO? Yes, the more cooks, the better the foodâŚ
I perfectly understand all DxO users and programmers who are fighting against a DAM in DxO - no single DAM can provide so many flaws, bugs and inconvenient use as all others - okay, maybe Photomechanic can, I just have a solid allergy against lousy user interfaces⌠[/sarcasm]
I just did a set of metadata in PhotoLab 5 and found it fast and easy.
select all the files first to add the general metadata (I donât think there are templates yet but itâs fast as long as you are aiming for main creator fields and event fields).
select individual files to add headline/title and caption/description.
rename output jpegs with Better Finder Rename including dates/time and headline.
This is considerably faster than back and forth between PhotoLab and PhotoMechanic and Better Finder Rename and gives very clean results. I wouldnât be that worried about reopening the set in PhotoMechanic if I had to. It really looks to me that the people who are in trouble are the ones using fancy keyword hierarchies.
Of course everything looks rosy early. Iâll post the issues I do run into as I run into them.
SInce I only manage metadata in PL5 I have had no negative issues at all. However, my requirements may be simpler than other users. As I suggested earlier, maintaining the integrity of a single source of metadata when edited by multiple independently developed applications is always potentially problematic.
Iâm nearing the end of a huge cleanup of my hierarchies. I had used several approaches over the years, going back to my original Lightroom days many years ago, so had a bunch of old-style stuff to clean up (like around 300 aircraft identities that were once standalone and now nest under the correct types).
Once I have the hierarchy in tip-top shape I will write them all to the files with confidence because I donât let any other software write. Do I wish I could do this in PhotoLab? Iâm actually starting to question that notion because having spent a lot of time in Lightroom in the last week or so, and also a little time processing some new photos in PhotoLab it has been really obvious that Lightroom is WAY faster for looking at images. Day to day when I might add a dozen images it wouldnât matter so much, but for any significant event I think Iâd be tearing my hair out.
Iâve said it before⌠the workflow capabilities of Lightroom when it comes to keywords make this possible. Based on all the other software I have tried (including some of my own hacked-together processes) I would probably just give up on this level of detail if I didnât have Lightroom.
Stenis
(Sten-à ke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
40
Well Joakim, if you are looking really hard for the best of the best you might end up with a non communicating mess. Sometimes a boring swedish compromise can be a better solution because it works than state ot the art without any compromises. Thatâs why Iâm fine with two programmes and the reason I settled with Photolab is Prime/Deep Prime. Doing so I donât need PureRaw or Topaz to mess up the work flow, like many others.
In my boring consensus country we even have three main types of milk. Fat milk with 3% fat and light milk for the fat fobic people and of course a true compromise of âmellan mjĂślkâ ( âmiddle milkâ) for the rest of us. You canât go wrong with a compromise lika that can you?
