tint() bug ?

edited March 2017 in Questions about Code

I think tint(255,255) should apply a transparency of 100%.
But i have problem with the following sketch:

PGraphics pg;
color c, cp;
boolean t;
void setup()
{
  size(200,200);
  background(80);
  c = color(166,130,180);
  t = false;
  pg = createGraphics(200,200);
  pg.beginDraw();
  pg.noStroke();
  pg.fill(c);
  pg.rect(10,10,180,180);
  pg.endDraw();
}
void draw()
{
  background(80);
  if (t) { tint(255,255); }
  else { noTint(); }
  image(pg,0,0);
  fill(0);
  text("rect rgb: " + red(c) + ", " + green(c) + ", " +  blue(c), 16, 26);
  text("pick rgb: " + red(cp) + ", " + green(cp) + ", " +  blue(cp), 16, 46);    
  text("tint: " + t, 60, 80);
}  
void mousePressed()
{
  cp = get(mouseX,mouseY);
  println(cp);
}
void keyPressed()
{
  t = !t;
}  

Click rect to pick color --> Correct color
Press a key --> apply tint(255,255);
Click rect to pick color --> Wrong color
More, changing tint to off (pressing a key again) does not restore the original color.
I have tested the color change with a color picker program too.
Where am I doing wrong?

Answers

  • cp = pg.get(mouseX,mouseY); get the correct color.
    But tint(255,255); should do nothing :-/

  • edited March 2017

    @cameyo --

    There is not a bug. You are making two mistakes here.

    1. You have alpha backwards. alpha = 255 is full color; alpha = 0 is transparent. From the Color tutorial: "Alpha values also range from 0 to 255, with 0 being completely transparent (i.e., 0% opaque) and 255 completely opaque (i.e., 100% opaque)." https://processing.org/tutorials/color/
    2. tint() is preserved between draw loops (like fill or any style setting). Because you only set tint() (and never unset it) your sketch will always get stuck on the same tint() value. Just turning your t flag off doesn't update tint()!

    To fix this, you should do one of these two things in draw():

    1. add an else statement:

    if (t){ tint(255,0); }
    else {  tint(255,255); }
    image(pg,0,0);
    

    2. use pushStyle() / popStyle() to unset tint when done:

    This works for you if your default outside the if statement is the default tint -- 255 alpha, or fully opaque. https://processing.org/reference/popStyle_.html

    pushStyle();
    if (t) tint(255,0);
    image(pg,0,0);
    popStyle();
    

    You can also do both, which might make your code easier to read and modify safely.

    I can't tell from your sketch code whether (t) should activate (255,0) or (255,255), although your description sounded like you may need a change. The first is nothing, the second is purple.

  • edited March 2017

    @jeremydouglass: thanks for the infos.
    But why tint(255,255) change the color of image (rect) ?

  • I'm not sure I understand your question. What value are you expecting, and what value are you getting instead?

    Can you be more explicit and perhaps provide a short example sketch?

  • @jeremydouglass: i have corrected the code adding the else statement.
    Run the sketch and try this:
    At start is applied noTint(): click on purple rect to pick the color: you get r=166 g=130, b=180. This is correct.
    Now press a key to change to apply tint(255,255): click on purple rect to pick the color: you get r=164 g=128, b=178. I think this is wrong. tint(255,255) shoud be equal to noTint() :-/
    Thanks for your time :)

  • Answer ✓

    Wouldn't that apply a gray tint? Would it work if you use the alternative version of tint: tint(v1, v2, v3, alpha)

    Kf

  • edited March 2017

    @kfrajer: the alternative version of tint works. Thanks :)
    But color(255,255) is equal to color(255,255,255,255).
    Why tint(255,255)is different from tint(255,255,255,255) ?

  • Answer ✓

    Based on the doc at https://processing.org/reference/tint_.html :

    To apply transparency to an image without affecting its color, use white as the tint color and specify an alpha value. For instance, tint(255, 128) will make an image 50% transparent

    So I was expecting this last quote to agree with your statement. However it doesn't agree with your observation. I guess one would need to dig into the source code to understand this discrepancy.

    Kf

  • @kfrajer: thanks. I'll dig into the source :-B

Sign In or Register to comment.