World: r4wp
[#Red] Red language group
older newer | first last |
Bo 27-Jun-2013 [8912] | OK. I'll enter it there. |
PeterWood 27-Jun-2013 [8913x3] | The calculation is okay. Code: Red/System [] red: as byte! 240 green: as byte! 120 blue: as byte! 60 greyscale: ((as integer! red) / 3) + (as integer! green) + (as integer! blue) print [greyscale lf] OUTPUT: -= Red/System Compiler =- Compiling /Users/peter/VMShare/Code/Red-System/test.reds ... Script: "Red/System IA-32 code emitter" (none) Script: "Red/System Mach-O format emitter" (none) ...compilation time: 122 ms ...linking time: 10 ms ...output file size: 16384 bytes ...output file name: builds/test 260 |
It may be an issue with the dereferencing. Could you try by assigning img1/r etc to temporary variables. | |
Oops, here's the proper code and correct answer: Red/System [] red: as byte! 240 green: as byte! 120 blue: as byte! 60 greyscale: ((as integer! red) / 3) + ((as integer! green) / 3) + ((as integer! blue) / 3) print [greyscale lf] OUTPUT ...compilation time: 133 ms ...linking time: 13 ms ...output file size: 16384 bytes ...output file name: builds/test 140 | |
Kaj 27-Jun-2013 [8916x2] | Your immediate problem should be solved if you do |
im1: as-byte 0 | |
Bo 27-Jun-2013 [8918x3] | Well, that seems to have worked around the problem! Thanks guys! |
Now I can work on making some real progress! :-) | |
I'm amazed by how fast Red/System is. | |
PeterWood 27-Jun-2013 [8921] | Excellent ! |
Kaj 27-Jun-2013 [8922] | Your code could be optimised a bit :-) |
james_nak 27-Jun-2013 [8923] | Kaj, I think there was something to the jarsigner being commented out in the file. I'll have to wait for Doc and Pekr to chime in. |
Kaj 27-Jun-2013 [8924] | Yes |
Bo 27-Jun-2013 [8925] | I'd love to learn how to optimize my code! |
Kaj 27-Jun-2013 [8926] | Are you low on memory? |
PeterWood 27-Jun-2013 [8927] | A simple one: im1: (as integer! r + g + b) / 3 |
Kaj 27-Jun-2013 [8928] | That won't work |
PeterWood 27-Jun-2013 [8929x2] | I meant : im1: (as integer! r) + (as integer! g) + (as integer! b) / 3 |
2 additions & 1 division against 3 divisions & 2 additions | |
Kaj 27-Jun-2013 [8931x2] | im1: (as-integer img1/r) + img1/g + img1/b / 3 |
But yes, that was my general idea | |
PeterWood 27-Jun-2013 [8933] | :-) |
Bo 27-Jun-2013 [8934] | I now have a working rudimentary motion detection algorithm. Now it's time to tune it with my special formula. |
Kaj 27-Jun-2013 [8935] | If you're not memory constrained, you can leave the / 3 out completely and compare two grayscales as integer values |
PeterWood 27-Jun-2013 [8936x3] | Im1 is already an integer in Bo's code. |
if you're desparate for a few millisecs, reversing the loop to start at the end and work toward the front will help. | |
(Subtraction being marginally faster then addiiton). | |
Kaj 27-Jun-2013 [8939] | That could be cast to byte again, to save the grayscale, but yes, there's no need to divide by 3 if it's just for the comparison |
Bo 27-Jun-2013 [8940] | I'm passing the processed image back out to Rebol to convert back into an image for visual verification of the motion detection algorithm. That part works fine. :-) |
Kaj 27-Jun-2013 [8941x3] | Subtraction faster than addition? That would surprise me. It's comparison to 0 that may be faster |
Further, the bumping of r, g and b each iteration is relatively much work, because you're also having to use them as indexes. It's more efficient to make a byte pointer for each and advance those | |
But it's probably even faster to iterate through the image with one integer pointer, because the pixels happen to be four bytes, and then use indexes of 2, 3 and 4 for r, g and b | |
Bo 27-Jun-2013 [8944] | So are you saying that if 'img1 is a pointer, to do the following? img1r: img1 + 2 img1g: img1 + 3 img1b: img1 + 4 and then img1r: img1r + 4 img1g: img1g + 4 img1b: img1b + 4 would be faster than what I'm doing now? |
PeterWood 27-Jun-2013 [8945] | You're correct. I checked and the optimisation benefit through "loop inversion" apparently comes from reducing the number of jumps in the underlying code not difference in speed in atrithmetic. |
Bo 27-Jun-2013 [8946] | OK, so this would be even faster: r: 2 g: 3 b: 4 until [ ...do stuff here... img1: img1 + 4 ...comparison... ] |
Kaj 27-Jun-2013 [8947] | Bo, yes, that would be more efficient, because you can then index with 1 |
Maxim 27-Jun-2013 [8948] | Bo, that's basically how it'd be done in C |
PeterWood 27-Jun-2013 [8949] | Kaj do you know if Red/System generates the same code for : img1/value and img!/1 ? |
Kaj 27-Jun-2013 [8950] | Yes, it's equivalent |
Bo 27-Jun-2013 [8951x2] | Thanks for the tips, guys! |
There is no way for Red/System to read a directory listing, is there? | |
Kaj 27-Jun-2013 [8953x2] | Perhaps fastest: pixel: as int-ptr! img1 + 1 ... rgb: as-binary pixel im1: (as-integer rgb/1) + rgb/2 + rgb/3 / 3 pixel: pixel + 1 |
That code would have to be tested, depends on lots of details | |
Bo 27-Jun-2013 [8955] | I'm only looping 20'000 times or so...not a lot for Red/System to handle. ;-) |
Kaj 27-Jun-2013 [8956] | But it's going to run on a Raspberry in realtime |
Bo 27-Jun-2013 [8957x2] | I was joking. :-) |
Can Red/System read a directory listing? | |
Kaj 27-Jun-2013 [8959x3] | It should, but you have to interpret the data manually |
I haven't looked into it yet | |
I see you'd need some extra definitions that aren't in my C library binding yet | |
older newer | first last |