reading MAT files

[StefanKarpinski]

This ability would be tremendously useful for Matlab users who have data already in MAT form.

[pao]

For v7.3 files, they are in an HDF5 format. We might also look into cribbing notes from SciPy.

[StefanKarpinski]

I was not aware it was HDF5. That's nice, actually, although it is a massively over-engineered format.

[pao]

Well, that only buys you compatibility with v7.3 files, which I'm still not sure they've made the default. It's much faster as you save larger files, though, and it's your only option for 2+ GB files.

I will also point out that the ability to read/save MATLAB files is important for dealing with customers who use MATLAB, or who might require it as an output format. We've dealt with both.

[ViralBShah]

We can use libmatio that octave uses.

[ViralBShah]

http://matio.sourceforge.net/

[pao]

That looks like it can handle both file types as long as HDF5 support is available elsewhere and has a pretty straightforward C interface.

[ViralBShah]

Right - we can quickly get matio support. The need had not come up before, but I always figured we could do it at a moment's notice if necessary. I had used it a few years back, and seems like development has continued.

-viral

On 06-May-2012, at 7:19 PM, pao wrote:

That looks like it can handle both file types as long as HDF5 support is available elsewhere and has a pretty straightforward C interface.

---

Reply to this email directly or view it on GitHub:
#805 (comment)

[JeffBezanson]

See https://github.com/timholy/julia_hdf5

[simonster]

For older MAT files, https://github.com/simonster/MAT.jl

[JeffBezanson]

Cool, thanks! Would be good to list it here: https://github.com/JuliaLang/METADATA.jl

[timholy]

Very nice, Simon!

[ViralBShah]

This is awesome!

[staticfloat]

Probably the module I'm going to use the most in the foreseeable future. Thank you very much, @simonster. :)

[timholy]

@simonster, do you have any interest in synchronizing with the interface for the HDF5 MatIO module? That way we could provide a single interface supporting multiple versions of *.mat files, and users wouldn't need to know which version a given file is saved in.

There are really two ways we could go about doing that: either you could extend your functions to support some of the operations in the HDF5 module (e.g., providing separate open, close, and read(mfile, "myvariable") functions), or I could provide a wrapper for the HDF5 functionality that mimics your interface. As you know well, the code in the HDF5 module checks to see what type of *.mat file it is; we could use that as the basis for an overall function that detects the type and then reads it either as a v7.3 file or an older file type. I guess I have a slight preference for asking you to move closer to the MatIO-style interface, for the particular reason that it will be more efficient if you just want to extract a single variable from the file (imagine you have a file with one huge variable and a few teeny variables, and you're only interested in the teeny ones). But I can go either way.

Out of curiosity, what does version == 0x0100 correspond to? Does this support -v4, -v6, and -v7? Also, are you intending to provide write support? Or is that not really necessary since it's in MatIO?