search

alchem0x2A / py-wdf-reader

Python package for read-only accessing the wdf Raman spectroscopy from Ranishaw WiRE software
MIT License
40 stars 16 forks source link

Contributors / Maintainers of this repository? #43

Open alchem0x2A opened 2 years ago

alchem0x2A commented 2 years ago

Since I'm now mainly working in theoretical / computational materials fields, it would be great if any of the code contributors would like to maintain this repository. I can add her / him as a maintainer so direct push / PR is possible. @ericpre @markotoplak @rodsmithMB @jji-ts @AlexHenderson ?

ericpre commented 2 years ago

@jlaehne may be more interested than me actually. In https://github.com/LumiSpy/lumispy/issues/130, there is some discussion about being able to read renishaw files in lumispy. Maybe this could be a good candidate to add this reader to RosettaSciIO, as that it can be maintained along with other file readers! :)

jlaehne commented 2 years ago

Yes, indeed @pietsjoh will be starting to implement Renishaw support for RosettaSciIO in the next weeks. An open question for the moment was, whether to make this repository a dependance. In the current situation, I would propose to migrate the Renishaw Support to RosettaSciIO so that it does not need to be maintained separately.

jlaehne commented 2 years ago

I see that this reader can provide only a limited number of metadata fields (I would expect things like slit width/pinhole size, grating used, etc. to be documented in the format). Are these all the fields that are contained in the format, or is it due to lacking documentation that only a part of the fields can be extracted?

alchem0x2A commented 2 years ago

Hi @eric @jlaehne thanks for getting back! Yes this repo is written for some of my PhD work so only the spectra / mapping extraction parts are implemented. Although as far as I know there is no official documentation on how the wdf files are constructed, the c codes from gwyddion is quite good at block parsing. Some of the blocks contain the instrument and calibration data, as can be seen in https://github.com/christian-sahlmann/gwyddion/blob/b0a16600d36fca015c2c3aabda489ea38db0e969/modules/file/renishaw.c#L607.

Either using this repo as dependency or refactor in rosetta sci io are fine by me. Kindly let me know if anything I can help (though no access to a real instrument now)

alchem0x2A commented 2 years ago

that being said, I can work with a PR to integrate the metadata parsing in renishaw_wire (if there is already a defined API in Rosetta Sci IO, that would be great to see what can / cannot be done), or you can spin off new codes

AlexHenderson commented 2 years ago

Happy to be involved, but not sure my experience with GitHub is good enough to be a maintainer.

alchem0x2A commented 2 years ago

thx @AlexHenderson !

pietsjoh commented 2 years ago

I took a look at the code and I would prefer to refactor this project into RosettaSciIO without introducing it as a dependancy. Primarily because I want to extend the metadata extraction. As I will work on the parsing anyways, I'd rather implement the complete parser directly in RosettaSciIO (based on this project) . Moreover, it seems easier to maintain everything combined in one project instead of maintaining seperate repositories for the parser and the RosettaSciIO wrapper.

alchem0x2A commented 2 years ago

@pietsjoh that sounds logical to me!

AlexHenderson commented 2 years ago

Hello, I think this is probably a good idea to move to RosettaSciIO. Notwithstanding the great work already done here by @alchem0x2A, a common platform for formats is preferable IMHO.

Regarding metadata, I have been in touch with Renishaw and they are interested in helping with information relating to the format, but would rather not actively manage a reader/parser. They have also agreed, in principle, to keep someone (a maintainer I guess) informed of future format changes. I think this is very helpful and will no doubt help any package in terms of robustnness and stability. One potential fly in the ointment is Renishaw prefer an Apache2 licence. Not sure where RosettaSciIO are heading right now, but it looked like LGPL. I'd have to check whether these are compatible, or a compromise could be reached.

pietsjoh commented 2 years ago

I have opened a draft PR (https://github.com/hyperspy/rosettasciio/pull/55).

Regarding metadata, I have been in touch with Renishaw and they are interested in helping with information relating to the format, but would rather not actively manage a reader/parser. They have also agreed, in principle, to keep someone (a maintainer I guess) informed of future format changes. I think this is very helpful and will no doubt help any package in terms of robustnness and stability.

Getting information about the file encoding directly from the source sounds great. Regarding future maintenance, @jlaehne is probably the person to speak to.

jlaehne commented 2 years ago

Indeed, we are really grateful for the way having been paved by @AlexHenderson with his Matlab reader and @alchem0x2A with this repo.

Regarding metadata, I have been in touch with Renishaw and they are interested in helping with information relating to the format, but would rather not actively manage a reader/parser. They have also agreed, in principle, to keep someone (a maintainer I guess) informed of future format changes. I think this is very helpful and will no doubt help any package in terms of robustnness and stability. One potential fly in the ointment is Renishaw prefer an Apache2 licence. Not sure where RosettaSciIO are heading right now, but it looked like LGPL. I'd have to check whether these are compatible, or a compromise could be reached.

It is a pity that most manufacturers don't really want to take responsibility for open readers of their formats. But it is already great that Renishaw is supportive of such implementations. I had the same impression from the colleague responsible for our setup and in contact with them. They do also actively promote e.g. the Matlab reader to their customers. In the long run, I think we have to push them to also support direct export to standardized open formats such as NeXus (where the German community is currently working on metadata conventions for a wide range of measurement types).

From a first glance, LGPL and Apache2 should be compatible for the purposes they might need (in particular it should allow using the parser as a library for other projects not necessarily under the same license). But maybe you can check with them again.

@pietsjoh please note here if you have specific questions on the metadata format that come up and cannot be solved through the existing open implementations, including the Gwyddion one.

In the long run, I can serve as a contact, but as I am primarily working with other systems and use the Renishaw PL/Raman only sparsely, I wouldn't mind if at least one more person is on their list as well.

pietsjoh commented 1 year ago

The implementation of the reader for RosettaScIO is almost ready for review. I started with the reader of this repo and modified it to meet hyperspy's format. Moreover, I extended it to read more blocks (inspired by gwyddion). Some of the examples of this repo are used as testfiles.

One of my open questions is how to handle licensing. Currently I include the license of this reader in the reader file and mention that this reader is inspired by the one from @AlexHenderson (similar to how this repo handles this). Additionally, I mention that the code is inspired by gwyddion. Do you think that this is sufficient?

alchem0x2A commented 1 year ago

great work @pietsjoh ! Regarding the licensing since this repo uses MIT, you're free to choose whatever you prefer, if that's compatible with renishaw.

Speaking of the maintenance, once the support in rosetta io is completed, I'll mark this repo as archived and add a link to your package.

btw PIL was chosen as the EXIF / WL image extractor only due to personal preference, you may want to switch to some other libraries for the consideration of lightweight / consistent API etc.