11-08-2006 05:34 PM - edited 11-08-2006 05:34 PM
Hello,
I am building a LabVIEW (8.2) application that will be acting as a slave to a web server. Its primary function is to send graphics in text format (UTF8) over a socket. There are lovely functions already that will read and write PNG, BMP, and JPG. But the diagrams are locked and they do not expose the binary stream that is being read or written to file. I would very much like access to that binary stream directly.I have a workaround (see example program), in that I can write my image to a file, in this case a PNG file, and then immediately read that file as a binary stream. But this is inefficient--notice how the example program takes a half-second to run on just a tiny amount of data. And I understand that you don't want to expose your PNG encoding scheme to the world; But you wouldn't have to unlock the diagram, nor expose your algorithm, in order to output that binary stream.
So I know better than to ask for some function that I've just dreamed up, as if NI is there to accommodate my fancies. But in this case, I suspect the functionality is already there, it's just encapsulated in a locked diagram. I suspect that the full binary stream is there underneath that 'write to png file' function.
You wouldn’t have to build it into a revised version of
LabVIEW (although as a hardcore
I'm just surprised that it is not already a function. If you're wanting to nudge LabVIEW in the direction of being able to accommodate web serving functionality (which from a few recent whitepapers, I've gotten this feeling from NI), this would be a fundamental requirement; i.e., being able to serve up little graphics via binary (whatever encoding, UTF8, UTF7, doesn’t actually matter) over a socket (really just a string control, that’s what goes into the TCP and networking functions anyway). LabVIEW's 2D and 3D graphs, as well as the picture control along with its sundry helper functions, are hugely powerful. Why not let us use them to make the best interactive technical websites out there?
Unless of course you point out something obvious that I'm missing, in which case I'll be both delighted and embarrassed.
Example program
explanation: This shows the workaround that I mentioned. You’ll want to look at the file in the root
C:\ directory “Through_the_binary_blender.png”.
This will show that the binary stream I’ve extracted does indeed contain
the right data. You can open the new PNG file with your choice of image viewers.
Message Edited by Ben Phillips on 11-08-2006 05:36 PM
Message Edited by Ben Phillips on 11-08-2006 05:37 PM
11-08-2006 05:34 PM - edited 11-08-2006 05:34 PM
Message Edited by Ben Phillips on 11-08-2006 05:38 PM
11-10-2006 03:22 PM
11-17-2006 05:27 PM
Hi Ben,
Unfortunately, even if we gave you access to the block diagrams of the VIs that you requested you would not be able to create a binary output, because the heart of the VI is a C++ dll, which is internal to our organization and we cannot reveal that information.
Best regards,
11-17-2006 09:31 PM
My apprentice wrote a program, with my help.
See http://forums.ni.com/ni/board/message?board.id=170&message.id=150815#M150815
It reads images via HTTP from the net. It would make good sense for me to turn this datastream straight into an image, but no, I can't do it.
I have to write a file, then turn around and read the file.
It seems like a bad decision to inseparably marry the encoding / decoding part with the file reading/writing part.
But then, they didn't ask me.
Blog for (mostly LabVIEW) programmers: Tips And Tricks