First, when trying to import Iso28600 format SPM files, I figured out that the import function fails (for the iso files I generated by an external program) in case the file contains multiple channels. I found out that the gwyddion Iso-file importer expects Tab-limited values in case of multi-channel data. However, the current (and first) ISO norm (from 2011-07-01) is expecting the different channel data as comma-seperated values. No big deal, but I would recommend to fix this to make gwyddion compatible with the ISO standard.
Second, I could not figure out how to save an ISO file with multiple channels. Is this possible at all? And if so, can anyone give me a hint how ? ;-)
Of course, also many thanks to everyone that has contributed to gwyddion. I think it the the best SPM postprocessing tool available!
Florian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the report. I missed the sentence about comma separation. I would kind of expect quoted commas be shown in the block that follows
The format for multi-channel mapping data is composed of a multi-column data array as shown below:
if fields are comma-separated.
Could you please attach here an example of multi-channel file written by real-world software? I do not have any and it will help fixing me the file import.
Concerning the export of multi-channel files, Gwyddion has no limitations on the number of channels and the relations between them. They can differ by dimensions, etc. So data open in Gwyddion cannot be generally written as ISO 28600 multi-channel data and we simply export the current channel because that is well-defined and always possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I generated those ISO files with my own software according to the official ISO 28600 documention. In the examples listed in the description of the standard data is formated as comma seperated values like this:
d1(1,1), d2(1,1), d3(1,1), ..... endofline
I assume that the last value shall not be terminated by a comma (at least this is how it is done for irregular data). However, the documentation is not very clear in this point.
Florian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
First, when trying to import Iso28600 format SPM files, I figured out that the import function fails (for the iso files I generated by an external program) in case the file contains multiple channels. I found out that the gwyddion Iso-file importer expects Tab-limited values in case of multi-channel data. However, the current (and first) ISO norm (from 2011-07-01) is expecting the different channel data as comma-seperated values. No big deal, but I would recommend to fix this to make gwyddion compatible with the ISO standard.
Second, I could not figure out how to save an ISO file with multiple channels. Is this possible at all? And if so, can anyone give me a hint how ? ;-)
Of course, also many thanks to everyone that has contributed to gwyddion. I think it the the best SPM postprocessing tool available!
Florian
Thanks for the report. I missed the sentence about comma separation. I would kind of expect quoted commas be shown in the block that follows
if fields are comma-separated.
Could you please attach here an example of multi-channel file written by real-world software? I do not have any and it will help fixing me the file import.
Concerning the export of multi-channel files, Gwyddion has no limitations on the number of channels and the relations between them. They can differ by dimensions, etc. So data open in Gwyddion cannot be generally written as ISO 28600 multi-channel data and we simply export the current channel because that is well-defined and always possible.
Hi David,
I generated those ISO files with my own software according to the official ISO 28600 documention. In the examples listed in the description of the standard data is formated as comma seperated values like this:
d1(1,1), d2(1,1), d3(1,1), ..... endofline
I assume that the last value shall not be terminated by a comma (at least this is how it is done for irregular data). However, the documentation is not very clear in this point.
Florian
The comma there can be just a separator of individual items (section 3.2), hard to tell. But there is an explicit statement
in section 3.7 that I missed.
Anyway, the current development snapshot should read comma-separated files.