Is FTP faster than NSV sending images from VBAI?

We love Vision Builder for Automated Inspection (VBAI). We often run VBAI on real time targets and there is usually a PC available to act as the HMI. It is always useful to display result images from VBAI on the HMI, and that leaves us with the issue of transferring images. VBAI offers a few different methods to do that.

1. VBAI API from LabVIEW
   Pro:  Allows very specific selection of image to display.
   Con: Requires dedicated connection to VBAI engine. Creates a strong dependency between the LabVIEW code and Inspection configuration. Not event based.
2. Network Shared Variables
   Pro: They mostly work.
   Con: They are terribly slow, and they are documented to "use disk operations" on the RT side, and that sounds scary. They are evil. Not event based.
3. FTP
   Pro: Has the ability to "run in background". Might be faster than #2 (NSV)?
   Con: Requires FTP server / dealing with files.

With no ability to deal with the 'Cons' on #1 and #2, I decided to investigate #3. What if we had a LabVIEW FTP server that we could customize to keep the image data in RAM instead of writing it to disk? Would that be faster? It could also give us an event based solution since VBAI will send a STOR command each time it sends a new image, and our custom server could send a message to our HMI process when that happens.

Here is where I have a challenge. The server can build a string that contains a PNG image. If we want the image to come with its non-destructive overlay, we can tell VBAI to send it including the vision data. I now have a string with the image and vision data. If I write that string to disk and use "IMAQ ReadFile 2.vi" it will load up the image and everything is fine, but it requires that write to disk / read from disk operation to happen every time. Perhaps that is not so terrible, but it feels dirty if the image is not something I want to save.

There is "PNG Data to LV Image.vi" that will work for getting the image into a Pixmap, but we lose the vision data. The "IMAQ ReadFile 2.vi" function only accepts a file path and not a string. It would be great if it was decomposed into a read-from-file and then a decode function. The alternative is to hack around on the chuck of the string that contains the vision data, but that is still undocumented and therefore risky correct?

Any help or insights are appreciated.

Thanks!