See the included screenshots. When I increase the perceptual brilliance grading in color balance RGB the clipped highlights are blown
I do not think it is a “bug”. Every algorithm has limits of applicability. If you push settings to extremes, you can expect artifacts.
I just tried your image with dt 4.0 on windows, and can’t reproduce it… from the screenshot I don’t think you’re pushing color balance rgb to it’s limits or anything either. I tried your image first with my workflow then with your .xmp, but all that happens when I increase the highlight brilliance slider is that the highlights get brighter as they should.
No sign at all of the big white areas in your screenshot, so I don’t know what’s going on… hopefully someone more knowledgeable will have an idea 
On the Mac I have seen similar artefacts when pushing luma curve in contrast equaliser, and get back to “normal” if decreasing exposure
On same machine running macOS Big Sur with earlier build by @MStraeten it doesn’t happen 
I can reproduce in Windows 11, branch 4.0.x.
I believe the artifacts are generated in filmic, not in color balance, as disabling filmic makes them disappear.
Most likely it is the filmic reconstruction that kicks-in at a certain point by increasing brilliance a lot.
See how the artifacts change by playing with reconstruct threshold and transition in filmic.
Unfortunately threshold can’t be set higher than 6 EV in the gui.
To me there should be a switch to disable reconstruct in filmic, not only by setting a high threshold
I can get this on DT 4.1.0+248~g8ce715250 with Ubuntu 20.04.
Starting point -
Highlights at 68%
Then at 67%
2014-05-30_19-47-01-highlights.cr2.xmp (17.5 KB)
Filmic iterations at zero and reconstruct threshold at +3. Agree, the spot goes if Filmic turned off.
Yeah, because it doesn’t have reconstruction
With “pushing to extremes” I don’t mean the color balance rgb setting alone. The critical regions of the image are already clipped in raw data. Additionally the exposure is increased by 1 stop. Then increasing “perceptual brilliance grading” pushes the highlights once more.
One can clearly see (by displaying the highlight reconstruction mask in filmic) that even with a threshold of +6 EV (highest possible value) filmic’s reconstruction is active (unwanted).
It’s not necessary to switch of filmic, the “blooming artifact” also disappears if you set structure ↔ texture to +100% in filmic’s reconstruct tab. In this case you get another artefact, the highly blown areas appear inverted.
For this image it would be helpful to have an “off”-switch for filmic’s reconstruction. Or just switch off filmic and use “tone curve” or “rgb curve” for example.
As a workaround, you may add a parametric mask to color balance rgb, and disable boosting the already extreme highlights.
I was unable to reproduce this on the Windows laptop that I have (darktable 4.0.0, no OpenCL), so it may be a newly introduced bug, or only affect OpenCL:
There’s another problem with the image shown by @pehar : raw whitepoint is set to 15831 by darktable, exiftool gives as white point values 
Normal White Level : 11767
Specular White Level : 12279
Linearity Upper Margin : 10000
Also, you’re pushing the perceptual brilliance for a zone that’s already seriously over-exposed, and way off the scale after filmic tone-mapping.
So yes, the artifacts are caused by filmic’s highlight recovery acting on zones in the images that end up >6 EV over display white. I think you have some other issues in the image if you have values like that, especially if that concerns a larger area of your image. Given that, I’d rather not see yet another element added to an already charged interface.
(I can get the same artifacts with dt 4.0 btw, or actually worse: a large part of the sky turned black…)
I can reproduce on two different machines (different GPUs), both Ubuntu 22.04, both 4.1.0+283~g5cca9d64b, with and without OpenCL.
Yes, I have also tried this with success. This way one can avoid stepping in filmic’s highlight reconstruction.
However this can be super confusing for normal users, you push a slider and all of a sudden you get an artifact because another module has a sleeping feature that kicks in.
To me we really need a switch to disable filmic reconstruction and that should be off by default
Sorry, but I did not show any image here…
The image (DSA06029.ARW) was posted by @Rajkhand. This is what I get from exiftool :
[MakerNotes] 0x787f White Level : 15360 15360 15360
which is different from the value darktable uses (but this is another problem with some Sony cameras). raw over exposed indication broken · Issue #12193 · darktable-org/darktable · GitHub. But even setting White Level in dt to 15360 does not solve the problem with filmic’s highlight reconstruction stepping in undesired.
I totally agree, that is what I meant in my first reply to @Rajkhand, “pushing settings to extremes”.
Can someone bisect from here after checking the white point? https://github.com/darktable-org/darktable/pull/12233
Oops, I mixed up the two examples, sorry for that.
The white point values I cited are for 2014-05-30_19-47-01.cr2, an older playraw; used by @RawConvert.
But yes, the Sony cameras also have a problem with the white point (less extreme). Probably “thanks to” the secrecy around the makernote sections… (exiftool deciphers the values, exiv2 seems not able to).
It’s not about exiv2 - part of the problem here is that exiv2 is not used to set black and white levels for the rawprepare dt module, they come from rawspeed at the point of file loading (which has very limited MakerNote support). I think this has been beaten to death recently on the forum and github…
Sorry, I was using the respective command-line tools to try getting the white points for manual use in dt. Exiftool worked with no problems, with exiv2 I didn’t manage to get those values.
Do you know if rawspeed is an abandoned project?