Repository navigation
Issue when loading binary .uff in third-party software #91
Description
Activity
I can help you with debugging it. Can you please provide the minimal code you use?
Hi,
Here is my minimal code, I just change the "binary" variable to export in ASCII or Binary encoding.
``` import numpy as np from pyuff import UFF x = np.linspace(0, 1000) y = np.sqrt(x) binary = 0 data = {'type': 58, 'binary': binary, 'id1': 'NONE', 'id2': 'NONE', 'id3': 'NONE', 'id4': 'NONE', 'id5': 'NONE', 'func_type': 1, 'rsp_ent_name': 'Pt 1', 'rsp_node': 0, 'rsp_dir': 0, 'ref_ent_name': 'NONE', 'ref_node': 0, 'ref_dir': 0, 'ord_data_type': 2, 'num_pts': 0, 'abscissa_spacing': 1, 'abscissa_min': 0, 'abscissa_inc': 0, 'z_axis_value': 0, 'abscissa_spec_data_type': 17, 'abscissa_len_unit_exp': 0, 'abscissa_force_unit_exp': 0, 'abscissa_temp_unit_exp': 0, 'abscissa_axis_lab': 'Time', 'abscissa_axis_units_lab': 's', 'ordinate_spec_data_type': 8, 'ordinate_len_unit_exp': 0, 'ordinate_force_unit_exp': 0, 'ordinate_temp_unit_exp': 0, 'ordinate_axis_lab': 'Displacement', 'ordinate_axis_units_lab': 'mm', 'orddenom_spec_data_type': 0, 'orddenom_len_unit_exp': 0, 'orddenom_force_unit_exp': 0, 'orddenom_temp_unit_exp': 0, 'orddenom_axis_lab': 'NONE', 'orddenom_axis_units_lab': 'NONE', 'z_axis_spec_data_type': 0, 'z_axis_len_unit_exp': 0, 'z_axis_force_unit_exp': 0, 'z_axis_temp_unit_exp': 0, 'z_axis_axis_lab': 'NONE', 'z_axis_axis_units_lab': 'NONE', 'data': y, 'x': x} uff_file = UFF("test_ascii.uff") uff_file.write_sets(data)Thank you @vlef .
With the code provided everything works fine on my side. Can you please check you are using the latest version (2.4.3)?
Did you by any chance write in and existing file? (in this case the new dataset is added at the end)Can you please double-check it? (and delete all prior test files, just in case so you do not append data)
Yes I'm using 2.4.3
No, I create new file, there was no existing file.With the code provided everything works fine on my side
Did you manage to import the generated binary UFF file in a third-party software such as NCode Glyphworks?
I am sorry, but I do not have NCode Glyphworks. But the data you provided in binary form is readable and does have the required data. I guess this is a problem of NCode, or?
It could be that the NCode has problems with double precision. Can you try using single? Be careful that you use the option
.write_sets(data, force_double=False)aspyuffby default forces double precision.Please report back the progress.
@vlef any progress? Can you try exporting from Ncode in binary format and importing it in pyuff?
@vlef can we close this issue?
Hi,
the data you provided in binary form is readable
Did you read the data with pyuff again? My point is that it is readable with pyuff, but not readable with other softwares (NCode, but also other signal analysis softwares)
I can export binary signal from NCode and importing in pyuff without issues.
Yes, I tried also with force_double=False, and the result is the same when importing the output in NCode :
Can read the txt file in NCode and save it as binary from there? Please provide the binary file, as exported from NCode, here. I will try to help.
Hello,
I'm encountering an error when loading a .UFF file generated by pyuff into a third-party software (such as NCode Glyphworks for example).
Importing the file results in abnormal values (cf picture below). This error only occurs when the export is in "binary" format.
Attached are two examples : Binary (incorrect) and ASCII (correct) exports. The only difference is the "Binary" field.
I'm using pyuff 2.4.3
Thanks for your help
test_ascii.uff.txt
test_binary.uff.txt