I found a file format that is currently not supported by Gwyddion. It comes from KLA Zeta Profilometer . If you want to implement it, I attached an example file.
I don't have any documentation on the format but was able to reverse engineer the relevant parts.
The header seems to be 505 bytes long.
Field
Startbyte
Type
Value in example file
Number of points in x
85
int32
1920
Number of points in y
89
int32
1440
Pointsize in x
97
float32
~0.182
Pointsize in y
101
float32
~0.182
Stepsize in z
105
float32
~0.0104
The actual data begins at byte 505 and has the datatype int16, which means it is 1920x1440x2 bytes long. The file itself seems to be significantly longer. I don't know what other data is in there. To obtain the correct height values, you multiply the array of height data with with stepsize in z.
Also, if you interpret bytes 117-120 as an int32, the value comes out to 300, which is exactly the length of bytes which are all 0 before the height data. So it is possible that bytes 117-120 encode the length of a comment zone or similar like in SUR files, which could also be of variable length. In all my files however, it is the same so I can't say for sure, it could be also a coincidence.
Thanks for the file example and analysis. I have already started implementation (even though the import module will not appear in 2.65 which is about to be released in a couple of days – too late for that). I have a few questions, some of which you might be able to answer…
The pointsize and stepsize values are in µm, right? This would give sane physical ranges, like cca 350 µm × 260 µm and height range of about 7.5 µm (after mean plane subtraction).
There seem to be a bunch more data. Do you know anything about it?
The end of the file contains another 1920×1440 image (ending 4 bytes before the file end). It looks like some kind of second derivative/edge detection filter of the first image. I recall seeing similar things in other profilometry files (but I do not know what it is useful for if anything).
Between them, there are 4 more extra bytes (it seems) and something weird. The data size corresponds to a 2880×1440 image. And the image rows look OK when I read it as such. But the columns somehow still seem a bit misaligned. So I do not know; maybe it needs to be transformed somehow.
I am attaching visualisation of the three things I found in the file.
Yes it is indeed micrometers. However, I havent found anything in the header that indicates the unit, so I'm guessing micrometers are simply the default unit for this file standard or some field is an enum which we do not know that encodes the unit.
the first image is definitely the correct height data and is equivalent to what MountainsMap spits out when I open the file there. Unfortunately I also don't know what the rest of the data is supposed to be.
Thanks for you efforts!
Last edit: Frederic Schell 2024-01-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, thanks. As you might have already noticed, Gwyddion 2.65 is out and does not include the ZMG file import.
The import module is present in post-2.65 development snapshots. Today's still kind of attempts to read all the three images, but I disabled it. So from tomorrow's snapshot it will only import the first (topography) image.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear David,
I found a file format that is currently not supported by Gwyddion. It comes from KLA Zeta Profilometer . If you want to implement it, I attached an example file.
I don't have any documentation on the format but was able to reverse engineer the relevant parts.
The header seems to be 505 bytes long.
The actual data begins at byte 505 and has the datatype int16, which means it is 1920x1440x2 bytes long. The file itself seems to be significantly longer. I don't know what other data is in there. To obtain the correct height values, you multiply the array of height data with with stepsize in z.
Also, if you interpret bytes 117-120 as an int32, the value comes out to 300, which is exactly the length of bytes which are all 0 before the height data. So it is possible that bytes 117-120 encode the length of a comment zone or similar like in SUR files, which could also be of variable length. In all my files however, it is the same so I can't say for sure, it could be also a coincidence.
Frederic
Edit: Corrected 220 to 120
Last edit: Frederic Schell 2024-01-03
Thanks for the file example and analysis. I have already started implementation (even though the import module will not appear in 2.65 which is about to be released in a couple of days – too late for that). I have a few questions, some of which you might be able to answer…
The pointsize and stepsize values are in µm, right? This would give sane physical ranges, like cca 350 µm × 260 µm and height range of about 7.5 µm (after mean plane subtraction).
There seem to be a bunch more data. Do you know anything about it?
The end of the file contains another 1920×1440 image (ending 4 bytes before the file end). It looks like some kind of second derivative/edge detection filter of the first image. I recall seeing similar things in other profilometry files (but I do not know what it is useful for if anything).
Between them, there are 4 more extra bytes (it seems) and something weird. The data size corresponds to a 2880×1440 image. And the image rows look OK when I read it as such. But the columns somehow still seem a bit misaligned. So I do not know; maybe it needs to be transformed somehow.
I am attaching visualisation of the three things I found in the file.
Last edit: David Nečas 2024-01-03
Thanks for you efforts!
Last edit: Frederic Schell 2024-01-03
OK, one more question, do all files start the same with
Zeta-Instruments_Zeta3D_file_type? I am currently using it for file type detection.All the files that I have do start with
Zeta-Instruments_Zeta3D_file_type = 3DSurface18.OK, thanks. As you might have already noticed, Gwyddion 2.65 is out and does not include the ZMG file import.
The import module is present in post-2.65 development snapshots. Today's still kind of attempts to read all the three images, but I disabled it. So from tomorrow's snapshot it will only import the first (topography) image.