I am having an issue related to loading Omicron MATRIX CITS files [STS maps
with ".I(V)_mtrx" extension].
Let's say the raster grid used for topography measurements is 200x200.
Measurement software allows to measure spectra not in each point of this
grid, but in a more dilute subgrid. It means that after the measurement we
get three files: Z and I data (both 200x200) and CITS cube (e.g. 25x25)
Please find some example files in the attachment. I have better and more
understandable data, but I cannot upload anything larger than this due to
file size limits.
If I load this last file in Gwyddion, it seems to appear in the original
200x200 grid with all the data squashed at the bottom of the image.
I believe the metadata parameters PMOD:XYScanner.Subgrid_X [Count] and
PMOD:XYScanner.Subgrid_Y [Count] should determine the subgrid.
For example if they are both 8, it means that subgrid includes the first
data point and then every 8th point in the line (and then the same every
8th line).
I also see a parameter "EEPA:XYScanner.Enable_Subgrid" which is 1 in the
example, but I saw it 0 once, I don't know why.
I am looking at it – admittedly somewhat confused, but finding my way through (already fixed a couple of more or less unrelated bugs). I can see what we do wrong, now to make it work correctly…
More/clearer examples would be nice. If they cannot be uploaded here due to size, I suppose e-mail is not an option either. Could you put/upload them anywhere else and post a link? (Privately to me if necessary.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems r23198 can read something reasonably looking as the volume data. It is hard to tell if everything works right now though, especially with a single example…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the files. Spectra cannot be loaded without the parameter file (default_2021Feb18-180218_STM-STM_Spectroscopy_0001.mtrx). So I could not use them for testing yet; could you also give me the parameter file?
Yes, the changes are included in nightly builds (which I hope work – last time I checked MS Windows devel snapshots they did, but there have been some build infrastructure changes).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the files. Spectra cannot be loaded without the parameter file
(default_2021Feb18-180218_STM-STM_Spectroscopy_0001.mtrx). So I could not
use them for testing yet; could you also give me the parameter file?
Yes, the changes are included in nightly builds (which I hope work – last
time I checked MS Windows devel snapshots they did, but there have been
some build infrastructure changes).
Thanks for the parameter file. This one does not work. Even the images seem to be loaded incorrectly because we get the pixel dimensions wrong. See the previous discussion.
Basically, we follow how X_Points and Y_Points change through the parameter file. When we find a particular image (or other data) we use the current values as the image pixel size. But we do not always end up with the same pixel size as the instrument software – and I have no idea why. It seems the logic we use does not match how it actually works.
There is a currently workaround which tries to just guess the correct image pixel resolutions. But guessing does not always get it right either, of course. I would much prefer to just read the resolutions correctly. Any help would be appreciated.
Most helpful would be knowledge on what is going on with the pixel dimensions.
Without that, being able to follow the data in detail could help shed some light. Maybe some log noting the the pixel sizes for all data. I could then see we agree up to blahblah--75_1.Z_mtrx, but then we diverge, and could focus on that. Since one parameter file usually corresponds to a zillion of data files, no one sends the complete data. But that makes it difficult to find out where exacly things go wrong…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The last files should be 400x400 and 80x80 (spectroscopy).
I will send you a link to the files to yeti-dn@users.sourceforge.net . There are many files, so writing down all the resolutions will take some time. I used a square subgrid everywhere.
Maybe it is better if you suggest a plan of a test-experiment (which sizes you want to get and in which order) and then I will try to measure that?
Best regards
Maxim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello and thank you for the amazing software.
I am having an issue related to loading Omicron MATRIX CITS files [STS maps
with ".I(V)_mtrx" extension].
Let's say the raster grid used for topography measurements is 200x200.
Measurement software allows to measure spectra not in each point of this
grid, but in a more dilute subgrid. It means that after the measurement we
get three files: Z and I data (both 200x200) and CITS cube (e.g. 25x25)
Please find some example files in the attachment. I have better and more
understandable data, but I cannot upload anything larger than this due to
file size limits.
If I load this last file in Gwyddion, it seems to appear in the original
200x200 grid with all the data squashed at the bottom of the image.
I believe the metadata parameters PMOD:XYScanner.Subgrid_X [Count] and
PMOD:XYScanner.Subgrid_Y [Count] should determine the subgrid.
For example if they are both 8, it means that subgrid includes the first
data point and then every 8th point in the line (and then the same every
8th line).
I also see a parameter "EEPA:XYScanner.Enable_Subgrid" which is 1 in the
example, but I saw it 0 once, I don't know why.
I didn't find exactly this problem mentioned on the forum before, but there
were two threads with similar issues, maybe it can help them too:
https://sourceforge.net/p/gwyddion/discussion/fileformats/thread/540f45eac3/
and
https://sourceforge.net/p/gwyddion/discussion/fileformats/thread/fe9ce08df3/
Best regards
Maxim
I am looking at it – admittedly somewhat confused, but finding my way through (already fixed a couple of more or less unrelated bugs). I can see what we do wrong, now to make it work correctly…
More/clearer examples would be nice. If they cannot be uploaded here due to size, I suppose e-mail is not an option either. Could you put/upload them anywhere else and post a link? (Privately to me if necessary.)
It seems r23198 can read something reasonably looking as the volume data. It is hard to tell if everything works right now though, especially with a single example…
Thank you very much for looking into this problem. Here are the files for one more example (again spectroscopy map, I and Z measured at the same time), they are not very large, but I think that I was not able to start a topic with an attachment larger than 10 MB.
https://nubes.helmholtz-berlin.de/s/ztZM2JX7qnqj6yW
https://nubes.helmholtz-berlin.de/s/YzSPfGdm7gDJZ2N
https://nubes.helmholtz-berlin.de/s/2oP8AFB7gsAyc8o
I can also check myself with other files later, are the changes included in the latest nightly build?
Thanks for the files. Spectra cannot be loaded without the parameter file (default_2021Feb18-180218_STM-STM_Spectroscopy_0001.mtrx). So I could not use them for testing yet; could you also give me the parameter file?
Yes, the changes are included in nightly builds (which I hope work – last time I checked MS Windows devel snapshots they did, but there have been some build infrastructure changes).
Sorry, forgot it this time. Please find the parameter file in
the attachment.
сб, 6 мар. 2021 г. в 08:55, "David Nečas" yeti-dn@users.sourceforge.net:
Thanks for the parameter file. This one does not work. Even the images seem to be loaded incorrectly because we get the pixel dimensions wrong. See the previous discussion.
Basically, we follow how X_Points and Y_Points change through the parameter file. When we find a particular image (or other data) we use the current values as the image pixel size. But we do not always end up with the same pixel size as the instrument software – and I have no idea why. It seems the logic we use does not match how it actually works.
There is a currently workaround which tries to just guess the correct image pixel resolutions. But guessing does not always get it right either, of course. I would much prefer to just read the resolutions correctly. Any help would be appreciated.
Most helpful would be knowledge on what is going on with the pixel dimensions.
Without that, being able to follow the data in detail could help shed some light. Maybe some log noting the the pixel sizes for all data. I could then see we agree up to blahblah--75_1.Z_mtrx, but then we diverge, and could focus on that. Since one parameter file usually corresponds to a zillion of data files, no one sends the complete data. But that makes it difficult to find out where exacly things go wrong…
The last files should be 400x400 and 80x80 (spectroscopy).
I will send you a link to the files to yeti-dn@users.sourceforge.net . There are many files, so writing down all the resolutions will take some time. I used a square subgrid everywhere.
Maybe it is better if you suggest a plan of a test-experiment (which sizes you want to get and in which order) and then I will try to measure that?
Best regards
Maxim