WYSIWYG Printing colours

[arenol]

The colours, particularly the cyan colour, is far from realistic compared to the printing colours.

Here's an algorithm that will, reasoably accurate, convert CMYK to RGB that are within the printing gammut:

(c, m, y and k) are in the range 0 to 1, and so are will the rgb's be:

        double r = (1.0 - c) * (1.0 - m * 0.098) * (1.0 - k);
        double g = (1.0 - c * 0.376) * (1.0 - m) * (1.0 - y * 0.070) * (1.0 - k);
        double b = (1.0 - c * 0.109) * (1.0 - m * 0.505) * (1.0 - y) * (1.0 - k);

[krticka]

If it works well, I consider it beneficial. The biggest problem I see with the current appearance of 100% blue, for some mapping projects I even adjust its definition to achieve better readability on the display.

[dg0yt]

The colours, particularly the cyan colour, is far from realistic compared to the printing colours.

Fair enough.

Here's an algorithm that will, reasoably accurate, convert CMYK to RGB that are within the printing gammut: ...

Which environoment did you test these formulas with? Are there any references?

This is what I learned in the past:

• Color "numbers" are usually considered meaningless without naming the color space (color profile). Here, RGB and CMYK are simply device-dependent. References: https://en.wikipedia.org/wiki/CMYK_color_model#Conversion
  https://community.adobe.com/t5/indesign-discussions/formula-to-convert-cmyk-to-rgb-or-rgb-to-cmyk/m-p/2581706
• "Device dependent" implies that visual results might be quite different for Windows vs. macOS vs. Linux vs. Android vs. printer models and drivers.

The CMYK/RGB conversion isn't part of Mapper's source code, but implemented in the Qt framework. This doesn't mean we couldn't integrate improvements. I'm just stating the fact.

[lpechacek]

As an illustration.

Top left: OO Mapper (current master), Top middle: Evince displaying a PDF exported from OCAD Viewer in CMYK color space. Top right: LibreMapper with the proposed code change from comment #0. Bottom middle: OCAD Viewer.

The patch.

diff --git a/src/core/map_color.h b/src/core/map_color.h
index e3a401eca273..0f2a8baf0844 100644
--- a/src/core/map_color.h
+++ b/src/core/map_color.h
@@ -579,7 +579,11 @@ MapColorCmyk::MapColorCmyk(const QColor& other) noexcept
 inline
 MapColorCmyk::operator QColor() const
 {
-       return QColor::fromCmykF(c, m, y, k);
+       double r = (1.0 - c) * (1.0 - m * 0.098) * (1.0 - k);
+       double g = (1.0 - c * 0.376) * (1.0 - m) * (1.0 - y * 0.070) * (1.0 - k);
+       double b = (1.0 - c * 0.109) * (1.0 - m * 0.505) * (1.0 - y) * (1.0 - k);
+
+       return QColor::fromRgbF(r, g, b);
 }

 inline

IMHO, it makes sense to make this change configurable as the differences in map appearance are substantial. In any case, I like the proposal. Thanks!