jpeg string to picture

[cosmin]

This is a subVI that takes a JPEG string and convert it to a picture. Usefull for on the fly visualization of pictures from IP cameras or picture received from networks.

Attention for Width and Height inputs, those must be minimum as the size of actual image, the VI is stripped of the code that dynamically detects those picture parameters.

Labjpeg7new.dll and jpeg7.dll form are a new version. Put them in the same folder and use labjpeg7new.dll instead of labjpeg7. It has the same calling parameters.

[londonew]

Hello, could be possible to save the file to version 8.2? please, I would appreciate your help at hese moments. Thanks

[cosmin]

posted

[londonew]

Thak you for the file cosmin. I executed the file but it crash when the dll is called.

[cosmin]

upload your picture

[londonew]

I hope the picture doesn't be the problem. Anyway, I tried with several pictures. Maybe the problem is when I call to the .dll as I can check in the debugger mode. Thanks.

[cosmin]

sorry I cannot reproduce your issue. In my computer is working fine with your picture.

[Enrico_Segre]

Hi Cosmin,

I'm evaluating the performance of your solution vs IMAQ Read file.vi (which probably calls directly the system codec for jpeg), vs. still another contraption of routines provided by a particular camera SDK for decoding jpeg streams. Clearly IMAQ Read file is an option only when the images are stored in the filesystem, while I'm concerned with image streams already in memory.From my tests IMAQ Read file decodes more than twice as fast than the routine in your dll; plus, I have to add an overhead of array gymnastics for casting the obtained image data (a nxXnyX3 array) to an U32 image with alpha channel, or anything the like. Any comment from your side?

Enrico

[cosmin]

Hi Enrico,

it's good that you are benchmarking the dll, I cannot do it against IMAQ Read file.vi since I do not have vision module installed. First of all, this was a sollution for jpeg streaming without vision module which means license cost. I made a little benchmark right now against JPEG read file.vi from Graphics pallette. The dll is 3 times faster. Against your benchmark you should consider the overhead of picture draw. The image is drawn on a picture indicator which adds on my computer around 35ms.

Last but not least, I must confess that I'm 90% sure that I put the debug version of the dll (from the size of the dll). I did this some 3 years ago, I do not have with me anything regarding this project since I'm 2000 miles away from the place I work then. I will try to get from one of my colleague the project.

cosmin

[Enrico_Segre]

Hi Cosmin,

yes, investigating further would be nice. I'm working with 18Mpimages, which involve timings of ~600ms with IMAQ Read file and ~1200ms with your routine. File access time as well as array manipulation to recompose an U32 image, as well as for drawing can be subtracted out, and are not the main contribution to the processing time. I would be glad to share my test snippets. I tried to attach them here, but I didn't work, so I hijacked the original thread and attached them there. There would be also another contribution to compare with, which I downloaded from somewhere I can't recall. It has a main vi called "video client JPEG request". The possibility of decoding several images in parallel on different threads is also of my concern, so I think it is also legitimate to ask about reentrancy.

Enrico

[Enrico_Segre]

Ah, I refound it. Here: http://sine.ni.com/devzone/cda/epd/p/id/3314

But it wouldn't be a solution, it was reported in many places to leak memory: http://lavag.org/topic/4947-reading-the-jpeg-string-in-c/page__p__27615__hl__%2Bjpeg+%2Bstring__from...

[cosmin]

download the labjpeg7new.dll and jpeg7.dll they should be in the same folder. Use the same calling for labjpeg7new.dll. First it may run slower as labview needs to load the jpeg7.dll. if you want to avoid this, put a CIN with jpeg7.dll in a case structure that never runs.

[Enrico_Segre]

When I replace, in the the CLFN, the call to the function test() in labjpeg7.dll with that to the same function in labjpeg7new.dll, I get an "Error loading "...labjpeg7new.dll". The application has failed to start because its side-by-side configuration is incorrect". First time I remember having seen that with a dll in LV. Might be that the file is corrupt? Or perhaps an absolute reference to the location of jpeg7.dll?

[Enrico_Segre]

DependencyWalker found that I was missing a msvcr90d.dll, which I downloaded from the net and stored together with the previous dlls. It keeps giving me the side-by-side error though, both LV and DependencyWalker.

[cosmin]

ok, so I build it with VC2008 express edition and I forgot about the redistributable and manifest file. So I rebuid them with static linking. Take them again and test it. Sorry

[Enrico_Segre]

Definitely improved, thanks!

First of all the most recent labjpegnew.dll works.

Then, as for timing, my results are, for two different images of 18Mp, mean VI times measured by profile:

Old labjpeg7: 680-780ms for the test routine alone

New labjpegnew7: 110-190ms. That is about a factor 5 increase!

To that I have to add an overhead of some 390ms to unpack the 3xNXxNY image stream and cast it into a grayscale image. For the time being I couldn't find a fatster way to do it than in the VIs I have submitted, but I don't exclude there would be a better way.

[cosmin]

absolutelly, it can be an input to dll that tells to convert directly to grayscale. This is faster than conversion to 24bit colormap

[Enrico_Segre]

can it be done with your dll in the present form?

[cosmin]

I have to be on my computer and rebuild it

[cosmin]

Check attached labjpeg with output color option. In the archive there is a VI for testing. Check it, I don't have right now the time for documenting it.

[Enrico_Segre]

That's good! I've made some quick modifications and checked it again with my 18Mp images, now converting to an IMAQ U8 image. Clearly the routine itself takes somewhat longer to run, but all the overhead gymnastic is avoided. The bottom line is that the total time to cast to IMAQ is in the range 350-415ms on my system, about 150msec less than before.

I'll eventually study other output formats in detail in the next days. Good work!

[JSResearch]

Cosmin, I've tried using your code with this image, but it crashes LabView every single time.  Do you have any idea what I'm doing wrong? I've also added a shot of my block diagram.

[RMT]

Dear cosmin:

Could you release the Head file taht labjpeg7new.dll and jpeg7.dll used.

That can helpful to imprement the application.

Thank you very much.

[dadreamer]

For anyone interested in this here's a WinAPI method to convert an image stream into a common 32-bit RGB array. Doesn't require saving a stream into a temporary file.