https://bugs.kde.org/show_bug.cgi?id=376721
Bug ID: 376721 Summary: Poor quality colour management in Preview vs Editor Product: digikam Version: 5.4.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: ColorManagement Assignee: [hidden email] Reporter: [hidden email] Target Milestone: --- Background: digikam 5.4.0-2 from Arch Linux packages. My colour-management settings: enabled working = BestRGB Monitor profile = specified an ICC file generated from displayCal Use colour-managed view in editor: enabled Use colour-managed view for previews and thumbnails: enabled Advanced: Use black-point; perceptual Problem: I am working with the image http://misc.sty.nu/IMGP0431_1-large_v1.tiff (21MB) which uses the ProPhotoRGB-linear profile. In the preview it looks utterly ghastly, with massively quantized shadow areas. See http://misc.sty.nu/digikam-screenshot-preview.png However, in the editor it looks fine: http://misc.sty.nu/digikam-screenshot-editor.png (I used the "keep" option on opening, so there remains a ProPhotoRGB->monitor-space transformation in place to display this.) This inaccuracy in the preview makes it difficult to compare/rate images that rely on shadow zones in ProPhotoRGB-linear space. I have tried varying the colour-management Advanced settings and no combination of blackpoint compensation nor rendering intent makes it go away - and some look even worse. The problem does go away when I convert the image to sRGB, but changing now would be premature in the workflow - there are lots of blends and edits pending in multiple utilities yet. I would understand if it was my monitor calibration profile being low quality, but how come the editor can get it right, so why can't the preview show the same thing? -- You are receiving this mail because: You are the assignee for the bug. |
https://bugs.kde.org/show_bug.cgi?id=376721
Maik Qualmann <[hidden email]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[hidden email] --- Comment #1 from Maik Qualmann <[hidden email]> --- Your image has 14 bits. The preview load for speed reasons images only in 8 bits. The Image Editor can load 16 bits images. Maik -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=376721
Maik Qualmann <[hidden email]> changed: What |Removed |Added ---------------------------------------------------------------------------- Latest Commit| |https://commits.kde.org/dig | |ikam/0ca4c66af71b2364d69d28 | |cdff4e5364e42db28a Version Fixed In| |5.5.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Maik Qualmann <[hidden email]> --- Git commit 0ca4c66af71b2364d69d28cdff4e5364e42db28a by Maik Qualmann. Committed on 24/02/2017 at 20:29. Pushed by mqualmann into branch 'master'. make it possible to disable converting preview image to 8 bits FIXED-IN: 5.5.0 M +2 -1 NEWS M +2 -0 libs/settings/applicationsettings.cpp M +1 -0 libs/settings/applicationsettings_p.cpp M +1 -0 libs/settings/applicationsettings_p.h M +6 -4 libs/threadimageio/previewsettings.cpp M +2 -2 libs/threadimageio/previewsettings.h M +4 -1 libs/threadimageio/previewtask.cpp M +20 -12 utilities/setup/album/setupalbumview.cpp https://commits.kde.org/digikam/0ca4c66af71b2364d69d28cdff4e5364e42db28a -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=376721
--- Comment #3 from Tim <[hidden email]> --- Many thanks! -- You are receiving this mail because: You are the assignee for the bug. |
Free forum by Nabble | Edit this page |