Loading mat files in matlab created from octave

I have this .mat file created from octave, which contains structures. When I wanted to load the mat files from matlab, it shows an error. How to load these files?

>> y = load('murikhao.mat')
Error using load
Unable to read MAT-file murikhao.mat: not a binary MAT-file.
Try LOAD -ASCII to read as text.

adding '-ascii' parameter didnt help.

Answer 1

[Robert]

Really late reply, but I came across this issue today and wanted to post the solution. Try using the option -mat7-binary in your octave save command.

save -mat7-binary 'filename' 'var1' 'var2'

I'm using R2014a on my osx host and octave 3.8.1 on a linux vm.

[web]

Thanks a lot for this solution! It works perfectly

[Michael Jung]

Thanks all. This worked perfectly for me as well. R2016a on Ubuntu16.04 OS

[Juan Martin Farias]

This worked perfectly for me too. I am using R2021b in Windows 10

Thanks!

[Gordon Fox]

Fixed the problem for me too! I'm using R2020a.

Answer 2

[James Tursa]

If MATLAB can't load it, then I would guess that it was not written properly in Octave. Double check the way Octave is writing this file.

[Adib Zaman]

The same code works perfectly fine when I run it from matlab. Its just simple save command.

Also I can read the mat files generated from octave using octave with simple load command.

[James Tursa]

What you are saying is that MATLAB can load the mat files that it saves, and Octave can load the mat files that it saves, but MATLAB can't load the mat files that Octave saves. Again, I would suspect that the mat file written by Octave, alghough understandable to Octave, is in some way incompatible with the MATLAB mat file format. Can you look in the Octave SAVE options to see if there are different formats you can try? Maybe one of the different formats will be acceptable to MATLAB.

[kkyaj]

scipy has no trouble reading the octave files. this is something that mathworks should fix. if it takes less time to install octave or convert the mat-files using scipy than it does to re-process a large batch of files with the mat7-binary option, why bother continuing to use matlab?

[Stephen23]

"this is something that mathworks should fix"

Octave's default so-called .mat file format is not a binary .mat file at all, it is in fact a text file format that Octave developed for itself. This is explained in the Octave documentation: "Save the data in Octave’s text data format. (default)". This proprietary text format is not (and never has been) compatible with any of the publicly documented .mat binary file formats. Note that Octave does support reading/writing proper binary .mat files, so this issue only relates to their nonsensical decision to make a text file which is incompatible with MATLAB's own .mat operations the Octave default. You would have to ask the Octave developers why they made that decision.

So why should TMW "fix" Octave's bad design decision? Should MATLAB fix the bad design decisions of every other language too? Where does this stop?

[kkyaj]

"_this issue only relates to their nonsensical decision to make a text file which is incompatible with MATLAB_"

Is this to suggest that MATLAB is somehow fundamentally incapable of reading octave text files? Every other format I've thrown at Matlab seems to be readable (read "compatible") using some script or toolbar.

[Walter Roberson]

MATLAB's load() expects .mat files to be in one of MATLAB's .mat formats, unless you give the -ascii option at the time of the load() call. If you do give the -ascii option then the format must be the same as MATLAB's save -ascii format, which permits one line of % comments, after which must be a 2D array of blank separated numeric values -- which is not at all what Octave's text based .mat looks like.

It would be possible to write MATLAB code to read Octave's text-based .mat files -- though I do not know if the format for storing graphics or object-oriented objects is meaningfully compatible.

[Stephen23]

"Is this to suggest that MATLAB is somehow fundamentally incapable of reading octave text files?"

Not at all, I explained that Octave's proprietary text format is incompatible with MATLAB's optimized .mat operations, which I think is completely reasonable: TMW designed the .mat format, and those operators are designed to work with exactly that format.

Of course MATLAB's textfile importing tools can import the proprietary Octave text file format, and you could even write a little routine that parses the contents back into the correct variable classes (at least, as much as is reasonable for transferring data between two different applications that might support quite different classes, etc.).

"this is something that mathworks should fix"

To be honest this is very strange discussion. Consider that someone develops a spreadsheet tool (lets call it "Octcell") and decides to use the file extension .xls for their own Octcell mark-up text file: would we be surprised that Microsoft Excel does not handle the Octcell text files like its own binary .xls files, and throws an error? Who would we complain to: the Octcell designer who decided to use the already existing .xls file extension for a totally unrelated file format; to the Octcell users who don't read the documentation; or to Microsoft because of Octcell's incompatible textfile format? What happens when Octcell forks into one thousand derivative projects, each developing their own special textfile format... can all of those projects demand that Microsoft has to recognize their totally incompatible proprietary textfile formats as being exactly equivalent to its binary .xls files? Where does this end?

That sounds like a fun weekend project: write a word processor ("Octword") that saves its own special, essentially undocumented text file with a .doc file extension, upload Octword onto the web, and then complain to Microsoft that Word must be buggy because it does not load Octword's special .doc files. I wonder what their reply would be.

[kkyaj]

"proprietary octave text format"

i admit ignorance here and won't argue semantics, but i never thought of gnu projects as having proprietary components.

i do understand and accept your arguments here, although i still see no reason for matlab to include no support to octave *.mat files by overloading the 'load' function or including a '-octave' flag. i know that it would have saved me hours of work in the past.

[Stephen23]

" i know that it would have saved me hours of work in the past."

Octave's save operator can write a real .mat file, which thus avoids this whole problem entirely.

[Walter Roberson]

If the problem was that you didn't know why the load was failing then you would not have known to use a -octave flag. If you did know that file incompatibilities were the problem then you could have saved with one of the octave mat binary flags. So what it seems to be getting down to is that you would have been saved time if MATLAB had autodetected that the mat file was octave format and loaded it anyhow.

[kkyaj]

yes, an a priori solution is fine. i do try to use the mat7-binary option but occasionally forget, and use an otherwise compatible matlab script under octave. hours later, I end up with saved output that cannot be imported into matlab.

a post hoc solution is sometimes what is needed, and none has been offered.

[Walter Roberson]

Load the file in octave, save it in MATLAB binary format.

[Walter Roberson]

Octave

Built-in Variable: default_save_format

This variable specifies the default format for the save command. It should have one of the following values: "ascii", "binary", float-binary, or "mat-binary". The initial default save format is Octave's text format.

Answer 3

[kkyaj]

The default_save_format in octave is a nice feature which I did know existed. Thanks, Walter. That is helpful.

I believe that we agree the solution to "how can i load octave *.mat files not written in mat-binary format into matlab?" is that matlab will not do this natively.

One needs to externally load/resave using octave (with '-mat7-binary' flag) or scipy (with io.loadmat, io.savemat), which is to say that there is no matlab solution to this.

[Walter Roberson]

It is possible that someone has written code to import octave save format into MATLAB, but that functionality is not built into MATLAB.