headers
Stuart Axon | 1 Jun 2010 01:22
Picon
Favicon

Re: opencv and TUIO libraries

Hi

Replying to quite an old email but... can you still supply an amd64 build for this ?

 S++

----- Original Message ----
> From: francesco fantoni <francesco@...>
> To: shoebot-devel@...
> Sent: Sat, January 17, 2009 11:38:31 AM
> Subject: [shoebot-devel] opencv and TUIO libraries
> 
> I've uploaded the sb-ported nodebox's TUIO library and the new version
of my 
> shoebot opencv library that I've renamed to sbopencv for two
reasons:
- 
> now it's more than a simple video input library, it could becoming 
> a
potentially full featured computer vision library based on opencv
- new 
> version has introduced the use of cvBlobslib for blob detection.
this part of 
> opencv usually is not part of main opencv distribution, and
comes with its 
> own python bindings. This means that a binary library is
included in 
> sbopencv, compiled for linux 386. I can provide a linux
amd64 binary shared 
> library as well, but for other systems you should
(Continue reading)

Permalink | Reply | 0 comments |
headers
francesco fantoni | 1 Jun 2010 09:04
Favicon

Re: scipy.ndimage filters

Yes, I had actually a branch with transform matrix handled by numpy, but
it didn't look too promising: it was slower than the cairo one we had at
that time, though I must admit I am not probably very clever with numpy,
and maybe there was some wiser trick I didn't think of :)

francesco

Il giorno lun, 31/05/2010 alle 23.18 +0100, ricardo lafuente ha scritto:

> I was thinking that maybe numpy could be interesting for matrix 
> manipulation, instead of handing it to Cairo. OTOH, i think that 
> Francesco tried this and that it actually became slower...
Permalink | Reply | 0 comments |
headers
Stuart Axon | 1 Jun 2010 18:55
Picon
Favicon

Re: scipy.ndimage filters

I think numpy might be better when you want to transform a whole load of matrices in one go.

On Tue Jun 1st, 2010 8:04 AM BST francesco fantoni wrote:

>Yes, I had actually a branch with transform matrix handled by numpy, but
>it didn't look too promising: it was slower than the cairo one we had at
>that time, though I must admit I am not probably very clever with numpy,
>and maybe there was some wiser trick I didn't think of :)
>
>francesco
>
>
>Il giorno lun, 31/05/2010 alle 23.18 +0100, ricardo lafuente ha scritto:
>
>> I was thinking that maybe numpy could be interesting for matrix 
>> manipulation, instead of handing it to Cairo. OTOH, i think that 
>> Francesco tried this and that it actually became slower...
>
>
>_______________________________________________
>Shoebot-devel mailing list
>Shoebot-devel@...
>http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
Permalink | Reply | 0 comments |
headers
Stuart Axon | 1 Jun 2010 22:22
Picon
Favicon

Getting folder of current bot...

A lot of examples have hardcoded paths in them, I'm looking to avoid this...

I've got __file__ working in my branch, so you can do

os.path.dirname(__file__) + 'someresource.svg'

Any objections to me adding
__dirname__  with the current folder ?

This would make the code simpler + it is consistant with __file__ being a builtin.

 S++
Permalink | Reply | 3 comments |
headers
Stuart Axon | 1 Jun 2010 22:25
Picon
Favicon

Re: Getting folder of current bot...

Having said that, maybe we should have an api equivilent to getResource in java maybe?

 S++

----- Original Message ----
> From: Stuart Axon <stuaxo2@...>
> To: shoebox mailing list <shoebot-devel@...>
> Sent: Tue, June 1, 2010 9:22:06 PM
> Subject: Getting folder of current bot...
> 
> A lot of examples have hardcoded paths in them, I'm looking to avoid 
> this...

I've got __file__ working in my branch, so you can 
> do

os.path.dirname(__file__) + 'someresource.svg'

Any 
> objections to me adding
__dirname__  with the current folder 
> ?

This would make the code simpler + it is consistant with __file__ being 
> a builtin.

S++
Permalink | Reply | 0 comments |
headers
ricardo lafuente | 2 Jun 2010 22:12

Re: Getting folder of current bot...

Sounds fine -- we'll just have to document it along with the other 
additions to Nodebox.

On 06/01/2010 09:22 PM, Stuart Axon wrote:
> A lot of examples have hardcoded paths in them, I'm looking to avoid this...
>
> I've got __file__ working in my branch, so you can do
>
> os.path.dirname(__file__) + 'someresource.svg'
>
>
> Any objections to me adding
> __dirname__  with the current folder ?
>
> This would make the code simpler + it is consistant with __file__ being a builtin.
>
>   S++
>
>
>
>
> _______________________________________________
> Shoebot-devel mailing list
> Shoebot-devel@...
> http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net
>
Permalink | Reply | 0 comments |
headers
ricardo lafuente | 2 Jun 2010 22:15

Re: Extending shoebot api to use neglected bits of cairo :)

On 05/31/2010 11:23 PM, Stuart Axon wrote:
> So I don't forget:
>
> Cairo has some stuff we should put in...  it supports filling with images, mirrored or not.
>
> I was thinking we could extend background() to work with images (with option to mirror).

I'm thinking of the "preferably one way to do one thing" principle in 
Python. How would this be an improvement from using image() passing the 
size of the canvas?

> Also there are gradient fills, and radial gradients.. we should definitely open up these too.

Agree. I'm wondering how the syntax for defining them should be. 
Probably worth discussing on IRC soon?
Permalink | Reply | 5 comments |
headers
Dave Crossland | 2 Jun 2010 22:52
Gravatar

Re: Extending shoebot api to use neglected bits of cairo :)

On 2 June 2010 22:15, ricardo lafuente <r <at> sollec.org> wrote:
>
>> it supports filling with images, mirrored or not.
>
> I'm thinking of the "preferably one way to do one thing" principle in
> Python. How would this be an improvement from using image() passing the size
> of the canvas?

Is "filling with images" how image() works?

--

-- 
Regards,
Dave
Permalink | Reply | 4 comments |
headers
Stuart Axon | 3 Jun 2010 01:13
Picon
Favicon

Re: Extending shoebot api to use neglected bits of cairo :)

It would mean that we wouldn't need to draw once with a single colour and
then over draw that with images.

+ With the fill modes available to cairo the semantics are a bit different -
they can repeat or be mirrored or not repeat.

Image() is more - draw a single image - not "fill with images".
+ If the underlying library supports it, it's possibly faster than us 
manually filling the background with a load of tiling images
(+ implementing the mirroring would be some work even
in shoebot).

Maybe I should try coming up with a syntax and we can see if it makes
any sense :)

 S++

----- Original Message ----
> From: Dave Crossland <dave@...>
> To: shoebot-devel@...
> Sent: Wed, June 2, 2010 9:52:19 PM
> Subject: Re: [shoebot-devel] Extending shoebot api to use neglected bits of cairo :)
> 
> On 2 June 2010 22:15, ricardo lafuente <
> href="mailto:r <at> sollec.org">r <at> sollec.org> wrote:
>
>> it 
> supports filling with images, mirrored or not.
>
> I'm thinking of
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Crossland | 3 Jun 2010 01:49
Gravatar

Re: Extending shoebot api to use neglected bits of cairo :)

On 3 June 2010 01:13, Stuart Axon <stuaxo2@...> wrote:
>
> > Is "filling with images" how image() works?

It sounds like image() should be refactored to use Cairo's "filling
with images" function :)
Permalink | Reply | 1 comment |

Gmane