CMYK components

I second that... just needed that today and couldn't find it

I don't think so.
Bad CMYK separation without proper color matching is no good for printing.
Good CMYK separation requires proper color matching with a target device profile, along with a proper separation setup (coating at least). While you can get away with the "RGB is almost device-independent, so let's slap on this sRGB label, or hell, just stick with gamma", you can't do the same stuff with CMYK -- it's the #1 device-dependent color space

On the other hand, if Vlad decides that some generic "CMYK" will do, it's very too hard to implement.
Please note that my previous statement does not imply that it will be implemented soon even if Vlad agrees that having "CMYK" splitter/combiner is a good idea -- you know what we're working on, right?

Extracting and assembling CMYK channels is really not that hard if you disregard color profile conversions ("Bad CMYK seperation"). But there is little use for it really, partly because of the device dependent nature, but mostly because FF do not support 5 channel composites (ACMYK).

I attached a small snippet that shows one way to extract/assemble CMYK channels - if you simply want to play around with intermediate CMY(K) channels and reassemble to RGB, its a good starting point.

The snippet is based on GIMP's internal conversion routines (really simple stuff).
There is an alternative assembly cluster that might be a bit more useful - it lets you select the cmyk dye to use when assembling (I included Adobe Working CMYK). I did not include a custom extract version though. Note that the GIMP cmyk -> rgb formula does a poor job converting cmyk input composed with key pullout > 0.

RGB _-_ CMYK.ffxml

Quote
On the other hand, if Vlad decides that some generic "CMYK" will do, it's very too hard to implement.

When I re-read my own post I found that I was going to say exactly the opposite -- "not too hard to implement"
Yes, generic CMYK splitting is easy stuff, sorry for making a strange typo "very too" instead of "not too". Also, I would like to not that to provide assemble/extract CMYK components, there is no need for us to support 5-channel operations in the UI. Inner workings of FF can work with unlimited number of channels with arbitrary meanings

The pipeline between components is ARGB, yes (this can be changed, though a bit hard), but internally, FF supports pixel formats with arbitrary precision and number of channels (provided there are conversions set up in the code).

There is actually a "grayscale" pipeline, you know it as "curves" I don't think we're going to introduce separate grayscale support for map components though -- it might require a lot of fiddling with components themselves.

Sorry, can't tell about the status of this problem since I'm at home now and don't have access to the issue database.

Not just CMYK extract and assemble. We also need a color input component with CMYK enabled or only CMYK.
I want to make a filter to know which two colors should be mixed in watercolor to get the color you wish. But the inputs dont have CMYK at all.