The DCI and Apples Display P3 uses exactly the same gamut/coverage. But apple uses a different gamma curve and white point.
I looked at some processed DNG files using various raw decoders and exif viewers and I cannot see any trace of this being in P3 color space. There is no ICC profile attached.
Also the embedded color matrix in the DNG (From the DNG spec: “ColorMatrix2 defines a transformation matrix that converts XYZ values to reference camera native color space values, under the second calibration illuminant” & illuminant 2 is D65):
$ exiftool DSC05638-DxO_DeepPRIME\ XD2s.dng
Color Matrix 2 : 0.746 -0.2365 -0.0588 -0.5687 1.3442 0.2474 -0.0624 0.1156 0.6584
matches the color matrix that libraw’s raw-identify tool got out of the original raw file:
$ raw-identify -v DSC05638.ARW
XYZ->CamRGB matrix:
0.7460 -0.2365 -0.0588
-0.5687 1.3442 0.2474
-0.0624 0.1156 0.6584
So it looks like the color space is preserved.
While staring at tiff tags i noticed that there are 2 full size images embedded in the dng:
$ exiv2 -pa DSC05638-DxO_DeepPRIME\ XD2s.dng
Exif.SubImage1.NewSubfileType Long 1 Primary image
Exif.SubImage1.ImageWidth Long 1 7008
Exif.SubImage1.ImageLength Long 1 4672
Exif.SubImage1.BitsPerSample Short 3 16 16 16
Exif.SubImage1.Compression Short 1 JPEG
Exif.SubImage1.PhotometricInterpretation Short 1 Linear Raw
Exif.SubImage1.SamplesPerPixel Short 1 3
Exif.SubImage1.PlanarConfiguration Short 1 Chunky
Exif.SubImage1.TileWidth Long 1 160
Exif.SubImage1.TileLength Long 1 144
Exif.SubImage1.TileOffsets Long 1452 4790944 4866536 4941612 5016192 5090344 5164126 5237508 5310562 5383330 5455854 5527926 5600048 5672048 5743954 58>
Exif.SubImage1.TileByteCounts Long 1452 75592 75075 74579 74151 73782 73381 73054 72767 72524 72071 72122 72000 71905 71646 71539 71693 71573 71506 71471 >
Exif.SubImage1.WhiteLevel Short 3 65535 65535 65535
Exif.SubImage1.DefaultScale Rational 2 1/1 1/1
Exif.SubImage1.DefaultCropOrigin Rational 2 0/1 0/1
Exif.SubImage1.DefaultCropSize Rational 2 7008/1 4672/1
Exif.SubImage1.AntiAliasStrength Rational 1 100/100
Exif.SubImage1.BestQualityScale Rational 1 1/1
Exif.SubImage2.NewSubfileType Long 1 Thumbnail/Preview image
Exif.SubImage2.ImageWidth Long 1 7008
Exif.SubImage2.ImageLength Long 1 4672
Exif.SubImage2.BitsPerSample Short 3 8 8 8
Exif.SubImage2.Compression Short 1 JPEG
Exif.SubImage2.PhotometricInterpretation Short 1 YCbCr
Exif.SubImage2.StripOffsets Long 1 154478
Exif.SubImage2.SamplesPerPixel Short 1 3
Exif.SubImage2.RowsPerStrip Long 1 4672
Exif.SubImage2.StripByteCounts Long 1 4636466
Exif.SubImage2.PlanarConfiguration Short 1 Chunky
Exif.SubImage2.YCbCrCoefficients Rational 3 299/1000 587/1000 114/1000
Exif.SubImage2.YCbCrSubSampling Short 2 1 1
Exif.SubImage2.YCbCrPositioning Short 1 Co-sited
Exif.SubImage2.ReferenceBlackWhite Rational 6 0/1 255/1 128/1 255/1 128/1 255/1
So maybe whatever tool you are using reads the second sub image somehow and not the linear raw?
1 Like
Yes but these two variants are used in different worlds
I looked at … various raw decoders …
Are you sure you understood the bug that I’m describing here? 
I’m not talking about “various raw decoders”. Please read the headline.
whatever tool you are using
exiftool, Geeqie and RawTherapee. And I pretty much trust them.
If we take a step away from the colour space discussion, we can find a way to use DPR for what it’s best: Optical corrections and noise reduction.
And if we use DPR as a pre-processor to e.g. Lightroom, we can export, from Lr, with any suitable colour space or profile.
Without having checked what follows, I suppose that DPR selects, for JPEG, whatever was set in camera which is either sRGB or AdobeRGB. RAW files have no colour space other than what the sensor provides, which in most cases is anything but a standard space. And macOS tells us that RAW files are in P3, which is the setting of most modern Apple displays.
Briefly checked with DPR v3 and GraphicConverter:
With DPR3, DNG files show AdobeRGB, JPEG and TIFF show either sRGB or AdobeRGB according to what I set in the camera. Check the screen above.
I better don’t comment on this.
Please anyone in this forum here who is using DxO-PR4.6, could you post the output of exiftool and the Color Space written there for the exported DNG and JPG file. Thank you.
Did you understand what I wrote? 
No matter which type of data is in a DNG file, you can still use a raw decoder library like libraw to extract the metadata out of it. libraw for example ships with a tool called raw-identify which also works on DNG. Sometimes those tools are better at extracting raw specific TIFF/EXIF tags from DNGs.
Okay let’s take exiftool. Can you show me the output where it gives you the color profile of the data in a DNG file? Right now you are just making claims. Give us something reproducable.
Also note that the Color Space exif tag is not the actual color space of the data. Even my Sony raw file has sRGB set here. Probably just carries over from the JPEG setting, but meaningless.:
$ exiftool DSC05638.ARW | grep 'Color Space'
Color Space : sRGB
$ exiftool DSC05638-DxO_DeepPRIME\ XD2s.dng | grep 'Color Space'
Color Space : sRGB
The DNG specifications don’t mention the ColorSpace tag at all. Seems to be part of EXIF.
A raw file doesn’t have an output color space. So it is from the jpg.
George
2 Likes
Dude, just because DxO has written the original Color Matrix 2 into the linear DNG file, that doesn’t mean that the pixel data itself is in the “camera color space“.
This is mainly for the sake of preserving the source of truth (or the starting point) where the picture is coming from and which color transformations were applied. This gives you the „theoretical” ability to de-demosaic the linear DNG back to the original RAW representation in Bayer-Pattern.
And mainly it gives you the ability to apply an alternative color matrix for example one that you have measured exactly only for your camera sensor.
And yes I’m also getting „sRGB“ for my ARW files.
BUT!!! There is a big difference between a linear DNG and a RAW (ARW) file: The linear DNG is already demosaiced and each pixel has a RGB value and therefore the color matrix etc is not directly relevant any more because the image is calculated.
The RAW file is still in the Bayer-Pattern with RGGB and no calculation of the pixels has happened. And then the Color Matrix is needed to apply the correct transformation to the target color space of representation.
The DNG specifications don’t mention the
ColorSpacetag at all. Seems to be part of EXIF.
Because DNG is only the container and DNG does not need to define this. It is important that the data within the container is well defined by the attributes needed for the image that you put into that container. And these attributes are summarized in the EXIF data that you are also putting into the DNG container.
For DxO PR4 exported DNG: sRGB
For DxO PR4 exported JPG: Uncalibrated
As written in my first post.
And even “Uncalibrated” is already a bug. Because the JPG specification demands a defined color space, to make sure that the viewer always presents the image in the correct color space.
What makes you think that the two are related? True, the output DNG isn’t using a CFA pattern anymore, but why should that change the color space used?
That is not true. The DNG specifications define the process how to convert camera native rgb values to a device independent color space. There is a whole chapter called “Mapping Camera Color Space to CIE XYZ Space” in those specs.
If DxO would just copy tags like ColorMatrix2 but changes the color space, that sounds like not conforming to the DNG specs.
Those are literally the only two values officially supported, see EXIF Tags.
Yes. Then maybe you can see that it makes no sense to tag the 8-Bit JPG file with „Uncalibrated“ and the 16-Bit DNG file with „sRGB“. Vice versa it would be at least half correct (for the JPG), but not for the linear DNG. Maybe one of the developers has mistakenly mixed it up.
Dude, as soon as you have demosaiced a RAW picture, you need a color space. Period.
We are talking about linear DNG’s. And not the classical DNG as a RAW file. DxO is using the DNG mainly as a container and you can see that also by the size of the linear DNG files. They are much bigger then a usula DNG file (which contains raw data from the sensor).
Yes. Correct. But again: This is for mapping (not converting, nor resampling) camera native color space to the color space that the DNG file is supporting to preserve the full sensor color space. But this is not valid when you are writing demosaiced (not raw anymore) Data. As soon you demosaic the sensor data, you need a color space to interpret the RGB values, because there is no R and G and B raw picture in the data.
Sorry but honestly there is a bug.
At least the JPG data must be exported in sRGB. Anything else is absurd. You can tell me whatever you like, but this is a bug.
Ok seems like DxO is not reacting to the bug report and also not willing to correct it.
And at the same time DxO is announcing PureRaw5.
If they don’t correct this soon, then I will definitely never purchase any DxO product any more.
Really arrogant behaviour.
Waiting for 2 months now for a response from DxO!
No bug…
- For dng exports, there is no application of a particular profile… or more precisely, it is the color space of the sensor that is preserved. So we find ourselves in exactly the same conditions - and the same possibilities - as a raw file when opening this dng.
- For rgb exports: jpeg or tiff, it is the default profile saved in the camera menu (in principle sRGB or Adobe) that is applied.
1 Like
But you change that to anything. In PL anyway.
George
Yes, of course!
But PureRAW does not have all the features of PhotoLab, and is not intended for the same users. DxO has clearly chosen a simplified setting for PR.
The main thing is that the dngs do not lose anything of their original color space (that of the sensor). I find it rather healthy that the jpegs can inherit the Adobe or sRGB space chosen in his camera by the user since it is very likely that it will not be reworked. Possibly, the question could arise for tiffs, but if we choose the Adobe space, the possibilities for further processing will not be affected.
I’m not a PureRaw user, but the discussion had me curious. I installed the PR4 trial and upon exporting the linear DNG straight into PL8, metadata tells me it’s in sRGB. I suppose the error could be in the metadata, but I have to believe it’s true, because there are no gamut warnings soft proofing the linear DNG against sRGB, while there is for the original RAW file that I exported next to the linear DNG. Thinking it could be using the system default, I changed it to Adobe RGB, and it was still exported in sRGB. There is nothing in the UI that allows you to choose the output color space. Unless I am missing something, I have to agree with the OP that this must be a bug. The original RAW data may be somewhere in the linear DNG file and recoverable, but that does not help me, if I want to export and continue editing my image.
1 Like
@Oldjstein thank you!
Finally someone tested it, instead of posting expert like comments without having any clue.
This is a severe bug, that makes PR4 completely useless and none of the “experts” here ever have complained about it
And DxO is still not correcting it while further selling the product and announcing PureRaw5. Shame on you guys. Really!
By the way, I assume that this bug was there in the previous PureRaw versions. I have never used them and PR4 is my first purchase.
But for those “experts” using it since quite some while, this would mean:
- All your exported JPG’s are useless and you need to re-export them, as soon as the bug was fixed
- All your exported linear DNG’s, that you have further processed are dramatically reduced in quality, as you have used an extremely limited color space to start your processing
Basically: You have paid for a product that didn’t fulfill what it promised to do 
You can export the dng and continue to edit your image! Don’t worry: there is no bug.
In the case of a raw file, the image data is of type “raw” since it is not demosaiced.
In the case of a linear dng file created by PureRAW (or PhotoLab), the image data is of type RGB, since the R, G, (G), B layers have been demosaiced. But RGB indicates the type of image data, not the ICC profile that would be assigned. And besides, in PhotoLab, you can create dng identical to those of PureRAW, but you cannot assign them an ICC profile. As for raw, the image data of linear dng are in the original color space of the sensor.
On the other hand, the dng files created by PureRAW (or PL) have, like raw files, an embedded thumbnail, which allows the instant display of the image. And this thumbnail must have a profile to be displayed (sRGB, Adobe…).
1 Like
I can edit a JPEG, if I want, but that is not the purpose of PureRaw. Linear DNG is already demosaiced and mapped to the designated color space. Quoted from DxO, “Linear DNG files are RAW files that have been partially developed, having undergone some complex mathematical processing to lock in demosaicing.” It is possible, and it is the claim made by DxO that the linear DNG created by PureRaw4 contains all of the information in the original RAW image and is reversible, but that’s not useful without an application that performs the reversal. My library is full of RAW (NEF) and standard DNG images that have no assigned color space in the metadata only “RAW,” despite having JPEG previews. The linear DNG files created by PR4 are all labeled as being in sRGB, and there is nothing I can do in PL8 that changes that.