Units not working on .al3d files

[jacekolender]

Wehn uploading a surface scan in the alicona format al3d, the unit field in step 3 of creating a twin is greyed out. But since it's a mandatory field, the twin cannot be ultimately created and no further operation can be done.

[pastewka]

Thanks for reporting this. We will fix asap.

[jacekolender]

Thanks! It might be also me doing something wrong or the files are incorrect, but I have tried with three different scans and had the same issue.

[mcrot]

I can confirm this bug. The problem is that the channel information returned by SurfaceTopography returns a dict with meta data. It should return a string with a valid unit or None.

Example:

In [1]: from SurfaceTopography import open_topography
In [2]: reader = open_topography("../SurfaceTopography/test/file_format_examples/example.al3d")
In [5]: ch=reader.channels[0]
In [6]: ch
Out[6]: <SurfaceTopography.IO.Reader.ChannelInfo at 0x7fb6c5d2bca0>
In [7]: ch.dim
Out[7]: 2
In [8]: ch.unit
Out[8]: 
{'raw_metadata': {'Version': 1,
  'TagCount': 17,
  'Cols': '200',
  'IconOffset': '0',
  'DepthImageResPtr': '3',
  'PlaceHolder': 'B\x91FIACAÃC\x1b',
  'DepthImageOffset': '1261',
  'CreatingApplication': 'MeasureSuite 5.3.6',
  'DepthResShiftVal': '2.35294e-09',
  'InvalidPixelValue': '3.000000028082e+15',
  'PixelSizeYMeter': '4.38027e-07',
  'PixelSizeXMeter': '4.38027e-07',
  'NumberOfPlanes': '4',
  'Rows': '296',
  'DirSpacer': '\x82SÙ<Ê@\x99;ØA',
  'TextureImageOffset': '238061',
  'TexturePtr': '0;1;2',
  'DepthResMinVal': '0',
  'DepthResFilterVal': '6.06e-07'}}

Examples for two other file formats:

In [9]: reader = open_topography("../SurfaceTopography/test/file_format_examples/example2.opd")
In [10]: ch=reader.channels[0]
In [11]: ch.unit
Out[11]: 'mm'
In [15]: reader = open_topography("../SurfaceTopography/test/file_format_examples/example1.mat")
In [16]: ch=reader.channels[0]
In [18]: ch.unit is None
Out[18]: True

[pastewka]

Ooops. The tests should actually catch this, I wonder what is going on. I am transferring this to SurfaceTopography. It will automatically propagate through once fixed.

[pastewka]

The file was not included in the list of example files. The generic tests never ran, but they catch this error.

[pastewka]

PR #277 fixes this issue.

[jacekolender]

I have now successfully uploaded an al3d file, but the unit multiplier is set permanently to 1, so I get results that are off by rows of magnitude. As per example on the image attached, I got Rq roughness of 331 microns, where realistically I would not expect above 3 microns. Unless I'm doing something wrong with the analysis...

[pastewka]

This looks like there is still a bug. Will look into this.

[pastewka]

Can you comment on the Sq value? Is that correct? It looks like the reader is assuming the wrong byte order when reading the file, but the overall height should be okay.

[jacekolender]

I think the Sq value of 0.3 mm (300 um) is quite probable.

[pastewka]

Okay, then the problem is just the data layout. I'll push and update soon(ish) - will let you know once that has happened.

[jacekolender]

Great!

[pastewka]

@jacekolender I've just updated the site, including a bug fix to the reader. Can you check whether the problem is resolved?

[jacekolender]

Hi, I'm terribly sorry I could not get back to this on time back in April. It caught me during a job change (and move across continents) and only now I had time to look into this and get back to this data. There is still issue with scaling. Software reads the scale between X-Y units and Z units as 1, when it's not. So I'm getting Rq and Sq results in mm instead of um. It's not a massive problem, I can manually scale it down. The other thing is that I get an error when exporting power spectrum to csv/txt.

[jacekolender]

PS. Happy to send you my file for testing if you would like to.