I think nobody eats up your meal, only because he sits next to you on the same table. Metadata is everything that is not core data. Development settings are product and image specific metadata. Nobody needs more than one sidecar.
@Asser, Should Photolab, Lightroom and the other RAW developers then contain options to remove the product specific develop settings from a XMP sidecar?
Oliver
No, why? They do not hurt anybody or each other. PL should not touch LR development setting tags, and vice versa. I have many LR development tags in my XMPs, although I do not use LR anymore.
1 Like
…no-one actually wants sidecars but it is the current state of things, along with the fact that different sidecar file formats exist that are not really interoperable…
I need sidecars, because I want my metadata to lie outside of a company specific database in a human readable and convertable format, like XML. XMP and the existance of the ExifTool ensure that my metadata will survive the lifecycle of every product specific database.
I would not even bother to enter a single metadata information into a database, which cannot store this metadata into XMP. It is like putting your valuable things into a tresor, without having a key for it.
1 Like
so where do you suggest to store such data?
Sidecars are a kludge that enables to store metadata close to the image file.
Would it not be preferable to incorporate metadata in the file itself?
I think, the original RAW file must always kept clean to be compatible to other applications and in case of a complete reset.
2 Likes
In principle, applications should be able to cope with embedded metadata,and many do.
DxO Photolab for example has no problem with it.
But I’ve read about programs that bitch as soon as the RAW file is changed.
So it depends on how bold you are.
Hi Fabrizio - - I’m echoing @Tilmann here by assuring you that I’m not at all “angry” with you, or with your team.
In fact, I have nothing but respect for the excellent work you are doing in the on-going development of the best RAW processor out there (ie. PhotoLab). Even if some of it is of no interest to me (case in point: the DAM additions), I do understand why you are adding these features to PL.
However, I did promise you (in my response to your earlier post about the “balanced load of tasks” that you are working on) that I would persist in reminding you about the list of long-standing, outstanding requests that many of us have voted for … particularly because I reckon a lot of user frustration (such as we saw in comments made about content of the major v2.0 upgrade) is directly related to these long-standing, outstanding requests not being delivered.
Yes, that helps a great deal: with this background we can see the purpose of Fabrizio’s request for feedback - - and we can understand that it’s not simply a frivolous whim. … Thank you, Nicolas.
Regards, John M
Ahhh - - I have seen that happen - - Now I understand why it occurs (and your dilemma).
OK, gotcha ! … On this understanding, I’d be happy to change my vote …
My reasons for preferring to keep the 2 options are minor. I’d be happy to give-up that flexibility if it meant that this issue could be addressed at “cheapest cost” - - and, thereby, free-up resources for attention to outstanding user requests.
Perhaps others may now see this in similar light (?)
Regards, John M
Hi @platypus,
For me yes.
Since years, I add IPTC informations like keywords, title, … directly into raw metadata, thru NIKON View NX or Aperture, and I have then all my raws tagged without any issue at all.
Till you don’t modify exif data, I don‘t see any issue on this.
And especially with DxO I can then generate very easily jpeg or tiff with all these informations perfectly taken bu LR, Aperture, Photoshop Elements, Photo, Affinity, …
So very simple, no xmp to manage which can be non compatible with other software xmp.
Keep in mind that “unwanted virtual copies” happen even if you set both options, see my detailed posting above about the difference of local and network/external storage.
I can’t wait to read a statement on this by DxO staff, because I do not understand completely yet.
Oliver
Nicolas,
why isn’t it possible to assign a GUID / UUID to each virtual copy at time of creation and synchronize based on these GUIDs? The virtual copies of old sidecars could get a GUID through a sidecar conversion step. Using GUIDs would resolve other virtual copy issues, like the ones that occure after renaming files with sidecars. Primary keys for all relevant entities is a base requirement for a functioning DAM.
Hi @CaptainPO
Can I suggest that you make a sticky post with this kind of informations… “Actual state of development”.
This way you only have to write it one time, and update it, and if someone can not see it it is easy to point there 
@platypus: Sidecars are a kludge that enables to store metadata close to the image file.
Would it not be preferable to incorporate metadata in the file itself?
Clearly and strictly NO. Never touch my RAW files.
Sidecars are the perfect solution that keeps all settings close to the image file while providing full control at OS level.
If anyone at DxO is thinking about putting metadata or processing information into the Raw files, it’s mandatory to make this configurable.
3 Likes
@m-photo => we’re thinking on how we could have this information available in a more “easy to access” way.
But indeed, that would be a nice addition to our communication and avoid lot of frustrations that have no reasons to be. 
1 Like
I use Media Pro as a DAM and have what they call “exported” my tags into the raw file. It works perfectly and was never a problem with DXO for all those years. But I agree it should be configurable.
If by “use” you mean that I go in and check the boxes depending on the job at hand, I say NO I do not use it. They stay checked on both accounts. I wondered the first time is saw the option, I wondered why it was there. Sidecars don’t take any space to speak of, and why would someone need to tinker with it at all. If you feel the need to not include it in your arsenal, then you can certainly remove it at any time. I hope that made some sort of sense.
There is one reason: if you don’t want to overwrite/update Dopfiles by accident.and want to protect current settings. Then you uncheck auto update. But it’s all or nothing in this preference.
So a more selective way of protection would be better.
Just tested it:
change a image and no sidecar is made , you have to go to File, Sidecars and then export to create one. (so if disciplined you can relay on the DB wile editing images and if done all select all and manual select “export” to update/create a DOP-file.)