Project

General

Profile

Bug #11649

Severe image quality regression after upgrade, most noticeable in gradients

Added by Matt Daubert about 2 years ago. Updated about 2 years ago.

Status:
Incomplete
Priority:
Low
Assignee:
-
Category:
General
Target version:
-
Start date:
06/10/2017
Due date:
% Done:

20%

Estimated time:
Affected Version:
2.2.1
System:
other GNU/Linux
bitness:
64-bit
hardware architecture:
amd64/x86

Description

After upgrading to Darktable 2.2.5 my photos now suffer from severe quality issues making Darktable essentially unusable. This affects both newly imported photos and opening photos imported from previous versions. I installed multiple older versions until I found that 2.2.0 is the most recent version that works okay and 2.2.1 is where the problem begins. Screenshots of both versions are attached. The screenshot for 2.2.0 seems okay to me while 2.2.1 has extremely poor gradient rendering to the point where it almost looks like a cartoon (notice the faces and rocks). The photo in the screenshots are unmodified, both versions are opening the same file. Every photo I've opened using version 2.2.1 through 2.2.5 suffers this problem to some extent.

I'm running Darktable on two different machines, both running Arch Linux. Both machines exhibit the same behavior after upgrading Darktable. Both machines exhibit the same behavior when Darktable is run in Xorg and Wayland.

I'm happy to try additional steps to narrow down where the problem may be if someone can offer suggestions.

Thank you!

Screenshot from 2017-06-03 18-12-41.png (3.87 MB) Screenshot from 2017-06-03 18-12-41.png Darktable 2.2.0 Matt Daubert, 06/10/2017 08:18 PM
Screenshot from 2017-06-03 17-46-32.png (3.95 MB) Screenshot from 2017-06-03 17-46-32.png Darktable 2.2.1 Matt Daubert, 06/10/2017 08:18 PM

History

#1 Updated by Roman Lebedev about 2 years ago

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

So 2.2.0 is fine and 2.2.1 is broken?
That is really weird.
In $ git log --reverse release-2.2.0..release-2.2.1
I don't really see any obvious candidates...

Can you build by yourself?
If yes, first try building 2.2.0 and check that self-built dt exhibits the problem

#2 Updated by Tobias Ellinghaus about 2 years ago

Please

  • include the history stack in the screenshots
  • start darktable from a shell and check for error messages there
  • try setting the display profile to sRGB in both versions and see if that helps. This looks a lot like a color management problem.

#3 Updated by Matt Daubert about 2 years ago

Thanks for your help!

TLDR: I think my ICC profiles are the culprit. I suspect that the issues fixed by 406f46 and 0244d7 may have been masking the real issue but I'm having trouble building versions that old from source so I can't do a git bisect to say for sure.

Steps I took:

Both machines are using custom color profiles from a Spyder5 so a color mananagement problem seems suspect to me. I installed 2.2.5 and switched the display profile to sRGB - photos look fine again after the previews rebuild.

When I disable OS color management prior to starting Darktable, photos look okay (not cartoony) in Darktable in both sRGB and system display profile (not surprised).

When I enable OS color management while Darktable is running, photos still look okay (not cartoony) and it appears that color correction is being applied (though perhaps not correctly, hard to tell).

When OS color management is enabled prior to starting Darktable, I continue to see problems. I also switched to a manufacturer-provided ICC profile with the same results. I'll run a verification on my ICC profile when I get a few hours that I don't need my machine.

Output of darktable-cmstest in 2.2.0, 2.2.1, 2.2.5 all the same except for the version:

darktable-cmstest version 2.2.5
this executable was built with colord support enabled
darktable itself was built with colord support enabled

couldn't locate primary CRTC!

XWAYLAND0    the X atom and colord returned different profiles
    X atom:    _ICC_PROFILE (873112 bytes)
        description: XWAYLAND0 #1 2017-02-09 22-24 160cdm2 D6500 2.2 S XYZLUT+MTX
    colord:    "(none)" 
        description: (file not found)

Better check your system setup
 - some monitors reported different profiles
You may experience inconsistent color rendition between color managed applications

After seeing that message I switched the display profile method to xatom in the global settings, restarted Darktable, but didn't help (when also set to system display profile).

While trying these things I ran Darktable from a terminal and there was no std{out,err} output from Darktable.

That makes me think that something isn't setup correctly on my machine. Why I'm seeing a regression from 2.2.0 -> 2.2.1 baffles me. I'd like to do a git bisect to determine the exact commit that changes the behavior for me, but, I'm having trouble building 2.2.1 from source from right (2.2.5 is building just fine).

#4 Updated by Roman Lebedev about 2 years ago

Matt Daubert wrote:

Thanks for your help!

TLDR: I think my ICC profiles are the culprit. I suspect that the issues fixed by 406f46 and 0244d7 may have been masking the real issue but I'm having trouble building versions that old from source so I can't do a git bisect to say for sure.

Steps I took:

Both machines are using custom color profiles from a Spyder5 so a color mananagement problem seems suspect to me. I installed 2.2.5 and switched the display profile to sRGB - photos look fine again after the previews rebuild.

When I disable OS color management prior to starting Darktable, photos look okay (not cartoony) in Darktable in both sRGB and system display profile (not surprised).

When I enable OS color management while Darktable is running, photos still look okay (not cartoony) and it appears that color correction is being applied (though perhaps not correctly, hard to tell).

When OS color management is enabled prior to starting Darktable, I continue to see problems. I also switched to a manufacturer-provided ICC profile with the same results. I'll run a verification on my ICC profile when I get a few hours that I don't need my machine.

Output of darktable-cmstest in 2.2.0, 2.2.1, 2.2.5 all the same except for the version:

[...]

After seeing that message I switched the display profile method to xatom in the global settings, restarted Darktable, but didn't help (when also set to system display profile).

While trying these things I ran Darktable from a terminal and there was no std{out,err} output from Darktable.

That makes me think that something isn't setup correctly on my machine. Why I'm seeing a regression from 2.2.0 -> 2.2.1 baffles me. I'd like to do a git bisect to determine the exact commit that changes the behavior for me, but, I'm having trouble building 2.2.1 from source from right (2.2.5 is building just fine).

Unless you actually show what the problem is, i'm not sure how to help solve it.
I would guess you may want to comment-out https://github.com/darktable-org/darktable/blob/26f2e2d624fc062df56ec87db28a95f710c2dae6/src/CMakeLists.txt#L576

#5 Updated by Tobias Ellinghaus about 2 years ago

This might also be a Wayland problem. Could you try running dt on a system using X11 please?

Another thing to try is copying your display profile ICC to ~/.config/darktable/color/out/ and select the profile manually in the display profile selection box. Does that also show the banding?

Also available in: Atom PDF

Go to top