DMIP:processing bugs

[renegr]

1. As soon as I use DMIP to process streams instead of single images, bad frames are created. This behavior seem to depend on how much action is done in UI. The faster I move windows the more bad frames are created - very strange. Note - only the bottom part of the image gets lost!
2. If the image height is not a multiple of the slice height given as parameter to the Compile function, the image isn't completely decoded.
3. According to point 2, if an image with an uncommon height is given as input (e.g. height=687) and automatic slice height is choosen, a slice is a complete image.
4. For some nodes the size of the temporary buffer(s) depends on the height of the slice. While "Alloc" is called, this size isn't known and therefore Alloc can't be used to allocate buffers anymore.
5. A graph SrcNode(Image1(data1, Ipp8u, roi, step))->DstNode(Image2(data2, Ipp8u, roi, step2)) destroys the source image data (roi, # of channels and image type are the same, only the step width differs)

[Igor_B_Intel1]

Hi,

1 and 2 It seems you have got something unsyncronized in your UI or some operations (or UI) not fit into RT. Maybe needto separate UI message handler and data processing thread.

3. There isn't any dependancy between"uncommon height" and slice height. Slice can be compilte image in case sufficient L2 cache size on your u-arch.

4. It is chicken and egg. To estimate slice size need to esimate free space into cache. So first of all estimated temporarybuffers size for nodes and in that point slice size doesn't calculated yet. Yes there is some over-allocation of the memory but temporary buffer size mostly much more less than whole image.

5. Could you please provide such test case for me?

Igor.

[renegr]

1, 2, 5 : I found a bug with an overlapping buffer which triggered all these problems - sorry for inconvenience

3: Ok, I forgot that I have 4MB of L2 cache

4: I need a temporary buffer of the same size as the source pointer. I know that this leads to nonlinear dependencies and that Alloc therefore has to be called more than once. Maybe another function "int GetBufferSize(int sliceHeight)" would help to reduce memory de-/allocation while compiling.

Some other questions:

Do you know when the next version with resizing functionality will be available?

What does FilterNode::PrepareBoder do? It takes a pointer to the source image. But this is the Dst pointer of the SrcNode. Problem here is that the real image data of the previous slice and the next slice is not known anymore and therefore only the slice internal data can be used to create a border. I can't imagine that this is the intention.

[Igor_B_Intel1]

Thank you for good news about solved problem.

1. Temporary buffer. I don't clerly understand. It is your custom node? What size of buffer you need: size ofimage or size of slice?

2. FilterNode::PrepareBorder. Filter ops introduce some fixed delay (in terms of image lines and the length is kernel size) in pipelins. So before first invokation of FilterNode::Do at least two slices processed through previouse operations in the pipeline. In that case slice with all surraunding data is avialable to filtration.

Igor

[renegr]

First thank you for the fast answer!

1. the image size is known because it is given within paramCompile.srcRoi. I need the size of slice because images can be up to 30 MBytes, slices at max 1 MByte. But sliceHeight is given only in paramExecute.sliceHeight, which is not initialized while compiling.

2. Ok, that's a nice idea. So I think it is enough to overwrite isFilter() method to get this fixed delay within the pipeline.

Unfortunately I have a very custom filter node, which doesn't need a kernel as is and also doesn't need all the member variables declared in FilterNode. The only thing is I need a border of 3. Would be nice to have a more abstract BaseFilterNode. And in DMIP example sobel I saw that at first an image with a border is created and inputted into SrcNode. Isn't it possible to use PrepareBoder also for image data where no previous slice exists?

Currently we have our own filter pipeline implementation which uses the L1 cache by allocating some pointers on the stack and process it. Means the slices are very small and we have more overhead for border processing because the width != image width like in DMIP. Our pipeline also is very inflexible and hard to extend. Hopefully we'll get a performance boost with DMIP but at least we will be more flexible. I'm hoping to get a resizing strategy very soon :)

One note at last: I play very often with the DMIP bench example and use the debugger to understand what's happening. While executing the Sobel edge detector I get a heap corruption at the end while destroying the graph. This isn't the case for the harmonize filter. I use the MSVC 2005 compiler. Without debugging information there's no crash.

Ren