When the display is set in wide gamut colours 10 bits/ channel the thumbnails are displayed with distorted colors as shown in the print screen that can be seen at the URL above. The image editor renders the pictures properly. The problem appears for JPG and RAW files. Other image editors such as darktable has no such problems, while rawtherapy behaves like digikam Reproducible: Always Steps to Reproduce: 1. open digikam 2. open a collection 3.
So, if i resume, only thumbnails view are touched by this problem. Image Editor and Preview work fine. Do you use lcms1 or lcms2 with digiKam ? Look in Help/Components Info for details. Gilles Caulier
Created attachment 89063 [details] Use of lcms 1 by digikam Gilles, I have both lcms1 and lcms2 on my system , but digikam uses lcms1 (v1.19). Is there a way to make digikam use the other version?
To use LCMS2, you must turn on cmake switch relevant. Look here : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/README#L128 Of course LCMS2 is recommend instead LCMS1. In the future LCMS1 support will be dropped. Gilles Caulier
Yes, this bug affects only the thumbnails. They must use a different rendered than the viewer/editor. Regarding lcms, I even disable colour management and the situation is unchanged. Look at the attachment to see that digikam uses lcms1 automatically although I have lcms 2.26 on my system too. Bogdan
I have digikam from OpenSuSE rpms. I'll need to compile it on my system to make digikam use lcms2. I'll try that over the weekend. Bogdan
I started compiling it now. You should fix the website that gives the wrong instructions fro getting the sources from the GIT repositories: https://www.digikam.org/download?q=download/GIT It is pointing to an old version, 3.2.
This is an interesting problem. I dont know the solution. Thumbnails are internally processed as QImage, all other data as DImg. That will not explain the problem because until this point, there is nothing known or assumed about the display. Does anyone know how the wide gamut is handled by X11 and Qt? I always believed that these only speak 8bit.
X11 and Qt4 (not QT5, yet, will be in QT5.4 when fully released) handle 10-bit channels. Here you can find a thread on the darktable flicker site where I contributed with information about how to enable it. In short you need Linux :-) a newer Nvidia card with Display Port and a wide gamut monitor. https://secure.flickr.com/groups/darktable/discuss/72157644287054058/#comment72157648503252685 Here there is an explanation how to prepare KDE/QT to do it. In short you need to enable the native rendering mode and not the default raster mode. I tested with KWin too, you don't need Compiz to make it work. http://www.oyranos.org/2014/05/image-editing-with-30-bit-monitors/ You can check you colour depth with this command $xdpyinfo If you have 30 bit colour depth you get something like depth of root window: 30 planes Below it is a 'small' output of the xdpyinfo tool name of display: :0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 11403901 X.Org version: 1.14.3.901 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 8 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 depth 30, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x4200bb6, revert to PointerRoot number of extensions: 29 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM NV-CONTROL NV-GLX RANDR RECORD RENDER SECURITY SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 2560x1440 pixels (650x366 millimeters) resolution: 100x100 dots per inch depths (8): 30, 1, 4, 8, 15, 16, 24, 32 root window id: 0x23f depth of root window: 30 planes <=== Here i number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 1024 preallocated pixels: black 0, white 1073741823 options: backing-store NO, save-unders NO largest cursor: 256x256 current input event mask: 0xfac033 KeyPressMask KeyReleaseMask EnterWindowMask LeaveWindowMask KeymapStateMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals: 168 default visual id: 0x21 visual: visual id: 0x21 class: TrueColor depth: 30 planes available colormap entries: 1024 per subfield red, green, blue masks: 0x3ff, 0xffc00, 0x3ff00000 significant bits in color specification: 11 bits visual:
The main difference that I see between the code paths is that the DImg-derived drawing is done by conversion DImg -> QImage -> QPixmap (GraphicsDImgItem::paint) and later drawing of this pixmap via a painter while the thumbnail pixmap is created by drawing a QImage on a QPixmap which is created empty (ThumbnailLoadThread::slotThumbnailLoaded), later this pixmap is drawn via a painter (ItemViewImageDelegate::drawThumbnail) You could try to edit line 742 of thumbnailloadthread.cpp so that the highlighting is not done to rule out that this step (drawing on empty pixmap) is the problem
Funny thing is that I could not build digikam from the 4.4.0 branch. The compiler chokes on this lines: 1) class SetupToolTip::Private =>setuptooltip.cpp:53:21: error: declaration of ‘class Digikam::SetupToolTip::Private’ in namespace ‘ShowFoto’ which does not enclose ‘class Digikam::SetupToolTip’ 2) qmlshow.cpp:54:1: error: qualified name does not name a class before ‘{’ token I don't have the time to chase the problem now. I'll try later next week.
I gave it one more try, I think I used the wrong repository which is pointed bu the main digikam site, you should fix that information to this one git clone git://anongit.kde.org/digikam This build fails again in a different place : faceutils.cpp: In member function ‘QList<Digikam::DatabaseFace> Digikam::FaceUtils::toDatabaseFaces(qlonglong, const QList<QRectF>&, QList<KFaceIface::Identity>, const QSize&) const’: /software/software/Graphics/Photo/digikam/utilities/facemanagement/faceutils.cpp:112:80: error: ‘class KFaceIface::Identity’ has no member named ‘attributesMap’ I think I have the right KDE/QT environment but I may be wrong. It does not seem so easy to build digikam on an Opensuse 13.1 system, there are too many versions hanging around.
You use older libkface version to compile digiKam. This patch must permit to compile digiKam in this case : http://commits.kde.org/digikam/85ec537be2c9cc5ffd9c15a567caa455b3c17254 Gilles Caulier
I thought that this may be the problem and I used 4.14 instead the 4.4.0 I had on my system., but still got the same issue. With you patch it compiled further to 81% but it hit a new problem: setuptooltip.cpp:53:21: error: declaration of ‘class Digikam::SetupToolTip::Private’ in namespace ‘ShowFoto’ which does not enclose ‘class Digikam::SetupToolTip’ class SetupToolTip::Private ^ /software/software/Graphics/Photo/digikam/showfoto/setup/setuptooltip.cpp:100:49: error: definition of ‘Digikam::SetupToolTip::SetupToolTip(QWidget*)’ is not in namespace enclosing ‘Digikam::SetupToolTip’ [-fpermissive] SetupToolTip::SetupToolTip(QWidget* const parent)
Commit http://commits.kde.org/digikam/a2dc9d1dc62e4d58727ba900852fb24436fb1c82 ...fix the problem ? Gilles Caulier
Created attachment 89123 [details] Digikam showing properly thumbnails on a 10 bit/channel display The thumbnails work fine now. Digikam showing properly thumbnails on a 10 bit/channel display.
Gilles, yes your patch allowed me to build digikam. Marcel, you were right too. The thumbnails display properly now. I commented out the highlighting code in ThumbnailLoadThread::slotThumbnailLoaded by putting in the if statement a false statement ( if (0) ). One problem remains with the frame around the thumbnails. It has strange colours such as pink, ultramarine, etc depending on the selected theme. It looks ugly in 10 bit per colour, but at least it is functional now. You can see digikam at work on a 10 bit/channel display here: https://secure.flickr.com/photos/45171664@N02/15346513737/ I also created an attachment #2 [details] with the same printscreen.
Your Frame color problem is not relevant of 10bits/channel support. I can reproduce this dysfunction here, if i use some bugous widget style and color scheme. Go to Setup/Misc and select Oxygen widget style. No go to Setup menu and change color theme. This must be better. Gilles Caulier
OK I assume that a "free empty" pixmap is using the raster paint engine which is apparently broken for 10bit/channel. You said you needed to force the native paint engine. Disabling the highlighting is hack / workaround. Ultimately, this must be fixed in Qt!
Yes QT has to fix many things. Until Qt5.4 the native rendering engine did not even work, even if the native paint engine was forced. Perhaps if more of us hammer them they are going to fix it. I added comments to a bug related to Qt5 being unable to render anything in 10 bits per channel. The result is that they fixed it in the upcoming 5.4, or at least this is what they claim. On another note, what is the highlighting code do? Why is it necessary? I din not test enough with and without it to figure that out. What are you going to do in digikam code until Qt fixes their problems?
It appears that GTK libraries do not haves suck problems related to colour management. I never though that I was going to discover something that GTK does better than Qt.
(In reply to bogdan from comment #20) > It appears that GTK libraries do not haves suck problems [...] Actually I was too quick to say that. Sorry. There are Gtk based applications such as Inkscape do not work. Reading here http://www.oyranos.org/2014/05/image-editing-with-30-bit-monitors it appears that are many Gtk2 applications that do not work but there is a patch for that. However, many others work, such as darktable and Gimp.
(In reply to Gilles Caulier from comment #17) > Your Frame color problem is not relevant of 10bits/channel support. I am not sure that you are right in this case. I am using the same settings for 8 and 10 bit/channel and the results are different. I use the Krita-dark theme and the frame around the thumbnail looks dark grey when using a 8-bit settings for the monitor. It is blue-pinkish when switching the display to 10 bits per channel settings. Bogdan
I am curious to know how far a functional QT5 KF5 digikam release is. I switched to Plasma 5 and the Thumbnail problem is still there, but this is again based on Qt4. I tried to compile digikam based on KF5 but I get errors because I don't have some libraries and I can't find them on my OpenSuSE 42.1 system. CMake Warning at cmake/modules/MacroLocalLibs.cmake:109 (find_package): By not providing "FindKF5KExiv2.cmake" in CMAKE_MODULE_PATH this project KF5KExiv2Config.cmake kf5kexiv2-config.cmake CMake Warning at cmake/modules/MacroLocalLibs.cmake:69 (find_package): By not providing "FindKF5KDcraw.cmake" in CMAKE_MODULE_PATH this project KF5KDcrawConfig.cmake kf5kdcraw-config.cmake CMake Error at cmake/modules/MacroLocalLibs.cmake:13 (find_package): Could not find a package configuration file provided by "KF5Kipi" (requested version 5.0.0) with any of the following names: KF5KipiConfig.cmake kf5kipi-config.cmake Is there anywhere I could find theres libraries? Thanks
the most easy way is to checkout digiKam code from git repository. Checkout the digiKam Software Compilation with git : git clone git://anongit.kde.org/digikam-software-compilation And follow instructions in README to checkout all relevant sub-project automatically. Take a care to set "export GITSLAVE=.gitslave.devel" before to be sure to download all that you needs... And read DEPENDENCIES file in root dir to see all extra needs to compile digiKam. Gilles Caulier
Digikam 5.0, which is based on Qt5.5 does not show the problem, while digikam 4.14 still has it. I suppose that since version 4 will be abandoned soon, we can close the bug.