When using copy on either a PImage or PGraphics object and attempting to
use the very bottom row or furthest right column of pixels of srcImg, they
are cut off.

As a novice programmer, I would guess that its simply a < checking to make
sure the pixel grabbing doesn't attempt to grab pixels that aren't actually
there where there should be a <=, but then again, novice programmer, so
take it for what it's worth.

I've put together a demonstration of the bug, though I'm not sure if I
should put code forum tags around it

[code]
PImage sampleImage;

void setup () {
background(127);
//Let "image.png" be any external image file.
sampleImage = loadImage("image.png");
size (sampleImage.width, sampleImage.height*6);

//Example 1
//The bottom row and left column are lost. Despite equal source and
destination dimensions, scaling occurs.
copy(sampleImage, 0, 0, sampleImage.width, sampleImage.height, 0, 0,
sampleImage.width, sampleImage.height);

//Example 2
//The bottom row and left column are lost. Despite inequal source and
destination dimensions, scaling does not occur.
copy(sampleImage, 0, 0, sampleImage.width, sampleImage.height, 0,
sampleImage.height*2, sampleImage.width-1, sampleImage.height-1);

//Example 3
//The bottom row and left column are purposefully excluded. Equal source
and destination dimensions and no scaling, as copy should work. Generates
identical results to example 2.
copy(sampleImage, 0, 0, sampleImage.width-1, sampleImage.height-1, 0,
sampleImage.height*4, sampleImage.width-1, sampleImage.height-1);
}
[/code]

I've encountered this bug compiling on Mac OSX, presumably with Apple's
Javac, and running on Mac OSX (Apple Java again) and MS Windows XP (Sun
Java). Additionally, there is a forum thread regarding the bug here:
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Syntax;action=display;num=1235163457

Thanks for your time.

edit]
copy misbehavior in PImage

edit]
fixed copy behavior in PImage

edit]
proposed changes to blit_resize

Changing the >= to > on lines 1560 and 1569 of PImage make things behave like
they in the provided test code. I changed the background to full green and
tested this using an image with a 1px pink border.

> Changing the >= to > on lines 1568 and 1569 of PImage make things behave like
corrected the line numbers, there was a typo in the first one above

Also, please excuse the spam, I didn't realize it was creating all those independent posts.

thanks chris, i don't think this is quite right though. on a quick glance,
i wonder if this works better:

if (srcX2 > img.width) srcX2 = img.width;
if (srcY2 > img.height) srcY2 = img.height;

but the problem is that

if (srcX2 > img.width) srcX2 = img.width - 1;
if (srcY2 > img.height) srcY2 = img.height - 1;

this seems to introduce a weird case where if the image is 100x100, and
srcX2 and srcY2 are 101x101, then it's gonna give up on that last row of
pixels (rather than scaling them in).

I added a 4th test case to the sketch where the destination is img.width+1 img.height+1 and my
fix scales in the last row and column fine. Curiously, I tried your proposed changes and it
produces the exact same results as mine for the test code. I've reproduced it multiple times,
altering between original, your fix, and my fix. Both are better than it sits now, though.

k, i've modified to go with this version:

if (srcX2 > img.width) srcX2 = img.width;
if (srcY2 > img.height) srcY2 = img.height;

let me know if that's working, and if so i'll close the bug. please also
attach the test sketch here, would be helpful for any future issues that
come up.

edit]
Test case with 1px differences in an image

Here is a test case

edit]
Screenshot of the fixed behavior

First image is unscaled. Second is scaled down by 1px. Third purposefully
excludes bottom row and rightmost column. Fourth is scaled up by 1 px. Produced
by the test case.

I'd say it works.

thanks, marking as fixed for 0182 (just posted).