Created attachment 130308 [details] Multiply and screen blending modes SUMMARY Multiply and Screen blending modes in CMYK document are calculated wrong. They appear to have been swapped. Additional thoughts 1. It could be that the cause of this error is the inverse color calculation for the CMYK color space. I have not examined the behavior of other blending modes. 2. If document is saved in psd format and opened in Photoshop everything looks fine.
Yes this is a known thing and it is by design. CMYK and RGB color spaces are opposite of each other one is subtractive and the other is additive. So the calculations show opposite result for the same blending mode. The documents look fine in photoshop may be because photoshop reverses the calculation based on the color profile used. There was a discussion about this some time back and I think it was preferred to keep the calculations intact and not show pseudo results.
This is so uncommon in print industry. I gave example of Photoshop but multiply in CMYK works the same way in every software (raster, vector, layout, imposition) I worked with for 20 years (Agfa, Corel, Qaurk, Adobe,...). I respect your decision, but I think it is not wise to go against industry standard. It is not about what is wrong or right, rather, it is what is expected from professionals preparing their artwork for prepress/press. CMYK is a subtractive color model, meaning adding /e.g. multiplying/ all colors together produces rich black/Registration. Multiply should have the same visual output as overprint. I wish Krita nothing but best. This thing would be small step to make Krita more appreciated from people involved in press industry, rather than dealbreaker.
Yes I don't refute your bug report. And I am not a developer, I merely stated what I know :) . I didn't close the bug report. I also don't question your intention of wishing krita the best. Let us hear what the developers have to say. > This thing would be small step to make Krita more appreciated from people > involved in press industry, rather than dealbreaker. I assume you believe that there are many more steps to make Krita not be a deal nreaker, so I politely ask If you want to discuss other bigger steps , if yes please make a thread on krita-artists.org, Where you will get inputs from developers as well as other users. Meanwhile let us keep this bug report only for technical detail.
OK. Second paragraph in my comment 2 is technical detail that is in line with yours but a little bit more in depth (prepress perspective).
Hi, nicola! Krita technically supports such blending, though there no proper GUI for that yet. You can workaround your problem with the following steps: 1) Create an image in decently wide RGB color space, in which you want blending to happen. It must *not* be sRGB, which is too narrow. 2) Drag&Drop CMYK(!) layers into this image (either from a TIFF file or from another Krita document) 3) Now your blending modes will work as expected. NOTE: You can also create layers in the image itself, but later convert them with Layer->Convert->Convert Layer Color Space
Dmitry, thanks for the hint and I tried it. Unfortunately, I didn't seem to be clear. 1. Workaround for standard*1* multiply would be to select screen blending mode and vice versa. Thus, the whole process is without changing the color space and/or profile (so no unwanted color transformations) and with the expected blending. The color readings with picker are 100% correct all the time. 2. When the artwork is done set all the layers that have multiply to screen and set all screen layers to multiply. Export to psd and import into any layout software that can read psd and continue working on e.g. illustrated book. 3. Later, if you want to edit the file, layers are preserved. All you need to do is repeat the swapping with the opposite blending so you can see the correct output. Swap (multiply/screen) again before saving. All said for blend modes for layers apply for brushes too. ------------ standard*1* - If we agree that pdf is the most widely used standard in the print industry, Table 7.1 Standard separable blend modes roughly describes the behavior of blend modes in CMYK space as well as in space with spot colors. See: wwwimages2.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/blend_modes.pdf
Hi, nikola! I've checked the standard in details, and, yes, you are right. According to the standard Multiply is applied after converting the color into "additive" form. I'll check what we can do with that.
*** Bug 434586 has been marked as a duplicate of this bug. ***
*** Bug 463756 has been marked as a duplicate of this bug. ***
So, based on yesterday's discussion, let's move forward with this in time for 5.2.0?
(We never use the importance field, but no idea how to otherwise raise priority :P)
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1796
Git commit f5f61bcf9a64891fde4237ca595302278368d8a4 by Dmitry Kazakov. Committed on 15/05/2023 at 08:13. Pushed by dkazakov into branch 'master'. A draft fix for CMYK blending modes This patch is a draft only. We need to decide what to do with the following modes as well (they are not touches atm): * Over * Copy * Alpha Darken * Erase * Behind * Destination In * Destination Atop * Greater * Dissolve * LuminositySAI Most probably, all the blendmodes except Greater, Dissolve and LuminositySAI don't need any changes, though it needs checking. M +8 -0 libs/pigment/KoCmykColorSpaceTraits.h M +8 -0 libs/pigment/KoColorSpaceTraits.h M +17 -4 libs/pigment/compositeops/KoCompositeOpGeneric.h https://invent.kde.org/graphics/krita/commit/f5f61bcf9a64891fde4237ca595302278368d8a4