Re: [PD] Best way to deal with many tables.

2009-02-22 Thread cyrille henry
marius schebella a écrit : > cyrille henry wrote: >> the best 2D table are probably images. >> if the 8bits limitation is not a problem, you can store your arrays in >> 1 (or more) big image (1000x768). > > hi, > just curios, are you using [pix_set] for that or sig2pix? or an external > progra

Re: [PD] Best way to deal with many tables.

2009-02-22 Thread marius schebella
cyrille henry wrote: > the best 2D table are probably images. > if the 8bits limitation is not a problem, you can store your arrays in 1 (or > more) big image (1000x768). hi, just curios, are you using [pix_set] for that or sig2pix? or an external program. because with pix set the range is bet 0

Re: [PD] Best way to deal with many tables.

2009-02-22 Thread David Doukhan
2009/2/21 B. Bogart : > Thanks all for your comments. > David, How fast was your python code to generate the tables? Seems like > it would be about the same issues as dynamic patching. The python code does not generate the tables: it generates a patch. IE: suppose you wrote a patch that load a pie

Re: [PD] Best way to deal with many tables.

2009-02-21 Thread Jonathan Wilkes
--- On Sat, 2/21/09, B. Bogart wrote: > From: B. Bogart > Subject: [PD] Best way to deal with many tables. > To: "PD list" > Date: Saturday, February 21, 2009, 5:59 AM > Hey all. > > I've managed to get my patches to use less objects, and > more messa

Re: [PD] Best way to deal with many tables.

2009-02-21 Thread Mathieu Bouchard
On Fri, 20 Feb 2009, B. Bogart wrote: Basically the system I'm working on needs to store the RGB hists of many images (10,000 ideally, RAM permitting). RGB hists are concatenated into tables of 768 elements each. [#store (1 256 3 #)] for int32 elements [#store (1 256 3 s #)] for int1

Re: [PD] Best way to deal with many tables.

2009-02-21 Thread cyrille henry
B. Bogart a écrit : > Thanks all for your comments. ... > > Cyrille, This is an interesting idea, pix_histo outputs tables though. I > don't know what you mean by 2D tables, what i call a 2D table is just a 2D matrix... > they should be 3D for each colour > channel right?? why 3D? density = fu

Re: [PD] Best way to deal with many tables.

2009-02-21 Thread B. Bogart
Thanks all for your comments. Roman, The major "inelegance" of dynamic patching is the massive CPU of generating the graph containing 1000s of objects. In theory one only needs to do this once, but I'm always changing the patch and also the number of tables. Dynamic patching seems to work great in

Re: [PD] Best way to deal with many tables.

2009-02-21 Thread David Doukhan
what I did in such situation was to generate pd patch using a python script. Using that method, all the arrays were stored in memory, and could be accessed dynamically by the other components through their names. 2009/2/21 B. Bogart : > Hey all. > > I've managed to get my patches to use less obje

Re: [PD] Best way to deal with many tables.

2009-02-21 Thread cyrille henry
hello, your RGB hists are 1D table. so what you need is 2D table. the best 2D table are probably images. if the 8bits limitation is not a problem, you can store your arrays in 1 (or more) big image (1000x768). pix_crop + pix_pix2sig to get a row of your image in a table. Cyrille B. Bogart a éc

Re: [PD] Best way to deal with many tables.

2009-02-21 Thread Roman Haefeli
On Fri, 2009-02-20 at 20:59 -0800, B. Bogart wrote: > Hey all. > > I've managed to get my patches to use less objects, and more messages. > > Problem I have now is storing data in an organized way. > > Basically the system I'm working on needs to store the RGB hists of many > images (10,000 idea

[PD] Best way to deal with many tables.

2009-02-20 Thread B. Bogart
Hey all. I've managed to get my patches to use less objects, and more messages. Problem I have now is storing data in an organized way. Basically the system I'm working on needs to store the RGB hists of many images (10,000 ideally, RAM permitting). RGB hists are concatenated into tables of 768