Dear all,
I'm having some issues opening some .stp files. I have reproduced this issue in multiple platforms (both in macOS and Windows 10 using the version 2.65 of the software). The files were generated using a third party program, but they can be read in WSxM just fine. I attach an example image, as well as the resulting data I get when loading into WSxM. The header info is quite sparse, but it always the same structure.
Let me know if any extra information is required.
which is obviously a lie. I added a workaround for invalid header sizes (or modified the one we already had there). However, Gwyddion then reads the file with height range of 1 nm. This is because the file says
Z Amplitude: 1 nm
So the information required is: How to convert the raw data to physical values? The answer cannot be ‘Ignore the value of Z Amplitude and only use its units’, even though it seems to work here. It breaks other files where the Z Amplitude value is needed for the conversion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the improvements. Could you point me to a description on how the Z Amplitude is typically handled on this files? I'm not aware of any documentation of how this files are structured. I might be able to programmatically add/modify the information on the header to make them behave as expected.
Thanks in advance
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did some experimentation with WSxM and we've been probably interpreting the value scaling wrong. At least for simple files like this nothing in the file header actually has any effect on how WSxM converts the raw data to physical values – it has to use some fixed conversion factors. I need to do more testing…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've done some testing as well in WSxM and, as far as I can tell, the behavior in WSxM depends on the Image Data Type.
If the image contains integer values, it will take the range of values in the image and map it to the Z Amplitude.
On the other hand, if the image contains floating point values, it would completely ignore the value provided, and just use the units provided with the raw values.
Here I attach some example images I've generated in Matlab, using both integer and floating point.
I just tried the new development version and all the test images I sent work as expected. I will try some other images later, and I'll let you know if I encounter any bugs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all,
I'm having some issues opening some .stp files. I have reproduced this issue in multiple platforms (both in macOS and Windows 10 using the version 2.65 of the software). The files were generated using a third party program, but they can be read in WSxM just fine. I attach an example image, as well as the resulting data I get when loading into WSxM. The header info is quite sparse, but it always the same structure.
Let me know if any extra information is required.
Thank you,
Miguel
As far as I can tell the file is invalid. It says
which is obviously a lie. I added a workaround for invalid header sizes (or modified the one we already had there). However, Gwyddion then reads the file with height range of 1 nm. This is because the file says
So the information required is: How to convert the raw data to physical values? The answer cannot be ‘Ignore the value of Z Amplitude and only use its units’, even though it seems to work here. It breaks other files where the Z Amplitude value is needed for the conversion.
Thank you for the improvements. Could you point me to a description on how the Z Amplitude is typically handled on this files? I'm not aware of any documentation of how this files are structured. I might be able to programmatically add/modify the information on the header to make them behave as expected.
Thanks in advance
I did some experimentation with WSxM and we've been probably interpreting the value scaling wrong. At least for simple files like this nothing in the file header actually has any effect on how WSxM converts the raw data to physical values – it has to use some fixed conversion factors. I need to do more testing…
I've done some testing as well in WSxM and, as far as I can tell, the behavior in WSxM depends on the Image Data Type.
If the image contains integer values, it will take the range of values in the image and map it to the Z Amplitude.
On the other hand, if the image contains floating point values, it would completely ignore the value provided, and just use the units provided with the raw values.
Here I attach some example images I've generated in Matlab, using both integer and floating point.
Thanks for the investigation. This seems to be the answer to why different files are converted differently.
As of r26176 Gwyddion should load your files correctly. Please try tomorrow's or later development snapshot.
I just tried the new development version and all the test images I sent work as expected. I will try some other images later, and I'll let you know if I encounter any bugs.