Read .mat file in android?

Is it possible to read .mat file in android ? how should I convert .mat file to java readable format?

Answer 1

[Kaustubha Govind]

You can write C code using the MAT-file libraries to read MAT-files outside of MATLAB - see Read and Write MATLAB MAT-Files in C/C++ and Fortran. You can then call this C code from Android/Java using JNI.

Alternately, you could use MATLAB to load the MAT-files and write the data inside them into a text-file (using one of the text-file related functions). You should be able to find Java file I/O functions that can read these text files. (Full disclosure, I am not a Java programmer, so can't give specific advice)

Answer 2

[Eric]

Here's another possibility: when saving the MAT file, use the -v7.3 option. Then the MAT file is actually an HDF5 file. You can use tools from the HDF Group to work with these files natively in Java and not have to resort to C/C++. See

http://www.hdfgroup.org/hdf-java-html/

http://www.hdfgroup.org/hdf-java-html/JNI/jhi5/index.html

Good luck,

Eric

[Walter Roberson]

Someone posted recently pointing out that it is a *modified* HDF5 format, and indicating that Support had told them that the HDF tools were not supported for .mat files.

[Eric]

Walter: Apparently you're right. I tried opening an "HDF5" MAT-file with HDFView and while the variable names are right, the values look like garbage. I wonder why the Mathworks bothers to call these "HDF5" files. I suppose at some low-level they share the same hierarchical format, but it's a bit misleading to call them HDF5 files if the standard HDF5 file utilities cannot be used on them.

I will not delete my answer as there's meaningful information in your comment.

-Eric

[Malcolm Lidierth]

@Aida

For Android, I do not know, but Octave, Python, SciLab, & R can all load at least pre-7.3 MAT-files so you may be able to find an open-source library you can adapt there.

@Walter

Possibly http://www.mathworks.com/matlabcentral/answers/15521-matlab-function-save-and-v7-3.

For R2012a, the MATLAB docs describe v7.3 as "an HDF5 based format" not "an HDF5 format". The "based" caveat was also present in TMW docs when v7.3 was introduced and for some years afterwards.

@Eric

Interesting. I have not encountered an HDFView unreadable 7.3 file. My assumption had been that TMW would only use a custom binary area which (I recall) HDF5 supports without breaking HDF5-compatibility. But "HDF5-based" could mean pretty much anything.

[Eric]

@Malcolm

You're right, they do caveat it as "HDF5 based", though I would generally read that as saying it's an HDF5 file. I just wonder why they bother mentioning that it's "HDF5 based" if you can't use standard HDF5 tools with them. Why not just leave it at "Variables can exceed 2GB"? The fact that the format is "HDF5 based" is of no value to the user if standard HDF5 tools cannot be used.

On a separate topic, I just noticed that Matlab -v7 MAT files "are compressed and use Unicode". Why the heck can't Matlab read Unicode text files then? Of all the tools on my machine that read text files (Notepad, Wordpad, Word, Excel, Visual Studio, jEdit, and FRED), Matlab is the only one that doesn't know what to do with a Unicode text file. This bugs me to no end.

[Walter Roberson]

fopen() and fread() allow you to specify particular unicode; if you don't do that, then MATLAB will examine the byte order marks (BOM) to determine which encoding you are using, defaulting to UTF-8 .

In theory it should only do this if you specify that you are working with a text file (e.g., 'rt' instead of 'r'), but it doesn't say it doesn't do this for binary. It is known that all of the major data import tools (e.g., textscan) handle unicode even for files opened without the 't' flag.

[Walter Roberson]

Okay, fread() doesn't allow you to specify unicode. fread() allows you to specify the source precision as 'char', the size of which "Depends on the encoding scheme associated with the file."

See for example http://www.mathworks.com/matlabcentral/answers/6347-arabic-document and note that the problem in that question was that the characters had been double-encoded, so along the way that Question shows reading unicode normally and also shows forcing a particular unicode interpretation of what was read in.

[Malcolm Lidierth]

At least they put the "based" back in the docs: which is slightly better than leaving us to spot that "an HDF5 format" might not be the same as "the HDF5 format". Perhaps "a proprietary and undocumented format based on HDF5" would be clearer still (if that is what it is). Do you recall the code needed to generate an HDFView-unreadable v7.3 file.

[Eric]

I'm wondering now if I actually previously selected a non-HDF5 MAT file for opening in HDFView. The ones I try opening now work fine.

Furthermore, I've been able to save data with the -v7.3 switch and read values back in using h5read(). Of course that's still in Matlab and perhaps h5read() is smart enough to know that it's a "modified" HDF5 file.

So I changed the extension of the file from MAT to h5. Mathematica's HDF5 import tool cannot open the file.

So interestingly enough, Matlab and HDFView 2.6.1 can both read values from a MAT file saved with -v7.3. Mathematica apparently cannot. Whether or not Java tools from the HDF Group (which makes HDFView) is perhaps still an open question.

[Malcolm Lidierth]

@Eric

h5read is a high-level MATLAB specific API but if HDFView handles the file OK there would seem to be no problem at the MATLAB end.

Plainly, generic HDF5 functions can not be expected to fully interpret the MATLAB-specific contents of a v7.3 file e.g. MATLAB objects, function-handles etc.

My initial support request related to using a low-level MATLAB HDF5 API function on a v7.3 file, which should, given the file contents, have returned an error code but instead threw an error and terminated.

For my money, v6 is by far the best MAT-file format and TMW should update that to include unicode and 64 bit - implementing compression on the data - not the metadata as well - as a user-selectable option.