Processing Forum

Default (Android2D) Renderer displays 16-bit instead of 24-bit

[0 Replies]
- 09-Apr-2013 10:10 AM
- Forum: Android Processing
So my application was looking uggggly... I tried setting and checking the color format for (what I thought was) everything, from the window to the loaded images and it did not help. So then because of this line in the wiki, I thought it was only natural:

Accuracy of colors is more limited on Android. Most screens will not be full 24-bit color, which especially shows up with gradients, highly detailed color sketches, or when using a lot of transparency. With gradients, you might see banding of colors, or when using transparency, you might see halos or visual artifacts left behind. These are just mathematical artifacts due to how colors are handled, subject to limitations of the screen.

Then I tried OPENGL and saw the colors where rendering correctly (24-bit).
So I took a look at the processing source, and figured out it has to do with the (non-GL) surfaceView used for the sketch.

Solution: Include this in setup():
1. getSurfaceHolder().setFormat(1);
Edit: Put it in onCreate() after calling super.onCreate() if you don't want your screen to freeze after orientation change!

It's easy to not notice this issue, but it is there! It's most visible in darker colors where you can see a lot of banding.

Edit: Here is a screenshot (brightness increased for exaggeration):

So why is this not the default format? Is it a bug or was it done like this on purpose?

p.s. I'm using 2.0b8 and a Sony-Ericsson Xperia Arc S.

saveBytes/loadBytes performance

[2 Replies]
- 05-Apr-2013 10:04 AM
- Forum: Programming Questions
I'm using the following function to write an image's pixel array to a temp file and then read them back into the array.
1. void setup() {
2. img = loadImage("image.png");
3. }
5. void keyPressed() {
6. if (key == 's') {
7. int t = millis();
8. saveRAW("x.dat");
9. println(millis()-t);
10. }
11. if (key == 'd') {
12. int t = millis();
13. loadRAW("x.dat");
14. println(millis()-t);
15. }
16. }
18. void saveRAW(String filename) {
19. byte[] bytes = new byte[img.pixels.length*3];
20. int index = 0;
21. for (int i = 0; i < bytes.length; i++) {
22. int c = img.pixels[index];
23. bytes[i++] = (byte)((c >> 16) & 0xff);
24. bytes[i++] = (byte)((c >> 8) & 0xff);
25. bytes[i] = (byte)(c & 0xff);
26. index++;
27. }
28. saveBytes(filename, bytes);
29. }
31. void loadRAW(String filename) {
32. byte[] bytes = loadBytes(filename);
33. int index = 0;
34. int count = bytes.length/3;
35. for (int i = 0; i<count; i++) {
36. img.pixels[i] =
37. 0xFF000000 |
38. (bytes[index++] & 0xff) << 16 |
39. (bytes[index++] & 0xff) << 8 |
40. (bytes[index++] & 0xff);
41. }
42. }
I'm getting ~6ms on saveRaw and ~36ms on loadRAW. Can someone please clarify why loadRAW is so much slower? I mean are the two functions not pretty similar?

Does it have to do with saveBytes and loadBytes or the rest of the function I've written? Is it possible to make it any faster?

SOLVED: Functions run slower the first few times! Is it a bug?

[4 Replies]
- 04-Apr-2013 03:53 PM
- Forum: General Discussion
I'm using 2.0b8 and the first few times a function is called, each time it performs faster than the last time, till it stabilizes on a certain speed. It is the same for both java and android, and depending on the function, it might take anywhere from 2 to 5-6 iterations till the speed stabilizes. Please try this code and see if you get similar results:
1. void setup() {
2. background(0);
3. }
4. void draw() {
5. }
7. void myFunction1() {
8. for (int i = 0; i < 50000; i++) {
9. float a = random(11);
10. float x = cos(sqrt(pow(sin(a), 20)));
11. }
12. }
14. void myFunction2() {
15. for (int x = 0; x < 1000; x++) {
16. loadPixels();
17. for (int i = 0; i < pixels.length; i++) {
18. pixels[i] = color(random(255), random(255), random(255));
19. }
20. updatePixels();
21. }
22. }
24. void keyPressed() {
25. if (key == '1') {
26. int t = millis();
27. myFunction1();
28. println(millis()-t);
29. }
30. if (key == '2') {
31. int t = millis();
32. myFunction2();
33. println(millis()-t);
34. }
35. }
I'm getting 580, 550, 490, 490, 490,... for myFunction2() everytime I run the program (+/- ~2ms) and 27, 17, 17, 17,... for myFunction1().

Is this natural and has to happen for some reason beyond my knowledge? or is it a bug?

It doesn't really matter if you're gonna loop over a function, but let's say there's a function I wanna run just once during the life time of my program, why does it have to run slower than it "really" can and is there a workaround for this (in case it is not a bug)?

Undo/Redoing image adjustments

[2 Replies]
- 02-Apr-2013 01:17 PM
- Forum: Android Processing
I'm trying to implement a simple, one-step undo/redo function in my image manipulation application. Unfortunately buffering the before/after images is not an option because of memory limitations.

So what I'm doing at the moment is saving the before/after images. But that creates a performance/quality dilemma:

- jpeg is fast (i.e. ~500ms to save on my Xperia Arc S) but degrades the quality beyond acceptability after two/three iterations.

- png is of course lossless, but is super slow (~7000ms to save) which makes it impractical.

- bmp would probably be fast, but android does not encode bmp (I think processing saves "file.bmp" as tiff).

- tiff has acceptable performance (~1500ms to save), but android does not decode tiff.

...so, is there anything else I can do?

EDIT: I also tried writing the raw pixel array to a file using this function (I copy/pasted from here and there):
1. void writeData(String filename, int[] data) {
2. try {
3. DataOutputStream dos = new DataOutputStream(new BufferedOutputStream(openFileOutput(filename, Context.MODE_PRIVATE)));
4. for (int i = 0; i < data.length; i++) {
5. dos.writeInt(data[i]);
6. }
7. dos.close();
8. dos.flush();
9. }
10. catch (IOException e) {
11. e.printStackTrace();
12. }
13. }
but it runs at ~2000ms, so I gave up on it. Is there a faster way to write the int array to a file?

Threading: background threads inherently slower than animation thread?

[19 Replies]
- 24-Mar-2013 01:50 PM
- Forum: Android Processing
I'm using thread("whatever") to run my intensive functions (image processing) on a background thread so that I can run a progress-indicator-animation-thingy in the meanwhile in the draw loop.

The problem is that the functions take almost twice the time they do on the animation thread to run on the background thread.

I noticed that it is not the same on my PC. So do the background threads on android have a lower priority or something and are thus inherently slower than the animation thread? or is it possible to use a faster worker thread?

P.S: I'm really illiterate in this area, but just in case it helps: I noticed in ddms that my threaded functions are run on Thread-83653 the first time and then on Thread-83654 and so on.

Any ways to further optimize this (Selective Hue Shift)?

[17 Replies]
- 08-Mar-2013 12:30 AM
- Forum: Programming Questions
So I've written this piece of code to shift the hues in a specific part of the spectrum.

I tried my best to optimize it as much as possible: used LUT, downsampled image for the preview and limited the color operations to the parts where needed.

I get pretty good results on the PC, with ~1ms for the shiftHue() function on the downsampled image and ~12ms for the original image. The problem is when I run it on my android phone I only get ~150ms and ~800ms respectively. Is there anything I am missing which can be further optimized? or should I just downsample further for the preview?

( note: I think my question is a general programming question and not android specific, hence posting it here. Am I right?)

here is the code:
1. PImage bigImg;
2. PImage smallImg;
4. float hueLUT[];
5. float hueShift;
7. void setup() {
8. size(480, 854);
9. colorMode(HSB, 1);
10. imageMode(CENTER);
12. initHueLUT();
14. bigImg = loadImage("big.png");
15. smallImg = loadImage("small.png");
16. image(bigImg, width/2, height/2);
17. }
19. void draw() {
20. if (mousePressed) {
21. hueShift = map((mouseX), 0, width, -3, 3);
22. image(shiftHue(smallImg), width/2, height/2, bigImg.width, bigImg.height);
23. }
24. }
26. void mouseReleased() {
27. image(shiftHue(bigImg), width/2, height/2);
28. }
30. PImage shiftHue(PImage in) {
31. int w = in.width;
32. int h = in.height;
33. PImage out = createImage(w, h, HSB);
35. in.loadPixels();
37. for (int i = 0; i < in.width; i++) {
38. for (int j = 0; j < in.height; j++) {
39. int index = i + j*in.width;
40. color c = in.pixels[index];
41. float H = hue(c);
42. int hueIndex = int(H*256);
44. if (hueLUT[hueIndex]>0) {
45. float S = saturation(c);
46. float B = brightness(c);
47. H = (hueShift * hueLUT[hueIndex]+H);
48. if (H<0) {
49. if (H<-1) H = 2+H;
50. else H = 1+H;
51. }
52. else {
53. if (H>2) H = H-2;
54. else {
55. if (H>1) H = H-1;
56. }
57. }
58. out.pixels[index] = color(H, S, B);
59. }
60. else {
61. out.pixels[index] = in.pixels[index];
62. }
64. }
65. }
66. out.updatePixels();
67. return out;
68. }
70. void initHueLUT() {
71. hueLUT = new float[256];
72. for (int i = 0; i<256; i++) {
73. hueLUT[i] = 1.1*pow(sin(PI*(i/256f)-HALF_PI-.12), 60)-.1;
74. }
75. }
Thanks in advance!

EDIT: Replaced the double for loops up there with " for (int i = 0; i < in.pixels.length; i++) " and it got ~30ms faster. anything else?

ControlP5 Control Window Screenshot

[8 Replies]
- 31-Aug-2012 04:53 PM
- Forum: Contributed Library Questions
Hey! Does anyone know of a way to save the CP5 control window to an image?

thanks

Activity Trend