uEye camera Plugin with TextureOut

vvvv beta question
1

Hi, I’d like to rewrite the uEye plugin to have a TextureOut pin.

First, I love the plugin. Great work!

Problem is, I think the whole SharedMemory aproach adds quite a lot of overhead. Especially when I just want to get the almost unmodified raw bayer data (8bit) the processor is at 40%.

I just realized that even changing the fps of the camera doesnt change the processor usage.

(Btw. I’m using the sharedmemory to texture node)

So what I actually want to ask is, if it’s possible to use the newly available TextureOut option for plugins to directly copy the camera data to a texture. And if one would gain performance from that.

Thanks alot in advance
Tomi.

2

helo tomeic,

that should be very much feasible indeed. and yep i’d say you should gain at least a little performance, can’t estimate how much though.

see how the _PluginTextureTemplate:
http://vvvv.svn.sourceforge.net/viewvc/vvvv/plugins/c%23/_Samples/_PluginTextureTemplate/trunk/
creates the texture output and find out how to create a plain texture via slimdx and copy the image to it. shouldn’t be too hard to figure out.

still i’d keep the option in the plugin (via an additional configuration pin) to write to the shared memory location as so it can still be used in connection with SharedMemory (DShow9) .

good lukc.

3

Thanks joreg for the fast reply!

Ok, transferred the TextureTemplate to the uEye Plugin. Compiles and outputs the Texture from a file. happy.

Now before trying, I wonder when and where are the places to create and update the camera texture.

A: there is UpdateResource()
What should happen here? What means “device specific operations” (from the comments of the Template)?

B: there is the DrawImage() function which is started by the uEye.IS_FRAME Message which says: there is a new image!
(coming from: “protected override void WndProc(ref Message m)”)

(And C would be the Plugin mainloop - but I guess thats not a place?)

I’m just wondering if I can Lock and fill the texture whenever from whereever I want?
Should I use two textures and double buffer?

greetings

4

A: there is UpdateResource()
What should happen here? What means “device specific operations” (from the comments of the Template)?

device here means directx-device. if you have two monitors in dualview and a renderer on each and the plugin connected to both, it has to deal with two such devices. textures are per device, so copying to a texture is a device specific operation and should be done in the UpdateResource() function which is called for every device.

but right, here the situation is a bit tricky, since uEye is pushing the image in DrawImage(). so what you could really do is use a doublebuffer as you suggested. always have one texture ready to write to in DrawImage() and hand back the other in GetTexture(). in UpdateResource() you only create the textures as this is the call that tells you for which devices the image/texture is requested.

hope that helps.

5

I almost gave up but on all these DX pointers and datatypes.
but now it’s running!
Luckily I found the uEye function:
CopyImageMem(…)

Now its basically this:
{CODE(ln=>1)}uint* pData = (uint*)texture.LockRectangle(0,LockFlags.None)
.Data.DataPointer.ToPointer();
FuEyeCam.CopyImageMem(FuEyeImages0.pMemory,0,
(IntPtr)pData);
texture.UnlockRectangle(0);^

Now some remaining questions:

  • The above code is simply executed in DrawImage() and I get the texture from a foreach loop on the FDeviceTextures.

What that means, is that it will copy the image for every device,right? It just doesn’t show up on a second renderer. :( And on the other hand is it needed to copy for every device?

  • I don’t do any double buffering and it runs like Schimdts cat. I just wonder if it should be implemented. Can it happen the write occurs when texture is being rendered? Will the renderer have to wait?

  • If I want to change the texture size and Format I just have to again foreach on FDeviceTextures, remove the entry and Dispose() the texture? Then in UpdateResource() it will create a new one? That’s enough?

Sorry for all the questions.
Tomi.

6

congratulations.

  • What that means, is that it will copy the image for every device,right? It just doesn’t show up on a second renderer. :( And on the other hand is it needed to copy for every device?
    ja, that is the deal. different devices are completely separate and you have to copy the texture to each.
    if it doesn’t show up yet on a second device you probably have something wrong still.

  • I don’t do any double buffering and it runs like Schimdts cat. I just wonder if it should be implemented. Can it happen the write occurs when texture is being rendered? Will the renderer have to wait?
    my understanding is that LockRect() is blocking and also waiting until it can access the texture that would explain why it is running without tearing.
    i am not certain about this, but i’d say doublebuffering would be the cleaner solution as it doesn’t block any of the two threads involved randomly which could result in some unwanted behaviour in more complex situations. doublebuffering will though introduce some additional delay (

7

Ok, now I also see a mayor drawback with this naive implementation…

It only allows camera image sizes of powers of 2. Otherwise the image is scrambled.

For me now it’s ok but I guess one has to do a more complex copy from the camera image to a non power of 2 texture.

Or is there another way to define where to copy the content?
Or define a texture?

8

hm, i don’t see how there should be such a drawback. i don’t know the uEyeCopyImageMem() function, but still i’d not see any reason why non-pow2 textures should cause any problems. if you upload the kode i could have a look at it (would still need to get my cam back though…)