[pygame] image.load() -->> array?

[AlgoMantra]

Hi All,

So I'm accessing and modifying pixels of a video capture image stream using
image.load() which type() tells me is a "PixelAccess" object.

I have a 160X120 image in RGB.

Is there a simple way to convert this into an array for applying functions
using Numpy? If the (x,y) coordinates for pixel access remain the same,
that is...

-- 
----.-
1/f   )))  --.
---...
http://www.algomantra.com

Re: [pygame] image.load() -->> array?

[Casey Duncan]

On Oct 25, 2007, at 4:33 AM, AlgoMantra wrote:


Hi All,

So I'm accessing and modifying pixels of a video capture image  
stream using

image.load() which type() tells me is a "PixelAccess" object.

I have a 160X120 image in RGB.

Is there a simple way to convert this into an array for applying  
functions
using Numpy? If the (x,y) coordinates for pixel access remain the  
same,

that is...


See:
http://www.pygame.org/docs/ref/surfarray.html
http://www.pygame.org/docs/tut/surfarray/SurfarrayIntro.html

hth,

-Casey

Re: [pygame] image.load() -->> array?

[AlgoMantra]

> hth,

casey, what do you mean by "hth"? yeah, I found surfarray :)

----.-
1/f   )))  --.
---...
http://www.algomantra.com

On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote:
>
> On Oct 25, 2007, at 4:33 AM, AlgoMantra wrote:
>
> > Hi All,
> >
> > So I'm accessing and modifying pixels of a video capture image
> > stream using
> > image.load() which type() tells me is a "PixelAccess" object.
> >
> > I have a 160X120 image in RGB.
> >
> > Is there a simple way to convert this into an array for applying
> > functions
> > using Numpy? If the (x,y) coordinates for pixel access remain the
> > same,
> > that is...
>
> See:
> http://www.pygame.org/docs/ref/surfarray.html
> http://www.pygame.org/docs/tut/surfarray/SurfarrayIntro.html
>
> hth,
>
> -Casey
>
>
>


--

Re: [pygame] image.load() -->> array?

[Casey Duncan]

On Oct 25, 2007, at 9:27 AM, AlgoMantra wrote:


> hth,

casey, what do you mean by "hth"? yeah, I found surfarray :)


"Hope this helps" 8^)

-Casey

Re: [pygame] image.load() -->> array?

[AlgoMantra]

it helps a lot!

# def ston3d(join=2)
 confirm  hypothesis

 if communication < = people:
global conversation
code += conversation

pygame.ROCKS.get st0ned( )



On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote:
>
> On Oct 25, 2007, at 9:27 AM, AlgoMantra wrote:
>
> > > hth,
> >
> > casey, what do you mean by "hth"? yeah, I found surfarray :)
>
> "Hope this helps" 8^)
>
> -Casey
>



-- 
----.-
1/f   )))  --.
---...
http://www.algomantra.com

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On a not unrelated note, I've been trying to make a 3D map viewer that
loads height values from a black/grey/white image.  I've been making
it a surface, and using surface.get_at() for each pixel.  I think
surfarray should do it better, though I've never used it.

Re: [pygame] image.load() -->> array?

[AlgoMantra]

On 10/25/07, Ian Mallett <[EMAIL PROTECTED]> wrote:
>
> On a not unrelated note, I've been trying to make a 3D map viewer that
> loads height values from a black/grey/white image.  I've been making
> it a surface, and using surface.get_at() for each pixel.  I think
> surfarray should do it better, though I've never used it.
>


Pygame seems quite flexible that way. Perhaps if you could construct the
landscape of the map as a n-dimensional surfarray, you would be able to
avoid creating too many surfaces. Since the final image -the 3D viewer -
may have only two dimensions. It could be any kind of screen or surface.

I don't know that much about what I'm saying, though!















-- 
----.-
1/f   )))  --.
---...
http://www.algomantra.com

Re: [pygame] image.load() -->> array?

[Casey Duncan]

On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote:


On a not unrelated note, I've been trying to make a 3D map viewer that
loads height values from a black/grey/white image.  I've been making
it a surface, and using surface.get_at() for each pixel.  I think
surfarray should do it better, though I've never used it.


surface.get_at() can be kinda slow, and typically sequence item  
access is faster in python then a function call anyway.


Regardless, I wouldn't worry about it unless it helps makes the code  
simpler or profiling shows you that using get_at() is slowing you  
down too much.


-Casey

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote:
> On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote:
> surface.get_at() can be kinda slow, and typically sequence item
> access is faster in python then a function call anyway.
> Regardless, I wouldn't worry about it unless it helps makes the code
> simpler or profiling shows you that using get_at() is slowing you
> down too much.
It's slowing it down some, but the speed is fine.  It's other people
running my program that I'm worried about.  My computer can do 256
squared calls to surface.get_at() in about 30 seconds, but it is
pretty new.
Ian

Re: [pygame] image.load() -->> array?

[Casey Duncan]

On Oct 25, 2007, at 12:11 PM, Ian Mallett wrote:


On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote:

On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote:
surface.get_at() can be kinda slow, and typically sequence item
access is faster in python then a function call anyway.
Regardless, I wouldn't worry about it unless it helps makes the code
simpler or profiling shows you that using get_at() is slowing you
down too much.

It's slowing it down some, but the speed is fine.  It's other people
running my program that I'm worried about.  My computer can do 256
squared calls to surface.get_at() in about 30 seconds, but it is
pretty new.


yeah, it's always a good idea to have an old warhorse machine laying  
around to test on. Either that or a relative that never upgrades ;^)


Even with a fast machine where performance is acceptable, profiling  
can tell you if you are spending a disproportionate amount of time  
doing certain things. And if you have capped the framerate, you can  
experiment with inserting time.sleeps() in there to give away large  
amounts of time per frame to simulate a slower environment. If you  
don't cap the framerate, you can improve how smooth things are on  
your fast machine by refactoring the slow bits. 50-60fps looks a lot  
more polished than 30fps for instance, but it really depends on the  
game and how much things are moving frame to frame.


-Casey

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote:
>
> On Oct 25, 2007, at 12:11 PM, Ian Mallett wrote:
>
> > On 10/25/07, Casey Duncan <[EMAIL PROTECTED]> wrote:
> >> On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote:
> >> surface.get_at() can be kinda slow, and typically sequence item
> >> access is faster in python then a function call anyway.
> >> Regardless, I wouldn't worry about it unless it helps makes the code
> >> simpler or profiling shows you that using get_at() is slowing you
> >> down too much.
> > It's slowing it down some, but the speed is fine.  It's other people
> > running my program that I'm worried about.  My computer can do 256
> > squared calls to surface.get_at() in about 30 seconds, but it is
> > pretty new.
>
> yeah, it's always a good idea to have an old warhorse machine laying
> around to test on. Either that or a relative that never upgrades ;^)
>
> Even with a fast machine where performance is acceptable, profiling
> can tell you if you are spending a disproportionate amount of time
> doing certain things. And if you have capped the framerate, you can
> experiment with inserting time.sleeps() in there to give away large
> amounts of time per frame to simulate a slower environment. If you
> don't cap the framerate, you can improve how smooth things are on
> your fast machine by refactoring the slow bits. 50-60fps looks a lot
> more polished than 30fps for instance, but it really depends on the
> game and how much things are moving frame to frame.
>
> -Casey
>
Yes, more framerates are always better- I've gotten the idea more than once
to obtain some high-performance graphics card and play one of those new
DirectX 10.0 games with the dynamically changing worlds (think blades of
grass moving independently and reacting to everything and being rendered
perfectly), or to play one of my older favorite games at like a billion
fps.

SDL has the limitation that it is really slow.  For some reason, it can
never run more than 60-80 fps while doing nothing.  OpenGL, which is what I
use for 3D stuff, runs at about 900fps doing nothing.  That's smooth.

Ian

Re: [pygame] image.load() -->> array?

[Luke Paireepinart]

Ian Mallett wrote:
On 10/25/07, *Casey Duncan* <[EMAIL PROTECTED] 
> wrote:


On Oct 25, 2007, at 12:11 PM, Ian Mallett wrote:

> On 10/25/07, Casey Duncan <[EMAIL PROTECTED]
> wrote:
>> On Oct 25, 2007, at 9:56 AM, Ian Mallett wrote:
>> surface.get_at() can be kinda slow, and typically sequence item
>> access is faster in python then a function call anyway.
>> Regardless, I wouldn't worry about it unless it helps makes the
code
>> simpler or profiling shows you that using get_at() is slowing you
>> down too much.
> It's slowing it down some, but the speed is fine.  It's other people
> running my program that I'm worried about.  My computer can do 256
> squared calls to surface.get_at() in about 30 seconds, but it is
> pretty new.

yeah, it's always a good idea to have an old warhorse machine laying
around to test on. Either that or a relative that never upgrades ;^)

Even with a fast machine where performance is acceptable, profiling
can tell you if you are spending a disproportionate amount of time
doing certain things. And if you have capped the framerate, you can
experiment with inserting time.sleeps() in there to give away large
amounts of time per frame to simulate a slower environment. If you
don't cap the framerate, you can improve how smooth things are on
your fast machine by refactoring the slow bits. 50-60fps looks a lot
more polished than 30fps for instance, but it really depends on the
game and how much things are moving frame to frame.

-Casey

Yes, more framerates are always better- I've gotten the idea more than 
once to obtain some high-performance graphics card and play one of 
those new DirectX 10.0 games with the dynamically changing worlds 
(think blades of grass moving independently and reacting to everything 
and being rendered perfectly), or to play one of my older favorite 
games at like a billion fps. 

SDL has the limitation that it is really slow.  For some reason, it 
can never run more than 60-80 fps while doing nothing.  OpenGL, which 
is what I use for 3D stuff, runs at about 900fps doing nothing.  
That's smooth.
The inherent flaw in this logic is that, while doing nothing, it really 
doesn't matter which is faster.

Especially since my eyes can only distinguish 30 fps or so.
-Luke

Re: [pygame] image.load() -->> array?

[Ian Mallett]

Of course it's pointless to draw nothing.  The framerates are still
respectable when drawing stuff.  SDL drops to about 40 or 50, OpenGL to
60-120 depending on the render method.

One's eyes "refresh" at about 12 fps, so anything faster than that looks
fluid.  The amount of smoothness, of course, is dependent on the framerate
of the screen.  12fps vs. 40fps is a big difference.  After about 60, most
people can't tell any increase.  I don't care if I can't see it.  It is
still cool to know that your computer is doing that.

Ian

Re: [pygame] image.load() -->> array?

[Patrick Mullen]

I've known people who could detect the difference between 100 and 80
fps, so it's possible.  12 fps may be where we decide that we are
seeing movement rather than a cycle of still images, but that doesn't
mean there is no difference beyond that.  If you draw enough stuff,
your framerate will drop like a rock with sdl, no matter how optomized
your algorithm.  You still have to take into consideration other
programming routines that occur besides just drawing.  I am looking
forward to the gl backend for sdl, that should help level the playing
field.  Although opengl isn't really that difficult to learn.

The main problem is that modern video cards aren't designed for 2d
rendering, so the increase in capability doesn't fit that domain.
Standard resolutions have grown well beyond 320x240, but 2d drawing
routines haven't increased nearly as fast.  And every time the
resolution doubles, the amount of the screen being drawn quadruples.

You could always write a game for gameboy, where the tile engine is
built right in to the hardware :)  Although even then I think you have
to fight the framerate eventually.

On 10/25/07, Ian Mallett <[EMAIL PROTECTED]> wrote:
> Of course it's pointless to draw nothing.  The framerates are still
> respectable when drawing stuff.  SDL drops to about 40 or 50, OpenGL to
> 60-120 depending on the render method.
>
> One's eyes "refresh" at about 12 fps, so anything faster than that looks
> fluid.  The amount of smoothness, of course, is dependent on the framerate
> of the screen.  12fps vs. 40fps is a big difference.  After about 60, most
> people can't tell any increase.  I don't care if I can't see it.  It is
> still cool to know that your computer is doing that.
>
> Ian
>

Re: [pygame] image.load() -->> array?

[Greg Ewing]

Luke Paireepinart wrote:
OpenGL, which 
is what I use for 3D stuff, runs at about 900fps doing nothing.  
That's smooth.


The inherent flaw in this logic is that, while doing nothing, it really 
doesn't matter which is faster.


And even if you were doing something, unless you have
a 900fps monitor to go with that, it doesn't do you
any good at all.

--
Greg

Re: [pygame] image.load() -->> array?

[Greg Ewing]

Ian Mallett wrote:
One's eyes "refresh" at about 12 fps, so anything faster than that 
looks fluid.


It's not quite a simple as that. You need motion blurring
to get something looking completely smooth at such a low
rate. TV and movies have that, but computer games usually
don't.

--
Greg

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:

> And even if you were doing something, unless you have
> a 900fps monitor to go with that, it doesn't do you
> any good at all.

No, because if your framerate is 900fps, but your refresh rate is 60fps,
then every 60th of a second, the most up-to-date frame to that point is
drawn.  At 900fps, then, at max, the frame was rendered 1/900th of a second
ago.  If, however, your frame rate is 60fps, like your refresh rate, the
frame was rendered 1/60th of a second ago.  That's 15 times the delay.  So,
if you're moving an object across the screen at a constant speed, you'll
get, every 60th of a second, with 900fps/60fps refresh time, a frame that
shows, at worst, where the object was 1/900th of a second ago.  With
60fps/60fps refresh time, you'll get, at worst, a frame which shows where
the object was 1/60th of a second ago.  I'd opt for the one which shows more
precisely where the object is.  True, a small difference, but a difference.

With motion blurring, one can do that with OpenGL; it's called
"Fullscreen Antialiasing".  So it is possible.  Of course, because this
lowers the framerate again, I often don't include it with my programs.
Ian

Re: [pygame] image.load() -->> array?

[Brian Fisher]

On 10/26/07, Ian Mallett <[EMAIL PROTECTED]> wrote:
> No, because if your framerate is 900fps, but your refresh rate is 60fps,
> then every 60th of a second, the most up-to-date frame to that point is
> drawn.  At 900fps, then, at max, the frame was rendered 1/900th of a second
> ago.  If, however, your frame rate is 60fps, like your refresh rate, the
> frame was rendered 1/60th of a second ago. That's 15 times the delay.
>
You are correct that there will be a lower latency with a higher fps,
but I think looking at it as "15 times the delay" for a 1/60th sec.
latency gives a distorted perspective of the situation.

Basically you are looking at 16.6ms latency vs. 1.1ms latency. It's
big difference as a percentage, but it's better to evaluate each of
those latency amounts in a meaningful context to understand the
difference between the two then it is to just compute some number. For
instance, 13500fps would be better than 900fps cause 900fps would have
15 times the delay, right? but arguing for 13500fps over 900fps in
order to make a better game would be a pretty ridiculous argument

I think a good context tends to be reaction time - in other words
comparing  how much delay the system introduces, compared to how much
latency people take in order to react to what they see. Well trained
athlete response times can get down to like 200ms (for more info check
wikipedia: http://en.wikipedia.org/wiki/Reaction_time )

So considering the game will already need to be designed to
accommodate about 200ms reaction time from seeing something to player
action no matter what your frame rate is, how much worse is it to set
up your game to accommodate 216.6ms of reaction time?  Or to put it
another way, if a 900fps player will take 201.1ms to stop their car
from flipping, or aim and shoot the head of the other player, or dodge
the bullet of the enemy, how much worse will their experience be when
at 60fps when they take 216.6ms to do the same action?

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On 10/26/07, Brian Fisher <[EMAIL PROTECTED]> wrote:

> Basically you are looking at 16.6ms latency vs. 1.1ms latency. It's
> big difference as a percentage, but it's better to evaluate each of
> those latency amounts in a meaningful context to understand the
> difference between the two then it is to just compute some number. For
> instance, 13500fps would be better than 900fps cause 900fps would have
> 15 times the delay, right? but arguing for 13500fps over 900fps in
> order to make a better game would be a pretty ridiculous argument

Yes.  I'm just saying there is a slight (though meaningless) advantage to
having really high framerates.

Re: [pygame] image.load() -->> array?

[Greg Ewing]

Ian Mallett wrote:
At 900fps, then, at max, the frame was rendered 1/900th 
of a second ago.  If, however, your frame rate is 60fps, like your 
refresh rate, the frame was rendered 1/60th of a second ago.


I doubt that human reaction times are anywhere near good
enough to notice a 1/60 second difference in timing.

But either way, 1/59 of a second after rendering the
last frame, the image is going to be nearly a whole
frame out of date. If you're relying on millisecond
precision for your shooting, you're already in trouble.

With motion blurring, one can do that with OpenGL; it's called 
"Fullscreen Antialiasing".


That's not the same thing -- FSAA smooths adjacent pixels
in a single frame, whereas motion blurring is about
smoothing between successive frames.

That's one way you could make use of your 900fps, though --
render several frames and blur them together.

That's assuming you wouldn't rather just use the power
to render a boatload more polygons instead, or some other
fancy effect.

--
Greg

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On 10/26/07, Ian Mallett <[EMAIL PROTECTED]> wrote:

> Yes.  I'm just saying there is a slight (though meaningless) advantage to
> having really high framerates.
>
slight meaningless advantage.

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> That's not the same thing -- FSAA smooths adjacent pixels
> in a single frame, whereas motion blurring is about
> smoothing between successive frames.

It's a blur.  I don't distinguish between blurs.  You're probably right
about the name of that sort of blur.  Wow!  I love to say the word "blur"!
Blur!  Blur!  Blur!  (I'm like this at 11:40)

> That's one way you could make use of your 900fps, though --
> render several frames and blur them together.

Sounds good...

> That's assuming you wouldn't rather just use the power
> to render a boatload more polygons instead, or some other
> fancy effect.

I think time would be better spent there.

> Greg
>
Ian

Re: [pygame] image.load() -->> array?

[Greg Ewing]

Ian Mallett wrote:
I'm just saying there is a slight (though meaningless) advantage 
to having really high framerates.


Well, it can sometimes be useful as a relative measure
of rendering speed -- if you know that e.g. a particular
game runs at 50fps on some system, and the same game
runs (or can be made to run) at 200fps on another
system, then the second system must have about 4 times
the rendering power.

But a better way to *use* that power would be to keep
the same frame rate (which was already plenty high
enough) and render a more complex scene, add nice-
looking effects, etc.

Also, to get a meaningful result, you need to be doing
something useful during those frames -- the fact that
you can do nothing 900 times a second doesn't tell you
much.

--
Greg

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Ian Mallett wrote:
> > I'm just saying there is a slight (though meaningless) advantage
> > to having really high framerates.
>
> Well, it can sometimes be useful as a relative measure
> of rendering speed -- if you know that e.g. a particular
> game runs at 50fps on some system, and the same game
> runs (or can be made to run) at 200fps on another
> system, then the second system must have about 4 times
> the rendering power.
>
> But a better way to *use* that power would be to keep
> the same frame rate (which was already plenty high
> enough) and render a more complex scene, add nice-
> looking effects, etc.
>
> Also, to get a meaningful result, you need to be doing
> something useful during those frames -- the fact that
> you can do nothing 900 times a second doesn't tell you
> much.
>
> --
> Greg
>
Yep.

Re: [pygame] image.load() -->> array?

[Michael George]

Just to be pedantic: FSAA is different from motion blur.  FSAA renders 
each frame at a high resolution and then scales it down, which can help 
remove jaggy pixellated edges.  Motion blur renders the scene at a few 
different points in time and averages them together, which makes the 
framerate appear to be higher.


--Mike

Ian Mallett wrote:
On 10/26/07, *Greg Ewing* <[EMAIL PROTECTED] 
> wrote:


And even if you were doing something, unless you have
a 900fps monitor to go with that, it doesn't do you
any good at all.

No, because if your framerate is 900fps, but your refresh rate is 
60fps, then every 60th of a second, the most up-to-date frame to that 
point is drawn.  At 900fps, then, at max, the frame was rendered 
1/900th of a second ago.  If, however, your frame rate is 60fps, like 
your refresh rate, the frame was rendered 1/60th of a second ago.  
That's 15 times the delay.  So, if you're moving an object across the 
screen at a constant speed, you'll get, every 60th of a second, with 
900fps/60fps refresh time, a frame that shows, at worst, where the 
object was 1/900th of a second ago.  With 60fps/60fps refresh time, 
you'll get, at worst, a frame which shows where the object was 1/60th 
of a second ago.  I'd opt for the one which shows more precisely where 
the object is.  True, a small difference, but a difference. 
With motion blurring, one can do that with OpenGL; it's called 
"Fullscreen Antialiasing".  So it is possible.  Of course, because 
this lowers the framerate again, I often don't include it with my 
programs.

Ian
 

Re: [pygame] image.load() -->> array?

[Ian Mallett]

On 10/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> That's not the same thing -- FSAA smooths adjacent pixels
> in a single frame, whereas motion blurring is about
> smoothing between successive frames.

Re: [pygame] image.load() -->> array?

[Rikard Bosnjakovic]

On 25/10/2007, AlgoMantra <[EMAIL PROTECTED]> wrote:

> casey, what do you mean by "hth"? yeah, I found surfarray :)

http://catb.org/~esr/jargon/html/H/HTH.html


-- 
- Rikard - http://bos.hack.org/cv/