processing jpgs with c++?

Hi, I'm not sure if this is the right forum to ask, but I'll try anyway..

I am using an application that reads in image data from a robot and apparently stores it in jpg format. Basically I can get the data into a buffer of about length 3000, but the image size is ~ 150x200. The only way I know to process images is to get RGB values of each pixel (i.e. bitmaps), but that is clearly not how image data is stored in this case. Does anybody know how I can work with these buffers? Specifically, I need a way to access RGB values of each pixel in the image. How do I do this if the buffer only has 3000 entries? Is it something jpg specific in this case?

It may also be the case that the buffer of length 3000 just doesn't make sense in this context, and there's something wrong with my buffer extraction code, so if you guys think that a buffer of length 3000 is impossible for an image 150x200 then please let me know.

Appreciate the help, thanks a lot.

The question is not clear. Are you not sure about what space to allocate to a buffer in advance??
Or you are facing trouble with extracting data and storing in buffer for temporary operations?


Nothing seems to be specific to jpeg as data is going to remain the same irrespective of file formats.

What do you mean by the bold text?

Sorry about the confusion. Here is what happens. I am using a C++ application written by someone else (source code hidden to me). One of the accessors I am allowed to use is a function that takes in a buffer and a buffer length, and returns image data from a robot and stores it in that buffer. The buffer length must be given in advance, and is returned to me by the application whenever I receive the message. Basically, a message is passed back to me which results in calling the following code:

LRESULT CRemoteTestDlg::OnITPImageUpdate( WPARAM wParam, LPARAM recvLen )

{
m_imageTPDlg->OnImageData(recvLen);

return S_OK;

}

When I run through the debugger, the value stored in wParam is zero, and the value stored in recvLen is about 3000. OnImageData is a member function I wrote which takes in recvLen, creates a buffer with size recvLen, and feeds the buffer and the length into the built-in image extraction function. recvLen seems to be the correct length to use, because any other length I give results in an error from the image extraction function.

Basically, my concern is the following. Before doing it this way, I tried it a different way; namely, by saving the image file on disk and then reloading it into a bitmap buffer. The resulting buffer had a size on the order of 150 * 200, which were the dimensions of the image when displayed. Therefore, I was able to write two for loops, iterate through each pixel in the buffer, and change colors around. Now, when I extract the data directly, the buffer size is only about 3000, so I don't think it can represent 30,000 pixels all by itself. I know that jpg's are a lot more compressed than bitmaps, and that could be reflected in a buffer size about 1/10 the dimensions of the image. I want to know if this shrinking in buffer size is correct behavior to be expected for jpgs, or an error somewhere in my code. Should a jpg image buffer be the same size, or smaller, than other types of image buffers? Can a 150x200 jpg image be stored in a buffer of length 3000? If so, how can I write a program to:

1) extract and modify any given pixel of the image from this buffer, and
2) display the resulting image?

If what I am experiencing is incorrect behavior, the problem is then code-specific, so I'll have to go back into my code and try to figure things out myself.

Sorry for the long and wordy explanation. I realize this is a little confusing...hope things are clearer now. Thanks for reading and helping!

Ok. I try to go step by step to help you out.
1. The jpeg buffer is obviously less due to high compression involved in it.
2. For modifying data in the buffer, you will have to uncompress it. I think here is the problem you don't know about the size of uncompressed data.For this , you will have to look for some fields in the header of jpeg that give you the exact dimensions.

The answer to your question highlighted in old is : Less. This is due to high compression ratio.Infact you can control this by controlling the quality of the picture and the resolution.

For your other questions, you will have to take out the data to a buffer in the form of jpeg compressed data.

Uncompress the data. Followed by your choice whether to represent the modified the same in jpeg or other file formats or just a DIB.

Point of caution: In Jpeg or JFIF, the header for markers (in the file headers), the data buffer and DCT Tables are distinct.There is no need to search and do calculations, but in JPEG2000 or JP2, the data buffer and AC/DC tables are represented as one table.Here you need to look for markers that distinguish them.

The function I am calling to retrieve the data gives me only the buffer in which the image data is stored. I know the size of this buffer (about 3000). The only other thing I know is the dimensions of the image that is displayed by this autonomous application (about 150x200). Regarding the underlined above, is what you mean when you say the "size of the uncompressed data" the dimensions of the displayed image? Or do you mean something else?

I don't know anything else about the image, and I don't think I can get any other info about it, because the program is protected and I am not allowed to access the image itself. Is the header of the jpg stored at the beginning of the buffer I extracted, then? If so, how do I get information out of it (i.e. where do I look and what code do I write to extract it)?

Is the info I currently have enough to decompress the jpg? Can you tell me some code I need to decompress it into a buffer of some other kind that I can work with? (Sorry, don't know anything about how to decompress something at all, and don't have much experience working with images in general, hence the flood of questions.) Preferably I will end up with a buffer that is 3 * 150 * 200 in size, with one entry corresponding to an R, G, or B value of some individual pixel, because I will end up writing a set of algorithms that will mathematically manipulate each pixel. How do I get the buffer into something like this?

thanks a lot for everything you've helped me with so far. I already understand this better than when I started!

edit: oh, btw, I'm writing this in a Visual C++ environment.

Writing a codec for jpeg images is a challenging job and for that you have to be cnversant with its structure. In layman terms, every file format has some block called header that contains basic info about data attributes. As regards to the underline, I mean that data in jpeg file is compressed. The original data should be obtained as uncompressed for modifications.

If the program is protected,better consult ofr ready made tools(3rd party) for codec operations. For buffer size , take maximum, if it gets short use realloc() funtion to increment the size.

I don't have the exact code. Anyway, you can get tools, from Net,for extracting stream of data.

See another approach for same , though inefficient, is to uncompress the stream and write down to a temporary file.Then calculate the size by getting size of this file.Allocate buffer and do the required operations.

Drawback of this method : Involves I/O operations, hence for large images, it consumes your computer resources.

Tried that before, and the writing/rereading takes too much time for what I need to do.

So there is no (easy) way to do what I'm trying to do using just msdn and mfc libraries that come with VC++? I know bitmap structures are built in and are pretty easy to use, but not for jpg?

Thanks soo much for help. Time to find and learn how to use jpg decompressers... haha. Do you have any suggestions/recommendations on that, btw?

Try sites www.download.com or search at Lead Tools' site.

Cirus -

Could you please talk more about DIB images? I have a problem where I am developing a DLL that is supposed to take in an HGLOBAL pointer to a DIB image in memory, pass it to a cropping function (already developed), and then pass back a pointer to the cropped image. What I need to test the DLL is a test program that loads in a bitmap file from disk, puts it into memory, and provides an HGLOBAL pointer to it. Do you know how to do this?

P

Do you want me to code or just explain the concept?

I have the EXE file built to run in command line so I don't need a whole package. I think it is best left to your judgement about how complex the code is. If it is a difficult concept that I would have trouble translating to code, it would be fantastic if you could provide code snippets or the whole function. Otherwise a step-by-step conceptual picture should suffice.

Thanks!

P

Well , you need to load DIB to memory.For this, you will have to read the BMP file in steps and extract the DIB from it.

Before proceeding, a clarification about DIB.
A DIB or Device Independent Bitmap is a structure or arrangement of image data irrespective of underlying Processor or operating system. The available file formats
are either s/w based , hardware based or independent.
DIB is inherent component of every file format.

For BMP, DIB starts after BMPFileHeader. It contains, BITMAPINFOHEADER,ooptional Color pallete data and mandatory image data.

Now, for loading DIB to memory you strip out fileheader ( 14 bytes ) for MS based file.the rest 40 bytes form bitmapinfoheader( gives info about nature of image data).

For 4 bit /8 bit ,color pallete table is present.This is excluded for 24bit RGB.
Thus for non-True color image, you load BITMAPINFOHEADER,ColorPallete and image data to a buffer or a memory block.

Thus your fucntion takes hardisk based or memory based file and returns address of memory block ( of type HGLOBAL), containing DIB.

Another thing for BMP. It is 4 byte padded.Meaning, each row of an image should have num. of bytes as 4's multiple. Thus you need to take out those padded bytes in order to get pure image data. For more reference ,refer to MSDN for BMP.

Clear?