Bertin-fap / raman-hyperspectra-examples

Examples of use of the package raman_hyperspectra
MIT License
0 stars 0 forks source link

[Sample spectra] Renishaw files #1

Open alchem0x2A opened 4 years ago

alchem0x2A commented 4 years ago

Hi Francois

I wasn't able to contact you by email since it was rejected. Simply sending over issues now

Hi Francois

Thanks for your interest! Recently I got some spare time to improve the parsing abilities. Currently the package (0.1.2) should work without problem for 1D and 2D spectra but image extraction and super-positions are still needed to be added. You may want to check the newer versions since the old ones may be bad about documentation etc.

In case you want to test, I have some sample spectra from an old project that I used for demonstration of renishawWiRE.

https://github.com/alchem0x2A/py-wdf-reader/releases/download/binary/spectra_files.zip

Also, many appreciated if you can provide pull requests / issues / suggestions !

Best TT

Bertin-fap commented 4 years ago

Hi Tran, many thanks for your reactivity. Your package works fine . I have uploaded a Jupyter example based on your package https://github.com/Bertin-fap/raman-hyperspectra-examples/blob/master/Check%20RENISHAW%20hyperspectra.ipynb

It works fine. Nevetheless I find it a little bit difficlt to decipher your types class. In particular I didn't succed in fiding the x, y, lbd unit, so I lousely fix them to µm and cm-1. Could you help me with this issue

Best

François

alchem0x2A commented 4 years ago

Thanks for testing out!

There is still work in progress to set the correct unit output, for most of my samples your assignment of μm and cm^-1 are correct.

The xy-pos information can now be retrieved in WDFReader.origin_list_header, where the first 2 items contain the x and y position units etc.

The spectral units are bit different, which now I read as UnitType(WDFReader.xlist_units). It gives me a RamanShift instance, which supposedly is cm^-1. In my case I didn't have other types of spectral data than this. Probably you can check with your files as well.

Bertin-fap commented 4 years ago

Base on your tip, to retrieve the unit I used this rather akward and unreadeable two lines of code Unit = {types.UnitType.members[x]:x for x in types.UnitType.members} unit_x = Unit[data.origin_list_header[0][2]] Could you suggest a better idea?

alchem0x2A commented 4 years ago

unit_x = Unit[data.origin_list_header[0][2]]

I think depending on how you want to output the value of unit? If you just want the normal name then data.origin_list_header[0][2].name gives you "Micron". Otherwise you can always use dict conversion

unit_dict=dict(Micron="μm")
x_unit = data.origin_list_header[0][2]
print("unit of x: ", unit_dict[x_unit.name])

I've made a PR to my package so that starting from version 0.1.5 all the UnitType etc instances can be converted to a conventional name string by the __str__ method, i.e.:

print("X coordinate unit", str(data.xpos_unit))
print("Y coordinate unit", str(data.ypos_unit))
print("Raman x-data unit", str(data.xlist_unit))

which gives:

X coordinate unit μm
Y coordinate unit μm
Raman x-data unit 1/cm

Nevertheless, I appreciate if you suggest some better naming for these instances. Currently the original naming by Renishaw is bit messy

Bertin-fap commented 4 years ago

Thanks a lot for your answer I will use your method.
A last point the warning "Block name WMAP not present in current measurement" is not understandable for a non expert . It could be suppressed or more explicit. I think you have to stick with Renishaw notations.

alchem0x2A commented 4 years ago

A last point the warning "Block name WMAP not present in current measurement" is not understandable for a non expert . It could be suppressed or more explicit.

Thanks for the input. I made a quick PR to this issue so that only if you create the WDFReader instance with debug=True, will these information output to stderr