Reading the JPEG string in C

[Neville D]

Hi All,

I am using JPEG VI's downloaded from NI, to take a color image and transform to a JPEG string.

This string is transmitted via TCP-IP to a VME based computer and my colleague uses C to capture this image.

Problem is the image he receives seems to have the colours messed up. It looks blue-ish.

I can't seem to be able to upload the JPEG images to LAVA..

Anybody have any ideas?

Thanks,

Neville.

[Neville D]

Figured it out.

I have been using the IMAQ JPEG Encode.vi and IMAQ JPEG Decode.vi from the Developer Zone. There is a "bug" or issue with the Encode, namely that the Red and Blue color planes are swapped, resulting in an image with incorrect color on the receive side, when used with a non-LabVIEW application.

However, if you use the JPEG Decode.vi on the receive side, you don't see the problem, since it interprets the color planes correctly.

The fix is to swap the Red and Blue planes before using JPEG Encode.

Neville.

[Yair]

QUOTE(Neville D @ Mar 9 2007, 11:56 PM)

However, if you use the JPEG Decode.vi on the receive side, you don't see the problem, since it interprets the color planes correctly.

If this is a bug, wouldn't that be incorrectly?

BTW, this is probably a moot point by now, but any reason not to use the picture VIs?

Of course, if you're using other IMAQ features, that would be a good reason.

[Neville D]

QUOTE(yen @ Mar 10 2007, 11:30 AM)

If this is a bug, wouldn't that be incorrectly?

BTW, this is probably a moot point by now, but any reason not to use the picture VIs?

Of course, if you're using other IMAQ features, that would be a good reason.

No, my first statement was "correct". If you use the pair of provided VI's to first encode and then decode, the output is definitely correct; however if you use another environment (trying to decode) with C, then the color planes appear to be swapped.

I'm not exactly certain, but I suspect the issue is the fact that the http://en.wikipedia.org/wiki/JPEG_File_Interchange_Format#Color_Space' target="_blank">JPEG file format does not define the color planes to be used, and the hence the original NI developer of the code was free to interpret the order of the planes as required.. just that interpreting the image in Windoze shows the planes as swapped.

The reason for using the JPEG VI's is the built-in compression & flexibility to adjust it up or down depending on file size (transmitting the 12k image takes about 100ms via tcp-ip).

I'm not sure how I could use the picture VI's to do the same thing?

And, yes, I am using IMAQ and a PXI RT platform for this time-critical image processing application. It's definitely matured a lot since I first started using it around LabVIEW 7.

Neville.

[mateo]

Dear friends,

I am using the IMAQ JPEG DECODE and IMAQ JPEG ENCODE but this 2nd VI waste a great amount of system memory. I think the cause is the Call Library Function Node called "IMAQ_JPG_JpegBuffer2Image" but I don´t know how to dispose the memory allocation.

Could anybody help me? Thanks in advance.

[Neville D]

QUOTE(mateo @ Jun 26 2007, 09:52 AM)

Dear friends,

I am using the IMAQ JPEG DECODE and IMAQ JPEG ENCODE but this 2nd VI waste a great amount of system memory. I think the cause is the Call Library Function Node called "IMAQ_JPG_JpegBuffer2Image" but I don´t know how to dispose the memory allocation.

Could anybody help me? Thanks in advance.

What do you mean by "great amount"?

Is it affecting performance?

How large of a JPEG file are you trying to encode?

The buffer in Encode may be re-usable for future calls. I wouldn't worry about it unless it is drastically affecting performance.

Neville.

[Aristos Queue]

QUOTE(mateo @ Jun 26 2007, 11:52 AM)

Dear friends,

I am using the IMAQ JPEG DECODE and IMAQ JPEG ENCODE but this 2nd VI waste a great amount of system memory. I think the cause is the Call Library Function Node called "IMAQ_JPG_JpegBuffer2Image" but I don´t know how to dispose the memory allocation.

Could anybody help me? Thanks in advance.

You might try placing the "Request Deallocation" primitive on the block diagram of the VI that is too big. Read the documentation before using this primitive. It explains the how and why this prim might help and the time/space tradeoffs you'll encounter.

[monzue]

QUOTE(mateo @ Jun 26 2007, 11:52 AM)

Dear friends,

I am using the IMAQ JPEG DECODE and IMAQ JPEG ENCODE but this 2nd VI waste a great amount of system memory. I think the cause is the Call Library Function Node called "IMAQ_JPG_JpegBuffer2Image" but I don´t know how to dispose the memory allocation.

Could anybody help me? Thanks in advance.

QUOTE(Neville D @ Jul 9 2007, 12:48 PM)

What do you mean by "great amount"?

Is it affecting performance?

How large of a JPEG file are you trying to encode?

The buffer in Encode may be re-usable for future calls. I wouldn't worry about it unless it is drastically affecting performance.

Neville.

I am having this VERY SAME PROBLEM. What is meant by great amount is that the code eats at the system Memory until it is entirely taken up. Note, I didn't see this effect with grayscale images, only RGB images.

This problem can be easily observed by downloading the JPEG code from NI at http://sine.ni.com/devzone/cda/epd/p/id/3314

Filename: 202724.zip

Then, Modifying IMAQ JPEG Demo.vi inside IMAQ_JPEG.llb so that there is a while loop placed in such a way as to allow the Imaq JPEG Decode.vi to run continuously. See attached picture. The .zip file is really a Jpeg image. Just rename the .zip file to .jpg

Any suggestions on what to do?

Ben

[Neville D]

QUOTE(monzue @ Oct 26 2007, 12:21 PM)

Any suggestions on what to do?

Ben

Can you post some example code that demonstrates the problem? I have been using Decode and Encode for a while now, with no problems.

What are you trying to do? Maybe if its blowing up, you could just save the JPEG string from the Encode to file, and then open the file instead?

How about trying to kill the buffer after decode and then using a fresh buffer on the next iteration?

If there really is a bug in the Decode, only NI can fix it, (since they have the source code) and you will have to open up a service request with them.

Neville.

[monzue]

QUOTE(Neville D @ Oct 26 2007, 03:08 PM)

Can you post some example code that demonstrates the problem? I have been using Decode and Encode for a while now, with no problems.

What are you trying to do? Maybe if its blowing up, you could just save the JPEG string from the Encode to file, and then open the file instead?

How about trying to kill the buffer after decode and then using a fresh buffer on the next iteration?

If there really is a bug in the Decode, only NI can fix it, (since they have the source code) and you will have to open up a service request with them.

Neville.

Attached in the previous Comment by me is a screenshot of the IMAQ JPEG Demo Code with a while loop. After your suggestion about killing the buffer after decode, then using a fresh buffer on the next iteration. I have implemented that concept (I think!) and have uploaded that code. See attached .zip file.

Also noteworthy is the fact that I do not have NI Vision Module, so I had to slightly Modify the JPEG code by deleting the IMAQ Cast.vi inside JPEG Decode.vi I don't think that doing this would cause my memory error though.

And noteworthy is the fact that the code from NU does not come with the current image datatype. I have tried converting the datatype with the utility provided by NI for this, and have tried just copying and pasting the new image datatype. I don't know if one works better than the other.

I could save the string to a file then open the file, but that to me seems to involve an unnecessary step. What I am doing is recieving a JPEG Encoded String over a UDP connection. On the recieving end I, I simply want to view the imagery. This imagery comes across the UDP connection at a rate of ~3 frames / second.

Thanks for your help, Neville

What I would like is for someone to verify that I am performing the Imaq Functionality correctly, and am not missing something small. Also, If someone could verify or not verify that the JPEG Decode.vi is working correctly with RGB images.

Ben

[Neville D]

QUOTE(monzue @ Oct 26 2007, 02:08 PM)

Attached in the previous Comment by me is a screenshot of the IMAQ JPEG Demo Code with a while loop. After your suggestion about killing the buffer after decode, then using a fresh buffer on the next iteration. I have implemented that concept (I think!) and have uploaded that code. See attached .zip file.

Also noteworthy is the fact that I do not have NI Vision Module, so I had to slightly Modify the JPEG code by deleting the IMAQ Cast.vi inside JPEG Decode.vi I don't think that doing this would cause my memory error though.

And noteworthy is the fact that the code from NU does not come with the current image datatype. I have tried converting the datatype with the utility provided by NI for this, and have tried just copying and pasting the new image datatype. I don't know if one works better than the other.

I could save the string to a file then open the file, but that to me seems to involve an unnecessary step. What I am doing is recieving a JPEG Encoded String over a UDP connection. On the recieving end I, I simply want to view the imagery. This imagery comes across the UDP connection at a rate of ~3 frames / second.

Thanks for your help, Neville

What I would like is for someone to verify that I am performing the Imaq Functionality correctly, and am not missing something small. Also, If someone could verify or not verify that the JPEG Decode.vi is working correctly with RGB images.

Ben

Ben,

you are right, when the decode is put in a loop LV Memory usage goes way up.. there seems to be a memory leak ONLY when used with RGB images. No way to fix that without getting NI involved.

Unfortunately your code is quite a mess :headbang: and I wasn't able to figure out all the things you said you are doing. Looks like TCP transmitting a JPEG and then reading the JPEG on the TCP receive side. Fair enough, should work.

I tried out my suggestion of using a fresh buffer every time in my version of the code. Doesn't help.

Your best bet is to try saving to file and viewing from there.

Not sure how you are able to use these functions without IMAQ Vision ??

Neville.

[monzue]

Thanks for confirming this Neville. I'll try to get NI Involved.

I probably uploaded too much code. I was only interested in the "IMAQ JPEG Demo.vi" inside of the "IMAQ_JPEG.llb." That uploaded attached zip file is almost exactly what is available on the NI website.

I don't have the Vision module, but I do have the IMAQ drivers which come with a NI Framegrabber, so I have a watered down, free version with some IMAQ functionality.

Thanks again,

Ben