Link Copied
Hi Goran,
Thanks for your feedback.
I experiment various crashes after deleting nodes and/or graphes, in release and/or debug. In example 0 and example 3, it crashes in debug. Hope it will be fixed soon :)
Regards
Olivier
Hi Vladimir,
Thanks for your answers. I'll be very happy with the next release, because all my tests do crash at some point, often very early. Do you have a release schedule ?
We're investigating different technologies regarding image processing, for a general purpose image compositing middleware. DMIP seems very interesting and promising.
Here are some general thoughts and questionsabout DMIP :
* As the source code of DMIP is not available, it seems impossible to build a node that would have 3 or 4 source images. The 2 sources limit isby design ? There are some cases where I would like to have three inputs: two images and a store, or more images.
* The store mechanism is very elegant, does DMIP provide nodes that operates only on stores (ie storeResult = f(store1,store2) ?How do I build a store containing serveral Dynamic stores (computed from the graph),as a node an only have a single input store ?
* As far as I understood, it is impossible now to change the size of an image in a node (ie a 'resize' node) within a graph. I must split my graph, and call in betweenlow level IPP functions (ie ippiResize_
* I'd like to know how DMIP behaves when dealing with geometric transforms (ie an example source code of an efficient'rotate' node would be very interesting). How DMIP will split the source image to be efficient in term of cache ?
* Many of my nodes will use accumulation buffers: a source pixel will be "spread" on many destination pixels using various geometric techniques. Later, the accumulation buffer is normalized. How can DMIP handle such cases ? This is a tricky parallel problem, as two threads processing distinct source pixel tiles can be accumulated in the same destination pixels. Or accumulation buffers can be distinct (in stores ?), and be merged later (involving a lot of nodes , because of the 2 sources limit)
* I'd like to know how DMIP behaves when fed with large graphes (involving a large number of nodes (more than 1000) on megapixel images): does it includes a memory manager ? Is there a way to get control on the graph traversing order ? As some of our nodes will allocate some memory, can I control when the Node::Free() method is called ?
* Given a graph, does DMIP keeps track of already computed nodes ? For example, you can imagine a graph whereonly onesource image change (ie retrieved from a stream). Only a small part of the graph needs to be computed again. Do I have to manage "dirty flags" myself (ie compute and give to DMIP the small graph that has to be recomputed), or does DMIP handle "dirty flags" ?
* In a more general way, I feel that the DMIP source code should be available somehow, in a whole or at least part of it (nodes). It would greatly help 3rdparty node writers. Also, as we'd like to implement some graph traversingorder to adress memory issues in large graphes, the graph optimization or execution should be accesible (actually, the Graph::Execute() or Graph::Optimise() methods are not virtual).
Best regards
Olivier
For more complete information about compiler optimizations, see our Optimization Notice.