I can open this file with bundle software, but it is much much less powerful than Gwyddion.
It only shows just 3D image.
I attached sample file and please help us to analyze this file with Gwyddion.
If you need another example, I can provide anything you want.
The Zygo format Gwyddion already supports (‘metropro’) is a relatively complex binary format. I am not sure how could you tell this SPM format is similar -- both look like binary junk at the first sight.
We were able to obtain file format documentation for the metropro format (don't recall how or where). That would be best also in this case. We can try writing to the manufacturer, but usually it's better when a customer writes to them and asks if they can provide file format documentation allowing us to add support to Gwyddion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the response.
I meant that the machine of nanosystemz functions almost same as Zygo.
But I did not notice that the data file format might be different each other.
If I do not have the documentation of file format, how can I support you to implement nanosystemz spm file to Gwyddion?
Can you recommend any other approach?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I said, you have their instrument so you are their customer (not necessarily you personally, but the lab is...). Write to them you want to open data from the instrument in Gwyddion and ask if they can provide the file format documentation to us to enable that.
I can also write to them but it seems to have lower success rate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) I have requested file format from the instrument and it is being considered now. But I am not sure the result. I'll feedback.
2) With provided software, I can extract xyz data from spm files. The supported file format is txt, csv, matlab file, vrml, zmatrix. I opened txt and csv with Gwyddion and it just shows the right imgae. But I can not use the data process function or Graph or tool anything (the commands menu are not activated). For your interest, I attached txt file, can you check it if this txt file has enough information to use Gwyddion functions?
Could you explain the difference between XYZ Data and conventional AFM file? By using "Rasterize" to XYZ Data, I can handle my xyz data file like conventional AFM file. What additional information is inserted to XYZ Data.
I am chemist and please understand low level knowledge of computer or analysis background.
Thanks in advance.
Last edit: YC Jeong 2018-10-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to attach txt file but it failed because of data limitation. I guess.
If you can email me (ycjeong@kitech.re.kr), I'll transfer by e-mail.
I think that spm file and xyz file would be helpful to you to find file format.
Some of the other formats (txt, zmatrix?) may be more useful for Gwyddion if they contain enough information for automatic import.
If we are not able to get any file format documentation, I can try some reverse-engineering based on probably any kind of text export. In fact, I looked at the file structure a bit more and the file -- fortunately -- seems much simpler than a typical ‘metropro’ file. I do not know how to read the physical scales yet, but I can already get the raw image data...
About XYZ data
XYZ data contain the location of each measurement (XY) and the measured value (Z). The locations do not have to form a regular grid as in a conventional AFM measurement. The tip can follow an unusual scanning path, you can acquire more data points in interesting locations, etc. So XYZ data are more general -- and often much more difficult to work with -- than conventional AFM data.
Gwyddion works with XYZ data, but only a few functions are currently available (in the XYZ data menu).
Commercial AFM software does not work with XYZ data (AFAIK), but sometimes someone thinks it is a good idea to export data as XYZ data (instead of simple matrix of Z values). Even though it means any software reading it will
(a) Treat the XYZ data as XYZ data (probably disapointing users thinking they have an image).
(b) Ignore the XY coordinates and load it as an image (probably doing something horrible when the points do not form a regular grid).
Gwyddion does (a). You can render XYZ data to an image using Rasterise -- if it detects that the points form a regular grid, it offers to create the image directly from the values.
Last edit: David Nečas 2018-10-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) I sent e-mail to you with explanation ppt file and data files. If you do not recieve e-mail, please let me know.
2) Thank you for explanation for XYZ data. I just thougt that the xy points are always regular in microscope because data are obtained by CMOS or CCD (predefined pixels..) However, the xy data points might be irregular in AFM mechanism as you already mentioned. Regenerating the new regular grid from AFM data points could lead small deviation (from real one) because of interpolaration even very small. Now I understand the difference in data points between conventional optical microscope and mechanical based AFM. However, I'm still confused why XYZ data is stored in ascii format rather than the hexademical binary type.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am an AFM user and I used Gwyddeon to analyze my images. I have images from a Nanotec instrument and also an Agilent one.
For some reason, Gwyddeon is now reading the images in a strange form. They are black and white, high contrast and I cannot see them correctly. When I open the recent files, they are viewed in the small format but correctly, but when I open them they are weird.
I have tried unistalling Gwyddeon and installing it again and I get the same. I´ve tried redefining the file type but it doesn´t work. When I first start browsing the images it looks Ok but then the right image goes away.
Do you have any suggestion?
Thank you
Marisela
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should have totally seen this coming a kilometre away and provided exactly how to start a new topic here. Mea culpa. Anyway...
There are a bunch of things that influence visualisation and might be set in an odd manner. I suggest to start by finding the setting file and moving it away. If it helps, restore it and check the default false colour gradient and default false colour mapping type. Or just forget the old settings and start afresh.
For GWY files the situation can be different. The false colour mapping settings are saved to them. So if they were manually adjusted, they will always display this way until/unless you again manually change the mapping using the gradient selector and/or false colour mapping tool for the particular image.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I tried to open spm file from Nanosystemz data, but it failed.
http://nanosystemz.com/en/product/nv-2700/
I can open this file with bundle software, but it is much much less powerful than Gwyddion.
It only shows just 3D image.
I attached sample file and please help us to analyze this file with Gwyddion.
If you need another example, I can provide anything you want.
Thank you very much.
For your interest,
As far as I know, the data format of nanosystemz is very similar to Zygo which the Gwyddion already supports.
Zygo MetroPro DAT .dat metropro Yes — — —
The Zygo format Gwyddion already supports (‘metropro’) is a relatively complex binary format. I am not sure how could you tell this SPM format is similar -- both look like binary junk at the first sight.
We were able to obtain file format documentation for the metropro format (don't recall how or where). That would be best also in this case. We can try writing to the manufacturer, but usually it's better when a customer writes to them and asks if they can provide file format documentation allowing us to add support to Gwyddion.
Thanks for the response.
I meant that the machine of nanosystemz functions almost same as Zygo.
But I did not notice that the data file format might be different each other.
If I do not have the documentation of file format, how can I support you to implement nanosystemz spm file to Gwyddion?
Can you recommend any other approach?
As I said, you have their instrument so you are their customer (not necessarily you personally, but the lab is...). Write to them you want to open data from the instrument in Gwyddion and ask if they can provide the file format documentation to us to enable that.
I can also write to them but it seems to have lower success rate.
I tried followings.
1) I have requested file format from the instrument and it is being considered now. But I am not sure the result. I'll feedback.
2) With provided software, I can extract xyz data from spm files. The supported file format is txt, csv, matlab file, vrml, zmatrix. I opened txt and csv with Gwyddion and it just shows the right imgae. But I can not use the data process function or Graph or tool anything (the commands menu are not activated). For your interest, I attached txt file, can you check it if this txt file has enough information to use Gwyddion functions?
Could you explain the difference between XYZ Data and conventional AFM file? By using "Rasterize" to XYZ Data, I can handle my xyz data file like conventional AFM file. What additional information is inserted to XYZ Data.
I am chemist and please understand low level knowledge of computer or analysis background.
Thanks in advance.
Last edit: YC Jeong 2018-10-30
I tried to attach txt file but it failed because of data limitation. I guess.
If you can email me (ycjeong@kitech.re.kr), I'll transfer by e-mail.
I think that spm file and xyz file would be helpful to you to find file format.
Anyway, the file shows like follwings.
X(mm) Y(mm) Z(mm)"
0 0 0.00003085
0.00049 0 0.00003233
0.00098 0 0.00003381
0.00147 0 0.00003362
0.00196 0 0.00003342
0.00245 0 0.00003364
0.00294 0 0.00003385
0.00343 0 0.00003114
0.00392 0 0.00002842
0.00441 0 0.00003061
0.0049 0 0.0000328
0.00539 0 0.00003489
0.00588 0 0.00003699
0.00637 0 0.00003645
0.00686 0 0.00003592
0.00735 0 0.00003725
0.00783 0 0.00003857
Last edit: YC Jeong 2018-10-30
Some of the other formats (txt, zmatrix?) may be more useful for Gwyddion if they contain enough information for automatic import.
If we are not able to get any file format documentation, I can try some reverse-engineering based on probably any kind of text export. In fact, I looked at the file structure a bit more and the file -- fortunately -- seems much simpler than a typical ‘metropro’ file. I do not know how to read the physical scales yet, but I can already get the raw image data...
About XYZ data
XYZ data contain the location of each measurement (XY) and the measured value (Z). The locations do not have to form a regular grid as in a conventional AFM measurement. The tip can follow an unusual scanning path, you can acquire more data points in interesting locations, etc. So XYZ data are more general -- and often much more difficult to work with -- than conventional AFM data.
Gwyddion works with XYZ data, but only a few functions are currently available (in the XYZ data menu).
Commercial AFM software does not work with XYZ data (AFAIK), but sometimes someone thinks it is a good idea to export data as XYZ data (instead of simple matrix of Z values). Even though it means any software reading it will
(a) Treat the XYZ data as XYZ data (probably disapointing users thinking they have an image).
(b) Ignore the XY coordinates and load it as an image (probably doing something horrible when the points do not form a regular grid).
Gwyddion does (a). You can render XYZ data to an image using Rasterise -- if it detects that the points form a regular grid, it offers to create the image directly from the values.
Last edit: David Nečas 2018-10-30
Thank you very much for your help.
1) I sent e-mail to you with explanation ppt file and data files. If you do not recieve e-mail, please let me know.
2) Thank you for explanation for XYZ data. I just thougt that the xy points are always regular in microscope because data are obtained by CMOS or CCD (predefined pixels..) However, the xy data points might be irregular in AFM mechanism as you already mentioned. Regenerating the new regular grid from AFM data points could lead small deviation (from real one) because of interpolaration even very small. Now I understand the difference in data points between conventional optical microscope and mechanical based AFM. However, I'm still confused why XYZ data is stored in ascii format rather than the hexademical binary type.
For some reason, Gwyddeon is now reading the images in a strange form. They are black and white, high contrast and I cannot see them correctly. When I open the recent files, they are viewed in the small format but correctly, but when I open them they are weird.
I have tried unistalling Gwyddeon and installing it again and I get the same. I´ve tried redefining the file type but it doesn´t work. When I first start browsing the images it looks Ok but then the right image goes away.
Do you have any suggestion?
Thank you
Marisela
I should have totally seen this coming a kilometre away and provided exactly how to start a new topic here. Mea culpa. Anyway...
There are a bunch of things that influence visualisation and might be set in an odd manner. I suggest to start by finding the setting file and moving it away. If it helps, restore it and check the default false colour gradient and default false colour mapping type. Or just forget the old settings and start afresh.
For GWY files the situation can be different. The false colour mapping settings are saved to them. So if they were manually adjusted, they will always display this way until/unless you again manually change the mapping using the gradient selector and/or false colour mapping tool for the particular image.