[PD] Best way to deal with many tables.

cyrille henry cyrille.henry at la-kitchen.fr
Sat Feb 21 11:52:08 CET 2009


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 écrit :
> 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 elements each.
> 
> What is the best way to deal with this number of tables? There are the
> usual thoughts of using dynamic patching and such, but really I'd like a
> more elegant solution.
> 
> Has anyone worked on something like a multi-table or nested table?
> 
> I could put everything in one giant table, but each chunk needs to be a
> list in the end and it seems to be iterating over a section of the table
> to dump it as a list would be a lot slower than using [tabdump].
> 
> Just wondering if anyone has any suggestions.
> 
> I've already mentioned my wish to have a generic storage system (similar
> to data-structures but independent of any graphical representation) namely:
> 
> tables of floats (done), tables of symbols, and most importantly tables
> of tables!
> 
> .b.
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 




More information about the Pd-list mailing list