Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C++ C
Hi everyone, here I have a problem which is very urgent and I couldn't resolve during the past three days. It can be simplified as below:
typedef struct _tagBufferStatus
{
      long BufferCount;
      byte** Buffer;
       ...
}StructBufferStatus;
        int nIndex = 0;
        byte *pIn;
        BITMAPFILEHEADER bmfHdr;
        BITMAPINFOHEADER bmiHdr;
        LPBITMAPIINFO lpbmi;
	StructCurrentImageSize structCurImg = MS_GetCurrentImageSize(g_CameraID,&status);
	int cxWidth  = structCurImg.ImageWidthFromCamera;
	int cyHeight = structCurImg.ImageHeightFromCamera;
	DWORD memSize = cxWidth*cyHeight;
	byte *pOut= new byte[memSize];
	ZeroMemory(pOut,memSize);
	LPBITMAPINFO lpbmi;
	DWORD BitmapInfoSize;
	MS_CreateDIBHeader(g_CameraID,&lpbmi,&BitmapInfoSize,&status);
	DWORD dwSize = lpbmi->bmiHeader.biSizeImage;
	static StructBufferStatus  structBufStatus = MS_GetBufferStatus(g_CameraID,&status);
	StructCaptureStatus structCapStatus = MS_GetCaptureStatus(g_CameraID,&status);
	nIndex = structBufStatus.LastValidFrame;
	byte **pTemp = structBufStatus.ImageBuffers;
	pIn = pTemp[nIndex];
	MS_GetGrayscaleImage(g_CameraID,pIn,pOut,&status);
        
        bmfHdr.bfOffBits   = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + 256*sizeof(RGBQUAD);
	bmfHdr.bfReserved1 =0;
	bmfHdr.bfReserved2 =0;
	bmfHdr.bfSize = memSize +sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + 256*sizeof(RGBQUAD);
	bmfHdr.bfType = 0x4d42;
        memcpy(&bmiHdr,lpbmi,sizeof(BITMAPINFOHEADER));
        SavetoBMP(bmfHdr,bmiHdr,pOut);
In this case, function StructImageBuffer GetImageBuffer(long CameraID) is provided for the purpose of retrieving a pointer to a series of image buffer. As each image buffer is represented by a pointer,we need a pointer pointer to get the starting address of image buffer series.
use functionGetImage(long CameraID,byte *pSrc,byte *pDst) to store an image data in pDst, where pSrc points to one of the image buffer in the image buffer series.
 
here,the problem is : the two functions is provdied by DLL,and ImageBuffer is reserved by DLL,and I can't copy data from Buffer to pDst. Is there anyone who has encountered the same problem and is kindly enough to give me a hand? All the thanks!
Posted 19-Feb-13 14:14pm
Edited 21-Feb-13 1:41am
v6
Comments
Albert Holguin at 19-Feb-13 21:57pm
   
What's the error you're encountering? ...state it specifically... Also, do you have the source for GetImage()?
louisejackie at 19-Feb-13 23:29pm
   
Thanks a lot for your kind reply Albert. GetImage() and GetImageBuffer() are provided in DLL,which is protected by Vendor of the vedio card.There is no problem in Debug and running, but when I tried to save the data in pDst to a BMP file,it turned out the saved bmp file is total black, which means the value in pDst is zero.
Albert Holguin at 20-Feb-13 0:39am
   
Does the function return anything? Is there any way to determine whether it failed based on the return? Are you sure you're supposed to allocate the dst buffer and not just pass a pointer to a pointer and let the function allocate it himself? ...have you tried initializing the destionation buffer to something (say all ones or all zeros) to see if the call is doing anything with the buffer?
louisejackie at 20-Feb-13 2:45am
   
well,as is in ImageProcessing, when you read a bmp file into a block of memory,say *pData, allocted manually, you cannot get the value in the block when debuging.it appear to be a mess,but the data is there.
Here lies the same problem.I can't check the value in pDst while Debuging. Can you tell me how?
Albert Holguin at 20-Feb-13 12:42pm
   
You're gonna have to learn to use your debugger effectively. Your initial statement about memory allocated manually doesn't make any sense.
Richard MacCutchan at 20-Feb-13 4:59am
   
Why do you have delete pDst; immediately after your call to GetImage(long CameraID,byte *pSrc,byte *pDst);?
Albert Holguin at 20-Feb-13 12:43pm
   
I assumed he was summarizing his code (i.e. omitting things he did after the call and before the delete).
Richard MacCutchan at 20-Feb-13 12:58pm
   
What you see now is not the original code block that was posted.
Albert Holguin at 20-Feb-13 14:01pm
   
I know... I edited the original yesterday, but I made the assumption based on his description.
Richard MacCutchan at 20-Feb-13 14:33pm
   
I'm not sure that's the right thing to do. What is posted may well be the code that is broken.
Albert Holguin at 20-Feb-13 15:22pm
   
When I say edited I mean... edited the question... I changed his tags from code to pre, that's all.
Albert Holguin at 20-Feb-13 15:22pm
   
You do know you can look at the edit history right?
Richard MacCutchan at 21-Feb-13 3:03am
   
Yes of course. I just misunderstood what you were saying.
louisejackie at 21-Feb-13 3:11am
   
It seems my comment cannot be posted...
Richard MacCutchan at 21-Feb-13 5:51am
   
Try posting a question at the Site Bugs & Suggestions forum, and the administrators will help you.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

There are several things that look weird here, besides the fact that you consistently left out the "r" in "struct". The code you showed would not even compile.
 
Take a look into the documentation of your library vendor and see whether GetImageBuffer really returns a StructImageBuffer! This structure can have a considerable size and it is unlikely that someone passes that as a result value.
 
If GetImageBuffer really returns a StructImageBuffer, why would one need a GetImage function? You could simply access the image by retrieving the buffer pointer from the StructImageBuffer.
 
The GetImage function takes the CameraId as first argument. That doesn't make sense if the image data already reside in the buffer pointed to by pSrc.
 
I think that you have misinterpreted the vendor's description of the two functions and it is hard to guess what they really do.
 
Btw.: The values in an image buffer do normally not look like "a mess", but are simply the pixel data of the image. Look at them in your debugger as hex or int values and they should make sense.
  Permalink  
Comments
louisejackie at 20-Feb-13 5:39am
   
Sorry for my bad spelling.Great thanks to nv3.I cannot upload an image to show you my debug situation. Allow me to try to put it like this:
char *filename ="lena.bmp";
byte *pSrc = new byte[cxWidth*cyHeight];
pSrc = ReadImage(filename);
when Debuging,at watch window, pSrc's address is shown,after which follows a trail of messy code,something like japanese character.
As to the two function, CameraID is the resource they can access ,and GetImageBuffer() returns a struct,not the actual memory.so it won't be very large.
nv3 at 20-Feb-13 5:56am
   
Can you copy paste the part of the vendor's DLL .h file that contains the relevant definitions? For example the exact definitions of GetImageBuffer and GetImage and the structs they use. Perhaps we can make sense of that.
 
In your above example you are creating a memory leak. You first allocate a buffer with new, then you reassign pSrc with the result of ReadImage, which obviously allocates its own buffer.
 
So, understanding the exact interface of those library routines is essential and I think your problem is that your idea of how they work is not entirely correct.
louisejackie at 20-Feb-13 6:17am
   
Alright,here is the vendor's DDL version of the two function.
 
MS_CAMERACONTROL_API const StructBufferStatus MS_GetBufferStatus ( long CameraID, int * pStatus =
 
NULL);
Returns:
a struct containing the current values of the status
 
Parameters:
CameraID: This is the unique Camera ID value of the camera you want to apply this function to.
This must be the same value that was returned by MS_InitializeCameraID() when you initialized this
 
camera.

pStatus: Returns the status code of the operation. See Status Codes for more information.
This parameter is optional. If it is not passed, then the status will not be returned.

 
MS_CAMERACONTROL_API int MS_GetGrayscaleImage ( long CameraID, unsigned char * pIn,
unsigned char * pOut, int * pStatus = NULL )

This function will leave the image in 8-bit grayscale format, but will remove the bayer pattern noise
 
from the image, and store the result in a user-created buffer.
The original image in StructBufferStatus::ImageBuffers will not be affected by this process.
This function is meant to be used when StructColorSettings::DisplayMode is set to c_ColorModeGrayscale
 

Attention:
You must manually allocate the buffer pOut before you call this function, and free this buffer when
 
you are finished using it.
The size of this buffer must be StructCurrentImageSize.ImageWidthFromCamera *
 
StructCurrentImageSize.ImageHeightFromCamera * 1, because each pixel will be 8 bits.
 

Returns:
the value of *pStatus
 
Parameters:
CameraID This is the unique Camera ID value of the camera you want to apply this function to.
This must be the same value that was returned by MS_InitializeCameraID() when you initialized this
 
camera.

pIn: This is the pointer to the image buffer to process.
This should be set to either a frame from the StructBufferStatus::ImageBuffers, or the pImage pointer
 
passed to one of the callback functions.

pOut: This is the pointer to the processed image.

pStatus: Returns the status code of the operation. See Status Codes for more information.
This parameter is optional. If it is not passed, then the status will not be returned.
Albert Holguin at 20-Feb-13 12:47pm
   
There's a status that is returned... why aren't you checking it?
nv3 at 20-Feb-13 17:12pm
   
Ok, I assume that MS_GetGrayScaleImage is the function that you were referring to as GetImage in your original post, correct?
 
The first thing I would do is to look at what is returned via pOut. We are expecting an array of w * h bytes that represent the pixel values. Look at the first 100 pixels in your debugger or print them via print to stdout, each byte with format "%3d". Something like:
 
for (int i = 0; i < 100; ++i)
printf ("%3d, ", pOut[i]);
printf ("\n");
 
Does that look like pixel values of normal image? If you receive 100 zeros that means, either the first scan line of the image is black, or the function call failed for some reason.
 
The next step is to look at the function SaveToBmp (byte* pOut). What bothers me is that SaveToBmp has no information about the width, height, and pixel size of your image. How can it create a valid BMP file with just receiving a buffer pointer; it doesn't even know the length of that buffer. Have you written that function or is it part of the camera vendor's library? Anyhow, it looks very weird.
louisejackie at 21-Feb-13 3:13am
   
According to your suggestion,I found pOut did have valid values. Now I can get the first frame from buffer series,but from the second frame,they are totally black.how come?
nv3 at 21-Feb-13 3:20am
   
Consult the documentation of your camera vendor. Is that a still camera or a video camera? For still cameras, multiple buffers could be used for the RGB color planes. In case of a gray scale image it would not be surprising that only the first buffer is being filled. In case of a video camera I would expect the buffers to be used in round robin fashion. Probably you have to configure the frame rate and number of buffers used.
 
What about SaveToBmp. Have you read my comment on that in my previous post?
louisejackie at 21-Feb-13 3:35am
   
Yes I read your comment on SaveToBmp().As I used some global variables,so one prameter would be enough to save the bmp.
As to the camera, It is a high speed vedio camera,its model known as MegaSpeed 75K,a product of Canada company MegaSpeed.As is specified in documentation,the DLL will reserve 80% of PC ram for image buffers. The raw data should be grayscale. The image buffer is used in round robin fashion in camera ram.
typedef struct _StructBufferStatus
{
long ImageBufferCount;
unsigned char **ImageBuffers;
int LastValidFrame;
long TotalFramesSavedToBuffer;
float ImageBufferSizeInMegabytes;
} StructBufferStatus;
 
This struct is used by MS_GetBufferStatus() to report the PC's current image buffer status. These values are updated immediately, whenever any of the values are changed.
nv3 at 21-Feb-13 5:40am
   
Ok, I assume then that the problem is in the way you query the buffer status and access the right buffers. If you like, show us the code how you access the buffer status and how you decide, which buffer to convert to a BMP. It would be best if you use the green Improve Question button and add that code to your original question. This way, all others see that code as well and can comment on it.
louisejackie at 21-Feb-13 7:32am
   
Thanks for your advice nv3.I really appreciate it.I've reshaped the code.Thank you very much.
nv3 at 21-Feb-13 10:13am
   
You are welcome!
louisejackie at 22-Feb-13 7:04am
   
Hi nv3, it seems I can save all the frame frome buffer,leaving out some of them due to speed.the problem is ,the image is upside down. how can I reshape it in a fast way?
nv3 at 22-Feb-13 7:25am
   
Take a look into your SaveBitmap function. There you will be writing a BITMAPINFOHEADER structure as header to the file. In that structure you find the member bi.Height. Set that to the negative height. That tells any reader of the file that the scan lines are stored top to bottom.
 
Note: Historically all bmp files were written bottom to top. And that is expressed with a positive number in biHeight.
louisejackie at 23-Feb-13 6:55am
   
Awesome,it seems you know everything about image processing.Now everything seem ok except that the sequence of bmp files saved appears to be at random.It is expected that them file name of saved bmp file should be in the format of "nIndex.bmp" ,where nIndex is the Nth frame in the image buffers.I suppose the value of nIndex should accumulate with the count of frames saved to the buffers.
nv3 at 23-Feb-13 9:00am
   
You are welcome. I am glad I could help. If you can't figure out why buffers are not written in strictly ascending order, you might want to ask your camera vendor. It is not uncommon that the sequence in which buffers are used is not straight forward.
louisejackie at 23-Feb-13 20:45pm
   
The frame I'm trying to read in is close to the current one being written by camera.The struct StructBufferStatus has a member :lastValidFrame,which specifes the index of the buffer written latest. So is there any problem in using this member to decide the buffer location of the frame?
nv3 at 24-Feb-13 6:35am
   
I don't think that there is a problem using LastValidFrame. If you want me to take a look at the full interface, just post the documentation of StructBufferStatus and the relevant functions via Improve Question - or just post a new question, this one is getting a bit lengthy.
louisejackie at 24-Feb-13 9:39am
   
Hi nv3,thanks for your sticking by with me. I have posted a continuation of this question.here si the link: http://www.codeproject.com/Questions/551769/5bContinuation-5dhowplustoplusgetplustheplusdatapl
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

Are you getting valid values in the pDst before saving as BMP file while you debug?
  Permalink  
Comments
louisejackie at 20-Feb-13 3:56am
   
Values in pDst seem to be a mess, as they are binary data.Do you have any suggestion on how to check data value of a BMP file when Debuginig ?
Albert Holguin at 20-Feb-13 12:45pm
   
You have to know whether that binary data makes sense. It's up to you to figure out what makes sense (look at the BMP standards).

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Sergey Alexandrovich Kryukov 853
1 OriginalGriff 410
2 CPallini 275
3 George Jonsson 226
4 Richard Deeming 145
0 OriginalGriff 5,450
1 CPallini 4,500
2 Sergey Alexandrovich Kryukov 4,482
3 George Jonsson 3,057
4 Gihan Liyanage 2,445


Advertise | Privacy | Mobile
Web03 | 2.8.140916.1 | Last Updated 21 Feb 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100