Bug #8665

blueish artifacts when using opencl

Added by supermaz - about 7 years ago. Updated about 7 years ago.

Target version:
Start date:
Due date:
% Done:


Affected Version:
hardware architecture:



I have a problem with some RAW files in darktable when using OpenCL. There are some blueish artifacts. I'll attach screenshots with and without OpenCL in use, also the RAW file.

I'm using nvidia-drivers-295.20 with an a GTS 450.


#1 Updated by supermaz - about 7 years ago

The RAW file is too big to attach, it can be found here:

#2 Updated by Simon Spannagel about 7 years ago

  • Status changed from New to In Progress

#3 Updated by Ulrich Pegelow about 7 years ago

I can confirm your findings with the image submitted. I suspect a problem in handling of out-of-bound a and b values in Lab, which we seem to handle differently on CPU and GPU. Will need to dig deeper into this problem.

As a short term remedy you can switch to "standard matrix" as input profile.

#4 Updated by supermaz - about 7 years ago

What I fear is that there are other places in the OpenCL mode where things work differently and one might get worse results. I hope not, but for the time being I disabled OpenCL (I got a fairly new PC 2 weeks ago, so it isn't that critical.

#5 Updated by supermaz - about 7 years ago

I think there are more problems, even when not using OpenCL, see my new screenshots comparing darktable with AfterShot Pro.

So normal editing is also affected and it seems to be really color related.

#6 Updated by Ulrich Pegelow about 7 years ago

I just pushed a fix to git master. Background of this problem is a buggy (in fact superfluous) clamping in module sharpen, which was even done differently between CPU and GPU code.

@supermaz: please check and report back.

#7 Updated by supermaz - about 7 years ago

Dear upegelow,

the good news is that the results seems to be the same with and without OpenCL. But the bad news is that there are still some blue artifacts in the image, see latest screenshot.

#8 Updated by supermaz - about 7 years ago

Used the latest git source 3 minutes ago.

I can confirm that its related to sharpen. Without it, its fine.

#9 Updated by Ulrich Pegelow about 7 years ago

I think the last reported topic is not a DT bug. It's in the nature of sharpen to enhance structure including noise. If you reduce sharpen amount to zero, and look close you still see that some weak magenta colored noise is there.

I assume this is based on different clipping values of camera in an overexposure situation. As this is only visible under very close pixel inspection, I do not regard this as a major issue. You might check different raw converters. If you can convince us that other converters deal much better with this situation we might consider to investigate it later.

#10 Updated by Pascal de Bruijn about 7 years ago

I just cherry-picked 7a08543ccbb08a4d05775782dca37b5245519554 to our darktable-1.0.x branch.

#11 Updated by supermaz - about 7 years ago

Thanks for the investigation. I will try same other raw converters an report back. At least the bug with opencl is fixed.

#12 Updated by supermaz - about 7 years ago

I made two comparisons (see attachments): Darktable vs RawTherapee vs AfterShot

I still think that darktable shouldn't create these blue pixels when sharpening. Both other programs don't do it, though RawTherapee gives some other colors on default settings.

After all I really like darktable, you are doing a great work!

#13 Updated by Ulrich Pegelow about 7 years ago

  • Status changed from In Progress to Fixed

Obviously all raw converters struggle to deliver a realistic reconstruction of this over-exposed situation. All of them produce artifacts and I would not call one more "correct" than the other. There simply is no standard way of solving this.

As the biggest influence in this special case seems to come from the input profile, I suggest that you select within DT the best suited one for you by trial and error. Either enhanced or standard matrix or a profile supplied by Canon. In some cases these manufacturer profiles deliver better results than the matrix approach.

I will mark this issue as solved. The real artifact has been fixed. Thanks again for reporting!

Also available in: Atom PDF