a few questions and ideas

[Jesse Vander Does]

Hi Guys,

It looks like you have a great project here.

What do you think about using Pypes to build a node based Compositor like the Foundry's Nuke?  Is there any reason that Pypes wouldn't work well with other python libraries like PIL?  I'm a little unclear about how one would extend the GUI - how to experiment with Pypes without the GUI - or how one would go about swapping it with another.

Would it be possible to design Pypes so that a user could reveal and edit a node's python code while the graph is running?  This would be a very powerful way to debug a program as well as a great way to teach programming.

Regards,

Jesse

[Eric Gaumer]

Jesse,

Thanks for your interest in pypes. We've gotten similar questions regarding image processing. To be honest I don't know much about Nuke (I had to go look it up to see what it was). As a sort of proof-of-concept, I started a project called pypes-imaging which contains some basic components for imaging processing in pypes:

• Image Cropping
• Image Rotating
• Image Flipping
• Image Mirroring
• Image Grey Scaling
• Generating Thumbnails

The project is hosted on bitbucket: http://bitbucket.org/diji/pypes-imaging/wiki/Home

I'm using PIL to drive these components and again, I don't know much about image processing. I just scanned through the documentation for PIL and put these together as an example.

The cool thing is that I didn't have to change pypes in any way. I'm just using the component API to pass around binary data as opposed to pure text. The data objects in pypes are key/value (generally speaking) so I simply have a key called "image_data" that contains a binary string. Then I used the meta-data API to store things like image size, type, etc. This way downstream image components can access this information.

What's even cooler is that you can mix and match image components with ones that generally work on text. For instance, I can take an image that has been geo-tagged, extract the coordinates, and index then into a search engine. At the same time I can generate and index a thumbnail version of the image for displaying in my search results.

Pypes is really nothing more than a workflow engine. You can write components that do virtually anything from image processing to video rendering to natural language processing.

The core engine is separate from the UI but that aspect is undocumented. There is a small example on the Python concurrency wiki that shows pypes being used without the UI:

http://wiki.python.org/moin/Concurrency/99Bottles

There is also some examples under the core module:

http://bitbucket.org/diji/pypes/src/tip/core/examples/

This allows folks to leverage the workflow engine without having to use the UI. Our original goal was to design something to handle Enterprise Information Integration but as we introduced pypes to different folks, we realized it could address a broad spectrum of needs.

In terms of the UI, it's 100% REST. When you drag a new component onto the canvas, the UI makes an HTTP POST to the server. A PUT is used to update configurations of components, POST is used to save projects, GET is used to load projects, etc.

The only missing piece is the wiring. Currently there is no REST API in place but we've been talking about this lately. The idea would be to have an API to connect nodes. Now this can already be done if your writing python code (see the examples I mentioned above) but there is currently no way to connect nodes via some REST call.

Providing this ability would mean that users could (relatively easily) build a pipeline with a bunch of HTTP calls. They wouldn't even need to know any Python. I suppose this same API could be used to build different web interfaces. If you're thinking about GTK or QT interfaces then I would just leverage the Python APIs.

With all that said, pypes was designed for high throughput. That is, hundreds of millions of documents or high volumes of low latency tasks. In areas such as video rendering you get low volume and high latency (rendering operations can take long periods of time). That's not to say pypes won't do this but it's not where it shines. It provides extremely fast context switching (via Stackless Python) for chaining series of small operations together in an efficient manner.

It also achieves parallelism by load balancing across CPUs/cores (scale up) and nodes (scale out). With low volume input and high latency operations, you would scale differently. The goal there would be to parallelize operations in the same pipeline rather than parallelizing the pipeline itself.

In other words, in order to achieve an efficient solution, pypes will process documents across each CPU or core. Something like video rendering would be better suited for spreading the individual pipeline tasks across CPUs. I'm not sure where image processing falls. Most operations will be longer than working with text but I don't think they would take hours to complete like video rendering.

Clone the pypes-imaging repository and give those components a try. They should (at the very least) give you some direction and or ideas.

Regards,

-Eric