Comments (13)
Well cl-sem and cl-stem would inherit from cl, and sticking to the naming of related hyperspy signals, that would give e.g. (with aliases in [ ]):
-LumiSpectrum (inheriting from hyperspy/signal1D) [LuminescenceSpectrum]
|-CLSpectrum [CL,cathodoluminescence]
||-CLSEMSpectrum [CLSEM]
||-CLSTEMSpectrum [CLSTEM]
|-PLSpectrum [PL]
|-ELSpectrum [EL]
-LumiTransient (inheriting from hyperspy/signal2D ?) [or TRLumi]
|-CLTransient [TRCL]
|-PLTransient [TRPL]
Transient
could also be replaced by TimeRes
. What would you prefer?
We cans till define several aliases, such
from lumispy.
I will work on the hierarchy and I personally like the name TimeRes
more than Transient
.
- Modify class hierarchy (by @jordiferrero)
from lumispy.
I thought that CLTransient
is more similar to CLSpectrum
, with TR...
and possibly also TimeResolved...
as aliases.
from lumispy.
I'm a little confused about the time resolved stuff and dimensionality... That's probably because I don't do it!
Why is time-resolved stuff not <t|E> i.e. a Signal1D with a time navigation axis?
Do you do time and spatially resolved stuff? E.g. <x,y|t,E>?
To move forward in a sensible way. I think we'll establish the code hierarchy for all the non-time-resolved stuff now, and make the 0.0.1 release and then we can add the time resolved stuff when ready.
from lumispy.
Well that is why I put it to discussion. Is the time an additional navigation or signal axis? In principle, I would say it could be both and we have to find the most suitable convention.
You can still have 0, 1 or 2 spatial navigation dimensions. In TRPL spatial resolution is indeed uncommon (not impossible), but that is one of the main points of doing TRCL. So, if time becomes a navigation axis, it would have to become the first navigation dimension [0], to be independent of how many spatial dimensions there are.
Of course, time is not a signal axis in the sense of e.g. a STEM hologram or diffraction pattern, where you have two signal axes of the same type. However, it is also not of the same type as the spatial navigation dimensions.
A streak camera collects an image of time versus wavelength <t,E> and when you do a map you get <x,y|t,E>. So, in that way, it really makes most sense to define time as additional signal axis. You might want to extract either spectra at a specific delay <x,y|E>, or time-traces (transients) for a specific wavelength window <x,y|t>. In fact, for other acquisition modes, such as time-correlated single photon counting, you actually do not have a wavelength axis and time remains the only signal axis <x,y|t>. In the end, an essential feature will be to fit models to these transients.
So thinking about it, time should indeed be a signal axis!
from lumispy.
I have added all these changes now.
I have left the LumiTransient (Singnal 2D) class open to any subclass.
I guess it will make sense to add them in the future. But for now, it is more tidy and similar to Hyperspy.
I have also added a supra-class called CommonLumi
(similar to how pyxem deals with it) to mimic the role of BaseSignal
in Hyperspy. In this general class I have added some functions that apply to both 1D and 2D signals (like modifing the navigation axis).
If you are happy with it, I will close this issue.
from lumispy.
Just minor points about the functions defined in the different classes:
cosmic_rays_subtraction
is necessary for any type of spectrum recorded with a CCD, so I would move it toCommonLumi
orLumiSpectrum
(depending on whether it plays a role also for streak camera data or not, I'm not sure)- I am not so sure about the correct position for
correct_grating_shift
. It looks to me like it needs specific Attolight metadata. That should be mentioned at least in the docstring. Or would it make sense to rework it to a more general function? If there will be more Attolight specific functions, we might have to introduce an Attolight specific sub-signal.
from lumispy.
I think this can be closed.
from lumispy.
Well that is why I put it to discussion. Is the time an additional navigation or signal axis? In principle, I would say it could be both and we have to find the most suitable convention.
You can still have 0, 1 or 2 spatial navigation dimensions. In TRPL spatial resolution is indeed uncommon (not impossible), but that is one of the main points of doing TRCL. So, if time becomes a navigation axis, it would have to become the first navigation dimension [0], to be independent of how many spatial dimensions there are.
Of course, time is not a signal axis in the sense of e.g. a STEM hologram or diffraction pattern, where you have two signal axes of the same type. However, it is also not of the same type as the spatial navigation dimensions.
Reading this while reviewing #118 and I am not convinced that there is a case for having so many classes for the following reasons:
A streak camera collects an image of time versus wavelength <t,E> and when you do a map you get <x,y|t,E>. So, in that way, it really makes most sense to define time as additional signal axis. You might want to extract either spectra at a specific delay <x,y|E>, or time-traces (transients) for a specific wavelength window <x,y|t>.
- the way we structure our data analysis is independent of how the data have been acquired. The fact that the streak camera generate an image with one axis being a time axis is not a reason for processing data with the time as signal axis, in my opinion. When reading the data, we need to set the axis so that the data is structure in a way for analysis, regardless of how it has been acquired.
In fact, for other acquisition modes, such as time-correlated single photon counting, you actually do not have a wavelength axis and time remains the only signal axis <x,y|t>. In the end, an essential feature will be to fit models to these transients.
- I don't see why it needs a specific class and
signal_type
, as this can achieve transposing axes and a generic signal. To give a similar example in a different context, you could model a composition obtained from a EDS linescan across an interface or core-shell nanoparticles, etc. and fits it. The same approach could be used (transposition with a generic signal and fitting) without creating EDS linescan signal type.
These classes are empty at the moment, I would suggest to remove them and only consider creating such signal_type
when the need arise.
from lumispy.
Well, I envision e.g. having some specific models for time resolved data in these classes. Though the additional CL/PL subclasses are maybe overkill at the moment.
from lumispy.
Well, I envision e.g. having some specific models for time resolved data in these classes. Though the additional CL/PL subclasses are maybe overkill at the moment.
It is worth creating these classes only when the needs arise?
Since, it is not defined what the functionalities would entail, what the requirement would be and there is ambiguity on its structure, I don't think that we should plan/speculate on how it should be. At least I can't do it without further information and I am not convinced that this is a efficient use of our time to do this now.
from lumispy.
from lumispy.
To able to use the energy axis facilities of lumispy for streak camera images, we will have to have a 2D signal class that inherits from the 1D luminescence classes. Similarly, it should inherit from a class that provides time-specific functionalities. So I'm convinced that this is the right way to go.
Ok, it seems that it would be need a bit of thinking!
from lumispy.
Related Issues (20)
- Docstring formatting in RTD HOT 11
- Transient signal classes HOT 3
- LumiSpy v0.2 HOT 2
- Create a `remove_background_signal` function HOT 1
- Extend functionality of crop_edges HOT 3
- Implementation of Spectroscopy File Readers HOT 18
- Increase coverage HOT 2
- Webhook failing HOT 3
- Adding an interactive way to slice HS over a wavelength range, and view the result spatially! HOT 12
- Consolidate axis conversion codes
- Failure with numpy 1.24.dev
- Slicing of energy/wavenumber signal with isig fails
- Failure with numpy dev HOT 1
- Documentation is broken HOT 3
- Azure tests failing HOT 2
- Find maximum and width of a peak HOT 1
- Reminder: Change doc-links to sphinx
- Fix test for `remove_spikes` HOT 4
- Slicing TransientSpec HOT 22
- `to_eV()` function and non-uniform axis HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lumispy.