TDA4VM: Failed to replace image by "Dequeue-Copy-Enqueue"

Hi Damon,

Could you help us understand what exactly you are trying to achieve? 

Regards,

Brijesh

Hi Brijesh:

I'm want to modify the output image of a node outside the graph. I want to replace the camera image with a sampled picture.So downstream nodes will use this image as input.

But I failed with the above method.Is the output image from a node not allowed to be modified outside the graph?

Regards,

Damon

Hi Damon,

In this case, instead of using graph parameter, you would need to update the node to take the input image using some control command, so that it can be changed run time, and then node needs to copy the reference image into output image.

Regards,

Brijesh 

Hi Brijesh,

Damon@INVO said:

"vxMapImagePatch()--write()--vxUnmapImagePatch()"

This is my PlanB to achieve the goal.And I've tried this  as my PlanA, got a problem too:

The target kernel called DrawIcon is running on R5F. So I need to alloc a shared memory for transferring data from A72 to R5F through control command.

At first, I alloced shared memory on R5F, and send the PhyAddr to A72.Then I found that there is  no way to convert the received PhyAddr to VirAddr.

So I changed the owner of the shared memory by allocing on A72. This time the convertion form VirAddr to PhyAddr can be performed normally on R5F.So I put it as one of the alternatives.

About the PlanA, I want to ask "Whether the shared memory created on R5F cannot be used by A72?"

As to my PlanB, I just want to find out if my plan itself doesn't work or if there is something wrong with my operation?

BTW：sorry for accidentally clicking the "report as abusive" button on your reply on another post a few days ago. I didn't find way to undo.

Regards,

Daomn

Hi Damon,

Damon@INVO said:

About the PlanA, I want to ask "Whether the shared memory created on R5F cannot be used by A72?"

Yes, since this is allocated from local heap of R5F, which is not mapped on A72, it cannot be used. It is better to allocate memory on A72 from the shared memory pool, which is then accessible on all cores.

Damon@INVO said:

As to my PlanB, I just want to find out if my plan itself doesn't work or if there is something wrong with my operation?

Do you mean to update the node with draw operation? Yes, it is going to then work fine.. 

Essentially, you could create an image using standard OpenVX APIs and then map it in the application space to copy known image, and pass the reference of this image to node using some control command. Images will be allocated from the shared memory, so will be accessible from all cores and also we can change the content of it anytime by mapping it in the application space..

Regards,

Brijesh

Hi Brijesh,

Brijesh Jadav said:

Yes, since this is allocated from local heap of R5F, which is not mapped on A72, it cannot be used. It is better to allocate memory on A72 from the shared memory pool, which is then accessible on all cores.

Thanks, This helped me figure it out.

Brijesh Jadav said:

you could create an image using standard OpenVX APIs and then map it in the application space to copy known image, and pass the reference of this image to node using some control command. Images will be allocated from the shared memory, so will be accessible from all cores and also we can change the content of it anytime by mapping it in the application space..

And this scheme seems to be more standardized.

However, my initial doubts remain.Sorry I didn't express my question clearly.

My ultimate goal is to overlay an information map on the image captured by the camera.The planB is to do this outside the graph instread of using a node.So I added an operation like this in the main loop:

step1:Dequeue the output image of capture node to get the reference

step2:Map the image to get  addr pointer

step3:copy overlay icon into image

step4:Unmap the image

step5:Enqueue to put the image back to graph pipeline.

As a result, there is no overlay icon displayed on the screen. It's just the camera video.

So I suspect that the image enqueued to the graph is refreshed somewhere in each loop. The operation of overlaying images doesn't happen between the capture and its next node in the graph stream. Is that so?

Regards,

Damon

Hi Damon,

Yes, If i remember correctly, dequeue returns the buffer after its processing in the next node, so this method will not be helpful in this case.

Regards,

Brijesh

Hi Brijesh,

Thank you.If so, maybe I can remove the "Dequeue" operation and do "Map-copy-Unmap" directly to update the image successfully.

Regards,

Damon

Hi Damon,

Damon@INVO said:

Thank you.If so, maybe I can remove the "Dequeue" operation and do "Map-copy-Unmap" directly to update the image successfully.

I think that could create conflict. Dequeue gives access to this buffer to the application. Without this access, there could be two application/components accessing the same buffer at the same time..

Regards,

Brijesh 

Hi Brijesh,

thanks for your advice. I think I will t do this by contrl cmd as you said.

Regards,

Damon.