jimmyv
(James W Vincent (OM-1, EM-1.3, PL7, FRV, W10, MacBook Air M1)
1
When travelling, I cull and process my best images on my MacBook Air adding keywords to the images. When I get home, I transfer all my RAW files plus the .dop files to my W10 deskside, select additional images of interest, and reprocess all the images.
Unfortunately, the keywords don’t come across in the .dop files so I have to reenter them, which is a lot of work as I may have to cross reference what I did on the MacBook.
Is there a way to transfer the keywords along with the .dop files for those images I’ve already added them to from the MacBook to the W10 system?
Yes. You need to use XMP sidecar files for metadata, alongside the DOP files, so that when you export the metadata, it will be read from the XMP files on the other machine.
as shown I will refer to this as (AS=ON) in the following post, if de-selected/not selected I will refer to that as (AS=OFF).
Regardless of that setting DxPL will store the metadata in the DOP so it should all be there providing there are no issues with reading metadata from a Mac DOP on a PC!?
But if that setting is not selected (AS=OFF) on the Laptop then no metadata will be written to the image, i.e. to the xmp sidecar file so there will be no xmp sidecar with keywords to transfer to the W10 system.
However, if that setting is selected (AS=ON) on the Desktop machine then the DOP will be used for only the edit data on first discovery on the W10 system but the metadata will be expected to come from any xmp sidecar files which may or may not (not by your description of the problem) exist.
Unfortunately the absence on any metadata on that initial discovery import will cause DxPL(W10) to update the DOP and the metadata that was carried over in the DOP will be overwritten, i.e. lost on the W10 machine (I just tested that expecting to be able to recover the data and found it was gone)!!
Basically when DxPL imports from the DOP when expecting metadata to come from the xmp sidecar file (AS=ON) it will decide there is no metadata and updates the DOP to reflect that fact, i.e. the metadata has gone from the imported DOPs completely at that point.
Another problem now rears its ugly head, the imported images are now known to the W10 system so any changes made attempting to re-import ‘images + DOP + xmp sidecar’( could easily cause the dreaded “Unwanted Virtual Copies” but just importing xmp sidecars should work.
So go back to the laptop and force the creation of the xmp sidecar files from the database using
which will create xmp sidecar files.
Now add just the xmp sidecar files to the data already on the W10 system. This will either cause an automatic import if (AS=ON) or DXPL can be forced to read that data using
I just tested this on my W10 system, with DxPL running but not with the new directory (my equivalent to the W10 system) selected and it worked as soon as I moved to the new directory in DxPL without any need to import but that might have been because the xmp sidecar files were made after I had imported on the test directory.
My tests were carried out on a PC using two separate directories
My assumption is that you are working between two DxPL systems, i.e. there is no keywords etc. being created/added by another product.
Please discuss here what you intend to do, either set AS(ON) on both systems, or (AS=OFF) on both system but don’t mix and match!
AS(ON):-:- The metadata will be written to xmp sidecar files as well as the DOP for RAWs (and to the image and DOPs for JPGs etc.), and will be imported automatically from xmp sidecar files etc.
AS(OFF):- The metadata will always be written to the DOP for either choice of the option and will be taken from the DOP with (AS=OFF) but only on first discovery thereafter it will be expected from sidecar files but will not be imported automatically from image metadata, the manual ‘Read from image’ and ‘Write to image’ commands must be used.
jimmyv
(James W Vincent (OM-1, EM-1.3, PL7, FRV, W10, MacBook Air M1)
4
Bryan:
Thank you for your quick and through response.
I do my culling with FastRAW Viewer. It is much faster for parsing 1000’s of RAW files and selecting those I want to work with/on.
(When I take bursts of photos of birds in flight, I’m shooting at 25fps and typically want only none, one, or two files of any burst).
I then copy those I’ve selected to another folder on the MacBook.
I open that folder in PhotoLab 7 and process them.
When I get home, I copy those RAW files and the associated .dop files to my W10 system.
When I open them in PhotoLab 7 on the W10 system, the edits done on the MacBook are applied to the images on the W10 system.
I didn’t know about the preferences settings for Metadata and mine were both “Off” on both systems.
When I went to turn the “Synchronize metadata” on, PhotoLab issued a warning which I don’t totally understand, so, I’ve not changed the settings yet.
I see you’ve written instruction on how to update the .dop files (on the MacBook in this case) and force a read of them to update the W10 system.
Before I proceed with that, can you explain the warning about the “Synchronize Metadata”?
Do I need both functions “ON”?
I will set both systems the same.
Thanks for your help.
Jim Vincent
jimmyv
(James W Vincent (OM-1, EM-1.3, PL7, FRV, W10, MacBook Air M1)
5
Thanks. Bryan has explained my issue and how to do it.
@jimmyv The warning is because there is never any guarantee that data will be passed back and for between different programs without the possibility that a change won’t be detected and data won’t be imported or conversely changes will be made on two systems (that will result data being read and overwriting data which is nearly ready to be sent.
Basically just accept the issue and use it if that suits but I need to look in more detail at your response and I am about to watch a film on TV so that will have to wait, sorry!
jimmyv
(James W Vincent (OM-1, EM-1.3, PL7, FRV, W10, MacBook Air M1)
7
Ok, thanks. I’ve tried it both ways and the keywords pass just fine.
I tried one file with both the “Synchronize Metadata” and “Write Keyword” options set “ON” on both systems; and, using another (new) photo with both set to “OFF” on both systems. Again the keyword assigned in PhotoLab on the MacBook came up when the W10 copy of PhotoLab read the image for the first time.
I also tried updating my existing photos by forcing the XMP creation for some older files on the MacBook then reading them on the W10 system and that worked.
Don’t know what I did wrong when I was processing files from my recent trip that the keywords didn’t come through, but, it appears the process is working as it should now.
@jimmyv I am glad it appears to be working. While watching the TV I was thinking that with (AS=OFF) on both systems it should have worked but didn’t!!??
With respect to FRV, it writes metadata when it is changed (Auto write) and that consists of ‘Rating’, ‘Orientation’, ‘Colour Label’ and
but there is no (Auto read), it has to be prompted to ‘Read’ that meta data back into FRV.
I had to configure a number of things with FRV to avoid metadata being put into an xmp sidecar for JPG images and configure colour labels as follows because DxPL does not provide a customisation feature for ‘Colour Labels’.
If you are concerned about running both systems with (AS=ON) then you could use (AS=OFF) but use the metadata write commands to force the metadata out of the database and into the image (xmp embedded or sidecar) and also to read it in as and when required.
Typically I run with (AS=ON) most of the time and DxPL is better at detecting changes automatically than many posts in this forum seem to imply? I still don’t know why your original attempts failed and that niggles a bit.
Hope things progress without further hiccups.
If you want to check that things are being written successfully then the front of the DOP should contain
For reasons of being in charge and controlling what gets read or written, I set import/export/autosync of DOP and XMP files to off and transfer metadata with the respective file menu items.
It’s good practice to use (exactly) one app to manage metadata and restrict all other apps to read-only. Unfortunately, PhotoLab does not provide separate preference settings for reading and writing to XMP.
While I understand your rationale for putting the reading and writing of the DOPs in your hands I fail to see the worth of that particular exercise!
Unless you can be sure that nothing untoward has happened or that nothing untoward will happen when you issue the command to write the DOP what is the point in exerting manual control over the operation (see below for a reason)?
It does ensure that all the DOPs have been written, just in case DxPL ignores some (unlikely but not impossible) so I would probably continue with my auto-read and auto-write and possibly add a Ctrl A to all images and a DOP ‘Export’, just prior to moving from a directory.
While delaying auto-read stops DxPL from taking a “rogue” DOP and corrupting the database with it, how do you know whether the DOP is good, bad or indifferent.
So I understand your caution but fail to see that you can actually determine when it is a safe time to read or write the DOP manually?
Arguably manual read protects the database from the DOP and manual write protects the DOP from the database, but when can you be sure that they need protecting or that your manual action won’t do the very thing that you were attempting to avoid with the automatic read/write settings?
The much respected FRV, which has very limited metadata scope, automatically writes but manually reads and that is not optional.
It has been a long time since I looked at LT and C1 (Capture One) but I have never been entirely happy with what I got from the C1 metadata settings in particular.
You know that I agree that DxPL could do a lot better and for very little DxO development work, we have both been banging our heads against that particular issue for some time
and I positively detest the way that the DOP handling was attached to the (AS=OFF) setting. Overloading a command/option like that is a recipe for disaster.
(AS=Off) should mean just that and a command should have been added to the ‘Metadata’ commands’ to provide ‘Import from DOP’.
However, that could then have suffered the same fate as the metadata in my test when with (AS=ON) and no metadata present in the image (embedded or sidecar) then the database contained no keywords and a DOP write was automatically initiated which overwrote a DOP with keywords with a DOP without.
At last I have found a scenario where I can agree with your (ADW=OFF) (Auto DOP Write) strategy.
jimmyv
(James W Vincent (OM-1, EM-1.3, PL7, FRV, W10, MacBook Air M1)
11
Bryan & Platypus:
Thanks for your comments.
Since the DOP seems to carry the Keyword data from my MacBook to my W10 instances of PhotoLab, I’m going to continue to use the “OFF” setting.
I mainly just use FRV for culling and use it’s “Copy selected to directory” right mouse action to copy the images I want to process to a ‘selected’ directory. If I think I’ll be taking another pass at culling the RAWs, I’ll flag all the selected images as ‘***’ to keep from wasting time re-evaluating those. This causes FRV to create an XMP file that PhotoLab will read. That gave me the idea I might be able to add Keywords during the culling process (since I am often verifying the species of birds then anyway). Unfortunately, while FRV does allow you to fill in the ITPC Title & Description and these will also transfer to PhotoLab via the XMP file, it doesn’t allow you to enter a Keywords field.
I suppose I could put the “Keyword” into the Title or Description then run a script to read the XMP and move it to the Keyword field …
Anyway, I now believe the issue that started this thread was a problem of my own creation (not sure what) and not an issue with the application. Thanks for your help.
However, you then need to be able to get the data out of those fields and into the keyword data!
Why do you use FRV, I originally bought it to help determine the best images from a burst of images using the sharpness review? However, you could consider using XnViewMP as an alternative for doing keywording as you go, you may or may not like its interface but it may avoid having to implement a script.
What “scripting” were you proposing?
jimmyv
(James W Vincent (OM-1, EM-1.3, PL7, FRV, W10, MacBook Air M1)
13
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:
Sharp
Properly Exposed
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).
jimmyv
(James W Vincent (OM-1, EM-1.3, PL7, FRV, W10, MacBook Air M1)
14
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.
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.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
15
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?
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!
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?
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
and now all you can do is have a coffee while the foreground indexing task grinds on and on and on and !
jimmyv
(James W Vincent (OM-1, EM-1.3, PL7, FRV, W10, MacBook Air M1)
20
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!
