Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PImage.resize() not implemented in Processing 4?? #200

Closed
processing-bot opened this issue Jun 4, 2021 · 8 comments
Closed

PImage.resize() not implemented in Processing 4?? #200

processing-bot opened this issue Jun 4, 2021 · 8 comments

Comments

@processing-bot
Copy link
Collaborator

Created by: jordirosa-p5

Description

The resize method for the PImage class is not implemented (yet?).

Expected Behavior

PImage.resize() has always worked, resizing the image to the size provided. Code made using previous versions stops working, the documentation in the processing reference web shows resize() as a usable method, though.

Current Behavior

Attempting to using the resize method on a PImage throws an exception, and looking at the Processing 4 code is easy to see why it's throwing it:

public void resize(int w, int h) { // ignore
throw new RuntimeException("resize() not implemented for this PImage type");
}

Steps to Reproduce

Your Environment

  • Processing version: 4.0a3
  • Operating System and OS version: macOS Big Sur
  • Other information:

Possible Causes / Solutions

Is this method going to be implemented in Processing 4?

@processing-bot
Copy link
Collaborator Author

Created by: behreajj

If you want to write one for yourself, it depends on what kind of algorithm you want to use (bicubic, bilinear, nearest neighbor). After reading this Stack Overflow discussion, I wrote this Processing code for my own use.

Like the README says, functions that rely on AWT are being shifted around. PImageAWT, a sub-class of PImage, uses a resize function that relies on AWT.

public void resize(int w, int h) { // ignore

Whether this version of resize is called depends on which renderer you use and whether you use loadImage or createImage.

PGraphics extend PImage. If a resize algorithm were implemented in PImage, all its sub-classes--various graphics renderers included--would need to be tested to see if the parent resize worked or needed an override. Check this issues section for topics on surface.setResizable and you'll see how the problems compound.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

If you're using createImage() or loadImage(), you should never run into this.

Can you share an example that causes this problem?

@processing-bot
Copy link
Collaborator Author

Created by: behreajj

void setup() {
  size(256, 256, JAVA2D);
  PImage img = createImage(256, 256, ARGB);
  println(img.getClass());
  img.resize(256, 128);
}

@processing-bot
Copy link
Collaborator Author

Created by: jordirosa-p5

In my case, the image I need to resize is one I create by calling g.get().

The visual effect i get from my app to create a nice blurry effect totally depends on the last lines in my draw() function. Here is the most simple version of it:


void setup() {
  fullScreen(P3D);
  frameRate(30);

  background(255,255,255);
  stroke(0);
}

void draw(){
  ellipse(width*0.5, height*0.5, 20, 20);
  
  PImage gBig = g.get();
  gBig.resize(width+2, height+2);
  set(-1, -1, gBig);
}

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Perfect, thanks both. resize() should be working in both of those cases; I'll check into what's going on.

@processing-bot
Copy link
Collaborator Author

Created by: jordirosa-p5

Thank you!

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Fixed for 4.0 alpha 4.

@processing-bot
Copy link
Collaborator Author

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant