Automatically Loading/Saving sidecar ? We need your opinion!


#21

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.


#22

@Asser, Should Photolab, Lightroom and the other RAW developers then contain options to remove the product specific develop settings from a XMP sidecar?

Oliver


#23

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.


(Platypus) #24

…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…


#25

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.


#26

so where do you suggest to store such data?


(Platypus) #27

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?


(Stefan Goldkuhle) #28

I think, the original RAW file must always kept clean to be compatible to other applications and in case of a complete reset.


#29

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.


(Melbourne, Australia) #30

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


(Melbourne, Australia) #31

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


(Pathal) #32

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.


#33

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


#34

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.


(Marc) #35

Hi @fdeitos
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 :grinning:


#36

@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.


(fdeitos) #37

@markinho.fr => 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. :slight_smile:


(Sigi) #38

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)


(Sigi) #39

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.