Rank: Member
Groups: Member
Joined: 7/25/2007(UTC)
Posts: 18
Thanks: 1 times
|
Is it possible to reuse the same pixel buffer for an Aurigma Bitmap? The application needs fast (read) access to a Bitmap’s pixels, so I store pointers to positions in the BitmapData scan lines (which I got with LockBits). But to change the Bitmap, I need to do UnlockBits and LockBits again. There are two problems with this: 1. It’s slow, and 2. Doing LockBits a second time may use a different buffer, which would make my pointers invalid. Some potential solutions are: 1. Getting a pointer to the Bitmap’s pixel buffer, and preventing the buffer from moving in memory, or 2. Making an Aurigma Bitmap with a user-supplied pixel buffer, or 3. Getting the same buffer every time from LockBits. Are any of these possible, or can you suggest another possible solution? Thanks! Alan
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 7/25/2007(UTC)
Posts: 18
Thanks: 1 times
|
Making a Bitmap with a user-supplied pixel buffer IS possible with a .NET bitmap, which has the following constructor: public Bitmap ( int width, int height, int stride, PixelFormat format, IntPtr scan0 ) This initializes a new instance of the Bitmap class with the specified size, pixel format, and pixel data. http://msdn.microsoft.com/en-us/library/zy1a2d14(VS.80).aspx The scan0 parameter points to the user-supplied pixel buffer, which would allow instant access to the Bitmap after it's changed. This Code Project article shows how to create and use this type of Bitmap: http://www.codeproject.c...ointerlessimageproc.aspx Unfortunately there's no similar constructor for an Aurigma Bitmap: http://www.aurigma.com/S...assConstructorTopic.html I need to use an Aurigma Bitmap because .NET doesn't support the CMYK color space, but I don't see a way around this problem. Is there any way to reuse a pixel buffer with an Aurigma Bitmap? Thanks!
|
|
|
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 1/31/2005(UTC)
Posts: 458
Was thanked: 5 time(s) in 5 post(s)
|
Hi Alan, Its a good question! Let me explain some internals to get things more clear. Actually you will always get the same pointer to the raw data. Graphics Mill stores pixels in umnanaged object, so GC cannot shift it during work. But this buffer can be recreated in case of applying a transform to the bitmap object. Moreover it is impossible to avoid recreation in most cases. The obvious reason - when you are scaling up an image - it cannot be fitted in the old internal object. But even when you are doing something not so cardinal (e.g brightness/contrast correction) Graphics Mill creates new unmanaged buffer underhood. This allows us to preserve correct state of the object in case of any exception during processing. So you can be sure that there will no partially processed images. Therefore we cannot "pin" buffers pointers. Another option - constructor with user-defined buffer will be unsecure (in case of direct usage) or slow (in case of just copying of the provided info into internally created buffer). All this sounds bad, but I wonder why not to recreate this pointers to the scanlines after each bitmap transformation? It should be really very-very quick. And another question - are you sure that LockBits() is so slow? Actually it don't contain any "heavy" actions and should work fast. Could you provide us with more details regarding to this ussue - some profiling metrics or something else? |
|
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 7/25/2007(UTC)
Posts: 18
Thanks: 1 times
|
Hi Alex, Thank you for your reply. The problem with recreating the scan lines after the image changes is that there are a lot of them. The application requires getting single scan lines of an image which is composed of many CMYK bitmaps. Each scan line is modeled as a linked list of scan lines from bitmaps that intersect the scan line in the original image. So there may be thousands of linked lists, each with pointers to scan lines in bitmaps. Your reply is helpful. Now that I know that the buffer is recreated I can look at alternatives. I'm thinking of just storing the offsets from the beginning of the image in the linked list, since these won't change, and just updating scan0 (the base address) when the buffer changes. Thanks, Alan
|
|
|
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 1/31/2005(UTC)
Posts: 458
Was thanked: 5 time(s) in 5 post(s)
|
Hi Alan, Thousands! Yes, in such scales it is significant time - and your variant with offsets sounds good. Do not hesitate to contact us in case of any questions - requirements of your project are very interesting and challenging - we will be glad to assist you. |
|
|
|
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.