Req- RGB to CMYK fuse

[gez]

Ohhh, I'm a sucker for this subject.
Google GCR and UCR. As @JustCropIt mentioned, the way black is "generated" in CMYK process is more nuanced than just replacing black or achromatic pixels.
The amount of black or gray you replace depends on many factors. It's generally driven by the color profile, but sometimes press people tweak it to make prints easier to print, cheaper or both.
But, although it might sound a good idea to just replace equal amounts of RGB/CMY with a grayscale K, on paper it never works really well, because black ink is not perfectly solid, and it tends to look bland, washed out. So in practice there's always some CMY under the black, and black is used to improve contrast and make black look richer.
On the other hand, keeping CMY and Black too high isn't practical, as paper ends up soaked with ink and it's a mess.
So it's a balance act, where you keep some CMY and add black to "close" the mix.

I'm fully aware that it doesn't really matter here in a compositing software and it's only an effect, but if your effect misses that aspect, print people WILL NOTICE IT, you can be sure.

[AndrewHazelden]

C:\Users\ANDY\Downloads\Untitled.lua:2: unexpected symbol near '{'

My understanding is that its not a Lua code snippet but a Copy/Paste macro "settings" file snippet. Copy the code as text, and paste it into the Fusion nodes area and you should see nodes added to the comp.

This type of code is called a Lua table format and is used when creating a Fusion macro .setting file. It is very similar to a Fusion .comp file format.

[JustCropIt]

As @JustCropIt mentioned,

Much better stated and summarized by you, than my ramblings:)

[SecondMan]

So it's a balance act, where you keep some CMY and add black to "close" the mix.

If you are aware of conversion equations that would be a bit further away from the print peoples' no-go zones, do share!

Gotta find a way, find a way, when I'm there
Gotta find a way, a better way, I'd better wait

[JustCropIt]

If you are aware of conversion equations that would be a bit further away from the print peoples' no-go zones, do share!

As far as I'm aware the physical CMYK process is related to a combination of several things (print machine, colors, paper, time of day, direction the wind blows) so... not sure you could get something useful (in the context of trying to convert RGB to CMYK)? But this is also quickly going way above my head so, you know, best of luck to you:)

[SecondMan]

Sounds good - I'll just trundle along until someone tells me to stop then

[JustCropIt]

I'll just trundle along until someone tells me to stop then

[gez]

If you are aware of conversion equations that would be a bit further away from the print peoples' no-go zones, do share!

DTP software use ICC profiles for that task, so probably there isn't a single equation that does that as the process is more complex. The first problem you'll find is that CMY inks aren't the same as the pure emissive RGB CMY. Yellow ink can be pretty close, but magenta and specially cyan are way off. Putting it in simple terms: you can't print a cyan that reaches the lightness and saturation of a pure G+B RGB cyan.
That makes it mandatory to use some gamut mapping, hence some color management is needed.
Add to that problem that different paper stocks affect printed ink color and other issues.
It's a bit tricky.
The gray component replacement part is probably something we can emulate.

It's an interesting challenge though. So I'm in.

Here's an idea: Using a software that does ICC and CMYK, I'd grab one of those charts with all the RGB colors and convert it to CMYK, then back to RGB to produce a CLUT. At this point it is important to pick a target CMYK profile, as we'll have to mimic a conversion that is really dependent on the target.
So, standard profiles: ISO/Fogra Coated 39L for Europe, SWOP Coated V2 for US are a good starting point.

Once you have your RGB rendition of how CMYK conversion affects your image's gamut, then it's GCR time:

As far as I could find, the conceptual formula is: gray = min(C,M,Y)
The idea is to figure out the "gray component" of any colour in your image. If you have some colour that is C=50, M=80 and Y=30, your GC is 30, while the chromatic part of the colour is defined by the difference of hue and saturation provided by the other components (in my example, C=20 and M=50).
However, if you used that conceptual formula straight away to remove the gray component and move it to black, it would produce a very harsh removal.
The key here is to apply a "level" of GCR, from 0 (no removal) to 100% (full GCR).
This level is defined by the profile: SWOP uses a more aggressive GCR while FOGRA is more balanced.
I tried to find a percentage for those profiles, but It appears to be non-linear and controlled by the ICC profile. Deeper shadows use a higher GCR, lighter shades use less, but a 70/80% reduction can be used as ballpark to simulate the effect.

So, summarizing the idea:

• a CLUT for the gamut mapping.
• translate the GCR process to a reasonable equivalent in RGB.

Enjoy

[JustCropIt]

Enjoy

I somehow get the feeling that all of this is like the reverse of working with EXR sequences in Quark Express:)

[SecondMan]

let's go

[gez]

I somehow get the feeling that all of this is like the reverse of working with EXR sequences in Quark Express:)

... or motion tracking in Indesign.

Whatever works to avoid working on real stuff and procrastinate. The god of ADHD demands it.

That being said, sometimes useful things come out of these experiments.
I'm pretty sure that being able to use scene-referred EXRs as assets for page layout in Affinity Publisher sort of proves the point!