This is not a very good photograph by any means, but I found a strange behavior in darktable.
I opened the raw in darktable, changed reconstruct highlights to color, and this was the result:
It had never happened to me, even in similar clipped scenes with huge dynamic range. Can anyone reproduce it in their systems? I haven’t ran any additional tests yet, so not yet sure what’s the cause.
reconstruct color
Use an algorithm that transfers color information from unclipped surroundings into the clipped highlights. This method works very well on areas with homogeneous colors and is especially useful on skin tones with smoothly fading highlights. Please note that this method can produce maze-like artifacts on highlights behind high-contrast edges, for example well-exposed fine structures in front of an overexposed background.
BTW, you posted a pp3 sidecar, which is from RawTherapee.
Ah… another case of RTFM 
For over a year i used reconstruct color without any artifacts .
But apparently , that was luck, because those artifacts are appearing for people quite often I’m told.
In a thread about ‘why is darktable bad in highlight reconstruction vs rawtherapee’ i was of the opinion that this wasn’t the case, because they have the same algorithms. This was WRONG, and a bad assumption by me. In multiple play raw files I’ve encountered files with artifacts like this and even in some of my own shots now. I guess I was always lucky.
(And to be honest , using DxO as a preprocessor removed the need / benefit of highlight reconstruction so I didn’t use it that often ).
So, what you are seeing is (probably ) just something that can happen with ‘reconstruct color’ . Try something else, even if you don’t want to 
.
(The new hlrecovery segmentation based is a good bet to replace it, try reconstruct lch if you don’t need color in your highlights , or leave it off and try the recovery / smoothing in filmic instead . Specially with luminanceY mode you might get less purple in your highlights ).
I am aware, should’ve mentioned it in the main post, I apologize. I tried reconstructing with filmic but was unable to get rid of the magenta cast, so tried to process it in RT.
Same here, a year and a few months and this was the first one that gave me troubles, thankfully it’s not a great shot so all the better.
I guess using RT every once in a while isn’t so bad, it’s a good piece of software, I just prefer darktable overall 
Using DxO as a preprocessor seems like a good choice and worth the extra work for those couple of images that can really make use of it.
Indeed, and hannoschwalm might also work on a recovering method that supports x-trans so the future is bright 
I think the raw white point (16383, the theoretical maximum for 14 bits) is wrong in darktable for this camera.
The magenta highlights, which are caused by clipping, are visible here, with only a few black dots indicating what darktable considers to be blown pixels:
Observe what happens when we cross a threshold. White = 16381:
White = 16380:
The highlight recovery module is affected by this, since it needs to know which pixels are blown.
LCh recovery
LCh + filmic:
That make sense, this also explains why I saw nothing when I toggled the raw over exposure indicator… It did seem weird that the highlight reconstruction was having such an effect if none of the image was overexposed. The camera reports its white point as “0.313 0.329” I guess it’s then calculated into the 16383 value, or is this value coming from somewhere else?
I don’t think so. Those are probably xy coordinates of the white point (colour), not sensor saturation values.
Interesting. Using the librtprocess (RawTherapee derivative) highlight reconstruction tool, I got this:
Making stuff up has its limits…
I have seen this on numerous images. I am forced to change the method on those occasions.
