Red fringes appearing on export only


I am running dt 3.4.1 on a mac, and I have noticed that on exporting to jpeg, with the following settings:

some thin red stripes near clipped areas appear in the exported image that do not appear in the darktable visualization (the following are 100% crops):

a) in darktable

b) in the exported jpg

From another area of the same picture:

a) in darktable

b) in the exported jpg

Here is the xmp file, I can post the raw and the jpg too (although they may be too big for attachment, ~ 20mb each)

X1FA5732.raf.xmp (20.2 KB)

I have tried to change some of the export settings, but the issue remains. I don’t really have a cue as to how to solve this, so thanks in advance for any input!



I am reposting to see if there is any take on this. The artifact is not subtle and makes the exported image quite unusable in my opinion.

thank you in advance

I’ve never seen this. Try posting the raw file and provide a creative common license (as per this post: Creative Commons Licence ) and we can test it.

Are you viewing the exported jpg in dt or other software?

Here is the raw file. This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

I am viewing the jpeg in the Preview app on the mac, but they are present in Gimp too. Rendering the jpeg file for the attached raw file gives somewhat less of the red fringes effect (I must have changed some dt parameters from last time), but they are still present, especially near the lamps.

thank you very much for your time

X1FA5732_01.raf.xmp (7.0 KB) X1FA5732.raf (18.8 MB)

I have a feeling this has to do with the reconstruction part of filmic (the lamps are obviously clipped in raw), so perhaps @aurelienpierre may be able to provide some specific clue about this?


I’m not sure if this is a flmic issue.

If I use your sidecars and export the images I do not really see this fringing. I do see that something is going on, but I do need to enlarge significantly to see it (300-350%).

There’s also a difference when you use different export settings. I always use this and, as expected, the quality is better:


The size part isn’t relevant (I tested the above with a full size setting).

I do see differences when I play with the demosaic, lens correction and defringe modules and I honestly think that the issue might be solved using those.

There are some partially blown out bits in your RAW, but luckily its only one channel so reconstruction is rather simple.

Here’s the sidecar from my little experiment so you can have a look: X1FA5732.raf.xmp (7.7 KB)

Hello Jacques,

Thank you very much for your input. I’ll try to play around with the modules you suggested and see whether I can get any improvement. I did try your sidecar, though, along with your export settings: the fringes are less evident but they are still there in the exported JPEGs, around lights/lamps’ rims (and on the left side of the guy’s hat). See a couple of 100% crops here:

Does this match what you’re getting on your end? Can this be related to some Mac OS X issue? The strange thing is that the fringes appear only in the exported image…


I forgot to mention that I also tried the @Jade_NL export setting with the original (first) sidecar files, but unfortunately I still get the very evident red fringes shown in the original post’s screenshots (no changes, really).


I just realized that my example file was made using darktable 3.5.0 (= development version) and, looking at your above posted xmps, I do believe you are using 3.4.X. There’s one thing that I used that isn’t compatible between the 2: The development version has some demosaicing options that the current stable version lacks. Use Merkenstaijn 3-pass, colour smoothing three times and match greens full average instead if you are on 3.4.X

OK, with that out of the way, this is what I see when looking at my simple edit (xmp/8.2 KB).

Exported jpeg using my above mentioned defaults and shown at 100%

As seen in darktable 3.5.0 at 100%:

I did have a quick go using darktable stable (3.4.1) and the “ugliness” is more visible, worse if you like, in that version compared to 3.5.0. And that would be looking at what darktable itself shows.

The only thing that comes to mind at the moment that might cause the discrepancy: Is your jpeg viewer (and possibly darktable itself) colour calibrated? My system is.

My system is Linux based and my darktables are self build.

Thank you again Jacques for the input.

I did try the demosaicing settings you suggested, but the problem remains. I remember trying the Mac OS built by @MStraeten of the development version (3.5.X) at a certain point, but it didn’t really help.

I am working on a macbook pro, whose screen has a P3 gamut, which is larger than and fully covers sRGB, but it is true that I did not calibrate the screen. Is it possible that the fringes are a consequence of this?


The stable version should do fine to be honest, one really shouldn’t have to use development for normal usage (I don’t). Some of the new stuff is rather nice though and on occasion some annoying bugs are already fixed in development.

I can only, strongly, advise you to make sure that you calibrate and use software that actually makes use of it. It would not be the first time that a (jpeg) viewer shows images in the wrong way due to this. But…

I’m not entirely sure that this is the case in the scenario that you are presenting here, or at least not the only/predominant one. I had a better look at all the modules in your sidecar (the first one you posted which uses the frame module) and especially how you used them.

It seems that a combination of things make this issue stand out more. The main thing that needs to be changed are the exposure/filmic settings. This image isn’t one that can use the default settings, they need to be adjusted. And your edit lacks any reconstruction done in filmic. Especially that last one is crucial to get a much better end-result. I used reconstruction to fix, among other things, the cars red tail-light.

Without the reconstruction/edits done in exposure and filmic the changes you made in the colour calibration module seem to make things a bit worse.

darktable might be able to show a (somewhat!) correct version of the image while editing (the tail-lights doesn’t look good though) this discrepancy most probably will show up after exporting. Especially when going from a wider working profile to the smaller srgb profile.

So I think this seems to be more an edit issue than a export/calibration issue, although those do tend to go hand-in-hand.

I would suggest you try changing some settings in exposure and filmic and do some reconstruction to see if that lessens or removes the issue completely.

1 Like

@Jade_NL first of all, let me say that I really appreciate the thought you have put on this. Thank you so much, I will try to work on the settings you suggested (especially reconstruction) and report here if I manage to get a satisfying outcome.

As for calibration, I confess I have never used calibrated screens and, strangely enough, I have been satisfied most of the time with the prints (from a very good lab), which have always turned out to match quite well what I was seeing on my laptop screen in Lightroom. But I understand it may be time to buy a colorimeter…

thanks again!

I opened the raw and your first .xmp on dt 3.4, exported as your settings show, and did not see any of the red that your export shows.

I’m assuming then its not anything to do with the processing, including filmic, highlight reconstruction or any other setting. I’m guessing its related to hardware, drivers or settings in the cpu/gpu/memory settings in dt.

Thank you for reporting this. It must then be something with my system: I haven’t a clue, though, about what it can be (except perhaps the uncalibrated screen as @Jade_NL suggested). This is a MacBook Pro 13" 2020 (no M1), and the screen should have a P3 color gamut.

Have you enabled “scene referred” in the settings? Make sure that is on. I noticed your history was very long. You may want to duplicate the raw, or reimport it and then try exporting from just the default adjustments. Then keep adding adjustments and exporting to see if its tied to one of the modules. You can also try processing it in other software - rawtherepee, or ART, or one of the commerical trial versions and see what happens.

Good luck!

Hi Brian, yes I am using a scene-referred workflow and have enabled the settings as such. I followed your advice, and reset the history: indeed, the red fringes appear as soon as I enable highlight reconstruction by moving the corresponding slider in filmic (in the standard pipeline, I only adjusted Exposure module, and did not touch the standard settings for white balance and color calibration). I also tried to switch off the module Highlight Reconstruction (which precedes demosaicing in the pipeline), or switch between the methods available therein (clip, reconstruct in LCh, reconstruct in color), to no avail.

At this point, I am inclined to attribute the artifact to some interaction between the filmic reconstruction component and perhaps, some Mac OS X related issue.

Thanks for your suggestions

Using the highlight reconstruction in combination with the filmic rgb reconstruction might not always work as expected (or put differently: Gives ugly results). I’ve got it turned off by default (the hc module) and if I use it in combination with filmic I tend to set it to reconstruct colour and do not touch the slider.

There are a few discussion floating around here on pixels about the best approach to highlight reconstruction, but some contradict each other (for example: turning off the hc module isn’t advised). Might be worth doing a search nonetheless to get some insights.

BTW: Something I’m not clear about reading back your replies. Is this a general issue or just specific to this specific image (and/or the other images from this set/scene)?

I’m asking 'cause I have come across individual images that just do not want to play nice or need a lot of massaging to get a half decent result. Just one of life’s annoyances I guess…

i was not able to reproduce this (using my latest build) - so at least it’s not a general issue. Maybe it’s just when using OpenCL because there are known issues with OpenCL especially with intel GPUs. So you might try to reproduce it using commandline option “–disable-opencl” to exclude this.

Thank you Martin, you may be onto something here.

There is no appreciable difference in the exported JPEGs with respect to the red fringes, running dt with or without opencl.

However, red fringes do appear (albeit not so evidently) in the dt interface at 100% zoom when disabling opencl. Kind of the opposite of what you would expect, but that’s what I am seeing…

I will add that using the latest mac binary provided by @MStraeten (3.5.0+1649), the red fringes get actually worse in the exported JPEGS (but there is no difference when using dt with or without opencl).

On the left the jpeg exported with opencl enabled, on the right the one with opencl disabled