Alternative Image Data to PNG Conversion VI

[smarlow]

Hello:  I am wondering if anyone has developed a VI to convert image data from the "Get Image" method to a PNG format string.  I do not need compression or filtering and will only store RGB (24-bit), or paletted 8-bit (optionally, but not required).  The trouble I am having is that the "write PNG file" and "LV Image to PNG" VI's are not supported in real-time.  The BMP file writer works, but is not really a web format.  I suppose I could write one, but I am under the gun on a project, and don't want to reinvent the wheel.  Thanks.

[mje]

Somewhere in the web palette there's a pair of VIs that can swap between the cluster image format and a PNG string, you could potentially just do the disk I/O yourself. Do those work on RT?

[mje]

http://zone.ni.com/reference/en-XX/help/371361K-01/lvcomm/ws_imagetopng/

[hooovahh]

http://zone.ni.com/reference/en-XX/help/371361K-01/lvcomm/ws_imagetopng/

I love that little VI.  It is probably the easiest way to convert a System.Graphics PictureBox image to a LabVIEW image.  You can invoke the save on the PictureBox Image saving it to a stream of bytes instead of a file.  If you set the file format to PNG you can then use that string with the PNG Data to LV Image VI to get it back.  Some things LabVIEW is better at as far as 2D picture controls, and some times the system PictureBox is better so this enables you to go from one to the other without having to perform any I/O operations on the disk.

 

EDIT: Here is an example of reading a file with .Net, scaling it, saving it to a PNG stream, and then using PNG to LV data to draw the resized image again.

 

http://forums.ni.com/t5/LabVIEW/Net-image-resize-how-to-convert-to-format-labview-can-use/m-p/2199022#M704093

[smarlow]

Unfortunately, the LV Image to/from PNG string VIs do not work in RT.  The "LV Image to PNG Data.vi"  VI returns error 1043.  I suspect it is calling an unsupported invoke node somewhere.  Like the write PNG file VI, the diagram is locked down, so you can't make any attempt to make it RT friendly.

[mje]

Darn. Probably just offloads to a third party library with no support for vxWorks-- I seem to remember someone from NI saying as much for some of the other image VIs. Hopefully it is at least available on mac/linux...

[hooovahh]

Unfortunately, the LV Image to/from PNG string VIs do not work in RT.  The "LV Image to PNG Data.vi"  VI returns error 1043.  I suspect it is calling an unsupported invoke node somewhere.  Like the write PNG file VI, the diagram is locked down, so you can't make any attempt to make it RT friendly.

As usual a unlocked block diagram won't help.  In most cases when a block diagram is locked it is for one of two reasons.  The code is horrendous and was thrown together quickly for a uncommon function that NI doesn't intend on anyone but them using.  Or (and this is the majority) the VI simply calls a Library or DLL function.  In these cases I'm guessing NI just doesn't want you to know what the data type to the library calls are.  In this case it is the second reason.

 

 

But I'm guessing you can replicate the function by writing the file to disk and then re-reading it as binary.

 

EDIT: Okay it was simple so I just wrote it.  Not sure if it actually works.

Image to PNG Data File Method.vi

[smarlow]

As I stated before, the "write PNG file.vi" and "LV Image to PNG Data.vi" VI's are not supported in RT.   I bit the bullet and wrote a VI using the OpenG library ZLIB Deflate VI and the MECC CRC32 vi.  Interestingly, the OpenG external library deploys and runs on the RTOS.  The ZLIB CRC32 vi produced a CRC value incompatible with the PNG spec for some reason.  I was careful to init the crc input register will all 1's per the PNG spec, but the value produced differed from that produced by the  "write PNG file" VI, so I switched to the MECC CRC32, which works.  Perhap someone who has the time can figure out why the ZLIB CRC32 vi is not suitable for the PNG spec.  The IMG_write_PNG.vi VI only supports 24-bit images. The array reshaping and insertion of a 0 column was used to insert the Filter Type byte at the beginning of each scan line.  Here is the code:

 

 

Here is a slightly updated version with some added U32 converts for the IHDR width and height (per the PNG spec) and a note about the filter type bytes:

 

 

Edited March 11, 2014 by smarlow

[hooovahh]

Wow very cool.  I'm sorry I missed you saying that the Write PNG file.vi didn't work on RT.  In either case congratulations on finding a solution.

[Darin]

Right now my experience suggests that you are using a method which depending on the image is either marginally better or marginally worse than simply using the bitmap format.  The sub and up filters are both very easy to implement and often quite effective at increasing the compression.

[ShaunR]

Interestingly, the OpenG external library deploys and runs on the RTOS.  

 

Of course - Rolf wrote it.

 

Zlib uses a "running" Adler32. See here for an good explanation of the difference.

[smarlow]

Right now my experience suggests that you are using a method which depending on the image is either marginally better or marginally worse than simply using the bitmap format.  The sub and up filters are both very easy to implement and often quite effective at increasing the compression.

 

Not even close.  A white-background X-Y graph I designed compresses from 790K to 6K using the default compression level of 6 of the ZLIB routine with no filtering.  A BMP of the exact same graph is 866K.   It's true the compression is highly dependent on the image data, but simple graphs of few colors is all I am using it for.

[Darin]

Ah.  I see, those will compress decently.  I typically use PNG for images and I do not see good compression with no filtering.  Line art such as graphs I export to SVG or EPS.

[smarlow]

Ah.  I see, those will compress decently.  I typically use PNG for images and I do not see good compression with no filtering.  Line art such as graphs I export to SVG or EPS.

 

SVG is great.  I wish I could get that format for my LV controls.

Of course - Rolf wrote it.

 

Zlib uses a "running" Adler32. See here for an good explanation of the difference.

 

Thanks for the info!

Edited March 12, 2014 by smarlow

[Mads]

On 3/10/2014 at 11:37 PM, smarlow said:

Hello:  I am wondering if anyone has developed a VI to convert image data from the "Get Image" method to a PNG format string.  I do not need compression or filtering and will only store RGB (24-bit), or paletted 8-bit (optionally, but not required).  The trouble I am having is that the "write PNG file" and "LV Image to PNG" VI's are not supported in real-time.  The BMP file writer works, but is not really a web format.  I suppose I could write one, but I am under the gun on a project, and don't want to reinvent the wheel.  Thanks.

Thanks for the PNG file writing VI. I could not get the snippet to work (lost its embedded code?) so I recreated it (attached, backsaved to LV2015 format), but then I could not really figure out how you got the Get Image invoke node to work on RT...unless you were not running it as a built application (it works from the IDE only)?

In fact it seems a rather big problem to generate graph images directly on an RT target (I'm using cRIO-9063 with Linux RT), has anyone done that with a built application? Using the Picture functions (Plot Multi XY) is a dead end as well, as the Picture to Pixmap function is not supported on RT either....

Right now I have an application that reports alarm conditions to customers by sending an alarm description and the trend at the time of the event as a log file, but some of the users want to view the trends immediately by having them as images in the e-mail. I can do that easily when Get Image works, but not from my RT targets...Has anyone done that, generated graph images on an RT target without Get Image-support? Perhaps there is a CSV to graph image solution somewhere?

I could probably find a cloud based data historian somewhere that is able to receive data logs by e-mail (?) or FTP, and then have the users use that web site instead to view the data (any good suggestions for such a service?). Continuously streaming individual data points to such a historian (which  seems more of the norm) is less ideal as the data link we have available is not that good (sending small compressed emails every now and then is OK).

Write PNG on LVRT.zip

Edited November 13, 2018 by Mads

[smarlow]

 

On 11/13/2018 at 2:26 AM, Mads said:

Thanks for the PNG file writing VI. I could not get the snippet to work (lost its embedded code?) so I recreated it (attached, backsaved to LV2015 format), but then I could not really figure out how you got the Get Image invoke node to work on RT...unless you were not running it as a built application (it works from the IDE only)?

In fact it seems a rather big problem to generate graph images directly on an RT target (I'm using cRIO-9063 with Linux RT), has anyone done that with a built application? Using the Picture functions (Plot Multi XY) is a dead end as well, as the Picture to Pixmap function is not supported on RT either....

Right now I have an application that reports alarm conditions to customers by sending an alarm description and the trend at the time of the event as a log file, but some of the users want to view the trends immediately by having them as images in the e-mail. I can do that easily when Get Image works, but not from my RT targets...Has anyone done that, generated graph images on an RT target without Get Image-support? Perhaps there is a CSV to graph image solution somewhere?

I could probably find a cloud based data historian somewhere that is able to receive data logs by e-mail (?) or FTP, and then have the users use that web site instead to view the data (any good suggestions for such a service?). Continuously streaming individual data points to such a historian (which  seems more of the norm) is less ideal as the data link we have available is not that good (sending small compressed emails every now and then is OK).

Write PNG on LVRT.zip

You are correct that an RT target alone cannot execute the Get Image invoke node.  Interestingly, it will execute if you are running the VI on the RT target from the host LabVIEW IDE.  The Get Image node actually runs on the host computer (even though it is on the diagram of the VI "running" on the RT target) and sends the resulting data to the RT target.  As soon as you compile the RT VI and try to run it alone on the target, it will not run.  This must be that because in order to see a "front panel" of a VI running on an RT target, the FP operations must be transferred to and executed on the host.

[smarlow]

On 11/13/2018 at 2:26 AM, Mads said:

I can do that easily when Get Image works, but not from my RT targets...Has anyone done that, generated graph images on an RT target without Get Image-support? Perhaps there is a CSV to graph image solution somewhere?


Unfortunately, the Picture Functions VIs are eliminated from the RT palette, so you can't draw a graph if you wanted to.  What you could do is to draw a graph in Inkscape as an SVG file (which is just XML), with the plot as a multi-point line and replace the points in the plot line with scaled data points using the XML editing functions.  I can walk you through the process if you want, since I used to develop WebPanel (now defunct) a long time ago.

See webpanel here

Edited December 5, 2018 by smarlow
added link to webpanel

[JKSH]

On 11/13/2018 at 3:26 PM, Mads said:

Has anyone done that, generated graph images on an RT target without Get Image-support? Perhaps there is a CSV to graph image solution somewhere?

You could save the data to file and then use the System Exec VI to run your choice of Linux chart generation tools like gnuplot (a command-line application) or Matplotlib (a Python library).