[DB Toolbox] Using a DB enables interconversion between fig and binary, but w/out it, no

Hi! (Note: the role played by the Database Toolbox herein may be a red herring--indeed, I hope it is.)

I needed Matlab to put a figure in an SQL Server DB and then retrieve it such that it is still a Matlab figure; using <http://www.mathworks.com/support/solutions/en/data/1-1BYF0/index.html?product=DB&solution=1-1BYF0> and some trial-and-error, I figured out how to do this by hgsave-ing the figure, then freading-ing it back in using '*uint8' mode, and pushing this result into the varbinary(max)-typed target field in my DB; then, to recover the fig from querying that field, I found I had to fwrite that query result to a file using 'int8' mode, then hgload that file. That all works wonderfully, so main mission accomplished.

So, the next thing I did was to code all this up, EXCEPT for the DB functions, in two functions, fig2bin and bin2fig; here they are (with a bunch of error-handling code removed for brevity):

function bin = fig2bin(fig, name)
  % Converts a Matlab figure into a database-pushable binary "string"
    hgsave(fig, name);
    b = fopen([name '.fig'], 'r');
    bin = fread(b, inf, '*uint8');
    fclose(b);
    system(['del ' name '.fig']);

function fig = bin2fig(bin, name)
  % Converts an int8 (binary) array into a Matlab figure
    b = fopen([name '.fig'], 'w');
    fwrite(b, bin, 'int8');
    fclose(b);
    fig = hgload([name '.fig']);
    system(['del ' name '.fig']);

Now these work great--just as they did when I used their contents interactively--when the output of the first is "filtered" through the DB steps, i.e., pushed into the varbinary field in my DB, queried back, and then that result fed into the second function. However, if I omit the DB steps, i.e., just try to use the output of the former as the input to the latter, I get the same error I got many times while trying to figure out how to do this in the first place, namely "Error using load Unable to read MAT-file. File may be corrupt." Since reading using uint8 in fig2bin but writing using int8 in bin2fig was the solution w/ the DB steps included, I tried using those as casts at logical places in the chain, but that didn't fix the problem.

I'd really like to have the option of using these functions w/out having to write to and read from a DB in the middle, and I don't understand why that would be so crucial, so if anyone has any ideas as to what's going on, please share.

Thanks in advance.

Answer 1

[Walter Roberson]

The bin you create is uint8, but you write the fig file as int8. This could cause saturation on the values above 127. Safer would be uint8 in fwrite()

[David Goldsmith]

I tried that when developing the soln. for including the DB steps and found that the removal of the signs "broke" it, but I'll try it again for the w/out the DB soln. (If it works, I guess I'll have to include a switch to tell the functions, essentially, whether or not the output is intended for a DB or not.)

[David Goldsmith]

That did work; I have to catch a bus, so I'll have to double check tomorrow whether it does indeed break the DB-inclusion.

[David Goldsmith]

Ok, confirmed, changing the *uint8 to *int8 in fig2bin and leaving the int8 in bin2fig makes these functions "inverses" of eachother, w/ or w/out the DB steps--thanks, Walter, for pointing me in the right direction!