Reading Zygo MetroPro file

[nombac]

I began using SurfaceTopography to read Zygo MetroPro files. Upon comparing an image generated by SurfaceTopography (along with matplotlib shown below) to one produced by Zygo's Mx software, it appears that the x and y coordinates of the height array have been swapped, as shown in the attachment. What could be the cause of the issue?

import SurfaceTopography as st
import matplotlib.pyplot as plt
import numpy as np
import pint

ureg = pint.UnitRegistry()

def display_surf_file(filename):
    # Load topography from file
    topography = st.read_topography(filename)

    # Extract height information
    heights = topography.heights()  # Transpose the heights matrix
    #heights = np.transpose(topography.heights())  # Transpose the heights matrix

    # Convert the physical sizes to desired unit (um)
    # Convert the heights to nanometers
    unit_from_file = ureg.Unit(topography.unit)
    conversion_factor = (1 * unit_from_file).to('um').magnitude
    physical_sizes_in_um = tuple(p * conversion_factor for p in topography.physical_sizes)
    conversion_factor_to_nm = (1 * unit_from_file).to('nm').magnitude
    heights_in_nm = heights * conversion_factor_to_nm

    # Create an evenly spaced range based on the physical sizes in um and pixel resolution
    x = np.linspace(0, physical_sizes_in_um[0], heights_in_nm.shape[0])
    y = np.linspace(0, physical_sizes_in_um[1], heights_in_nm.shape[1])

    # Plot the data using extent to adjust the axes
    vmin = -20
    vmax =  20
    cmap = 'viridis'
    # Plot the data using extent to adjust the axes
    plt.imshow(heights_in_nm, cmap='viridis', extent=[x.min(), x.max(), y.max(), y.min()], vmin=vmin, vmax=vmax)

    ticks = np.arange(0, max(physical_sizes_in_um), 20)  # Example: increments of 25 um
    plt.xticks(ticks)
    plt.yticks(ticks)

    plt.colorbar(label='Height (nm)')  # Updated the label to nanometers
    plt.title(filename)  # Use the filename as the title
    plt.xlabel(f'X (um)')
    plt.ylabel(f'Y (um)')
    plt.show()

if __name__ == "__main__":
    filename = 'NS030L_003_processed.dat'
    display_surf_file(filename)

20231011_st.pdf

[pastewka]

This is the data layout, thanks for notifying us. I will swap it, but note that this does not affect any of the statistical properties that you may compute using the code.

[nombac]

Thank you for your answer. (I'd appreciate it if you could let me know when the swap is done.)

[pastewka]

Hi @nombac - the data map should be swapped starting version 1.11.1. Can you check whether this works for you?

[nombac]

I've confirmed that version 1.11.1 works for me. Thank you very much for working on this.

…

On Wed, Oct 18, 2023 at 7:28 PM Lars Pastewka ***@***.***> wrote: Hi @nombac <https://github.com/nombac> - the data map should be swapped starting version 1.11.1. Can you check whether this works for you? — Reply to this email directly, view it on GitHub <#332 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJIYRNUIZJHO2M5TBQSD4W3X76VLRAVCNFSM6AAAAAA53DB6XWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TGMJTGY2DE> . You are receiving this because you were mentioned.Message ID: <ContactEngineering/SurfaceTopography/repo-discussions/332/comments/7313642 @github.com>

[pastewka]

Perfect, thanks for confirming (and for reporting the issue)!

[nombac]

It seems that Gwyddion format files (.gwy) also need the swap (I'm using 1.11.3).

[pastewka]

Okay, thanks for notifying me. Will fix this.

[pastewka]

@nombac Is this still an issue for .gwy files. It looks okay if I load and plot them, but it is correct that the origin in the plot below is in different locations in Gwyddion and SurfaceTopography

[pastewka]

I guess you want the y-axis swapped (but I should then also adjust the plot function to invert the y-axis).

[nombac]

Just to clarify the orientation issue with the heights data from different formats, I've attached diagrams comparing the three cases:

• metropro format: topo.heights()
• Gwyddion native format: topo.heights()
• Gwyddion native format after rotation: np.rot90(topo.heights())

It seems that topo.heights() from the Gwyddion native format needs a np.rot90 rotation to match the metropro format orientation, which is consistent with how these files are displayed in Gwyddion.

[nombac]

Here are the links to the files I used in the above example:
test.gwy
test.dat

[pastewka]

@nombac - This was fixed in v1.13.0. Can you confirm that this is indeed working for you now?

[pastewka]

I am referring to the Gwyddion flip

[nombac]

Sorry for the late reply. The issue still appears to persist in version 1.16.2 as attached.

…

On Thu, Jul 25, 2024 at 6:52 PM Lars Pastewka ***@***.***> wrote: I am referring to the Gwyddion flip — Reply to this email directly, view it on GitHub <#332 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJIYRNR3HD5WMH5PIYHZQ2LZODDGLAVCNFSM6AAAAAA53DB6XWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJUG4ZDENY> . You are receiving this because you were mentioned.Message ID: <ContactEngineering/SurfaceTopography/repo-discussions/332/comments/10147227 @github.com>

[pastewka]

Okay, will look into this!