# Difference between Cvb.SharedImg and Cvb.Image.IMG **URL:** \ **Category:** C-style API\ **Tags:** csharp, acquisition, linearaccess, ringbuffer, parallel\ **Created:** [September 4, 2017, 11:01am UTC](https://forum.commonvisionblox.com/t/difference-between-cvb-sharedimg-and-cvb-image-img/207 "2017-09-04T11:01:45Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![parsd](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.commonvisionblox.com/parsd/32/7_2.png) [@parsd](https://forum.commonvisionblox.com/u/parsd)\ **Post date:** [September 7, 2017, 8:37pm UTC](https://forum.commonvisionblox.com/t/difference-between-cvb-sharedimg-and-cvb-image-img/207/6 "2017-09-07T20:37:17Z")
The way you handle your application looks correct to me. If you dispose the driver `IImageVPA` you unload the driver, release the camera and free the driver’s ring buffer memory (if nobody else is sharing the ownership 😉). If you want to acquire again within your app, it would be faster to not unload the driver. As otherwise you would need to reload everything again from scratch. **IRingBuffer for Task-based Processing** Also as @illusive hinted, you can get rid of the costly duplication step. In :cvb: we use the `IRingBuffer` interface for your use case. This is the companion interface to `IGrab2`, which you probably used to acquire the images. For this use case you probably need to increase the number of driver buffers via the driver’s ini-file or programmatically via the `RBNumBuffer` function with `RINGBUFFER_NUMBUFFER_CMD_SET` as _Action_. This will create a new driver `IImageVPA` with the desired number of buffers if successful. The old `IImageVPA` object stays intact until you release it. Only all driver interfaces were moved to the new handle. This enables you to e.g. finish processing while switching to a different mode in your app. After you have your desired number of buffers, you can set the lock mode to `RINGBUFFER_LOCKMODE_ON` via the `RBLockMode` function. This is a manual mode in which the acquisition engine only locks the buffers to write-protect it for the engine. You as the user must unlock the buffer via `RBUnlock` when you don’t need it anymore. Otherwise no buffers are available anymore after the ring buffer is filled and no new images can be acquired. With `RBBufSeq(m_Camera, 0, bufferIndex)` you get the buffer index of the last awaited buffer (`G2Wait`). With `RBGetBufferImage` and this index you get a view (no copy) on that buffer as a :cvb: image. For more information about `RBBufSeq` see [this post](https://forum.commonvisionblox.com/t/where-does-the-image-point-to-using-rgbufferseq-with-numbuffers-1/140). Instead of your copy, you can give that ringbuffer image to your processing task(s). After processing is finished you can unlock it (but note, that `RBUnlock` works on the driver image `m_Camera`). Whether you release the ringbuffer image every time or cache these and free them after the acquisition is finished is up to you. The ringbuffer images stay valid until released. And as long as you don’t change the number of buffers or their size (`IImageRect`}), they stay connected to the acquisition engine. I normally bind together the ringbuffer image, the driver image, the buffer index (the last two for unlocking) and my own ref count initialized to the number of tasks running on the image. Every task decreases the count by one when finished and then unlocks (and maybe releases) the ringbuffer image if that count reaches zero. A `Parallel.For` for example wouldn’t need the ref count as you have a sync point after the loop finished. Again a longer post… This is a bit more complicated programming wise, but yields better performance in the short (no copy) and long run (less memory fragmentation). And yes, this scenario including `ReleaseObject` on the ringbuffer images is thread safe (as long as the driver image stays alive). I hope that helps. --- _[View the full topic](https://forum.commonvisionblox.com/t/difference-between-cvb-sharedimg-and-cvb-image-img/207)._