The pixel values do not represent red, green and blue because the light hitting the sensel is not red, green or blue but a mixture of colours…
Deciding how to process the data, and allowing for this, is part of the reason why not all raw converters are equal.
This diagram show the bayer sensor filter dye transmission curve.
Not saying you are not correct… but does that have anything to do with the wide-gamut option introducing colour casts in the DNG data??
The DNG is in range 0 - 65535 of values, the valuesin the files written by 4channels are in the range 0 - ‘whatever your camera uses as white level’.
Try a 4channels -A sample.cr2, it doesn’t scale it properly, but it at least says the maximum value your sensor records. 65535 / sensor-white-level = multiplication factor needed to bring it to 0 - 65535.
If you made the DNG with ‘legacy gamut’ or PL5, they should match up quite well. Doesn’t tell us anything about what is happening with the wide gamut option.
But it’s a sort of proof that a linear DNG is just your original recorded sensor values, with ‘the missing gaps filled in’, and nothing colour-space wise is done.
Your red channel from the DNG contains the original values…, and new ones from the upscaling… but in that upscaling they don’t have to know the colour space, or the ‘meaning of the numbers’. It is just numbers and smart interpolating algorithms… Although I bet there are demosaicing algorithms who want to understand the colour meaning of the numbers, so they can make better upscale decisions. But that still doesn’t mean they have to convert the data in the DNG.
The simplest form of demosaicing is taking those quarter-resolution R, G1, G2 and B channels… and then averaging the G1 + G2 channels to get a single G channel, and then just making a RGB image from that, without any upscaling / reconstructing. You get an image that is quarter-resolution to what you expect, but it’s there. Results are not bad and quite OK, and easy to compute… but the file is less resolution 
.
One step up - but also still dumb - is just to simply use a bicubic resizer to upscale the 4 channels to ‘full’ resolution, and then average the G1 + G2 to get a single G channel, and then using them to create an RGB image. Results will not be that great, and I expect issues with moiré and CA. But it works as a demonstration .
I did that, but other than scaling, the shape of the histogram was the same. By “shape” I mean not values per se, but undulations. It’s a different looking curve. I’m not trying to find the differences in DNG, just trying to understand what changes demosaic does to “raw” color response. My conclusion is that gray scale out from 4channels (each image is from only the same color filtered sensor pixels) will not match the same color channel demosaiced output
May I have a look at the CR2? Because that would be the opposite of proof my point , but also very different as what is happening with my file.
It’s your cr2 file that you referenced at pixls.us
If you export with ‘optical corrections’ only from DxO, with the legacy gamut selected, they align up pretty well again.
If you use the ‘all corrections’ mode, the highlight-recovery system in DxO kicks in to (attempt to) repair the sensor-clipped highlights, which can affect the histogram pretty drastically. If you crop the top half away for example, they are much closer (although I have a sort of black-level difference somewhere… but the ‘shape of the histogram’ as you said, is pretty much the same).
2014-05-30_19-47-01_raw_legacy_1.dng_test.tif (8.5 MB)
from_raw.tif (8.5 MB)
Again, this is purely academic. It’s proof that a linear DNG does contain the ‘same colorspace’, the same sort of data as the original RAW. And that demosaicing does not (have to) mean ‘bring it into another colorspace’ or ‘do stuff with camera profiles’.
Of course, if you start to add algorithms the recover parts, refill parts, change color, apply different profiles, etc… it can all change.
You did get me experimenting again.
And look at this, this is the green channel of the DNG files created by DxO. One in ‘all corrections’ legacy mode, one in ‘all corrections’ wide-gamut mode.
It appears there is not so much difference at all… except in the highlights… which are ‘repaired’ in the legacy version, but remain clipped in the wide-gamut version?
legacy_green.tif (8.5 MB)
wide_green.tif (8.5 MB)
Maybe there is no real export difference, except in clipped highlights? In wide-gamut mode, the highlights-repair doesn’t kick in, because it thinks it has more than enough room left? 
This would indicate that ‘the bug’ is maybe not in the DNG export itself, but in the highlight-repair in wide-gamut mode.
I am an amateur and have not so good understanding of linear DNG. But I assume in general the relation to color space requires a color profile. Other it is not possible to correct representation in another programms/devices. The base for conversion is not present. In my modest opinion DNG must not be relate to any color space. Or it must be possible to choose a color profile during export, or probably use any one as default. Additionally it is unclear to me what is the difference to export to TIF and export to DNG with the specified color space? What is advantage of DNG in this case?
Moreover the default value “Wide Gamut” is causes really problem by post processing:
I am seeing this issue on my MBP M1 and latest version of Photolab.
I am not liking the color rendering when Wide Gamut is enabled. It is definetly different then when using Legacy Gamut.
Here is my experience between wide gamut and classic working color space and exporting the exact same file with exact same setting and exporting with Denise and optical corrections only
this image came from a Fuji GFX100s
Somewhere in the exporting of DNGs from Photolab 6. Images were displayed in Adobe bridge.
Exporting the files as jpgs eliminates the color shift but then there is a density shift instead between classic and wide gamut
Note: Wide gamut is displayed on the left and classic color space on the right in both screen grabs
