Lists : isn't that what is meant with "Listable"

Yes, exactly. I thought I'd explain it in plain terms rather than force you down another learning trail about attributes.

So this is what overloading means - restricting the input variable to a certain type (Hue).

Overloading basically means having multiple "functions" with the same name. In Java you can overload if your input lists differ in their types. Some languages don't allow overloading at all. In Mathematica, you can overload with pattern matching.

I am probably still thinking Old School [regarding using the color square as input]

Yeah, don't get me wrong. I don't know that I would actually ever do that for real. I was just taking the opportunity to make a point about about representations.

RGB, HSB and Lab triplets above each color. But I suppose I would have to get the numbers the same way as I did in my primitive try, and convert to the different colorSpaces.

Not at all. This bit here,

Flatten[{hue = ColorConvert[rgb, "HSB"], HueSplit[HueComplement[hue], spread]}]

evaluates to a List of Hues. You can apply ToString to them to see them as Hue[0.5, 0.5, 0.5] (or whatever). Before you do the ColorConvert, you'll have RGBColors, and you can apply ToString to those to see RGBColor[0., 0., 0.] (or whatever). I don't know what Lab is, so you might have to come up with your own display representation for that. Or, if you really do want them as just triplets (list of three elements), then do the List@@ thing.

I tried with a different start color for the ColorSetter (not Black), but nothing seemed to work

In the Manipulate, you can change the bit that specifies the controller for rgb to look like this: {{rgb, RGBColor[0.5, 0.22, 0.5]}, ColorSetter}

I am so much used to 'stay' in the numbers and variables, until all the calculations are done and only then do the 'Translation' to the graphics on screen

Right. I pretty much agree with you. That's kind of what I'm trying to explain when I go on about representations. But I think we've reached the limits of being able to communicate this idea within this context, so I won't belabor the point anymore.

Here's a deeper dive...

I can see your notebook. Must be some lag or something.

Anyway, later I'll put together a notebook to show you how I'd approach this. But I'll put a couple of thoughts here first.

When a result has some sort of error (something recognized by Mathematica as an incorrect usage, not just something that didn't work the way you expected), there will typically be an associated message. These can show up in a few places:

• The messages window: in the menu bar, Window -> Messages
• A little red ellipsis near the bracket for the output cell where the error happened
• If the output itself has a red outline, you can hover over it to see the message

So, for your failed Graphics output, hover over it and you'll see a message that explains the failure. In your case it is: "FullForm is not a Graphics primitive or directive." That's a pretty good clue, and it suggests that the problem is with this line:

orgColorRGB = x // FullForm

So, a quick comment about FullForm and related *Form functions. These are used to inspect data structures. They are helpful for debugging. But they aren't intended to be part of the data structure (at least I have never done that, and I can't think of a reason to do so). What you've done here is assigned the variable orgColorRGB to FullForm[x], and so if x was RGBColor[0,0,0] then your orgColorRGB is really FullForm[RGBColor[0,0,0]]. Now this data structure will display fine (it should, that's the purpose of FullForm), but it's no longer a data structure that is recognized as a color by Graphics. FullForm structures don't display as FullForm[...], because that would actually be distracting and detract from the usefulness of FullForm. So, if you evaluate FullForm[orgColorRGB], it will just appear like a RGBColor structure in the output. But you can evaluate Head[orgColorRGB] and see that it's a FullForm.

I think that you are somehow thinking that you need to use FullForm to get at the "numerical represenation" of a color. But you don't. Just because colors display as little colored squares does not mean that there is some other representation being used. It's just a display thing. When you use your ColorSetter, you're setting x to an RGBColor data structure. You don't need to do anything more to x to use it as a color. You would only apply FullForm to it to see the raw data. FullForm doesn't actually do any transformation to x itself.

And maybe I'm beating a dead horse, but this isn't all that mysterious. Every text letter you see on the screen right now, or in any software application, is just a representation of some binary data. That binary data is there, it's just hidden for our convenience by the various interfaces we use. Mathematica is extending that idea to "higher level" data structures. Evaluate Head[1/2] in one cell and just 1/2 in another cell. Mathematica has a special way to display fractions, but that doesn't mean that you need to transform 1/2 to some special "numerical form" to use it as a number. Try assigning a variable to FullForm[1/2] and then try to add that variable to 1. Mathematica doesn't know how to add FullForms to Integers. But of course 1+1/2 will output a new fraction just fine.

On to comment 2: When prototyping something, I'd suggest you work incrementally. Do one step in one input cell and evaluate that. Tweak it until that bit works, and then move on to a new input cell. You have a whole bunch of expressions in one input cell. It makes it difficult to trace the outputs to the inputs. I'll demonstrate this when I have a moment to put together a demo notebook.

Comment 3: You might still be early in the prototyping stage, so maybe you would have gotten this eventually, but my suggestion is that you bundle up your logic for creating complementary colors into a nice, reusable function. Again, I'll try to show that later.

I seem to have troubles to attach the NoteBook as a seperate file, instead of it being inserted into the post. I managed once, and now I think I do the same, but get different results.

How should I do it correctly?

Thanks Eric, your guidance is really helpful. It’s very much appreciated.

I understand what you are explaining to me. I will look into Apply later, but that seems interesting.

Your code :

Dynamic[{x, FullForm[x], ColorConvert[x, "HSB"], 
  FullForm[ColorConvert[x, "HSB"]], List @@ ColorConvert[x, "HSB"], 
  ColorConvert[x, "HSB"][[1]]}]

Works well and I understand all of it. So basically, I have now what I want to start with : The selected color in RGB numbers , as well as in HSB numbers.

Also the List thing works and is understandable.

From here I can continue.

I managed to make use of Apply, I think an important function. I used it to get the HSB values, which I transformed, again into a ‘color’ format.

hueComp1 stands for a complementary color

colComp1 = Apply[Hue, {hueComp1, orgColorHSBsat, orgColrHSBbrit}]

To show the colors in the form of rectangles I have the following code - with a question :-)

I don’t understand that not one of the first two lines does work, but only the third way : RGBColor[x] I have already : orgColorRGB = x // FullForm So why is it not working as orgColorRGB has the same values as x?

THIS DOES NOT WORK

colorResult1 = Graphics[{RGBColor[orgColorRGB], Rectangle[]}] ;       (*  The ORIGINAL COLOR  *)
colorResult1 = Graphics[{orgColorRGB, Rectangle[]}] ;       (*  The ORIGINAL COLOR  *)

BUT THIS DOES WORK

colorResult1 = Graphics[{RGBColor[x], Rectangle[]}] ;     (*  The ORIGINAL COLOR  *)

I attach the Nb I am working on for reference. The purpose of it is to select a color, and make two complementary colors, with an adjustable speed from the exact complementary color. I plan to use this to create nice 3 color palettes for my design work.

Thanks again Eric, really helpful.

Best, Beat

Attachments:

Color-2 color co...nb

Thanks Rohit, this works and let's me save the values in a seperate variable.

I would never have come up with this solution of putting parentesis. Something like this, is hard to search in the docs. The only way, I would imagine, to get to a solution is to know and understand the bigger processes behind the scenes, like what exactly is happening when //FullForm is used. Unfortunately, these deeper, but somehow very elementary things are not often mentioned in the docs or for that matter in books. I have read maybe 2500 pages of WL instruction books, but still do not have a clear idea or concept of WL. I fiddle and search until something as by magic starts working. Sometimes just putting a curly bracket in another place does the job, but I feel I still have no clue.

Fortunately there is the forum, populated with very kind and helpful people. Great :-)

Apologies, I forgot to mention...

(* THIS DOES NOT WORK *) h=v[[1]]//InputForm

You had assigned the value to v1, not v. So, v1[[1]] will give you the first part of the expression.

I get it so far. I would never have come up with //FullForm. This WL really does things different from what I am used to. very surprising.

Now the next step, which I thought I would be able to manage, but I don't :-(

If I select a color, take the //InputForm and convert to HSB I get e.g. the following :

Hue[0.14196606106828644, 0.6012019781875348, 0.9318074311436637]

As this is not a List, I do not know how to extract the parameters separately into the variables 'h', 's' and 'b'. See my clumsy attempts in the attached Nb :-)

Maybe a little more flavor would help. The documentation used the expression

{ColorSetter[Dynamic[x]], Dynamic[x]}

to demonstrate how you can dynamically update a variable with a ColorSetter. That expression isn't itself the "color setter". You could just as easily use an expression like this:

NonsenseHead[Dynamic[x], ColorSetter[Dynamic[y]], Dynamic[y], 
 ColorSetter[Dynamic[x]]]

If you evaluate that and play with the output, you can see that one ColorSetter is linked to one dynamic variable and the other to the other.

If you execute this:

ColorSetter[Dynamic[x]]

then the value of x will be the color displayed by the ColorSetter. If you click on the ColorSetter and change the color it displays, then x will contain the value of the new color. In other words, the answer to your question, "How do I get the vales of the selected color into a variable?" is that you already have the value in a variable--it's the variable wrapped in Dynamic and passed to the ColorSetter.

Notice how Rohit applied InputForm to the variable (or maybe you couldn't see that post). I also like to use FullForm when I want to inspect an expression in detail. Anyway, the little square you're seeing is just the way a Mathematica notebook renders an RGBColor expression in an output cell. I should have realized that this might be throwing you. It's extremely common in a Mathematica notebook for the output to be formatted in some "nice" way. If you evaluate Complex[1,1], for example, you'll see a "nice" representation of that complex number. If you evaluate RGBColor[1,0,0], you'll see a red box. If you evaluate Rule[a,b], you'll see an arrow. But if you apply FullForm to each of these, you'll see that "underneath the covers" they are all just plain old Mathematica expressions with a head and body.