Use of loadPixels() not applied to PImage instance?

edited November 2013 in Questions about Code

Getting started with image creation and manipulation. Ran example "LinearImage" trying to figure out pixel color "set" and "get". But, whoa, loadPixels() is used both as a method applied to the already-created instance "img" and all by itself. Note this snippet with my added comments:

void setup() {
  size(640, 360);
  stroke(255);
  img = loadImage("sea.jpg"); // define previously declared PImage instance
  img.loadPixels(); // fill pixel array field of "img" using PImage class method
  loadPixels(); // Yipes! Create another pixels[] not attached to any PImage
}

Evidently the stand-alone call to loadPixels() creates an independent array of pixels[] since there is such a reference below in this line in the draw() block:

for (int y = 0; y < img.height; y++) {
  arrayCopy(img.pixels, signalOffset, pixels, y*width, img.width);

If so, can one do a stand-alone "loadPixels()" more than once and have access to additional pixel arrays (of uncertain size and unknown name/label/address)? By the way, although this example confused me, I DO appreciate all the well-organized examples downloaded with Processing.

Answers

  • loadPixels() alone is loading the array containing display window pixels.

  • edited November 2013

    Processing's canvas is itself a PGraphics object. Its reference is stored in variable g! @-)
    And PGraphics is a sub-class of PImage. That's why it got pixels[] as well. >-)

    When we issue a loadPixels(), pixels[] is merely filled up w/ current image representation as an array of pixel colors.
    It's not created, 'cause pixels[] is a field of class PImage. And it's always there! 8-X
    In the same vein, updatePixels() re-copies pixels[]'s content back to its PImage's internal format.

    A simple example demonstrating that drawing w/ or w/o specifying variable g is the same thing: O:-)

    noLoop();
    
    rect(0, 0, 50, 50);
    
    g.rect(width>>1, height>>1, 49, 49);
    
  • edited November 2013

    Thanks _vk and GoToLoop. The situation may be clearing up. Let me review in simple terms (the kind I best understand):

    1. I might declare and load several images, say img1, img2, ...
    2. Each of these will have available a pixels[] array -- filled via loadPixels()
    3. I could access any pixel by addressing it through pixels[], or using get() and set()
    4. The revised pixels could then be "sent back" to the internal store via updatePixels()
    5. I might display any of them, say img1, with a call to image(img1, 0, 0) in draw() which transfers img1 into the display window store.
    6. The display store is itself a unique instance of PGraphics (subclassed from PImage)
    7. Thus, the stand-alone loadPixels() call makes the one-of-a-kind pixels[] array accessible and contains color values of the current visible scene.
    8. At this point img1.pixels[] and pixels[] have the same set of values.

    I'll keep exploring the examples and documentation. The examples are a real treasure 'cause one can hack up the code to explore various effects.

  • My next challenge is how to enforce something like CR/LF in this editor! :-/

  • Answer ✓

    A single empty line before your list made it a real list. I edited your message to add it. B-)

    And basically, your analysis / summary is right.

    Just one remark: loadPixels() isn't necessary, actually, for a PImage (but it is mandatory for a PGraphics) in default (JAVA2D) mode in Java mode.

    It is good practice to always use it, because it can fail in Android mode and perhaps in other modes (OpenGL? JavaScript?).

Sign In or Register to comment.