World: r4wp

img1 is a pointer to an array of those bytes, I should have said.

The addition can't result in more than a byte, so it should be no 
problem to do it with bytes

I just can't see how the output I'm seeing is not a bug.  I was hoping 
you could explain it.

But it seems as the compiler thinks that img/r is an integer!

Yes, it looks like a bug

Agreed.

Could it be a problem that I'm type casting im1 to an integer in 
the line

	im: 0

??

Forget it, that can't be the problem.

That's not a cast, just an assignment

I thought maybe the type was cast by the value you assigned to it.

Declared, but not cast, because it wasn't known yet

The problem I'm trying to solve is to convert two seperate images 
to grayscale and then compare the pixels in each image to each other 
to look for big variations in contrast between the pixels.

You did upgrade your Red/System, didn't you?

If I can't assign the answer of a calculation to a word and then 
use that word in other calculations, then it's a roadblock that I'm 
not sure how to overcome.

Yes, I updated Red/System yesterday from Github.

I found many such bugs in the past, so I would like to think they're 
gone, but it looks like you found another :-)

Doc doesn't do many byte manipulations, so it's up to us to test 
them

OK.  Curecode doesn't work for me for some reason, so how do I submit 
this bug?

Red is not in Curecode. The tracker is on GitHub

OK. I'll enter it there.

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

Your immediate problem should be solved if you do

im1: as-byte 0

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.

Excellent !

Your code could be optimised a bit :-)

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.

Yes

I'd love to learn how to optimize my code!

Are you low on memory?

A simple one:

im1:  (as integer! r + g + b) / 3

That won't work

I meant :

im1: (as integer! r) + (as integer! g) + (as integer! b) / 3

2 additions & 1 division against 3 divisions & 2 additions

im1: (as-integer img1/r) + img1/g + img1/b / 3

But yes, that was my general idea

:-)

I now have a working rudimentary motion detection algorithm.  Now 
it's time to tune it with my special formula.

If you're not memory constrained, you can leave the / 3 out completely 
and compare two grayscales as integer values

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).

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

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. :-)

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