Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMYK #6

Open
flosse opened this issue Jan 12, 2016 · 7 comments
Open

CMYK #6

flosse opened this issue Jan 12, 2016 · 7 comments
Labels
color type A new color space, model or meta type

Comments

@flosse
Copy link

flosse commented Jan 12, 2016

It would be cool to be able to convert to an from CMYK :)

@Ogeon
Copy link
Owner

Ogeon commented Jan 12, 2016

I have been holding off on device specific color spaces because of the hairy business around different devices. The values of CMYK depends on printers and the colors of their ink, which makes it particularly tricky, but I think I saw some "standard" formula somewhere that may be "good enough". Same for CMY. It's definitely worth investigating, since they are both very common. :)

@Ogeon Ogeon added this to the 0.2.1 milestone Jan 29, 2016
@Ogeon
Copy link
Owner

Ogeon commented Feb 3, 2016

Looks like there's no way to implement accurate CMYK without a color profile, since it depends on paper color, ink, etc. The only possibility without implementing color profile support is the naive implementation, where

black = 1 - max(red, green, blue)
cyan = (1 - red - black) / (1 - black), or 0 if black is 1
magenta = (1 - green - black) / (1 - black), or 0 if black is 1
yellow = (1 - blue - black) / (1 - black), or 0 if black is 1 

red = 1 - min(1, cyan * (1 - black) + black)
green = 1 - min(1, magenta * (1 - black) + black)
blue = 1 - min(1, yellow * (1 - black) + black) 

Some people may prefer to define their colors this way, so it may still be useful as an input interface, but the colors won't be accurate.

@flosse
Copy link
Author

flosse commented Feb 3, 2016

hm... I think something like black = 1 - max(red, green, blue) is not the solution we want.
But having a stuct that can hold CMYK values is useful. More general, a generic type that can hold n different channels could allow to define custom spaces. Let's say you want to print something special, then you'd define the colors c, m, y, k but also e.g. two spot colors custom0 and custom1.
And transforming from color space A to color space B should only be implemented if it is definite. In all other cases I'd offer a convert function where you can pass in your custom function.
That would look like this (pseudocode):

let my_rgb = Rgb::new(0.5, 0.3, 0.7);
let my_foo: FooColor = my_rgb.convert::<FooColor>(|channels|{
  let a = some_calc(channels[0], channels[2]);
  let b = some_cals(channels[1], channels[2]);
  FooColor::new(a,b)
});

Then you can also offer official standard profiles and just do s.th. like

let my_cmyk = my_rgb.convert::<Cmyk>(Cmyk::Profiles::ISOUncoded_v2);

What do you think?

@Ogeon
Copy link
Owner

Ogeon commented Feb 3, 2016

Yea, something like that is probably the way to go. The main problem with implementing the naive variant is that it can be mistaken for the accurate variant, so I feel like it should be avoided. I'll postpone this for the time being, until a concrete solution comes up, but it looks like some form of color profile support is desirable. A more generic conversion interface can still be independently added. I'll open a couple of issues...

@Ogeon Ogeon removed this from the 0.2.1 milestone Feb 3, 2016
@Ogeon Ogeon added the wish list May be implemented in the far future label Feb 23, 2016
@Ogeon Ogeon added the color type A new color space, model or meta type label Aug 1, 2024
@Ogeon Ogeon removed the wish list May be implemented in the far future label Aug 1, 2024
@Ogeon
Copy link
Owner

Ogeon commented Aug 1, 2024

I think this should be straight forward enough with ICC profiles off the table. Palette's support should mainly be for the naive version (e.g. Cmyk<Srgb> and similar) or as a semantic value container (could be Cmyk<Any> or a different marker type). The documentation just need to be clear enough on regarding how the naive variant is not suitable for printing.

@flosse
Copy link
Author

flosse commented Aug 1, 2024

Oh wow, eight years have already passed... I (almost) can't remember which project I needed CMYK support for back then 🤣
But it's still good to know that there are now new perspectives 😉
Thank you! 👍

@Ogeon
Copy link
Owner

Ogeon commented Aug 1, 2024

Ah, yes, I have a better idea of what I'm building now. But other things have also been calling for more attention along the way, so this one had to be patient. 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
color type A new color space, model or meta type
Projects
None yet
Development

No branches or pull requests

2 participants