GIF file import

[richjoh]

A have a problem correctly interpreting GIF file characters from an instrument. Any ideas on correctly interpreting a GIF file from an instrument. I'm stuck with the format, its what the instrument supports.

It appears that MS Windows platform, labview text control interpretation of GIF characters, like \s, \0, \FF, is different from the Agilent E4404B Spec An. I have no problem fetching the file, but characters are being changed (interpreted) whenever I use a labview text box (i.e. an ascii string control, I really need a character control, or some work around).

Attached is a good GIF from the instrument and the bad imported GIF.

[richjoh]

Turn on show \xx format display and I can see the problem. GIF file uses \00 for space that labview interprets as \s. My bad file replaces all \s (in labview text ctrl) with \00 but the catch is some \s in the file are legitimate. A mass replace of characters won't work.

Any work around for this?

[Darin.K]

What is the sequence of operations you are using to go from a GIF file on the SA to text indicator on the LV VI?

[smercurio_fc]

http://forums.ni.com/t5/LabVIEW/How-to-to-read-write-GIf-files-not-animated/m-p/789934/highlight/tru...

That thread links to a post by Mike S in which he provided a small library for reading GIF files.

[Darin.K]

Unless I am missing something here, the issue is not with the GIF files per se.  What is happening is that somewhere along the lines the file is being interpreted as text and the nulls (x00) are being replaced with spaces (x20).  You can recreate this by taking the good GIF file, changing the extension to .txt, opening in Notepad, saving, then renaming back to GIF.  You will see that it is no longer a valid GIF and if you examine the file in LV or a hex editor you will see all of the spaces.

LV does not do this, it may cause trouble if you read a binary file as txt with the convert EOL option selected, but that is about it.  Something happens to the file along the way from the instrument to LV.  That is why I am curious to know how he fetches the file from the analyzer and gets it into LV.

[richjoh]

I took the NI driver for E4404B GPIB and convert the GPIB to serial loop (since the initial developer work was serial). Here's a pic of the loop, LV2010. Fetching the data work just fine. My VI reworked for serial attached. (removed not the VI that fetched but the one that fetch data points...will correct soon

[richjoh]

OK, here's the VI that fetches the plot. Ignore the one pic above (that pic I'm fetching the data points and this pic I query for the GIF file). This just popped into my head, I'm now wondering if fetching the file from a floppy to Windows XP is an issue.

[Darin.K]

That makes more sense.  I have a few GIF files that I have transferred from a similar instrument using a floppy disk.  I fought a similar battle years ago on an older instrument (I think it used JPEGs), I'll test to see if I won or not since I forget.

To get this straight:  the good GIF came from a floppy transfer and the bad one came from copying from the instrument to the PC, correct?  I have only a passing familiarity with that family of SA, so it could be that the DATA? query will only transfer files in ascii format and is doing the null to space conversion.

[richjoh]

---

Darin .K wrote:

"the good GIF came from a floppy transfer and the bad one came from copying from the instrument to the PC, correct?"

so it could be that the DATA? query will only transfer files in ascii format and is doing the null to space conversion.

---

Correct, the bad file come from the instrument query (serial communication), good from floppy transfer. The file query I guess would be no character conversion yet this is happening somewhere in the chain of events.

[ben64 · Accepted solution]

Somebody have created a vi called VISA Read Binary Block Data to File to save GIF to file. Here is a modified version I use to save screenshot from a E4440A spaectrum Analyzer.

Ben64