Loading...
Logo
Processing Forum
Ok here's one that for the life of me I can't figure out. Take the following code:

Copy code
  1. String inputFile="someImageBiggerThanTheScreen.jpg";   
  2. PImage img;
  3. int x, y;
  4. color clr;
  5. float r,g,b;
  6. void setup() {
  7.   img = loadImage(inputFile);
  8.   size(1200,800);
  9.   stroke(255); // just to prove that an ellipse is actually being drawn
  10. }
  11.  
  12. void draw() { 
  13.   if(frameCount==1) {
  14.     image(img, 0, 0,width,height);  // puts the image on screen - works
  15.     loadPixels();  // loads the pixel array - appears to work
  16.     }
  17.     x = int(random(width-1));  // grab a random x
  18.     y = int(random(height-1));  // grab a random y
  19.     int i = int(x + (y*width));   // get the pixel array location
  20.     clr = pixels[i];  // pixel is supposed to have a color datatype so put it in the color variable clr
  21.     r=red(clr); g=green(clr); b=blue(clr);  // just for grins, grab the r,g,b components
  22.     //println(x+","+y+" --> "+r +","+g+","+b);
  23.     //fill(clr);
  24.     fill(r,g,b);
  25.     ellipse(x,y,70,70);
  26.  }
So in the above code, everything works fine using the fill statement on line 24.
BUT - if I comment out the fill on 24 and uncomment the fill on 23, the ellipses drawn become invisible. I confirmed that they were actually drawing by putting the stroke(255) into setup(). Obviously clr has valid color data because the r,g,b variables are correctly populated with the appropriate values.
So what am I missing? Why does fill(clr) result in the creation of invisible ellipses?
Best Regards, Jim

Replies(17)

Seems to work fine for me in Processing 1.5.1, using either kind of fill.

I would point out that there's no need to draw the image or use loadPixels()... You can get the color from the image directly with img.get(x,y);
Hi, I should have mentioned that I am using the most recent version of Processing 2.

Regarding get(x,y) I normally don't use that or  colorvar = pixels[index] method but use the pixels[index] bitshift method to retrieve the color information.

The reason for the image() and loadpixels() is that they are necessary  for the way in which my actual program is designed to work. The code presented above is a greatly stripped down version of my program - created in an attempt to isolate the source of the invisible ellipses problem.

Logically, the only answer I can come up with is that for whatever reason, the color variable is being assigned an alpha of 0 because when I grab the individual r,g,b components from the color variable and pass them to the fill() statement, the program works as expected.  What I haven't done is to examine the alpha component of the color variable to see what it actually contains.

Best Regards, Jim
Well well well.  Inserting the following statement into my test code:

int alpha =  clr >> 24 & 0xFF;
as well as float alp2 = alpha(clr);

reveals that every color is defined as being 100% transparent. That's surprising. Given that I can actually see the image on the screen and I am getting the correct r,g,b values back, how can it be that Processing thinks the alpha value is 0?

Ideas?

Best Regards, Jim
More investigating. I still have Processing 1.5.1 installed on my system. I run the above program and it works as it should with the color variable containing non-zero alpha values.  Rebooting and running Processing 2 takes me right back to the invisible ellipses and 0 alpha values. Looks like it's time to head over to github.

Best Regards, Jim
Final update for now.  I have posted this issue at:
https://github.com/processing/processing/issues/2030

Prior to posting that I've observed that this problem only happens with the default renderer.       If I specify either P2D or P3D the problem vanishes.

Best Regards, Jim
At one point (I forget which version) Processing changed how pixels[] works and setting alpha became required. I noticed this in my old sketches that stopped working because I would do something like this:
Copy code
  1. pixels[i] = (someRed<<16)|(someBlue)|someGreen;

Fixing it required adding this:
Copy code
  1. pixels[i] = 0xff000000|(someRed<<16)|(someBlue)|someGreen;
AFAIK, since I started to use Processing (around v.0135), setting the alpha channel explicitly when building the color with bit shifting has always been necessary. Only in the form #AABBCC it is set automatically by Processing.
The # is merely a syntactic sugar for 0xff. So #AABBCC is actually 0xffAABBCC.
The 0xff part just means a full alpha, 100% opaque color.
Hi PhiLho,
It is clearly a bug somewhere in Processing as the program code worked with v1.5.1 and worked with v2.0 if I specified P2D or P3D but failed in v2.0 if the default renderer is used. In the 1st 3 cases, alpha is correctly handled. In the last case it isn't.

Best Regards, Jim
My remark was aimed at asimes, not at you, Jim. When we build a color from scratch with bit operators, we have to explicitly set the alpha value, it was always the case. But indeed, if we get a color from the pixels array, it should be fully specified, so when we put it back in the array, the image must remain the same.

Looking at the source, the pixels array is filled directly by Java, with the getRaster().getDataElements(0, 0, width, height, pixels); line (in loadPixels()).
So perhaps the problem lies in the way the BufferedImage is created?

Looks like you found an interesting bug...
(I still have the v.2, the bug was already there.)
It has been a while, I don't remember how long ago (or what version) it was that I could omit alpha and pixels[] would still work. I made a post about this a while ago:  http://forum.processing.org/topic/processing-2-0-changed-how-pixels-works
Hi PhiLho,  

Understood.

Re BufferedImage,  the question is what is the difference between the use of Java as the graphics engine in version 1.5.1 and version 2?  Is that portion of Processing that invokes Java functionality for the default JAVA2D renderer  calling different Java routines or has the way in which the data that is received by Processing changed? 

Bugs, yeah I hate them because 99 times out of 100 the problems I encounter are due to my own coding errors.  In this instance I spent quite a bit of time trying to figure out what "I" was doing wrong - when in fact I had done nothing wrong.

Best Regards, Jim

  • Default JAVA2D is the same for both.
  • In P1.5.1, only OPENGL mode uses OPENGL.
  • In P2+, only JAVA2D mode doesn't use OPENGL.
  • In P2+, P3D is the same as OPENGL.
  • P2+ uses a more recent OPENGL version than P1.5.1.



RE "P2+ uses a more recent OPENGL version than P1.5.1."

Yeah I found that out the hard way. Nothing but opengl framebuffer errors  with v2.  Even though my laptop is only 2 years old, the most recent driver Dell had available was a year old and that did not fix the problem. Had to grab a generic driver from the NVIDIA site and jump through some hoops to get it installed.

Best Regards, Jim
I always used "generic" nVidia drivers. They're always most updated.
Moreover, I don't believe a seller's nVidia driver would be better than the 1s direct from nVidia site!
Re "I don't believe a seller's nVidia driver would be better than the 1s direct from nVidia site". It's just that they're modified and/or have had features added for a tighter integration with that particular system configuration.  Personally I am not a fan of that sort of configuration.

Best Regards, Jim
@asimes: I tried the code you show in this old topic, with Processing 1.5.1 and 2.0, and they seem to behave identically, with a nicely rendering rotating column of 3D shapes.

Now, I notice you used the P2D mode, which I rarely used in v. < 2 and even less now...
So perhaps the behavior of updatePixels() was different from the one in JAVA2D (default mode): if I run the sketch in 1.5.1 in default mode, I get a flat rendering, probably what you see with transparent pixels.
Now that P2D is now OpenGL, the handling of transparency is different.

Curiously, in 2.0 default mode, the sketch is unaffected! Ie. it acts like the transparency is lost too.

Mmm, I made a simple sketch where I build a color from scratch, it behaves identically in both versions, so transparency of color is still kept. I haven't looked how your sketch is make, but it must be a bit atypical.

Copy code
  1. PImage image1, image2;
  2.  
  3. void setup()
  4. {
  5.   size(800, 600);
  6.   image1 = loadImage("H:/PhiLhoSoft/images/Forest.jpg");
  7.   image2 = loadImage("H:/PhiLhoSoft/images/Tree.jpg");
  8.   image1.resize(width, height);
  9.   image2.resize(width, height);
  10. }
  11.  
  12. void draw()
  13. {
  14.   background(0);
  15.   image(image1, 0, 0);
  16.   PGraphics gr = createGraphics(width, height, JAVA2D);
  17.   image2.loadPixels();
  18.   gr.loadPixels();
  19.   for (int i = 0; i < width; i++)
  20.   {
  21.     for (int j = 0; j < height; j++)
  22.     {
  23.       int pos = i + j * width;
  24.       color g = int(brightness(image2.pixels[pos]));
  25.       int alpha = 128;//int(map(pos, 0, width * height, 0, 255)); // Try 0, 255, the commented out expression...
  26.       gr.pixels[pos] = (alpha << 24) + (g << 16) + (g << 8) + g;
  27.     }
  28.   }
  29.   gr.updatePixels();
  30.   image(gr, 0, 0);
  31. }