You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Described in the pull to add a grains entry point the structure of a topostats object during processing with topostats is different from that which is returned by AFMReader.topostats.load_topostats().
At the end of processing a topostats object is a nested dictionary of (mostly) Numpy arrays which is written to HDF5 as is.
However, on loading with AFMReader.topostats.load_topostats() this dictionary is loaded and two items extracted from the data dictionary (which is the structure as written to HDF5) and a tuple returned.
This can be seen from line 42 onwards where the flattened image is extracted along with pixel_to_nm_scaling and returned along with the complete data as a tuple.
try:
withh5py.File(file_path, "r") asf:
data=unpack_hdf5(open_hdf5_file=f, group_path="/")
ifdata["topostats_file_version"] >=0.2:
data["img_path"] =Path(data["img_path"])
file_version=data["topostats_file_version"]
logger.info(f"[{filename}] TopoStats file version : {file_version}")
image=data["image"]
pixel_to_nm_scaling=data["pixel_to_nm_scaling"]
exceptOSErrorase:
if"Unable to open file"instr(e):
logger.error(f"[{filename}] File not found : {file_path}")
raiseereturn (image, pixel_to_nm_scaling, data)
It would make more sense if a topostats object were the same structure, whether it is created during processing or loaded using AFMReader. I believe the current situation is for "convenience" but extraction of either parameter if only the data were returned would not be wholly different, i.e. referring to the required element of a dictionary by name.
Suggest removing this and having instead...
try:
withh5py.File(file_path, "r") asf:
data=unpack_hdf5(open_hdf5_file=f, group_path="/")
ifdata["topostats_file_version"] >=0.2:
data["img_path"] =Path(data["img_path"])
file_version=data["topostats_file_version"]
logger.info(f"[{filename}] TopoStats file version : {file_version}")
exceptOSErrorase:
if"Unable to open file"instr(e):
logger.error(f"[{filename}] File not found : {file_path}")
raiseereturndata
The text was updated successfully, but these errors were encountered:
I'm tentatively in favour of the proposed change there, I am trying to think of any issues but can't come up with any, though it seems like the kind of thing that might bring up unforeseen complications 😅
Adding all the data that is produced during processing would be good.
Do you think I should add the image mask tensor to the .topostats file in my PR or leave it for its own PR?
Closes#109
Rather than return the HDF5 object loaded from `.topostats` as a dictionary as the third item in a tuple along with the
`image` and `pixel_to_nm_scaling` (both of which are extracted from the loaded data anyway) just the dictionary is
returned. This matches the structure of objects created by TopoStats and how they are saved to HDF5 files.
Described in the pull to add a
grains
entry point the structure of atopostats
object during processing withtopostats
is different from that which is returned byAFMReader.topostats.load_topostats()
.At the end of processing a
topostats
object is a nested dictionary of (mostly) Numpy arrays which is written to HDF5 as is.However, on loading with
AFMReader.topostats.load_topostats()
this dictionary is loaded and two items extracted from thedata
dictionary (which is the structure as written to HDF5) and a tuple returned.This can be seen from line 42 onwards where the flattened
image
is extracted along withpixel_to_nm_scaling
and returned along with the completedata
as a tuple.It would make more sense if a
topostats
object were the same structure, whether it is created during processing or loaded using AFMReader. I believe the current situation is for "convenience" but extraction of either parameter if only thedata
were returned would not be wholly different, i.e. referring to the required element of a dictionary by name.Suggest removing this and having instead...
The text was updated successfully, but these errors were encountered: