Write Gif File.vi (L 8.5)

[waldemar.hersacher]

For some versions LV has the "Write xx File.vi" (xx = png, jpeg, bmp). These VIs work fine in development and runtime environment.

In LV 8.5 there is a similar VI in vi.lib\picture\gif.llb named "Write GIF File.vi". This VI seems so work fine in development environment but not in an build application.

Why does this VI not work in an application? Does anyone know if this will work with the LV 8.5.1 Version?

[PhillipBrooks]

Maybe this is a historical, relating to the GIF patent issue?

It appears that the patent is no longer an issue, so maybe it would make sense to add this feature into a built app...


Message Edited by Phillip Brooks on 04-11-2008 07:08 AM

[waldemar.hersacher]

I will make a product suggestion for it. Maybe they can put it in the next version.

Please read this http://forums.ni.com/ni/board/message?board.id=130&thread.id=4420 thread too.

[smercurio_fc]

<Deleted>

Posted in wrong thread.


Message Edited by smercurio_fc on 04-14-2008 09:30 AM

[zou]

Image Toolbox (http://www.geocities.com/gzou999/index.html) can read / write gif.

[rolfk]

---

@Phillip Brooks wrote:
Maybe this is a historical, relating to the GIF patent issue?

It appears that the patent is no longer an issue, so maybe it would make sense to add this feature into a built app...


Message Edited by Phillip Brooks on 04-11-2008 07:08 AM

---

No it can't be anything with the patent. The VI is there since LabVIEW 7.0 and seems to callback into LabVIEW hence the password protection. 7.0 would have been early enough to conflict with the GIF patent but that patent is specifically an issue with the LZW compression algorithme used for compressed GIFs, while the help text for this VI specifically says that it will only save uncompressed VIs, so without LZW algorithme.

Someone at NI decided once that the GIF export functionality was not needed in the runtime system to save executable size, and that hasn't been reviewed since it seems. This also is probably the reason why that function still does not appear in the menu palette.

So your product suggestion is the way to go here.

Rolf Kalbermatter

[Vijay Ramalingam]

Double click the dll file, now it will display the VI. Now double click that and the VI will open. Now save the VI in your desktop, or under your working directory. Now include this saved VI into your main program. Your run-time should work like a charm.

Good Luck!
VJ.

[rolfk]

---

@Vijay Ramalingam wrote:
Double click the dll file, now it will display the VI. Now double click that and the VI will open. Now save the VI in your desktop, or under your working directory. Now include this saved VI into your main program. Your run-time should work like a charm.

Good Luck!
VJ.

---

I'm pretty sure you missed here something. vi.lib/picture/gif.llb/Write GIF File.vi seems to not call a DLL but instead calls directly into LabVIEW.exe most probably using the exported function LVImageToGIF(). No DLL involved there. At least it did so in earlier LabVIEW versions.

And these exports (together with the other LVImageToxxx() functions are not present in lvrt.dll., which is the LabVIEW runtime kernel for build applications. the other image export functions however do not make use of those LVImageToxxx functions anymore (they did in LabVIEw 5 or 6) but instead call into the according lvpng, lvjpg, etc DLLs directly, which can and will be copied by the Application Builder into the build app. No lvgif.dll exists however since that code is directly embedded into the LabVIEW development system.

Correction: I just checked the lvrt.dll export table in LabVIEW 8.5 and those functions seem to be there. So there is probably a different issue. I can think of two possibilities:

1) if the entire build app is broken when including that VI, most likely the Call Library Node in that diagram links to LabVIEW.exe explicitedly instead of using the special keyword LabVIEW, which would take care of referencing the rigth LabVIEW kernel module automatically.

2) If the app is not broken but the VI in question just fails to do anything, the according function in lvrt.dll is stubbed out to not do anything at all in the runtime.

Case 1) could be solved with access to the diagram. Case 2 can only be fixed by NI in a future LabVIEW version.

Rolf Kalbermatter

Message Edited by rolfk on 07-29-2008 08:21 AM