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@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list