I did not read every single answer here but there is one important aspect: Please save also changes to XMP files, like rating for example!
2 Likes
From my position - if XMP support is ever added to PhotoLab then the creation of XMP files alongside my photos must absolutely be optional, and PhotoLab should never insist that I must “use XMP files, like it or not”.
I do not want or need any XMP files cluttering up my image folders. I am one of the many users of the fully-fledged, mature and standards-compliant IMatch DAM software, and IMatch is able to manage my thousands of images perfectly well, while allowing me the choice of whether or not to use XMP files for my metadata. (And I choose not to use them.)
I do know how XMP files (should) work, and I know that - in theory - any metadata that is properly inserted into an XMP file by one piece of software (for example by PhotoLab) need not (and should not) interfere with data already inside that XMP file that was written to it by other software. So yes - in theory - the metadata inside a (hypothetical) PhotoLab XMP file should never cause confusion or conflict with any other image editing program … but nevertheless, my main concern is that I should be able simply to say “No” to the use or even the creation of XMP files on my system.
Colin P.
One thing that I don’t understand is can XMP files from more than one DAM co-exist? In large part Colin thinks in they they should. If not it must be an option as many of us use DAM’s already that anything done in OP is most unlikely to make it worth replacing. If its not an option it could come down to staying with OP or the DAM and especially if images from more that one processes are used e.g. from cameras not supported by OP will OP start supporting cameras/raw files not currently supported?
Hello John,
I suggest that you could look at your (perfectly good) question another way. You could ask the question “can more than one DAM co-operate OK while using the same XMP file for a particular image”.
The question must be asked this way because - for any particular image file, for example “P1000156.JPG” - there can only be one single XMP file in the same folder, and that XMP filename must be “P1000156.XMP” (or in Windows it could be the lower-case version “p1000156.xmp”).
There are agreed standards for the use of XMP files which (if the XMP standards are adhered to) can ensure that multiple software programs such as PhotoLab and a DAM program together can both write and read whatever information (“metadata”) they need to, on the same XMP file, safely and without damaging each others’ metadata.
And of course it’s also possible for different programs to share and to modify or update the same types of metadata in the same XMP file. Keywords are a good example of this shared metadata.
It would then be obvious that for shared data such as keywords, the different programs would need to agree 100% on every detail of how they write and read this metadata in the single XMP file … and - as long as the programs agree on such details, then everything in the garden can be rosy and trouble-free. With such agreement, our metadata should never become corrupted, or confused, or be modified in ways that we didn’t expect.
(This topic of using XMP files for metadata is wide and deep and complex and has been discussed in Forums for years … which is why I worry about how thoroughly the PhotoLab developers would be able to ‘honour’ the XMP standards (if they choose to add XMP support) and guarantee PhotoLab’s 100% cooperation with every other program that might use the same XMP files.)
And - just to repeat my own preference here: Even if PhotoLab implemented XMP support 100% perfectly, it would still be hugely important for me to be able to tell PhotoLab “I do not want to use XMP files at all on my system”.
Colin P.
1 Like
I think there may be a couple of editors out there that employ their own .xmp type files. But it seems that those folks used existing files to read when opening the file for editing, but don’t write back to it. Instead, they write their own sidecar. I like the sidecars for a couple of reasons, but if they are not there, I don’t panic. I do like that if using one editor, you can keep track of certain things such as renaming, number of virtual copies. But those are not things that are being discussed. I would just as soon keep them, but if you, like myself, hand-off images from one editor to another and then back (or not), I don’t think the sidecar will be of much use past the first transfer. I think that if you hand an LR image to PL or to Luminar, you are given the chance to send the changes to the receiving editor. I figure that the sidecar is handy for that. How far down the line it can go, I have no idea. Someone spoke of clutter. Depending on how you view your file structure, many folks, including myself rarely see the sidecars. They are just hidden. Out of sight, out of mind. That’s all the ramblings I have. Cheers!
I think i am in favor of separate sidecars for image/editor related stuff and properties as tagging/keywords/rating/grouplinking/ exif data as shutterspeed and F-number and such.
If i send stuff forward and backwards it’s a Tiff to dxo NIK, and back for jpeg processing.
one way export is a group of Tiff’s to stack-application or a Tiff to a pixel editor which has there own export.
So i like to keep editor info of the rawfile at the source and main editor . namely DxO PL.
So my XMP sidecar can live side by side with the DOP-file from DxO.
It’s has to be only a carrier for my added keywords ,static exifdata and such.
Thus if DxO can used for input keywords and such and create such a XMP of this when export.
it will be fine.
ill just wait what they cook up.
Good evening everyone,
Sorry for the late response to this thread but I only saw it when I received the latest forum summary by e-mail. I do not know where this thread is because I do not find it by the normal way.
I have been using Optics Pro / Photolab since version 3 in 2012 Since that time the content and even the format of the sidecars has changed many times, creating incompatibilities between major version. Yes, I’m aware that it was possible to migrate sidecars but only at the expense of a reprocessing of all photos For this reason I kept all the successive versions of the software, but in pure loss since, finally, older 32 bits versions are no longer supported by the actual OS’s. On the other hand, for reasons of stability and participation in beta tests, I had to delete the database frequently.
Finally these files sidecars, although essential to my practice, offer interest only during a relatively short period of time. After that, if I want to rework an old photo to take advantage of recent improvements in the software, I have no choice but to start from a blank page.
Personally I do not see too much interest to dissociate the reading and writing of these sidecars files. I can understand, however, that others users may take advantage of this possibility for some reason. I do not see why these options should be grouped together. Once we understand how the software behaves when working on multiple PCs, we can manage conflicts in the proper way.
Best regards,
Henri-Luc
1 Like
If anything PL should read and write .xmp sidecar files for IPTC extensions, Dublin and Darwin Core et al. as it’s the standard.
PL could without problem continue to use it’s own sidecar files .dop for editing and settings sharing.
That way PL would continue with it’s editing sharing as well as inter/co-operate with the DAMs and other DAMs with PL.
1 Like
All I will add, is that if any changes starts to create sidecars automatically for me, with no ability to stop them generated - I will stop using the program. There is no question of that for me. My folders, littered with sidecar files when I browse manually, or use my most critical app Photomechanic drives me crazy, absolutely crazy. Photomechanic can write metadata straight to the raw file, and in all the years I’ve used it (since 2003) I’ve not had a single problem, despite a few alarmists on the internet.
So please, let us individually decide on what the software does for us and how, and give more customizability, and never less. 
1 Like
PhotoLab should really update Bridge style XMP file ratings as well as the DOP files as it’s confusing when any ratings changes don’t show up in other applications.
I’d love to have an option to not use the database at all and only sidecar files. That would mean there could never be a conflict (unless via manual merge). That’s the whole point of the PhotoLab separate from DAM. Images and folders are portable between computers, drives and laptops.
I believe if I’d understood how hot to trot the DxO developers are to move to a non-portable rigid database system like Adobe Lightroom, I would have chosen to look for other software or just stayed with Iridient Developer, despite its limitation in terms automated tools (SmartLighting, ClearView, Horizon, Viewpoint, Autocrop) and in terms of noise reduction.
Portability and an absence of sync related conflicts was what I seek in photo software. Based on its surface behaviour, I thought PhotoLab respected those values. I see the database is already creating lots of space for conflicts and ignored information.
So far it only affects me for instance if I perchance regrade a photo from 4 or 5 star to 3 star or vice versa. That change in evaluation is not reflected in any of my other software, whether FastRawViewer or Capture One or Lightroom. Rating information should be updated in the XMP should be updated and not just hidden in the DOP.
DOP vs XMP. XMP should be used for commonly agreed XMP functionality (keywords, ratings) while the DOP should be used for development settings. Older DOP should be readable by future versions of the software.
2 Likes
Yes, that would work well for me too - - and, would save me having to regularly delete the database file.
John M
4 Likes
My backup flow is a mixture of desk drive, server to son’s server and USB drives (for when away form home). Using SSD drive locally I don’t have the space for all my data, kept by year. So the DxO data base is really irrelevant as I am dependent on dop files if I switch drives for recovery (so far not needed) access to data not on the local SSD, needed often. The only use I see the data base having is for any one creating projects, which I don’t do in PL. This is the advantage of Photo Supreme foe DAM I can switch between my full backup drives depending where I am.
1 Like
Exactly, can’t say that often enough!
You shouldn’t put proprietary information in XMP (or image) files, although LR does.
Standardized information (rating etc.) shall be written there, conforming to MWG guidance and IPTC Core Spec (in a sensible way). But this can/shall be done with a DAM, not with a raw developer.
3 Likes