Add function to convert string to image

[BruceAmmons]

Currently in IMAQ Vision, there is a function to convert an image to a standard formatted string (JPEG, PNG, etc.).  The contents of the string is exactly the same as the data that is normally written to a file.  This is a great function to compress an image and send it over FTP, etc.

The problem is that there is no inverse function available - you can't convert the string directly to an image.  The only way to do it is to save the string to a file, then read it as an image, which slows down the process significantly.

I repeatedly see the need for this function.  People receive strings from other devices or PCs and want to display them as images.

There are functions to flatten images to/from strings, but they are limited in their scope (JPEG and PNG only, I believe) and they include the image name and other information in the string.  The format is proprietary and can't be read by other programming languages (yes, some people still program in languages other than LabVIEW).  It is also difficult when you want to unflatten a string and store it in an image with a different name than it was stored with.

Bruce

[Update] Part of this idea for the PNG format was implemented for LabVIEW 2013. Please see this post for details.

[BruceAmmons]

A small step in the right direction.  Just PNG format, and not easy to convert to IMAQ Vision format.  I still would like to see this for multiple formats into IMAQ Vision format.  I still don't see why it would take more than a few hours to make the change and check it.  Just start with the Read Image from File, and read from the string instead of a file.

Bruce

[AristosQueue (NI)]

Bruce: Yes. We are not closing this idea. It remains open because of the other formats requested. I just wanted to update it for those who came looking for such an idea.

[AristosQueue (NI)]

> I still don't see why it would take more than a few hours to make the change and check it.

> Just start with the Read Image from File, and read from the string instead of a file.

We call out to third-party DLLs to read the JPG data. Those APIs take a path. To the best of my knowledge (and I may be wrong), we don't have any entry points that take a string. We would need to find a new implementation of the JPG libraries. It would be a substantial piece of someone's time to build such VIs.

[BruceAmmons]

Okay, at least I understand why it hasn't been done.  That is more work than I expected.  I still would like to have the function, though.  You can't get source code to a JPEG reader?

Bruce

[AristosQueue (NI)]

> You can't get source code to a JPEG reader?

I wish it were so simple. 🙂

We would need to find a JPEG library that works on all of our platforms, make sure it is appropriately licensed for redistribution, update our build process to compile the DLL (unless it comes already compiled for all the targets), wrap it in VIs, build a test suite for it, design an icon for it, update the palettes, add documentation, and put it through localization into all the foreign languages. Honestly, on the spectrum of "things customers can solve for themselves" and "things only NI can do to improve LabVIEW", this is much closer to the former side than the latter, and that is going to push down its priority. Your task is much simpler: find an open-source DLL that does what you want and use the Call Library Node to invoke it (possibly writing a small bit of C code to wrap it for LV data types).

Ideas like this stay open because every once in a while, we notice that we can get one for cheap -- like someone has to write these VIs anyway for some toolkit, so let's put it into core -- or because NI decides to make a push in some area and we grab a group of related VIs and actually kick them up in priority.

[QFang]

I personally prefer working with PNG's anyway since jpg and graphs / data don't mix to well.. I don't like the compression artefacts.. I guess for completeness it would be nice to have these other formats as well.

[Darin.K]

I have LV code to display the viewfinder image from certain still cameras.  This is sent via a JPG stream from the camera.  With a fully G JPEG decoder I get about 0.5 fps (image size 320x240).  Using some LV math libraries (in C of course) I can get up to about 5 fps.  Using the Save to file/read file method I get ~15-20 fps.  Using my C-based JPG string decoder I could get close to 800 fps if my camera were so inclined.  I can even do scaling+decoding at once which is very nice.  So yes, the performance gains are significant.

I have never understood why all of these image VIs were file based to begin with.  I have always had a harder time dealing with the file api's, strings have always been easier.  Once I have my string-based encoder/decoder working it is easy peasy to add the file versions.

[muks]

Great function added in 2013. Time to explore!!!!

[muks]

I understand just the png is  being added but should the status be something like "in develoment"?

[AristosQueue (NI)]

muks: No. The PNG was added in 2013, but there are no plans to work on the rest of this idea.