Transferring Keywords from Mac to Windows

I use FRV to be able to cull the few images I will want to postprocess in PhotoLab 7 from the 1000’s I take. It allows me to quickly review the images to see that they are:

  1. Sharp
  2. Properly Exposed
  3. An interesting composition
    It does not require “ingesting” or other pre-processing steps like Photo Mechanic and it costs a lot less. PM would allow entering the keywords and other info, but it’s preprocessing puts me off.

Yes, you have shown (as I noted previously) that I could enter “Description” info in FRV and it will display in PhotoLab. I may start doing that, as I can just “Copy/Paste” from the Description field to the Keyword field. (Can’t use the Title field because PhotoLab populates all photos with the same Title if you enter it in one).

It’s been many years since I did any programming, but I think a simple Perl script could read the xmp file, and add the Keyword tag copying the text from the Description (or just replace the Description tag with a Keyword flag).

No Programming Required. Just a little time figuring out how to work with EXIFtool.

FRV will output an XMP file which may contain the Description.
While PL will display this, and, you could copy/paste it from Description to Keyword, I’ve managed to come up with a way to eliminate the need to copy/paste.

Just execute this command in the directory your XMP files are.

    exiftool -subject<$Description -ext xmp -overwrite_original .

It turns out PL loads the contents of the “subject” tag into keywords (I tried the keywords tag in the xmp and that didn’t work). This command will look only at the xmp files in the directory and it will load the contents of the “Description” tag field into the “Subject” tag field for all xmp files in the directory (the ‘.’ tells it to do this for all files in the folder).

The -overwrite_original just keeps exiftool from creating a back-up copy of your xmp

This will be very helpful for me since while culling, I’ll add the text I want in Keyword in PL to the Description in FRV, run this command, then open the selected files in PL. When I process the images in PL it will pass this keyword info to the DOP file so on transferring this from the MacBook to the W10 system the keyword will come along for the ride and I don’t have to add it a second (or third) time.

There is another thing hardly mentioned here and that is the need for synching the keyword lists. In Photolab unlike Photolab and Capture One there is no way what I know either to export or import the whole keyword lists from a Photolab installation.

In many cases out there organisations and business branches use standardized “vocabularies” of keywords. Both Capture One and PhotoMechanic can both export and import flat and structured keyword lists in TAB-separated text format. Photolab can´t and that is one indicator of how immature Photolab is. Photolab is really not a good member of the XMP-world in that respect.

It is easy to migrate to Photolab if you are OK with letting an initial indexing av all your images taking place vid using the “Index a folder”-function IF you have all your images organized under one common topfolder. That will automatically build a new keyword list from the used keywords in the XMP-data of the images regardless how they are organized downstream BUT it is totally impossible to import an externally produced TAB-separated keyword list from what I know or to export a list like that if you want to migrate.

So Photolab ImageLibrary isn´t really meeting the demands that we might have to put on it when we need to migrate one day and this day have already happened once to me when my old computer was totally demolished by my movers last year and I was forced to migrate manually

While this might be a workaround for single keywords, I see no way that it will handle hierarchical keywords properly. Imo, tags are best used for what they were intended in order to avoid workarounds. This would mean that FRV can be used for ratings, title, description and possibly colour labels, but not for keywords. Maybe that libraw llc could be asked to add keyword management to FRV?

@jimmyv I am glad you have found a workaround.

@platypus The FRV author is amenable to making amendments, he kindly put the 'Reload File(s) command here when I requested it

But given the amount of effort DxO had to put in to add keywording and the reception it got from the users can you imagine undertaking such a task!

@Stenis you are right about the lack of synchronisation but if all you require is a simple keywording application then DxPL meets that requirement, except that DxO then vandalised the product and removed the asynchronous indexing capability on a design whim that went nowhere!

@jimmyv I wrote this but never posted it (until now)

Check out XnViewMP just in case it suits. or can be usefully pressed into service.

I am currently trying to teach myself Python again, having I started programming in Python about a year ago and abandoned it in favour of testing PhotoLab but recently returned to develop a WatchDog program (built around a sample WatchDog program) to see what programs do when they are changing metadata, e.g FRV versus PM versus XnViewMP versus DxPL versus etc…in particular.

The following sample bit of xmp sidecar file shows both DxPL inserted keywords and FRV inserted the Title and (misspelled) Description!

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Golf Course</rdf:li>
               <rdf:li>Walk</rdf:li>
            </rdf:Bag>
         </dc:subject>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">Walk, Worthing Golf course, Autumn Colour, Sunny Day </rdf:li>
            </rdf:Alt>
         </dc:title>
         <dc:description>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">Descirption from FRV</rdf:li>
            </rdf:Alt>
         </dc:description>

So I hacked the xmp sidecar file and modified it to

         <dc:description>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">Descirption from FRV</rdf:li>
            </rdf:Alt>
         </dc:description>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">Walk, Worthing Golf course, Autumn Colour, Sunny Day</rdf:li>
            </rdf:Alt>
         </dc:title>
         <dc:subject>
            <rdf:Bag>
               <rdf:li>Autumn Colour</rdf:li>
               <rdf:li>Golf Course</rdf:li>
               <rdf:li>Sunny Day</rdf:li>
               <rdf:li>Walk</rdf:li>
               <rdf:li>Worthing Golf Course</rdf:li>
            </rdf:Bag>
         </dc:subject>

i.e. once the ‘Title’ has been located the elements can be unpacked and simple keyword entries created after the ‘Title’ entries so the file can be read line by line and transcribed to a new file without any need to go back and insert the keywords section earlier in the file

DxPL was perfectly happy with the re-arranged xmp sidecar file albeit the xmp sidecar I started with already had both simple and structured (hierarchical) keywords put there by DxPL, given that might happen in practice then any script might need to be able to handle the fact that some keywords already exist and add to that list.

This xmp sidecar file was put together with basic editing just to ensure it would work, as I expected it would, and it seems O.K. but having discovered the xmp sidecar file complete with duplicate and hierarchical keywords in the simple keyword list I needed to get DxPL to ‘Write to image’ for it to update the xmp sidecar file.

So a script that can parse can easily handle hierarchical keywords by not bothering to “handle” them at all!

This hacking of the xmp sidecar file can only handle RAWs while I suspect that your ‘exiftool’ method could work for RGB (JPG etc.) files as well as RAW?

Please elaborate. What do you mean exactly? What was removed?

@platypus

Once upon a time you did this to index as little or as much as you wanted indexed

that is PL6.11, PL6.12 is currently downloading.

When the folder is selected then indexing starts but you are free to make a coffee and edit or not while indexing continues in the background.

During PL7 Beta development DxO seemed to have had a cunning plan which essentially went nowhere, i.e. no real development (except a ‘Delete Directory’ command on Win 10) but they moved the command to here

image

and now all you can do is have a coffee while the foreground indexing task grinds on and on and on and !

exiftool works with all image files, so yes if you change the -ext xmp to -ext jpg it would copy whatever is in the description field to the subject field. If you left the -ext option out it would work on all image files, including the ORF - which I never want to modify a RAW file!

On Mac, can have DPL index the complete archive while I can still edit away happily with my images. The progress bar makes its journey too, bouncing from lft to right and back until finished.

As long as all images have their metadata in themselves or sidecars, all keywords will be imported. Boring…but another workaround.

1 Like

This indexing is not bad at all if you have a reasonably fast computer. After all, I have just made it once in 1 1/2 year. Is that anything to lay sleepless over?? After all, this is not anything you do frequently if you don´t mess up your index by being unthoughtful or careless.

@platypus we do get this on PL6
image
but just a blue line sliding across and across and across the screen continuously giving no indication of progress whatsoever.

But all that vanished on PL7 so they effectively destroyed the one feature that would have made DxPL useful as a search engine, unless you set it running late at night and see how it is doing the following day, except that there isn’t really anyway of knowing how much has been done or how much is left!?

There never was an indication of progress but at least editing was possible at the same time but not anymore. A few of us complained profusely as soon as we saw what had happened but DxO never responded, never explained what the original aim was and we are left with a much less useful feature.

@Stenis the destruction of the original feature was “wanton vandalism” and/or the worst example of software mis-engineering I have seen in years.

You may only index infrequently but I prefer to do it as I go and not have to wait for the operation to complete when I didn’t have to wait before.

What I lay “sleepless” over is the question that if software engineers can make such a hash of that what next!

As for the infrequency that depends on how you do your indexing, given that just opening a directory will automatically index that directory anyway.

PS:- you are arguably putting the “blame” on the user who doesn’t have a reasonable fast machine, they didn’t need one before but after this particular “update” they might do now, if they actually use searching at all!?

Bryan, of course it isn´t good at all that the indexing doesn´t have a progress indicator but I seem to be kind of used to it. I realized that even PhotoMechanic lacks one for the indexing when using “Scan to catalog”. It is really hard to figure out even how long time will have to wait despite there is live info about number of “Metadata Updates” and “Image Previews” waiting. There isn´t a progress bar there either.

In fact I have done I huge maintenance job implementing a new two level keyword structure in PhotoMechanic (on a flat keyword structure) by batching the whole database with the top level kewords over and over again with the help of Metadata Templates. The result has taken my system to a whole new level when searching it. So I have reindexed my folder structure both in PhotoMechanic and Photolab - but still I refuse to use structured hierarchic keywords in PhotoMechanic since they are much more inefficient to apply and maintain.

I deleted even the old Photolab-database since I wanted a fresh database without any “orhans” and other obstacles but it might even be the case that it shouldn´t be necessary if Photolab is in “synch”-mode. Normally all changes I use to do in the metadata with PhotoMechanic instantly gets propagated to Photolab.

The real problem here is that DXO is ghosting its users. That is a real problem! After indexing a few times we learn about how long it will take - problem solved. This insn´t something that keeps me awake at night.

@Stenis It doesn’t keep me awake but I ran tests on the Beta Release and saw something that shouldn’t have been there and that DxO then denied.

I believe that the issue came about because someone in DxO had a “cunning plan” which turned out to be far from cunning and not much of a plan if truth be told and destroyed a working feature in the process.

So a working feature that offered asynchronous (background) indexing alongside editing vanished for no good reason, as far as I can tell.

On slower machines indexing may put PhotoLab offline for a considerable period of time while indexing and on faster machines that could cope with both (indexing and editing) with ease, well they can’t because someone re-wrote the code and indexing is now a foreground process!

Seems to be not the case with PhotoLab on macOS.

@platypus I had realised that from your previous response in Transferring Keywords from Mac to Windows - #21 by platypus so I am sorry that I didn’t state that the indexing feature changed from a background task on PL6 to a foreground task on PL7 on Windows but remains a background task on the Mac (I presume that “remains” is correct and DxPL(Mac) didn’t go from foreground to background going from PL6 to PL7!?)

If I remember correctly, it never was a foreground only task, but I’d have to check that for a definitive answer :smirk:

@platypus Thanks for the update. I was more interested in whether we had the ultimate irony that DxPL(Win) lost background indexing at the same time that DxPL(Mac) acquired it!!

Nevertheless, if DxPL(Win) has had the capability for as long as I can remember, DxPL(Mac) has had the capability for as long as you can remember why did DxO consider it acceptable to remove the capability from DxPL(Win)?

Particularly when it was spotted as soon as it was released in Beta testing which was some 6 months + before PL7 was released. No reason for the change was ever given and no attempt to revert was made as far as I can tell, i.e. users are expected to “like it or lump it” as an old English expression goes!

The removal of the Beta Test forum prevents those who have signed the NDA from discussing Beta Test issues, past or present in the special Forum restricted to those who have signed such an agreement as well as “hiding” all the details and issues raised during the various Beta Tests.

What a gagging order that is!

Don’t respond to that last part, I believe you value your involvement with Beta Testing.

1 Like

Look at this @BHAYT and @platypus Platypus

Yesterday I had problems with PhotoMechanic I first couldn´t see any solution for.
I wrote to CameraBits Support on CameraBits Forum “Yesterday** at 03:09:42 PM”

33 minutes later their staff replied “Yesterday** at 03:42:00 PM”

This isn´t the first time I have asked for help and usually they are extremely quick to listen and help. Maybee it is because PhotoMechanic is the industry standard metadata and workflow tool among sport journalist and event photographers. People working under extreme pressure with tight dead lines. Unlike some software companies they don´t charge you for it either. I think they are outstanding together with Hamrich Software that manufactures Vuescan software for scanners. They are truly fantastic in their customer support.

@Stenis What took them so long?

Many of the smaller companies are keen and proud to be able to react quickly, either to bugs or suggestions for new or updated features.

Maybe there was some people before him in the queue to their toilet. :slight_smile: