CMYK Support about qgis-enhancement-proposals HOT 22 OPEN

I would agree to @frspp: In my previous workflows done with ArcMap the assignment of icc profile was done in Illustrator.

from qgis-enhancement-proposals.

In order to be able to transform colors dynamically, we need to be able to identify symbol layer color attributes. To achieve this, QgsSymbolLayer class and those which inherits from it should use the Q_PROPERTY macro to expose theirs attributes as properties.

Why not just add a virtual method "applyColorTransform" and let each subclass decide how best to handle this? It would make it much cleaner for eg the raster/svg subclasses which need the extra logic.

from qgis-enhancement-proposals.

Thanks!

few notes:
In my workflow the (CMYK) pdf will be anyways imported to Indesign and there I can & will assign a icc profile anyways so in that sense choosing a specific ICC CMYK profile in QGIS is not a must.

If document color mode is CMYK would be very useful to see warning if there is any RGB colors in use.

IMO Color mode belongs to Document properties (like in Indesign), not into Styles.

from qgis-enhancement-proposals.

Why not just add a virtual method "applyColorTransform" and let each subclass decide how best to handle this? It would make it much cleaner for eg the raster/svg subclasses which need the extra logic.

To have a more generic approach, avoid duplicate code which are error prone, ease maintenance if we want to change the way we transform color.

from qgis-enhancement-proposals.

@troopa81

I really like the rest of the proposal, but I strongly disagree with a property based approach for color handling

have a more generic approach, avoid duplicate code which are error prone, ease maintenance if we want to change the way we transform color.

On the contrary, going with a qt based introspection is likely to lead to ongoing issues. My arguments against would be:

1. We leave behind the security of compile time checks
2. We are relying on qt specific functionality. While we get a lot of benefits from qt, experience has taught me that in cases where we can avoid qt-isms and stick (without loss of performance/ functionality) with standard libraries we should. By using standard c++ we are sticking with mainstream approaches, which means less likelihood of issues and higher chance of optimisations in the compiler, and no risk of qt deprecating things we've come to rely on.
3. The property system is pretty clunky for access via python
4. Using introspection rather then a virtual method makes the code less maintainable. Eg I can't use an ide to find places where the property is accessed. (It also breaks static analysis tools)

from qgis-enhancement-proposals.

I would assume CMYK view without ICC would give a good color match to general printing on coated paper which has a wide color gamut (I mean wide on cmyk scale; such as Fogra39 profile; total ink around 350% I recall).
--> I would suggest that if user has not selected ICC, preview with some "generic" CMYK coated ICC profile such as Fogra39.

Noted, Krita has also a default ICC profile, which would be better than the default "naïve" conversion. I'm gonna amend the QEP to state that QGIS will embed a default ICC profile selected as soon as you select CMYK color space

from qgis-enhancement-proposals.

@troopa81

This is an implementation detail

Agreed 👍 how about dropping these details from the qep and we'll discuss them in depth when it's time to start coding? From a high level perspective this qep looks great and I don't really want to get side tracked on specifics either!

from qgis-enhancement-proposals.

@eurojam @frspp Thanks for you comment, that the kind of user workflow details I am looking for.

If you don't set the ICC profile in QGIS, you cannot have an on-screen estimated rendering of what it would look like on paper.

Maybe you don't care but how do you manage to choose correctly your color for your map ?

Krita for instance offers the option to select the ICC profile for the document.

from qgis-enhancement-proposals.

I can describe one of my previous workflows when I used ArcMap. The goal was to make a paper map, for example "geology map". Our customer has a list of color values in CMYK for each geology unit displayed in the map.

In ArcMap there is no need to define or asign the color model to the project. If you choose a color for "unit 1" you will have three color options: RGB, HSV and CMYK. In the CMYK dialog I will enter the values given for unit 1 (see image below...)

After finishing the map and Layout the next step starts, postprocessing in Adobe Illustrator which starts with the export of the map (layout). Depending on the export format, ArcMap offers different color spaces (CMYK for PDF, AI, EPS)...

Preparing the final print version will be done in Adobe Illustrator, which has a lot of possibilites in PDF formats, ICC profiles and so one.

I am not sure, if QGIS should cover all theese steps?

from qgis-enhancement-proposals.

@eurojam Thank you for the workflow description

Setting ICC profile is interesting for 2 things:

• Writing it in PDF output file
• On-screen rendering

Like you said, the first one could be done with another tool, even though it would be better to have it directly set by QGIS else user would have to be informed that there is another needed step to have a fully compliant CMYK PDF.

Regarding the second one...

Our customer has a list of color values in CMYK for each geology unit displayed in the map

IMHO the tricky point is here because the CMYK color has to be defined regarding a given colorspace i.e the ICC profile used for printing. In your situation, you get the color and ICC profile from a customer so you don't really care about on-screen rendering but I can imagine that some users would like to fine pick the CMYK and check an overall rendering as close as possible as what it look like on a paper.

I don't know if such user really exists (if so, please raise your hand 🙋 ) and if this is needed

I am not sure, if QGIS should cover all theese steps?

Me neither 🤷‍♂️ , I would say yes !

from qgis-enhancement-proposals.

@troopa81 I can imagine that some users would like to ... check an overall rendering as close as possible as what it look like on a paper.
Yes, everyone likes WYSIWYG :)

I would assume CMYK view without ICC would give a good color match to general printing on coated paper which has a wide color gamut (I mean wide on cmyk scale; such as Fogra39 profile; total ink around 350% I recall).
--> I would suggest that if user has not selected ICC, preview with some "generic" CMYK coated ICC profile such as Fogra39.

And if map will be printed on uncoated paper then the designer should itself know that he/she needs to preview with preview with uncoated ICC (such as Euronewspaper26), as the total ink is only around 240% I recall and by that the color space is much narrower.

from qgis-enhancement-proposals.

@nyalldawson This is an implementation detail and I can live with a virtual method (which could call a function which would transform an array of given color members) but I would like to avoid as much as possible things like this or that where IMHO, there is too much copy-paste code.

1. We leave behind the security of compile time checks

I get your point but it is a classic use of reflection mecanism. Q_PROPERTY define statically a member with a pair of getter/setter, and the code will go through QColor only properties to read/write QColor, so I don't really see what compile time checks we would miss.

2. We are relying on qt specific functionality. While we get a lot of benefits from qt, experience has taught me that in cases where we can avoid qt-isms and stick (without loss of performance/ functionality) with standard libraries we should. By using standard c++ we are sticking with mainstream approaches, which means less likelihood of issues and higher chance of optimisations in the compiler, and no risk of qt deprecating things we've come to rely on.

I would be in favor of relying less on qt-isms but what exactly is the policy here, because I count more than 300 Q_PROPERTY in QGIS code. It looks like we don't use QMetaClass/QMetaProperty though, so I imagine that we don't use Qt reflection system on purpose, for the reasons you just described.

3. The property system is pretty clunky for access via python
4. Using introspection rather then a virtual method makes the code less maintainable.

Is it really? I would say it's widely used for good reason 🤷‍♂️

from qgis-enhancement-proposals.

Agreed 👍 how about dropping these details from the qep and we'll discuss them in depth when it's time to start coding? From a high level perspective this qep looks great and I don't really want to get side tracked on specifics either!

I'm gonna edit the QEP to state that the color transformation is still to be determined

from qgis-enhancement-proposals.

CMYK color definition is only meaningfull if it is done respectfully to the color space targeted for printing. If a user wants to work with CMYK colors, he needs to select the ICC profile of the device he plans to print on. This has to be done in the early stage of its project definition, meaning in project properties.

I know this might be out of the scope of this proposal, but can it be implemented with color management in mind? Right now, QGIS like Qt itself is assuming sRGB output. But color industry professionals have AdobeRGB-screens since forever, and the general public is getting more and more P3-display capable screens. It's useless to provide a ICC for the paper output and then just assuming the screen will be sRGB. Also, most "sRBG" screens out there are horribly misconfigured and don't even produce a picture within the range of the sRGB standard.

So, without color management, I propose to ditch the ICC-profiles completely and warn users, that the colors on the screens do not represent the paper output! Without color management one can use the CMYK colors like index colors. You or your printer predefine the colors, you set them as CMYK in QGIS, the screen doesn't match the later output, which is fine, because you'll be softproofing in a color managed application, or your allowed colors for the map have been already set in advance.

Color picker has to be modified to allow selecting a color in CMYK color space. I propose to add a combo box in order for the user to select the color model, either RGB/HSV or CMYK.

Color picker and all gradients in QGIS have suffered under the current implementation. There is always linear blending between the RBG values (128,128,128 is not neutral gray!), but the output is rendered with gamma 2.2. For proper RGB gradients, one would need to perform mixing with linear gamma and convert it to display gamma. Same for the color space. A green, defined in sRGB, might be way to bright on Display-P3 or AdobeRGB.

And CMYK mixing will give completely different gradients, as the color model is fundamentally different!

Implement Color ramp

A CMYK color interpolation algorithm has to be implemented using CMYK components without converting to RGB. A classic linear interpolation will be applied on each component like it is done for RGB interpolation algorithm.

Generating PDF

Print services often requires PDF/X format as input. This PDF format is specially adapted for printing because it enforces some already existing PDF features being mandatory when it comes to printing. Fox example, embedding fonts to be sure that the rendering would be the same for printer for instance.

Qt does not support this format at the moment. It does not allow setting the color profile for the output PDF file neither . These two limitations will have to be removed if we want to be able to print a correct CMYK PDF file.

PDF/X format (when available) will be choosen over default PDF 1.4 version when the user selects a CMYK color model in his project.

Rendering

As described above, when choosing to work in CMYK mode, we target a specific printer for the generated PDF layout/report. In that case, users may want to have an on‑screen preview of how their document’s colors will look, when reproduced on this specific device.

This only works, if the user's screen is exactly adhering to the sRGB-standard. For proper display, you need a calibrated and profiled screen and color management in your app. Or, you do it like in video and film and have a monitor with properly set primaries, then you don't need to profile.

Qt applies a default "naïve" transformation for colors defined in CMYK mode when it comes to draw on an RGB device.

In order to get closer to what the color will actually look like on the printing device, we need to use QColorSpace to load selected ICC profile file, and create a QColorTransform to transform CMYK defined colors from the selected ICC profile to the sRGB color space QColorSpace::SRgb, which Qt operates in by default.

As a consequence, when CMYK mode is enabled, we need to convert all colors before painting.

We could consider develop soft-proofing in order to transform raster RGB working colors to CMYK space and then to screen device, so we can have a better estimation about how raster would look like when printed. This option has been developed in software like Krita or GIMP but I am not not sure that this would be something that QGIS users are interested in. For now, I consider it beyond the scope of this QEP.

This definitely needs color management and a complete overhaul of how colors are internally represented. You need to do all color work internally in a color space big enough to fit at least sRGB and ISO-coated, do all the calculations in linear gamma and convert only the output, on the fly, to display gamma and display color space.

QGIS would need to remove its own, Qt-based painting engine and switch to e.g. krita's, as Qt is not color managed at all and always assuming RGB and sRGB.

Currently, most users don't need color management. Only a fraction of GIS mapmakers actually calibrate and profile their screen. If they produce paper maps, they will likely get printed with desktop printers (I also conflate laser printers and ink plotters of copy shops into that category) and not offset printers. Or the maps will be viewed on uncalibrated and unprofiled computer screens. If your map will end up on a offset printer, you either have the expertise to set the colors or you hopefully have someone else to set it for you. Already being able to set CMYK colors directly would be of great use, as one can define all black lines and text as pure black.

So, I would leave out everything, that only results in a half-hearted attempt on color management. So no ICC-profiles for CMYK unless there is also a way to convert to display gamut and not just sRGB. And think about a solution for color mixing, since without color management, RGB and CMYK will yield visually different results.

from qgis-enhancement-proposals.

@troopa81

I would be in favor of relying less on qt-isms but what exactly is the policy here, because I count more than 300 Q_PROPERTY in QGIS code. It looks like we don't use QMetaClass/QMetaProperty though, so I imagine that we don't use Qt reflection system on purpose, for the reasons you just described.

I realise we're deferring this conversation, but I forgot to answer this bit to fill you in! Q_PROPERTY is only currently used in QGIS code for the sole purpose of exposing things for use in QML (ie by QField/Mergin client), or for custom widgets which are designed to be usable within Qt Designer. That's why there's a lot in master.

from qgis-enhancement-proposals.

@tannenfreund87 Thank you for your valuable comment. I am not an expert in that particular area so any comment is helpful to provide the best implementation in QGIS.

I know this might be out of the scope of this proposal, but can it be implemented with color management in mind? Right now, QGIS like Qt itself is assuming sRGB output. But color industry professionals have AdobeRGB-screens since forever, and the general public is getting more and more P3-display capable screens. It's useless to provide a ICC for the paper output and then just assuming the screen will be sRGB. Also, most "sRBG" screens out there are horribly misconfigured and don't even produce a picture within the range of the sRGB standard.

For now, I proposed a technical solution which makes only one conversion, from the ICC profile CMYK color space to the sRGB Qt output, but we could apply several transformations and have an extra transformation to the screen colorspace. Do you think it would be enough to implement what you're calling "color management"?

It would require thorough testing to check if it is actually working/relevant.

So, without color management, I propose to ditch the ICC-profiles completely and warn users, that the colors on the screens do not represent the paper output! Without color management one can use the CMYK colors like index colors. You or your printer predefine the colors, you set them as CMYK in QGIS, the screen doesn't match the later output, which is fine, because you'll be softproofing in a color managed application, or your allowed colors for the map have been already set in advance.

I tend to disagree here. Imagine a user creates a QGIS project and sets up its CMYK colors to match a specific printer. Then imagine another user taking over this QGIS project without any communication with the former user. If there is no ICC profile within the project, he has no idea in what color space CMYK colors are described and he has to review all its color to match a new printer/colorspace.

IMHO color space are like projection for coordinates. The later are kind of useless if you don't know in what projection they are used.

PDF/X specification format forces to embed the targeted color space in the PDF file, so I would say that it's relevant to embed it in the QGIS project.

This only works, if the user's screen is exactly adhering to the sRGB-standard. For proper display, you need a calibrated and profiled screen and color management in your app

Anyway, I think you would never have perfect paper rendering on screen, the goal is to get closer as possible, and yes it does require a calibrated screen. Regarding color management in app, see my first comment.

QGIS would need to remove its own, Qt-based painting engine and switch to e.g. krita's, as Qt is not color managed at all and always assuming RGB and sRGB.

Could you elaborate about what Qt is missing to be color managed?

Currently, most users don't need color management. Only a fraction of GIS mapmakers actually calibrate and profile their screen. If they produce paper maps, they will likely get printed with desktop printers (I also conflate laser printers and ink plotters of copy shops into that category) and not offset printers. Or the maps will be viewed on uncalibrated and unprofiled computer screens. If your map will end up on a offset printer, you either have the expertise to set the colors or you hopefully have someone else to set it for you. Already being able to set CMYK colors directly would be of great use, as one can define all black lines and text as pure black.

To be honest, I asked myself this very question from the beginning, What do users actually want ? Like what ArcGIS proposes maybe (and I don't know exactly what's the CMYK color suppport in ArcGIS ?

You mentioned Krita in your comment. QGIS, like this software, can be used to produced output that would be printed using offset printers. And Krita proposes to select the ICC profile and to work regarding this ICC profile. So why not proposing this in QGIS?

And think about a solution for color mixing, since without color management, RGB and CMYK will yield visually different results.

What do you mean by color mixing ? You mean blending a color when painting over another ? When on-screen rendering, it will indeed be done in RGB, not in CMYK color space, so you would not get the color you would get on paper. You would have the issue only if you have transparency but that's a limitation we can live with I think.

from qgis-enhancement-proposals.

I realise we're deferring this conversation, but I forgot to answer this bit to fill you in! Q_PROPERTY is only currently used in QGIS code for the sole purpose of exposing things for use in QML (ie by QField/Mergin client), or for custom widgets which are designed to be usable within Qt Designer. That's why there's a lot in master.

That makes complete sense. I think using property is not fondamental here and I can avoid duplicate code with helper methods.

from qgis-enhancement-proposals.