Processing Forum

How to properly dispose of movies with the new built-in library

[0 Replies]
- 10-Jun-2013 02:21 PM
- Forum: Core Library Questions
I want to be able to open and close various movie files during the duration of a Processing sketch.

Opening is fairly straightforward, getting rid of it seems to be a bit tricky: just removing all references to it gives me a warning. Haven't run out of memory during tests yet, but the program is meant to run for a long time so this does matter. I found out that there is a "dispose()" method (discovered by trying out if the old GSVideo API was still appropriate), but I'm not sure how to use it.

At the moment I'm calling stop() followed by dispose() followed by removing all references to the Movie object. I still get warnings that the resources aren't properly freed sometimes, althought "it could be a refcounting bug"? It's not entirely clear.

"This file is named x.jpg not X.JPG. Rename the file or change your code."

[5 Replies]
- 20-May-2013 03:10 AM
- Forum: General Discussion
Encountered when using loadImage or loadBytes in the Processing 2.0 beta.

This seems to be a change in the API, as before these functions would return null. Also, only in Windows, as my Linux beta still happily keeps working - perhaps because NTFS is case insensitive?

I think I understand the reasoning, typos are almost always a bug, but the thing is that my program relies on typed user input to open files, and I don't want the sketch to crash whenever an almost-right filename is typed. What are my options then?

Help! F10 blocks other function keys - have potential solution but I don't understand it

[2 Replies]
- 18-May-2013 04:08 AM
- Forum: Programming Questions
This probably is OS dependant - I'm on Windows 8. When I press F10 it registers, but after that all function keys are ignored until I either press a non-function key or F10.

Example code to show what I mean:
1. import java.awt.event.KeyEvent;
2. void setup() {
3. }
4. void draw() {
5. }
6. void keyPressed() {
7. switch(keyCode) {
8. case KeyEvent.VK_F1:
9. println("F1");
10. break;
11. case KeyEvent.VK_F2:
12. println("F2");
13. break;
14. case KeyEvent.VK_F3:
15. println("F3");
16. break;
17. case KeyEvent.VK_F4:
18. println("F4");
19. break;
20. case KeyEvent.VK_F5:
21. println("F5");
22. break;
23. case KeyEvent.VK_F6:
24. println("F6");
25. break;
26. case KeyEvent.VK_F7:
27. println("F7");
28. break;
29. case KeyEvent.VK_F8:
30. println("F8");
31. break;
32. case KeyEvent.VK_F9:
33. println("F9");
34. break;
35. case KeyEvent.VK_F10:
36. println("F10");
37. break;
38. case KeyEvent.VK_F11:
39. println("F11");
40. break;
41. case KeyEvent.VK_F12:
42. println("F12");
43. break;
44. }
45. }
Potential solution here? I don't really follow what's going on though:
http://www.dreamincode.net/forums/topic/268248-f10-blocks-other-action-keys/

Anyone with a better understanding of Java able to help out?

Fast blurring

[19 Replies]
- 12-Dec-2011 02:38 PM
- Forum: Share your Work
Hey all,

TL;DR: I've been working on faster variants of filter(BLUR), filter(DILATE) and filter(ERODE). Also plays nice with code that tends to play around with the pixel array a lot. Up to fourteen times faster than normal blur! About two times faster than Mario Klingemann's Super Fast Blur, but note that this is only because I specifically optimised for a 3x3 kernel. His version is faster for bigger kernels. See code in action here, with source:

http://jobleonard.nl/fastFilters/

Added downside/upside: wraps around (suited my needs)

I've been trying out some glow/dissolve effects in my code. Combining filter(BLUR), filter(DILATE) and filter(ERODE) gives results tha:t look nice, but the problem is that filter(WHATEVER) is very slow, especially BLUR.

Note: I'm mostly coding on a netbook, without OpenGL. Otherwise I'd use the GLGraphics library and apply shaders. Also, I tend to use per-pixel manipulation a lot in my code, and we all know loadPixels()/updatePixels() and OpenGL don't really like one another (again, can be fixed with textures and shaders, but not on my netbook). Also it felt like a complete waste of time to use
1. updatePixels();
2. filter(SOMETHING);
3. loadPixels();
... every time I wanted to apply a filter to the pixels I was messing around with.

So, I've tried to build faster filters that manipulate the pixel array, then leave it alone. Actually ended up with making a second buffer, but hey, it suits my needs and doesn't make the code that much complexer in use.

I made these assumptions:

- multiplication is faster than division

- shifting is faster than either of those

- reads are faster than writes

- numeral constants are faster than variables

- bitwise AND is probably quite cheap as well

- las but not least, the JVM is smart enough to optimise something as crazy as:
1. for (int j = 1; j < (height-1); ++j){
2. t[i + j*width] = (((((s[i + j*width] & 0xFF) << 2 ) +
3. (s[i + 1 + j*width] & 0xFF) +
4. (s[i - 1 + j*width] & 0xFF) +
5. (s[i + (j+1)*width] & 0xFF) +
6. (s[i + (j-1)*width] & 0xFF)) >> 3) & 0xFF) +
7. (((((s[i + j*width] & 0xFF00) << 2 ) +
8. (s[i + 1 + j*width] & 0xFF00) +
9. (s[i - 1 + j*width] & 0xFF00) +
10. (s[i + (j+1)*width] & 0xFF00) +
11. (s[i + (j-1)*width] & 0xFF00)) >> 3) & 0xFF00) +
12. (((((s[i + j*width] & 0xFF0000) << 2 ) +
13. (s[i + 1 + j*width] & 0xFF0000) +
14. (s[i - 1 + j*width] & 0xFF0000) +
15. (s[i + (j+1)*width] & 0xFF0000) +
16. (s[i + (j-1)*width] & 0xFF0000)) >> 3) & 0xFF0000) +
17. 0xFF000000;
18. }
19. }
Here's the results of my own sloppy, not that trustworthy benchmark:

http://jobleonard.nl/fastFilters/filterbenchmarks.txt

filter(BLUR) 532467 - 26931 = 505536 factor: 1.00

divBlur 130583 - 26931 = 103652 factor: 4.87

shiftBlur 84658 - 26931 = 57727 factor: 8.75

shiftBlur3 82710 - 26931 = 55779 factor: 9.06

shiftBlur2 76136 - 26931 = 49205 factor: 10.2

shiftBlur1 73402 - 26931 = 46471 factor: 10.8

I discovered Klingemann's filter when I checked if other people had done stuff like this, but after benchmarking. Made a quick addition, it's slightly faster than divBlur, but still slower than the shiftBlurs

Obviously, these blurs have a different behavior from the filter(BLUR). Here are the kernels:

divBlur:

0 1 0

1 1 1

0 1 0

shiftBlur: combination you want of:

0 A 0

A B A

0 B 0

Also, you define how much it shifts. Note that by shifting so that the divisor is more/less than actual sum of the kernel, you can blur and fade to black or white at the same time! The linked example uses the shiftBlur3 kernel.

shiftBlur3:

00 51 00

51 52 51

00 51 00

shiftBlur2:

0 3 0

3 4 3

0 3 0

shiftBlur1:

0 1 0

1 4 1

0 1 0

Any ideas for further improvements are welcome. I'll probably update this in the coming days to accept any PImage or PGraphics, and versions that don't wrap.

Again, applet version with ridiculously long and ugly source code can be found here:

http://jobleonard.nl/fastFilters/

EDIT: Updated with Klingemann's optimisation. Now between ten and fourteen times faster than regular blur on my netbook!

Per-pixel manipulations in Processing 2.0

[0 Replies]
- 28-Sep-2011 03:49 AM
- Forum: Library and Tool Development
I was reading the upcoming changes for Processing 2.0

http://wiki.processing.org/w/Changes#Upcoming_changes_in_Processing_2.0
P2D and P3D have been removed. Using P2D will simply use the default (JAVA2D) renderer, and P3D will try to use OpenGL. We made this change to simplify things for us, and focus our efforts on better feature parity across other implementations. This fits better with the situation on Android and with JavaScript, for instance. This will cause some sketches to actually run slower, but the bottom line is that we simply don't have anyone to help maintain all of this extra code. We hope to sort out the performance problems over time—if you see something weird, please report a bug.

And on a lesser note:

textMode(SCREEN) has been removed. SCREEN was a super fast/efficient way of rendering text with P2D and P3D, but since they're going bye-bye and it's actually slower in the remaining renderers, it's going away.

I understand the reasoning, but I also tend to do a LOT of per-pixel manipulation. So I figured: why not start a topic on how to change your code to keep the sketches reasonably fast, or maybe make them even faster?

Here's what I'm already doing with GLGraphics on computers that fully support textures:
1. GLTexture GL2D; // I suck at good variable names
3. void setup(){
4. GL2D = new GLTexture(this, width, height);
5. GL2D.clear(0);
6. }
8. void display(){
9. //replaces loadPixels()
10. GL2D.updateTexture();
12. //replaces pixels[something] = something
13. GL2D.pixels[something] = something
15. //replaces updatePixels();
16. GL2D.loadTexture();
17. GL2D.render();
18. }
I haven't benchmarked it against P2D, but logically, as long as you keep the transfer of pixeldata between the texture and regular RAM to a minimum (that is: don't run GL2D.updateTexture()/GL2D.loadTexture() too often, preferably only once per loop) it should be faster. I mostly use it because it can be combined with shaders.

Sadly, this doesn't work on my netbook (crashes). If I use the current built-in OpenGL renderer there, I need to update the screen twice to avoid flickering. That is to say: once, and then in the next draw() loop. I'll look up the code I use for that later (haven't acces to it right now). Don't recall if it's faster or slower than P2D, will test that.

So, who else has ideas?

Hue Mirror

[0 Replies]
- 04-Aug-2011 01:28 PM
- Forum: Share your Work
Very simple application. Asks you to open an image, lets you scroll around with arrow keys. Click on two pixels in the picture to switch the hues of those pixels (and mirror every other hue along with it).
This is different from inverting the hue of an image in Photoshop! (which I why I thought of making it in the first place). Spacebar to switch between original/result view, 'O' to open another picture, 'S' to save the result (make sure you've clicked twice first!)
1. PImage sourceImage, invertedImage;
2. boolean displaySource, displayInverted, mouseClicks;
3. int sourcePixelOne, sourcePixelTwo, x0, offsetX, y0, offsetY;
5. void setup() {
6. size(screen.width, screen.height, P2D);
7. loadPixels();
8. colorMode(HSB, 1.0);
9. strokeWeight(1);
10. stroke(1.0);
11. if (!openImg()) {
12. exit();
13. }
14. initKeysAndInput();
15. }
17. void draw() {
18. checkKeyboardInput();
19. if (displaySource) {
20. imgToPixels(sourceImage);
21. }
22. else if (displayInverted) {
23. imgToPixels(invertedImage);
24. }
25. updatePixels();
26. }
28. boolean openImg() {
29. String inputImg = selectInput();
30. if (inputImg == null) {
31. println("No file selected!");
32. return false;
33. }
34. else {
35. background(0);
36. sourceImage = loadImage(inputImg);
37. sourceImage.loadPixels();
38. imgToPixels(sourceImage);
39. invertedImage = createImage(sourceImage.width, sourceImage.height, RGB);
40. invertedImage.loadPixels();
41. displaySource = mouseClicks = true;
42. displayInverted = false;
43. return true;
44. }
45. }
47. void imgToPixels(PImage img) {
48. if (width > img.width) {
49. offsetX = (width - img.width) >> 1;
50. x0 = img.width;
51. }
52. else {
53. offsetX = 0;
54. x0 = width;
55. }
56. if (height > img.height) {
57. offsetY = (height - img.height) >> 1;
58. y0 = img.height;
59. }
60. else {
61. offsetY = 0;
62. y0 = height;
63. }
64. for (int i = 0; i < x0; ++i) {
65. for (int j = 0; j < y0; ++j) {
66. pixels[i + offsetX + (j + offsetY)*width] = img.pixels[i + x + (j + y)*img.width];
67. }
68. }
69. }
71. void mirrorHue() {
72. float hueOne = hue(sourcePixelOne);
73. float hueTwo = hue(sourcePixelTwo);
74. println("hueOne: " + hueOne + " hueTwo: " + hueTwo);
75. float avgHue = (hueOne + hueTwo) * 0.5;
77. for (int i = 0; i < sourceImage.pixels.length; ++i) {
78. hueOne = hue(sourceImage.pixels[i]);
79. hueTwo = (1.0 + 2*avgHue - hueOne)%1.0;//mirrors the hue around avgHue.
80. invertedImage.pixels[i] = color(hueTwo, saturation(sourceImage.pixels[i]), brightness(sourceImage.pixels[i]));
81. }
83. invertedImage.updatePixels();
84. }
86. int x, y, delta;
87. boolean[] keys;
89. void initKeysAndInput() {
90. keys = new boolean[526];
91. for (int i = 0; i < keys.length; ++i) {
92. keys[i] = false;
93. }
94. x = y = 0;
95. delta = 5;
96. }
98. void keyPressed() {
99. keys[keyCode] = true;
100. }
102. void keyReleased() {
103. keys[keyCode] = false;
104. if (!(checkKey(LEFT) || checkKey(RIGHT) || checkKey(UP) || checkKey(DOWN))) {
105. delta = 5;
106. }
107. }
109. boolean checkKey(int k) {
110. if (keys.length >= k) {
111. return keys[k];
112. }
113. return false;
114. }
117. void checkKeyboardInput() {
118. if (checkKey(LEFT) && x > 0) {
119. x = max(x-delta, 0);
120. delta = min(delta+1, 40);
121. }
122. if (checkKey(RIGHT) && sourceImage.width > width) {
123. x = min(x + delta, sourceImage.width - width);
124. delta = min(delta+1, 40);
125. }
126. if (checkKey(UP) && y > 0) {
127. y = max(y-delta, 0);
128. delta = min(delta+1, 40);
129. }
130. if (checkKey(DOWN) && sourceImage.height > height) {
131. y = min(y + delta, sourceImage.height - height);
132. delta = min(delta+1, 40);
133. }
134. if (checkKey('o') || checkKey('O')) {
135. openImg();
136. }
137. if (checkKey('s') || checkKey('S')) {
138. PGraphics saveGraphics = createGraphics(invertedImage.width, invertedImage.height, P2D);
139. saveGraphics.beginDraw();
140. saveGraphics.loadPixels();
141. for (int i = 0; i < saveGraphics.pixels.length; ++i) {
142. saveGraphics.pixels[i] = invertedImage.pixels[i];
143. }
144. saveGraphics.updatePixels();
145. saveGraphics.save("output.png");
146. saveGraphics.endDraw();
147. }
148. if (checkKey(' ')) {
149. displaySource = !displaySource;
150. displayInverted = !displayInverted;
151. keys[' '] = false; //one switch per press
152. }
153. }
155. void mouseClicked(){
156. if (mouseClicks){
157. mouseClicks = !mouseClicks;
158. sourcePixelOne = sourceImage.pixels[mouseX - offsetX + x + (mouseY - offsetY + y) * sourceImage.width];
160. } else {
161. mouseClicks = !mouseClicks;
162. sourcePixelTwo = sourceImage.pixels[mouseX - offsetX + x + (mouseY - offsetY + y) * sourceImage.width];
163. mirrorHue();
164. }
165. }

java.awt.Color.RGBtoHSB and java.awt.Color.HSBtoRGB confusion..

[3 Replies]
- 01-Aug-2011 01:31 PM
- Forum: Programming Questions
I'm trying to play around with some HSB pixel manipulation, which requires reading out HSB values from existing pixels. ~~This functionality isn't built into Processing (yet?)~~ (see below), but the following topic:

http://processing.org/discourse/yabb2/YaBB.pl?num=1264613462

and the Java documentation on the mentioned functions:

http://download.oracle.com/javase/1.4.2/docs/api/java/awt/Color.html#HSBtoRGB(float, float, float)

http://download.oracle.com/javase/1.4.2/docs/api/java/awt/Color.html#RGBtoHSB(int, int, int, float[])

... seemed to be what I'm looking for. However, it's not quite working like I want it to. Copy/paste the following code into a sketch and see for yourself:

EDIT: code is bugged, see response below.
1. PImage img;
2. img = loadImage(selectInput());
3. size(img.width, img.height, P2D);
4. loadPixels();
5. img.loadPixels();
6. for (int i = 0; i < img.pixels.length; ++i) {
7. float[] pixelHSB = java.awt.Color.RGBtoHSB(img.pixels[i]>>16, (img.pixels[i]>>8) & 0xFF, img.pixels[i]>>16, null);
8. pixels[i] = java.awt.Color.HSBtoRGB(pixelHSB[0], pixelHSB[1], pixelHSB[2]);
9. }
10. updatePixels();
(obviously, you must open an image file to test)

I figured that the most sensible behaviour would be if the result of RGBtoHSB fed back into HSBtoRGB would result in the same value as what we started with, ignoring rounding errors. How wrong I was...

I've already tried dividing/multiplying by 360.0 (figured the might be inconsistent with the range on Hue), but that's not the answer. Also, I've tried replacing line 8 with:
1. colorMode(HSB,1.0);
2. pixels[i] = color(pixelHSB[0]/360.0, pixelHSB[1], pixelHSB[2]);
Doesn't solve the problem, and actually produces different results!

If anyone has any idea what is going wrong, please chime in :)

TL;DR: F*cking RGBtoHSB/HSBtoRGB conversions, how do they work?

GSVideo frame(), length(), duration() and jump() functions not working in my sketch

[10 Replies]
- 16-May-2011 06:59 AM
- Forum: Contributed Library Questions
First of all, a big thank you to Andres Colubri for his GSVideo and GLGraphics libraries - somehow, compared to a full CPU load with stuttering images in Cinder, my ported sketch instead has only a 20% load with no stuttering at all! I didn't expect Java to be superior to a C++ framework at something like this! :D

Now, I'd like to make a sketch that plays random short clips of different movies in sequence, so I need (amongst other things) to check how long the movie is and to be able to jump to a frame within the movie. However, the functions that are supposed to let me do this don't work on my computer (Windows 2008 with default Processing 1.5.1). They all return 0, or jump to frame 0 regardless of input.

This might not be GSVideo's fault - maybe the movies I'm using don't decode properly or something. They're encoded in H264, in an MP4 file. Could that influence this?

Thanks again!

Job

Pi is wrong!

[1 Reply]
- 19-Apr-2011 02:28 AM
- Forum: General Discussion
Are you all aware of the Tau Manifesto? It's a half-joking, all-serious rant saying that Pi is the wrong circle constant. No, really! Here's a short youtube clip inspired by it that explains this:

http://www.youtube.com/watch?v=jG7vhMMXagQ

For the full manifesto, see:

http://tauday.com/

I'm convinced! So, in order to get more people to know of the superiour τ, I humbly suggest we add TAU as a constant in Processing, equivalent to the already existing TWO_PI. Minor change, doesn't bother anyone insisting on using TWO_PI, and with added educational value.

For the greater good!

EDIT: This isn't really a question. How do I change that?

Activity Trend