The program for which we develop our OMERO Matlab client is FLIMfit.
To store service files in OMERO (like IRFs, etc.), we use "annotation file" option.
It works well for text IRF files, but for small B&H *sdt's there were difficulties.
Here is the code retrieving the bytes:
- Code: Select all
originalFile = ann.getFile();
rawFileStore = session.createRawFileStore();
rawFileStore.setFileId(originalFile.getId().getValue());
byteArr = rawFileStore.read(0,originalFile.getSize().getValue());
rawFileStore.close();
Here is how these bytes are saved on disk (bytes are "str" variable):
Then, the saved file becomes useful for loading to program.
- Code: Select all
full_temp_file_name = [tempdir fname];
fid = fopen(full_temp_file_name,'w');
%
if strcmp('sdt',fname(numel(fname)-2:numel(fname)))
fwrite(fid,typecast(str,'uint16'),'uint16');
else
fwrite(fid,str,'*uint8');
end
%
fclose(fid);
Other words, if it is "sdt" file, bytes are written after casting them to 'uint16' - that was found by trials and errors. Reasons are unknown, but "sdt" files are saved to disk correctly this way.
The next challenge is to work with Excel "xlsx" annotation files, as our program loads Plate metadata in this format. Both methods shown above failed to write the "xlsx" file to disk correctly, - the saved file has the same size as original but Excel can't open it. It is also binary-different from the original.
If one uses "Download" option in "Insight" - the file is saved to disk correctly, Excel opens it.
I wonder if anyone has any thoughts about why it behaves like this, and how to resolve it.
I use Omero Matlab Toolbox 4.4.6, but problem with "sdt" was there for some time, for previous versions.
Best regards,
Y.
