Inspecting the max value of an element set by colormode (e.g. HSB Alpha) - possible?

Processing Beginners
1

Using colorMode() we can set the max for the range of the different values used to describe colours.

Is there a way to recover this information in code via an expression? (I have searched for it, but haven’t found. Maybe because it doesn’t exist.)

tx

2

Hi and welcome to our forum

Not clear what you want but here is some refernace

https://funprogramming.org/90-Change-pixel-hue-saturation-and-brightness.html

1 Like
3

Thanks for the help @jafal . What I’m looking for is whether it’s possible to retrieve the value(s) that you set, when you set colour dimension scale value(s) via colorMode.

You can use the keyword width to get at the width that you define in size. I was wondering if there was an analogous thing (keyword, function, property, or whatever) that you could use to retrieve the value of the upper end scale parameter, in a similar way. Is that clearer?

This is probably somewhere in the reference documentation, but I’m not really friends with it yet…

5

Your title mentioning “value of an element” confused people. Here’s what you’re looking for:

void setup() {
  size( 200, 200 );
  
  colorMode( HSB, 234, 7452, 423, 626 );
  
  println( g.colorModeX );
  println( g.colorModeY );
  println( g.colorModeZ );
  println( g.colorModeA );
}

Not very intuitive, but at least those values are public so we can read them.

I tracked those down from the source: https://github.com/processing/processing4/blob/main/core/src/processing/core/PGraphics.java

4 Likes
6

A more precise on target link: :dart:

3 Likes
7

Here’s another perhaps more intuitive method. Colors given by hex codes are always RGB8 independent of colorMode().

void setup() {
  colorMode( HSB, 456, 823, 562, 2837 );
  println( 2 * hue( color(#00ffff) ) );
  println( saturation( color(#00ffff) ) );
  println( brightness( color(#00ffff) ) );
  println( alpha( color(#00ffff) ) );
}

#00ffff is halfway around the color hue, so multiply it by 2 to get the full hue range.

Accessing g.colorModeX directly is much faster, though, as this method causes Processing to do a bunch of needless math to get to the same result.

2 Likes
8

I might be missing what you want to achieve.

Isn’t it easier to store the values in variables?

int m1 = 1;
int m2 = 2;
int m3 = 3;

And use them to configute the colorMode

void setup()
{
  colorMode(HSV, m1, m2, m3);
}

And when you need to know them somewhere else, just use the mX variable like println("m1 = " + str(m1)).

Code not tested.

4 Likes
9

That would be the ideal if you wrote all of the code. If you’re writing a library, however, you may not know what settings others have used.

Although in this case, you can let Processing store the variables for you and just read g.colorModeX instead.

1 Like
10

For a well written library both of these statements should be true

  • If you are using a 3rd party library then it should be impossible to get any rendering settings unless the author provides functions to retrieve them.

  • A 3rd party library should isolate any changes in rendering settings from the library user by using the push()/pop() methods.

So having said that the user should store any settings they in variables if they want to reuse them later, as suggested by @sterretje .

2 Likes
11

Re @scudly advice re using g, this is indeed what I was looking for. Thank you. I’ve read somewhere (probably here or in its predecessor) that using g was going offroad and not guaranteed to be stable over updates. What I’m doing at the moment is entirely disposable so it’s not likely to be an issue in practice. But I guess that’s a Good Style thing to consider.

Accepting this answer as it’s what I was asking. Though there is lots of other interesting discussion around Good Style for dealing with this type of thing. And thanks for the supplementary reference info around the same answer, @GoToLoop

Re @scudly advice re using a numerical trick using a hex value halfway round the colour wheel - this is much less intuitive to me but it’s an interesting technique I was unfamiliar with.

1 Like
13

Re @sterretje suggesting I just assign the value via a variable, and reference the variable when I need it, yes indeed this is indeed what I am doing. But style-wise, I prefer not to proliferate global/environment variables if I can avoid it - especially if they are already built in.

14

Interesting point re Good Style for 3rd party libraries @quark . Thank you. At the moment I am just writing my own code - which I may reuse in a number of different contexts, as part of the explorations I am doing, and I wanted to minimise dependencies between different aspects of it.

15

When I first started using Processing (2009) using g was strongly discouraged but that doesn’t seem the case now.

Having said that I prefer not to use g directly. I always use getGraphics() which returns the same value as g - try this

println(g);
println(getGraphics());

and you see they refer to the same object.

Even if Processing ever makes g a private or protected member, getGraphics() will always be public

So instead of g.colorModeX you can use getGraphics().colorModeX. It’s a little more verbose but there is no real loss in efficiency due to JVM optimization.

3 Likes