[PD] sending image from of / libpd

[Dan Wilcox]

For gray values this should work.

On Aug 30, 2011, at 6:56 AM, ronni montoya wrote:

> i solved this creating  a fuction called send inside AppCore:
> 
> void AppCore::send(unsigned char *pixels) {
> 
> 	for(int i = 0; i < array1.size(); i++)
>        array1[i] = pixels[i]* 1;
> 
> 	pd.writeArray("array1", array1);
> }

Here I would send a resize message to the array if the array length is different from you image size. Also, I'm assuming you set the correct size for the array1 vector to be the size of the image pixel buffer aka width*height ...

void AppCore::send(unsigned char *pixels) {

	// check array length
	if(array1.size() != pd.getArrayLen("array1") {
		//
		// send resize message to array1
		//
		// aka [ ; array1 resize # <
		//
		pd. << StartMsg("array1") << "resize" << pixelLen << Finish();
	}

	for(int i = 0;  i < array1.size();  i++)
        	array1[i] = pixels[i];

	pd.writeArray("array1", array1);
}

> then im calling the function from testApp.cpp and sending the pixels
> from a opecv gray image.
> 
> 
> void testApp::draw() {
> core.send(grayImage.getPixels());
> 
> }

I'd send the image to pd in the core.update() function. The whole point of the AppCore wrapper classes is to be able to write the same core app code for both desktop and iOS, since iOS requires a Obj-C file for the main Application delegate aka example/src/ios/testApp.m.

> What do you guys think, maybe theres a more effective way?

Dunno. Try it out and let us know. I'm pretty sure it may be slow to send a largish image > 640x480, so I'd start out at 120x240 or so. I've streamed realtime color video at that size using binary blobs in OSC without a problem, so I can't imagine small images being too slow ... then again I haven't tried it with libpd.

> 
> cheers
> 
> 
> R.
> 
> 
> 
> 2011/8/30 IOhannes m zmoelnig <zmoelnig at iem.at>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> On 2011-08-29 20:51, Peter Brinkmann wrote:
>>> 
>>> 
>>> Maybe we can have a poll and come up with a better estimate.  Here are a few
>>> questions:
>>> 
>>> 1. What sort of use case for long list messages to you have in mind?
>>> 2. Exactly how long would you need the list to be?
>>> 3. Is this really a use case for list messages or would it make more sense
>>> to write to an array instead?
>>> 
>>> If we converge to a reasonable number, that'll be the new limit.  Otherwise,
>>> the entire approach may have to go.
>>> 
>> 
>> personally i do think that any fixed limit is going to impose troubles.
>> 
>> afaict, the main idea here is to provide an easy to use API, combined
>> with some performance.
>> 
>> somebody _will_ reach your hard limit, and i think that telling them to
>> either switch from the "foolproof API" to "export mode" or to redesign
>> their patches just because they called "add_element()" once too often
>> will not do.
>> 
>> why not simply resize the internal array as needed, starting with 32
>> elements and doubling whenever the limit is reached?
>> 
>> fgasdr
>> IOhannes
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> 
>> iEYEARECAAYFAk5ckYcACgkQkX2Xpv6ydvQ85gCfWJcNIzEGnhz9hdnz/XBuRYuI
>> TMEAnjfytStl5sFDqkJ9HppZ9XQylgni
>> =HvJ0
>> -----END PGP SIGNATURE-----
>> 
>> 
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>> 
>> 
> 
> 

--------
Dan Wilcox
danomatika.com
robotcowboy.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110830/ebcfeb2f/attachment-0001.htm>