How to store DxO Optics Pro sidecar files (.dop)

[lnh]

DxO is one of the tools I use for RAW conversion which end up creating sidecar files with a .dop extension. Is there a way to manage these files inside PSU? I was thinking you might be able to create a "version" type for these, but haven't seen anyway of importing them into the catalog. I suppose one strategy would be to always locate the RAW/sidecars using the same folder scheme as the rest of my files (I file by year\month\date taken changing the original filenames upon import) and always work on the files in DxO directly from their catalog stored location so the DxO sidecars just naturally stay in the right place. Any other ideas?

[Hert]

The dop sidecar file is not an image file but a configuration file that DxO stores and it contains, among others, the development settings for the image. Consider it to be the DxO "database" for that particular image. I don't recommend that you use that file extension as a non-image format, but if that's what you want, then do so in the Preferences.

For the next update I'll add the dop extension as a sidecar extension. That way, PSU will always keep the dop file together with the raw file that it belongs to

[Jeff F]

For the next update I'll add the dop extension as a sidecar extension. That way, PSU will always keep the dop file together with the raw file that it belongs to

RawTherapee's sidecar is (.pp3)
If the extension is not already in PSU would it be possible to include while you are adding DxO's?

Thanks

Jeff F

[Hert]

I'll also add that.

For my info; how is the pp3 sidecar file stored? e.g.
when I have a file named IMG0001.CR2

- Will the .pp3 sidecar file be stored in the same folder?
- is the sidecar file named IMG0001.pp3 or IMG0001.CR2.pp3?

Thank you
Hert

[jstartin]

And I have .spd sidecars, which have to remain in a specific sub-folder (\SILKYPIX_DS) of the folder containing the raw file.

Naming for "rawfile.ext" is "rawfile.ext.N.SPD" where "N" is a numeral corresponding to application version number - currently 5, soon to be 6, and I still have 3s and 4s.

[Hert]

Keep in mind that the more sidecar definitions that I create, the slower all file operations become as PSU has to check all the possible raw file/sidecar file combination.
To add a sidecar definition for every possible version of their RAW converter is adding too much overhead. You have 3s, 4s, 5s, 6s, and if added it also needs 2s and 1s in order to be complete. This means 23 RAW extensions * 6 = 138 extra possible combination to check for every single file operation. And then for every new main version that Sikypix releases yet another set needs to be added. That's too much to ask.
Better to ask Silkypix to drop the version number in their sidecar files.

[Jeff F]

For RawTherapee file would be saved as 'IMG0001.CR2.pp3' in the same folder as the raw file.

However I don't want to slow down PSU for everyone. If there is a workaround I'd rather do that.

Thanks,

Jeff F

[jstartin]

Keep in mind that the more sidecar definitions that I create, the slower all file operations become as PSU has to check all the possible raw file/sidecar file combination.

I hardly dare mention it ( ) but a tick list in preferences, so that PSU checks only for what the user decides is relevant (initially defaulting to nothing), might cater for speed and flexibility for the subset of users for whom this is relevant.

[jstartin]

To add a sidecar definition for every possible version of their RAW converter is adding too much overhead. You have 3s, 4s, 5s, 6s, and if added it also needs 2s and 1s in order to be complete. This means 23 RAW extensions * 6 = 138 extra possible combination to check for every single file operation. And then for every new main version that Sikypix releases yet another set needs to be added. That's too much to ask.
Better to ask Silkypix to drop the version number in their sidecar files.

I accept what you say about having the version number in the file name causing an excess of possibilities, but it allows backwards compatibility between Silkypix versions ("output on demand" for a raw file accompanied by an old-version sidecar can be identical to that from the old version, but new-version features and process improvements can also be applied and parameters placed in a separate sidecar). ISL (purveyors of Silkypix) are not going to change it.

Incidentally, to my naive thinking your 23 x 6 possible combinations are not necessary. Surely if we move/delete/rename "filename.abc" where "abc" is a raw extension and have sidecar files "*.scf" we need to check for "filename.scf" and "filename.abc.scf" only. Other raw extensions are not relevant.

[lnh]

Hert,

Many thanks for considering inclusion of .dop sidecars. Sounds like some other folks had good suggestions for how to deal with all the sidecars from various raw converters and not make too much overhead. Would you prefer this be listed in Mantis as a feature request?

I am finding what I believe to be a XMP compatibility issue between PSU and DxO Optics Pro. If I the following:
1) bring a RAW image into PSU and keyword it,
2) then edit inside DxO finishing with an exported JPG (and specifying to keep metadata in the export), and
3) then input the DxO generated JPG back into PSU,

I'm finding the keywords are absent from the DxO JPG. If I do the same steps but start with Lightroom and do the keywords there and finish importing both the original RAW and the DxO generated JPG into PSU, the keywords are present in both files. I use the setting in PSU under Write settings - Always write Lightroom hierarchical keywords checked.

Just curious... Do other RAW converters (e.g. Lightroom, Capture One Pro, ...) essentially do the same thing in terms of storing the recipe of non-destructive edits, keywords, etc inside their sidecar XMP files as DxO does with DOP files?

[jstartin]

And I have .spd sidecars, which have to remain in a specific sub-folder (\SILKYPIX_DS) of the folder containing the raw file.

Naming for "rawfile.ext" is "rawfile.ext.N.SPD" where "N" is a numeral corresponding to application version number.

To add a sidecar definition for every possible version of their RAW converter is adding too much overhead. You have 3s, 4s, 5s, 6s, and if added it also needs 2s and 1s in order to be complete. This means 23 RAW extensions * 6 = 138 extra possible combination to check for every single file operation. And then for every new main version that Sikypix releases yet another set needs to be added. That's too much to ask.

Fantastic to find that, despite the above, handling of Silkypix "SPD" files is implemented in build 1040. Hert, thank you so much!.

[Hert]

You're welcome. The only thing that I'm not sure about is if Silkypix also allows sidecars for JPG files like DxO and CaptureOne do.

[jstartin]

You're welcome. The only thing that I'm not sure about is if Silkypix also allows sidecars for JPG files like DxO and CaptureOne do.

Yes it does (well, not so much "allow" as "insist on" if jpegs are processed ). And, to my delight, PSU now deals with them very nicely.