darktable export bug: photo changes depending on pixel size

I’ve just realized the export module has apparently a bug… at least for me.
Look at the 2 following exported jpeg:


The only difference between them is the setting for pixel size in the export module.
I think there is something off, right? The one a lower resolution is not properly exported… and now I suspect a bit any sort of resizing, too…
It’s not the only picture where I’ve seen this difference, but in this is very apparent.

I have darktable 3.6.1 installed in Ubuntu 20.04 through OBS. Is it maybe a known bug already resolved? Or should I open an issue in GitHub?

Are you used ng openCL?

Yes, I think I do.

Ok wait… it happens also at full resolution (setting the export module to 0x0 pixels).
If I set the size to 3840x3840 the jpg looks ok…

So, it seems now I have a problem… I can export only to some magic resolution…

and disabling OpenCL has yet another output altogether again…


(compare to the top one in the main post, identical settings, but OpenCL disabled)

Not sure what the problem is, I’d open an issue.

Thanks, opened an issue.

This seems really strange that different part appear to be blown out depending on your scaling??? Can you share the raw file if possible??

You can find the raw and xmp in the issue.

1 Like

I found the same if I export to tiff (32bit float).
So, right now, I really can use darktable… I try now with a different Nvidia driver (even though it’s beyond me how that could affect anything except performance…)

Exporting to OpenEXR is even worse, the photo has the same “damages”, plus a lot of noise and no contrast (but to be honest, I don’t really know how to deal with this format).

Edit: as expected, updating Nvidia driver to 470 (from 460) has no effect.

have you activated high quality upsampling in the export options?

1 Like

I think I can confirm this. Exported at low res looks ok, full size is broken.


using dt 3.7 git master

I tried both.
In general, I’m reporting my findings in the GitHub issue (linked before).

I think it would be beneficial to add consensus there, so priority goes up and it can be addressed.

EDIT: if it can be useful to someone, my current workaround is to set “set size” to “by scale” and a value of 0.99. It’s not full res, but at least it works. I then resize the image to the desired size with another tool (for batch resize I use digikam, it works nice for me on JPG files).

Can you discard the history, start from scratch and redo the edit?
If I load the sidecar file, I get the same broken export but as I am trying to find out which module causes is I cannot recreate it.

As noted by @kofa in the GitHub issue, it seems haze removal is causing it (issue not present when disabled for both our setups).

Interesting…I feel like there recently was another issue reported that seemed to be resolved by disabling dehaze…can’t recall what it was. I assume you have noticed this on other images as well not just this one…

I’ve started noticing something on another similar image, in which however the abrupt dynamic range was not so extreme. We can say that this was a challenging image, that other one not so much.
Anyhow, I think I started noticing something in an area with clouds in that image: I had exported 2 versions of the image, identical except the size.
One was an HD, the other a 4K. Well, feeling there was something off I did a few tests, for instance looking at them side by side at a level of zoom that made them same size on the screen, and they were clearly different.
To rule out something given by the resizing of the desktop made by the OS, I took the 4K one, resized to HD with Gimp and then looked at them again. Now they appeared to be identical (as expected, the look should be extremely similar, even if the size is different, if the pics are looked at a zoom level that does not upscale).
At that point I was not sure if it really was a bug, the difference was not really a thing… but then while working on this other photo from the same shooting, I realized how much more clearly this bug was showing in this picture and resolved to publicly complain about it :wink:

For me this is what I see with exporting…ie that the look of export is tied to the scaling factor not what the preview looks like…this is 1 by default. So your export will look at the detail level like a 100% sized display preview version… at any other display preview size the export will not match ie it will have the level of detail shown at 100%…if you however you export with a scale to match…say for me around 25% is about what full screen preview size is …then the jpg and display preview match as they have both been scaled the same amount…So a jpg exported at 0.25 will look way more like the full screen preview than one exported with the scale set to 1…at least in my experimentation…similar discussion going on here… Denoising high-ISO images: a sourdough bread - #96 by priort

Once you start to play with all the resizing and preview combinations there may be other considerations but in direct limited testing this is what I see…

I’m not sure I’m following you here…
Anyhow, I just told the little story to describe how I could verify that the “rescaling feature” in darktable is broken (=does not work as a state-of-the-art image rescaling feature should).
As a matter of fact, even “disabling” this rescaling yields broken results, so I guess there is something off with the exporting from the module pipeline to output file.

You can’t really disable rescaling of your screen…if you have your screen set to anything other than 100% there is some rescaling of your image…How this rescaling is translated to the output when you export or print is another issue…My observation was that if the scale factor was 1 when you exported then that jpg would match your preview only if the display was set to 100%…so open the raw set display to 100 and then advance to the jpg you just exported…the zoom level will stay at 100 percent and they will look similar wrt to detail noise and artifacts…Now keeping in mind most people likely export after viewing the full screen view or after being satisfied with the look there which will be something around 25%, I have found to match what you see at full screen ~25% you need to set the scale factor to 0.25 and do an export. Then you repeat the exercise…this time view the raw at full screen not 100% and then take a snapshot and then advance to the jpg saved with 0.25 scale factor…they will be very similar…I feel this is because they have both been scaled in a similar way…So my conclusion from a very limited sample of 3 or 4 images is that the jpg output wrt to detail will not be well represented by the displayed image in DT unless you are at 100% or you scale the export to match the degree of screen scaling in your preview…not sure if that explains if any better… I think this is why people are noticing more noise in the exported Jpg as they use the default scaling factor on export of 1 which will create a jpg with the level of noise that you have when viewed at 100%… This could be an oversimplification but just what I seem to have observed…