Bug #10270

Problem with X-Trans RAW files: color artifacts

Added by Francisco Cribari about 5 years ago. Updated about 5 years ago.

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


Estimated time:
Affected Version:
git stable branch
hardware architecture:


My second camera is a Fuji X100S, which has an X-Trans sensor. I am getting color artifacts in several images when I raise the lower end of the tone curve. The problem does NOT happen with my Nikon D800 RAW images, only with X-Trans RAW images. I would also like to point out that it is common to raise the lower end of tone curve and to lower its upper end. This is done to give the image a "vintage/classic" look. See, e.g.,

For some reason, that tends to cause color artifacts in X-Trans RAW images processed using Darktable.

Here is an example:

RAW (.RAF) file:

XMP file:

(I am attaching those files.)

Zoom in the image and take a look at the man's shirt (near his right arm). (I have already reported another case in the darktable-users mailing mailing list.)

I run DT version 1.6.1+30~g6b508d0 on an Ubuntu 14.04 (64 bit) notebook. Francisco

_FFX7093_01.RAF.xmp (8.52 KB) _FFX7093_01.RAF.xmp XMP file Francisco Cribari, 01/05/2015 02:38 AM
_FFX7093.RAF (32.2 MB) _FFX7093.RAF X-Trans RAW file Francisco Cribari, 01/05/2015 02:43 AM


#1 Updated by Pascal de Bruijn about 5 years ago

  • % Done changed from 0 to 20
  • Status changed from New to Incomplete

The only artifacts I see, are typical X-Trans artifacts, which is simply due to X-Trans' overcomplicated nature.

Darktable has three different demosaicing algorithms which are "suitable" for X-Trans: VNG, Markestein (1pass), Markestein (3pass). Usually most artifacts disappear with the Markestein algorithms, but they are usually slower. Which is presumably why they're not the default (yet).

If there are still any artifacts left, they can usually be further reduced by applying a few color smoothing passes.

That said, having done a quick benchmark, sortof tends to indicate that Markestein (1pass) is not significantly slower than VNG, and thus might be a candidate as a default

[dev_pixelpipe] took 1,720 secs (5,119 CPU) processed `demosaic' on CPU, blended on CPU [export] VNG
[dev_pixelpipe] took 0,800 secs (5,094 CPU) processed `demosaic' on CPU, blended on CPU [export] Markestein (1pass)
[dev_pixelpipe] took 1,598 secs (11,264 CPU) processed `demosaic' on CPU, blended on CPU [export] Markestein (3pass)

If switching to Markestein helps your case, I'd love to see similar benchmarks on your end, which you can get by running darktable -d perf from a Terminal.

#2 Updated by Pascal de Bruijn about 5 years ago

So we've tentatively changed the default in our development trees:

#3 Updated by Ulrich Pegelow about 5 years ago

Eventually this is strongly linked to the occurence of "unbounded" colors. You can read here [[]] to learn more about that topic.

A possible solution is to use the gamut clipping feature in the input profile module. You need to experiment a bit to find out which clipping
profile leaves you best color dynamic while preventing artifacts. I found AdobeRGB to be a good choice in your example image.

#4 Updated by Pascal de Bruijn about 5 years ago

Would you mind reported back, if either suggestion helps?

#5 Updated by Francisco Cribari about 5 years ago

Pascal de Bruijn wrote:

Would you mind reported back, if either suggestion helps?

I have noticed moiré in some X-Trans RAW files, so it's probably a good idea to change the default demosaicing method. In the specific case I reported in this issue, the problem is not caused my moiré (I believe). What solves the problem is to change scale chrome to manual in the tone curve module. The color artifacts in the man's red shirt (near his arm) no longer show up when we do so.

Also available in: Atom PDF

Go to top