File Loaders

A place to post questions and information about the availability, utility, and design of file loaders in Igor Pro.
If anyone uses or knows about Grass Instruments Polyview software (LabView based I think), perhaps you could help. Data acquired with this software is saved in binary format, but I've had to play with it quite a bit to get it to import into IGOR properly. Furthermore, only the data from certain dates works with these settings, whereas data from other dates imports as noise (e.g. 9/5/07 works, 9/25/07 does not). I normally use 3 channels at 6000 Hz and if I import these using:

GBLoadWave/A/V/T={16,2}/Y={0, 0.0001526}/S=216269/W=3/P=Path filename

it loads fine, making one wave for each channel, cutting off the first few seconds.

Importing these binary files (10-20 minutes of 6000 Hz recordings) is several minutes faster than exporting the data as a txt file from Polyview and importing as a general txt file into IGOR. If anyone has any suggestions or insights as to how I might clean up these binary file imports, I'd really appreciate it.

Ben Gallarda
UCSD Biology
Salk Institute
A hunch is that the skip value needs to be different for different files. I suspect that the file itself contains an offset to the start of the data so you would need to read the value for the /S flag from the file itself. If documentation of the file format is available, this should tell you how to determine where the data starts. If not you could try to reverse engineer it by loading a file as unsigned byte data, displaying it in a table as hexadecimal and then searching for 00034ccd (216269 in hex) in the file.

A less likely explanation is that the files have different endianness because they were saved on different platforms.
You were correct about the bytes skipped changing. The number of bytes to skip seems to be dependent on the number of channels recorded and the date. The date affects the bytes skipped depending on how many digits occupy the month and day: either 3, 4, or 5 (e.g. 9/1 has 3, 9/10 has 4, 10/10 has 5). I would be happy to pass on the particulars if anyone has the need, but there was nothing clever about solving the problem-I just tried different byte numbers until I hit info that was clearly not data. IGOR Pro was definitely the only way I could find to solve this problem.

Ben Gallarda
A recent email on the Igor Listserver asked about the ability to access OriginLab OPJ file formats within Igor Pro.

FWIW, in spite of discussion about OriginLab wishing it to become a standard given here, the Origin OPJ format is a closed, proprietary one. In addition, the free OriginViewer and associated dll files only work on Windows systems (with some indication they may not even work on Intel Macs under Parallels or equivalent).

Therefore, any options to access OPJ files from Igor Pro will likely have to be developed by a user who can do the necessary reverse engineering of the file format.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
jjweimer wrote:

FWIW, in spite of discussion about OriginLab wishing it to become a standard given here, the Origin OPJ format is a closed, proprietary one.


That article you link to there has the rather intriguing passage, "When I asked whether other applications would be allowed to add OPJ to their export or File Save As menus using Orglab, I was told 'we would love that'". That statement would seem to be completely at odds with the license that comes with the Orglab installation, that says, "The Orglab Package files, however, may not be used in an application that competes with OriginLab Corporation's own software products Origin, OriginPro, or any of its modules.".


John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
johnweeks wrote:

That article you link to there has the rather intriguing passage, "When I asked whether other applications would be allowed to add OPJ to their export or File Save As menus using Orglab, I was told 'we would love that'". That statement would seem to be completely at odds ...


Exactly this contradiction prompted me to write emails both to OriginLab and the journal. The former resulted in a reply from OriginLab that, in conclusion, asked me to consider sharing any developments that I might make in coding for OPJ with the Origin community of users (but offered no help to open the file format). The latter resulted in an exceptional nice letter from the author of the article showing that serious consideration was given to the potential misleading tone of the article by the author and by the editor of the journal himself.

BTW, expect in the coming year an on-line review of Igor Pro 6 in Scientific-Computing World (I put in a good word or two already ;-) )

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH
jjweimer wrote:

Exactly this contradiction prompted me to write emails both to OriginLab and the journal. The former resulted in a reply from OriginLab that, in conclusion, asked me to consider sharing any developments that I might make in coding for OPJ with the Origin community of users (but offered no help to open the file format). The latter resulted in an exceptional nice letter from the author of the article showing that serious consideration was given to the potential misleading tone of the article by the author and by the editor of the journal himself.

I e-mailed the editors as well. So they've had an earful, er, monitor-full by now!
jjweimer wrote:

BTW, expect in the coming year an on-line review of Igor Pro 6 in Scientific-Computing World (I put in a good word or two already ;-) )

Excellent! Thank you.

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com