Closed mwalls closed 12 years ago
msarahan
commented
13 years ago I have added something like this. Please grab the latest source, and tell me what you think.
https://github.com/hyperspy/hyperspy/commit/d391b175b6c6cc653f430d7b90ac6a896be792c0
francisco-dlp
commented
13 years ago Cool! What about printing the object type in the first line about the object type e.g. hyperspy.signals.spectrum.Spectrum in the first line? This would make the "data representation" and "signal type" lines redundant but I think that it is more informative.
Are you working in prompting the user to assign a sygnal type if none is defined? Otherwise I could do it.
msarahan
commented
13 years ago The object type you propose is only equally informative if we have pre-programmed the subclass which ends up representing the file.
For example, we don't currently have an EDXSpectrum class. If someone loads a DM3 file that is an EDX SI, the current approach would show that it is spectral data, and that it came from EDX. The object type would default to Spectrum, which says nothing about the signal.
Trying to create subclasses for every data type is obviously not a good idea. I also am not sure that a printout of the class is more informative to the average user.
I don't really think a prompt for undefined data types is a good idea, either. What purpose would it really serve? If we have special subclass methods that aren't available unless a data set is declared as, say, EELS, then that's a very good purpose. For images, though, the data type doesn't especially matter, and the thought of a prompt becomes extremely tedious. It's especially true because most image formats won't have signal metadata.
What I would propose instead is easy converter functions, like you have for going between Image and Spectrum classes. Any Spectrum subclass should be easily convertible to any other subclass, which would just add in the other methods.
Perhaps the best compromise might be a prompt, but only for spectral data. I'm going to keep polishing the image processing stuff, so if you want a prompt, please do write it.
-Mike
On Mon, Sep 26, 2011 at 3:09 PM, francisco-dlp reply@reply.github.com wrote:
Cool! What about printing the object type in the first line about the object type e.g. hyperspy.signals.spectrum.Spectrum in the first line? This would make the "data representation" and "signal type" lines redundant but I think that it is more informative.
Are you working in prompting the user to assign a sygnal type if none is defined? Otherwise I could do it.
Reply to this email directly or view it on GitHub: https://github.com/hyperspy/hyperspy/issues/17#issuecomment-2198552
francisco-dlp
commented
13 years ago What I meant by "informative" is that the user will learn that the object is an instance of a given class that has a given import path and so on. This can help the users understand what is going on behind the scenes. This might not be of great interest for the average user, but it will help the average user to become an advanced user faster imo.
I think that in the long-term we will have as many subclasses of Spectrum as signals are analysing our users because, despite the many common tools and infrastructure, a lot of customization is required to make the users of a particular technique feel at home with a data analysis package. Therefore, I think that it makes sense to implement Mike's prompting proposal. I'll work on it.
Best,
Francisco
2011/9/26 Mike Sarahan < reply@reply.github.com>
The object type you propose is only equally informative if we have pre-programmed the subclass which ends up representing the file.
For example, we don't currently have an EDXSpectrum class. If someone loads a DM3 file that is an EDX SI, the current approach would show that it is spectral data, and that it came from EDX. The object type would default to Spectrum, which says nothing about the signal.
Trying to create subclasses for every data type is obviously not a good idea. I also am not sure that a printout of the class is more informative to the average user.
I don't really think a prompt for undefined data types is a good idea, either. What purpose would it really serve? If we have special subclass methods that aren't available unless a data set is declared as, say, EELS, then that's a very good purpose. For images, though, the data type doesn't especially matter, and the thought of a prompt becomes extremely tedious. It's especially true because most image formats won't have signal metadata.
What I would propose instead is easy converter functions, like you have for going between Image and Spectrum classes. Any Spectrum subclass should be easily convertible to any other subclass, which would just add in the other methods.
Perhaps the best compromise might be a prompt, but only for spectral data. I'm going to keep polishing the image processing stuff, so if you want a prompt, please do write it.
-Mike
On Mon, Sep 26, 2011 at 3:09 PM, francisco-dlp reply@reply.github.com wrote:
Cool! What about printing the object type in the first line about the object type e.g. hyperspy.signals.spectrum.Spectrum in the first line? This would make the "data representation" and "signal type" lines redundant but I think that it is more informative.
Are you working in prompting the user to assign a sygnal type if none is defined? Otherwise I could do it.
Reply to this email directly or view it on GitHub: https://github.com/hyperspy/hyperspy/issues/17#issuecomment-2198552
Reply to this email directly or view it on GitHub: https://github.com/hyperspy/hyperspy/issues/17#issuecomment-2198732
On opening a datafile the nature of the data should be sent to the user, as well as the filetype, e.g EELS SI, not just .dm3. If no data type is found, the user should maybe be prompted to assign one.