PImage Copy Strangeness

Programming Questions

artsnova

in Programming Questions • 1 year ago

Hi, I'm experiencing an unusual problem with PImage. That is I am repeatedly using get, set, and copy to copy from a source PImage to a destination PImage. The problem is that after each get/set/copy series of operations the image becomes progressively darker. This happens on 2 different systems running Processing 1.5.1 under Windows 7 64bit so I know it is not machine dependent.

In the image below, the left side is the original image and the right side is what it looks like after 160 copies. :

The code that follows is part of a much larger program in which I discovered the problem. Cutting out all the other code, I was able to isolate the source of the darkening to the code that appears below. Based on my understanding of get/set/copy, I am at a complete loss to explain why successive copy operations should cause the image being processed to darken.

Any suggestions as to how to overcome this will be greatly appreciated. Thanks.

int maxFrames=160; // number of times to copy
String inputFile="C:/a_PDE_Input/Mona_Lisa_smalllight.jpg";
String filenam="C:/a_PDE_Output/Mona_Lisa_smalllight_output.jpg";
PImage img, imgtmp;
color c;
int px;
float cx,cy, mx,my;
boolean looping=true;
float h,w;
void setup(){
img = loadImage(inputFile);
imgtmp = loadImage(inputFile);
img.loadPixels();
px = img.pixels.length;
mx = img.width/2;
my = img.height/2;
h = img.height;
w = img.width;
noLoop();
cx = mx; cy=mx;
for(int i=1; i < maxFrames; i++) {
if(i%30 == 0) print("*");
copyit();
}
img.save(filenam);
println(" -> Saved "+filenam);
}
void draw() {}
void copyit() {
int i,j;
for (j=1; j < h-1; j++) {
for (i=1; i < w-1; i++) {
c = img.get(int(i),int(j));
imgtmp.set(int(i), int(j), c);
}
}
img.copy(imgtmp, 0,0, img.width, img.height, 0,0, img.width, img.height);
}

Replies(10)

artsnova

Re: PImage Copy Strangeness

1 year ago

Well it looks like I have found the culprit - though confirmation from someone else would be nice.
I was able to confirm that after executing the two for loops (j and i), the img and imgtmp pixel arrays contained the same information.

However executing the img.copy() statement resulting in the two arrays NOT having the same color information. So it looks like the copy operation is the villain. Removing the copy() statement and substituting my own pixel array copying routine solved the problem.

So users of the PImage copy() method - beware.

Best Regards, Jim

amnon.owed

Re: PImage Copy Strangeness

1 year ago

For many cases using your own pixel array operations is better (read: faster) than using get-set-copy methods. But if you really want one-liners, you could use get-set instead of copy. Apparantly copy runs into some rounding/buffer/replace issue or something. If you want to get to the bottom of this issue dive into the source code of PImage. In the example below, press the mouse to see the effect you encounter. If you use the get-set methods, all is fine. When you add resize into the mix, you have all the functionality of the copy function.

Code Example

String inputFile = "http://dakzoekje.nl/images/mona-lisa.jpg";
PImage img, imgtmp;
void setup() {
img = loadImage(inputFile);
imgtmp = loadImage(inputFile);
size(img.width*2, img.height);
}
void draw() {
image(img, 0, 0);
image(imgtmp, img.width, 0);
imgtmp = img.get();
if (!mousePressed) {
// different route
PImage temp = imgtmp.get(0,0,img.width,img.height);
// resize here if necessary
img.set(0,0,temp);
} else {
// your route
img.copy(imgtmp, 0,0, img.width, img.height, 0,0, img.width, img.height);
}
}

artsnova

Re: Re: PImage Copy Strangeness

1 year ago

Regarding your statement "Apparantly copy runs into some rounding/buffer/replace issue or something." would you say this qualifies as a bug in the PImage copy() code or is it deeper down in Java itself? For my part I'll just do my own copying from now on.

Regarding your statement "using your own pixel array operations is better (read: faster)" agreed but then I was going for speed of code generation over speed of program execution. However in the course of identifying the problem I replaced all the get/set/copy operations with straight pixel array operations. So now not only does the program run faster but it works as intended.

Best Regards, Jim

eltodesuk..

Re: PImage Copy Strangeness

1 year ago

Could it be that some transparency alpha value increases each time values are put onto a pixel?

Even an almost but not quite transparent image will become opaque if pile on too tick.

artsnova

Re: PImage Copy Strangeness

1 year ago

Hi, No transparency/alpha in the source image nor am I using it in the code so that is not the issue.

There definitely is quirkiness somewhere. For example, I just discovered that if I write the same text to the screen at the same location over and over and over, that area of the screen will go completely black after enough iterations resulting in solid black rectangles where each letter would normally appear. Most strange.

Best Regards, Jim

PhiLho

Re: PImage Copy Strangeness

1 year ago

" if I write the same text to the screen at the same location over and over and over, that area of the screen will go completely black after enough iterations resulting in solid black rectangles where each letter would normally appear. Most strange."
Not strange. That's why we use background() in most sketches: if not, nice text becomes blocky, then goes as you describe. That's because the anti-aliasing used to make the text to look good cumulates, the transparency goes down to opacity, and at the end, you get a rectangle.

artsnova

Re: PImage Copy Strangeness

1 year ago

Hi PhiLho,

It is worth noting that this behavior does not happen when using the JAVA2D renderer. It does happen in both P2D and P3D. In OpenGL, it progresses in that direction but I didn't have the patience to wait till it happened. So it looks like this issue is limited to the P2D, P3D renderers.

Best Regards, Jim

quarks

Re: PImage Copy Strangeness

1 year ago

The problem appears to be in the PImage class.

The copy command can be used to blend the source with the destination but the default behaviour is REPLACE and if you trace through the source code for PImage at first glance it appears to do just that BUT it does more. The documentation for copy() states

If the source and destination regions aren't the same size, it will automatically resize the source pixels to fit the specified target region. No alpha information is used in the process, however if the source image has an alpha channel set, it will be copied as well.

To do this PImage uses a method called blit_resize() that method calls filter_bilinear() to do the actual colour calculations. Now here comes (what I believe is) the problem, the blit_resize() method is executed even if the source and destination regions are the same size so each pixel is being blended with its four neighbours even though it is not neccessary.

If others agree with me then it is a bug in the PImage class.

PhiLho

Re: PImage Copy Strangeness

1 year ago

OK, I can see that, except I just get a black background on the letters (because I used a fill color). It is indeed independent of the aliasing classical issue (but still, it isn't a good idea to write repeatedly a text without refreshing its background).

Indeed, I think we can file that as a bug.

artsnova

Re: PImage Copy Strangeness

1 year ago

Hi Quarks and PhiLho,

Thanks for the digging on this as that is something that I was not prepared (nor qualified) to do. Fortunately the work around of using my own pixel array copy operation makes it possible to circumvent this issue with respect to what I was doing.

Best Regards, Jim

Top Reply