Custom function to use ColorPicker with alpha

In response to another post here, I made a small definition to be able to call up the V7 color picker with the alpha sliders enabled - which rs.GetColor() doesn’t do yet. I ran into one interesting situation with the CMYK settings - which I have never used before to be honest. The definition is this:

import rhinoscriptsyntax as rs
import Rhino

def GetColorAlpha(color=[0,0,0,255]):
    #returns a tuple (r,g,b,a)
    color = rs.coercecolor(color)
    if color is None: color = System.Drawing.Color.Black
    rc, c = Rhino.UI.Dialogs.ShowColorDialog(color,True)
    if rc: return (int(c.R*255),int(c.G*255),int(c.B*255),int(c.A*255))
print oc

This works fine with any of the RGB or HSL/HSV panels. However if I have the CMYK panel up, the fact that the alpha is specified as 255 by default gives me full black - even if I pick somewhere arbitrary on the color wheel.


Note that Alpha is at 255, but Black is also at 255 - i.e. full black.

If I set the default to [0,0,0,0] then in CMYK I get the black value set to 0 (to get a fully saturated color), but then the Alpha is also set to 0, so it is fully transparent, which doesn’t help me at all. In either case I have to manually set either the Alpha slider or the black slider.


How do I get this definition to work correctly for both RGB/HSV and CMYK ?

1 Like

Hi Mitch,

I’m dredging in some murky, long-disused corners of my brain, but I have some recollection that alpha channel transparency is irrelevant with CMYK.

Reason being that CMYK is a subtractive colour model, only relevant to printing, and you only send a finished image to a printer.

I stand to be corrected by anyone with current knowledge, but HTH.

Yep, but we’re not dealing with printing ink on paper here, we’re dealing with some some sort of formula cooked up that converts CMYK to RGBA as that’s all your computer screen understands. The addition of the A channel allows for opacity/blending:

And in any case, all the settings are available and active in the color picker… With it you can make a CMYK color with transparency. For example CMYK 100,0,0,0,127 makes a half-transparent Cyan color - for which which the RGB equivalent is 0,255,255,127…

Yeah, but what’s the use case for CMYK outside of print?

Don’t ask me, I didn’t request it for the color picker…

Absolutely right - 10+ years experience in printing…
Another way of looking at it is that RGB is additive - colored light (output). CMYK is reflected light output.

But what’s important is that you might want to know what your print colors might look like in print before printing. But today with 7 color printing tech, this is less and less relevant depending on the printer’s application.

So i would say it is valid if you want to simulate the look of advertisment, painting, paint, etc.

Correct me if im wrong, it is 15=20 years i dont ‘print’…

Yes, this has gone off topic sorta, as this was a scripting question, not one about the actual usefulness of CMYK. @dale, @alain any clues here?

As far as my take on CMYK:

Originally this concerned ink on paper. i.e. selective color absorption of white light (subtractive). In principle one does not need the “K”, in an ideal world, printing perfect C, M, Y inks on top of each other should produce black as all colors will be absorbed. However, in the real world, pigments/dyes are not perfect, so they always make a sorta muddy brown. Black was added to the mix to be able to easily produce deep blacks and with less ink use. These days good photo printers even have several of varieties of intensity of black.

As related to RGB on a computer screen, CMY are the halfway points between them on the “wheel”. (i.e Y is between R and G; C is between G and B; M is between B and R). So where does the “K” come in? It just darkens the color - from nothing (0) until full black (255)

I think the main problem here is that all the others only use 4 parameters (RGB+A) but CMYK uses 5 with the addition of Alpha. So I suspect a parameter mismatch here.

I suspect it is only CMYK within that color picker and is translated to ARGB for storage and use within Rhino. Unfortunately the color4k struct documentation is incomplete so I might have to dust off the python editor to prove or disprove this assertion.

Most likely. However CMYK+A does have 5 parameters whereas ARGB has only 4. So my feeling is the A argument is being used to initialize both the A and the K values when the CMYK panel is active. Which is bad.

Except that if you pick a CMYK + A and apply it to a layer, say, when you re-edit the layer color it shows the correct values in the picker.

Please re-read the first post. I did not say it was not working correctly. I said simply that there was no way scriptwise (that I found) to have the initial values of the alpha channel set to 255 (non-transparent) and the Black channel set to 0 (no black, fully saturated). You either get Alpha 0 and Black 0 - color is fully saturated but also fully transparent; or Alpha 255 and Black 100 (color is black).

@curtisw - is this something you can help with?

Hey @Helvetosaur,

Hm, yes that’s an interesting situation. Really, if black is 100%, picking a color from the wheel should set black to 0, otherwise it is not particularly useful.

The HSL/HSV wheels do something similar to that as well if saturation is 0, otherwise you would get into the same situation.

I’ve created RH-63267 to fix that up.

Hope this helps!

No, you are under a misapprehension. You are not getting full black because the alpha=255 but because your defaults are R=0, G=0, B=0 which is black. Regardless of which picker is displayed you are supplying ARGB values, not CMYK - you will see this if you expand the wheel to see the sliders and use, say, a default of (10,20,30,255). You will see that these are applied to the RGB and A sliders and the CMYK black is not 255.