Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: add attributes for spectral processing #143

Open
1 task done
wincowgerDEV opened this issue Sep 15, 2023 · 6 comments
Open
1 task done

[Feature]: add attributes for spectral processing #143

wincowgerDEV opened this issue Sep 15, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@wincowgerDEV
Copy link
Owner

Guidelines

  • I agree to follow this project's Contributing Guidelines.

Description

Have been thinking about this for some time. Definitely part of the long term vision but not quite sure when to bring it in. One of the challenges with using spectra is that you can forget what transformations you made to the spectra. For example if you did a derivative transformation and then forgot if it was a first or second derivative you'd be in trouble because you need to identify it using the appropriate library. Another example is if you've transformed the data but forgot how and want to reverse the transformation (sometimes possible sometimes not). Obviously the best way for a user to manage this is to code everything and version control their code so they always have the raw data and the cleaned data, but sometimes things get lost so I totally get it.

Problem

Keeping track of processing steps for spectra is hard.

Proposed Solution

I think we could add attributes that describe how spectra are processed to the OpenSpecy object type. These attributes could have special functions that we hit them with, one could be that the user can provide a suite of attributes to the OpenSpecy object and then it will use those attributes to process the spectra. Another could be to reverse the attributes to get as close to the raw spectra as possible. Another could be to try and merge two OpenSpecy objects using similarities in their attributes. Let me know what you think @zachar

Alternatives Considered

Create separate metadata object types that store common processing operations.

@wincowgerDEV wincowgerDEV added the enhancement New feature or request label Sep 15, 2023
@zsteinmetz
Copy link
Collaborator

Yeah, why not! I would maybe keep this simple in the beginning since a well written R script should take care of this anyway.

@wincowgerDEV
Copy link
Owner Author

Agreed, maybe slowly start supporting it in the background mostly just to send the user helpful warnings then start to support autocorrection of the issues.

@wincowgerDEV
Copy link
Owner Author

Along these lines, also thinking we could control some of the metadata values a little better. We could add checks for metadata variables. W.g. xy need to be distinct, col_id needs to be the same as the spectrum names. Need to have xy and col_id in metadata... I worry though that people may have alternative intended uses for the metadata values that we are currently not considering. Can let that simmer for a while.

@wincowgerDEV
Copy link
Owner Author

Sketching this out for things that could be useful to keep track of:

Intensity Unit Options: Absorbance, Transmittance, Reflectance
Derivative Order: Deriv_0, Deriv_1, Deriv_2
Baseline Options: Raw, No_Baseline
Spectra Type: FTIR, Raman

Looks like to initialize or update we can just add this to the OpenSpecy for each.
attr(obj, "intensity_unit") <- NULL

Then we can retrieve the value with attr(obj, "intensity_unit") and run checks using it.

@wincowgerDEV
Copy link
Owner Author

Have a first pass of this addition added now 74e936c

I think we probably want to add in some functionality to updating attributes when it makes sense. For example, if the user does a derivative transformation we can add the order or if they do a baseline transformation we can add that label. Perhaps these could be used to warn people if they try to do something weird like take the 4th derivative or try to remove the baseline on a derivative transformed spectrum or try and baseline correct something that has already been baseline corrected. There are probably other things we can try to catch too.

@zsteinmetz
Copy link
Collaborator

Sounds good to me! I'll try to have a look at PR #157 as soon as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants