The ICC of images exported to Photos is not sRGB IEC61966-2.1 color gamut

The colour space set in the camera is only applied to the in-camera JPEG. The RAW file has no colour space until it is processed. Initially it acquires the ‘working colour space’ of the processing software, which for PL6 can either be DxO’s proprietary ‘wide gamut colour space’ or DxO’s ‘legacy working space’ (which happens to be Adobe RGB 1998). When the RAW file is exported from the processing software the output file (TIFF, JPEG, whatever) can be set to the colour space of your choice, sRGB, Adobe RGB 1998, ProPhoto, etc.

This means you can safely set your camera to ‘sRGB’ and still process the RAW files from the camera in a wider gamut colour space. You only need to set your camera to Adobe RGB 1998 if you want to post-process the in-camera JPEGs in a wide gamut colour space than sRGB.

…unless the export mode “Add to Photos” is used.

As I understand it, the OP selected aRGB as the in-camera JPG setting. After RAW processing in DxO PL the OP then exported a JPG that exhibited an embedded aRGB profile. This may be confusing, but it is not a bug.

In the Export to Disk interface (whether soft proofing is on or off), if the ICC Profile is anything other than sRGB IEC61966-2.1, the program will embed the corresponding ICC color profile at export. The sRGB IEC61966-2.1 selection will not embed a profile.

The As Shot setting honors this convention. When you process a RAW file where the in-camera JPG setting is aRGB, the As Shot setting will embed the Adobe RGB (1998) profile. I suspect this is what happened in the OP’s workflow.

DxO PL is being internally consistent here in that routine sRGB exports will not have an embedded color profile.

As has been advised by others here, the OP should consider exporting as JPG via the main Export to Disk interface, selecting sRGB IEC61966-2.1. Personally, I would instead embed an sRGB ICC profile by using one of the workarounds discussed in this forum. This will strike many as overkill, but it avoids ambiguity in the intended color space.

Thanks very much. Your statement should be correct, otherwise the RAW file will not be the original.

I’m very sorry but I don’t understand what you mean, the English doesn’t make sense. Perhaps you could write your reply in your native language and then post a translation (from Google Translate / DeepL / etc.)?

He agrees with you. He’s saying if the raw data was affected by a color space option the raw data wouldn’t be raw sensor data anymore so you must be right.

This might be of interest:

1 Like

Ah, yes, when you put it like that, that does explain his wording.

Thanks