How can I extract the numerical array from a hypercube object?
42 次查看(过去 30 天)
显示 更早的评论
Hi! I've been using the hyperspectral library for the image processing toolbox for some years now. In the beggining, when a variable of class hypercube was created, it was storing the nomerical array (i.e. the spectral image) in a struct way that you could acces via dot indexing, for instance:
spectral_image = cube.DataCube;
However this seems not to be working anymore. Instead if I try this, I get a string instead of a numerical array. I've cheked and there is a funcion called gather which is supposed to be for this. I have also tried:
spectral_image = gather(cube);
But it is also not working. I get the following error, but my spectral image fits more than enough in my RAM, so I am sure this is not a problem.
Dot indexing is not supported for variables of this type.
Error in hypercube/gather (line 1398)
if isa(obj.BlockedDataCube.Adapter,'images.blocked.InMemory')
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The problem is that I have spectral images stored in files in hypercube class that I saved some time ago with Matlab R2023 version or even earlier, but now I can not access directly to this numerical arrays that previously were perfectly fitting in my RAM.
Any clue about how could I fix this?
Thanks in advance.
0 个评论
采纳的回答
dpb
2026-2-3,19:59
编辑:dpb
2026-2-3,20:23
The <Version History> section of the doc for R2025a discusses that the new version doesn't contain the actual datacube and that the prior versions will as you've discovered return the property as text. Why on earth that is is bizarre, indeed, it seems. But, it is what it is. Fortunately, they provide a helper function to convert to the expected numeric form. Why this wasn't included as a a builtin feature is anybody's guess.
From that doc page (sans my somewht cheeky side remarks) <vbg> --
"If you have saved hypercube objects created using the hypercube function in older releases prior to R2025a, the DataCube property contains the actual data cube. However, starting from R2025a, the DataCube property will be read as a string. You cannot use the new gather and apply object functions with these hypercube objects. To extract the actual data cube from hypercube objects created in prior releases, use this helper function."
function [datacube,wavelength,metadata] = classConverter(hcube)
datacube = str2double(hcube.DataCube);
metadata = hcube.Metadata;
datatype = metadata.DataType;
datacube = cast(datacube,datatype);
wavelength = hcube.Wavelength;
end
Good luck...
5 个评论
dpb
about 3 hours 前
str2double is notoriously slow -- with current MATLAB, you can convert directly and is quite a lot faster.
Try replacing
function [datacube,wavelength,metadata] = classConverter(hcube)
datacube = double(hcube.DataCube);
metadata = hcube.Metadata;
datatype = metadata.DataType;
datacube = cast(datacube,datatype);
wavelength = hcube.Wavelength;
end
更多回答(1 个)
Parth Parikh
about 10 hours 前
Hi Miguel,
I completely understand the frustration that comes with adapting to changes in well-established workflows. Moving forward, the best solution is to adopt the latest MATLAB functions for hyperspectral data, namely imhypercube and geohypercube. These provide seamless integration with current features, improved compatibility, and enhanced data management, positioning your work for future updates and optimizations from MATLAB. The helper function is meant to recover data from legacy hypercube objects created before R2025a, for robust, long-term workflows it’s highly recommended to transition to these newer functions. This way, you’ll be able to take advantage of MATLAB’s ongoing improvements with greater ease and reliability.
Note: For multispectral data, MATLAB provides the corresponding immuticube and geomulticube functions.
4 个评论
dpb
11 minutes 前
@Parth Parikh, your response brushes off the real cost imposed on users as inconsequential.
Why on earth if this was going to be done was it not in prior release notes as coming and were not efficient tools provided to aid in the transition rather than dumping all the work onto the user unannounced? This is quite rude.
Why, at least, since Mathworks has access to all the internals could not the new methods be able to discern an object of the prior type and directly return the data stored therein rather than the string? Or at least distribute the prior version (perhaps in an aliased form) in paralles so there would be an (at least relatively) painless way to make the transition? As it is now, if one reverts to a prior release to read the data, there isn't a tool to create the new version directly and as @Miguel Ángel noted, the conversion even replacing str2double is nontrivial.
This was just a very bad move on Mathworks' part in the way the transition was rolled out.
dpb
1 minute 前
@Miguel Ángel - "Now I am searhing for the fastest way to convert dozens of old hcube objects into the new version, and this will take me too much time. .."
Given the lack of coexisting tools in either the prior or present versions (shame on you, Mathworks!), I suspect the best approach will be to write a batch script to run in the prior release that does a search for the saved objects (I'm assuming they're in a .mat file format?) and extracts the data from them and writes to either another .mat or binary file that can then be read in the later release and create the new objects from the raw data. That could be set to be a background or overnight unattended bach job. Painful and shouldn't be necessary to have to go to such extremes, but better than a one-at-a-time approach.
ADDENDUM
Not having the TB no way to go look at just what the prior code might be, I wonder if it might be possible to move the previous version over to a private directory on the new and give it an aliased name. It may be it's too intertwined with other supporting internals to be possible, but I'd probably give it a look...
另请参阅
类别
在 Help Center 和 File Exchange 中查找有关 Hyperspectral Image Processing 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!