acquaman/acquaman — Issue #245: Limitations on AMScanView and AMGenericScanEditor
Author: dretrex
Created: 2012-03-02 20:35:22+00:00
State: open
Labels: Bug - Performance, Impact - High, Module - Acquisition, Module - Data Management, Module - Visualization, Reason - Feature Request, Reason - Missing from API, Reason - User Experience, Time - weeks

I've been thinking on AMScanView and AMGenericScanEditor a bunch lately and feel I should list some of the deficiencies that I've noticed. Maybe other people can bring up their things they've noticed as well and we can have a discussion on upgrades. Here are some of the things that I've noticed:

##### Displaying data sources
Different normalization constraints: There are conceivably many situations situations where a normalization scheme of min mapped to 0 and max mapped to 1 is not appropriate. I've highlighted the issue in #242. Handling these in MPlot is no big deal since we can just make another axis scale to correspond to the different schemes, but then we still need to decide where to put the axis. We can necessarily just choose the right axis since that contains the vertical axis for images. Likely some quasi-sophisticated logic will be required.

##### Handling 2D scans
* As I eluded to in #243, we aren't able to go about displaying 2D scans like we currently handle XAS scans because of the memory requirements. If it only had to contain images then the problem is more tractable within the current framework but when you include the spectra file you are going to run into problems.
* 2D scans also bring up an interesting point where it no longer makes sense to simply be able to add scans into the current scan to compare them. Having multiple 2D scans in a single editor doesn't really make a lot of sense since images will just overlap each other. However it is conceivable that people might want to look at some 1D scans at the same time as the 2D scan. Again, more logic for adding scans to editors would be a requirement.

##### Hiding/Showing data sources
* Within the current framework, the simple approach to this is not difficult. We can simply change the hiddenFromUsers flag inside of AMDataSource and do the appropriate logic to add it to the scan bar in AMScanView. However, it is my desire that if a data source is hiddenFromUsers, that it is not stored in memory.
* As a corollary, there are also some data sources that should _always_ be hidden from users. Loading up the spectra files for 2D scans is an example of this. You will still want access to that information (do a 2D map equivalent of our current spectra->PFY in XAS scans), but that information should likely never be stored in memory.

##### Lots of editors open simultaneously
* I like the concept of the current scan having a new scan editor for every new scan that is performed, however, I'm running into memory issues (#235, broken record, I know). I'm wondering if we should move to a model where there is only ever one scan editor open for scans that are being run rather than opening a new editor and then switching to the new one (#161).
* Although not necessarily a part of this issue, we probably need to have a process for choosing between what kind of AMDataStore we should use depending on the type of scan that we are opening (likely more complicated).
* As part of potentially moving to a model of having only one scan editor (or dramatically reducing the number of scan editors), I think we should try and accomodate having sets of scans going into a single editor. This would have to be within reason and may be linked too hiding big data sources automatically. But I figured I'd at least bring it up.

I'd **_really_** appreciate your guys' thoughts on this because this is going to become a _major_ issue for me. I also apologize if some of the thoughts seem segmented, I wrote this issue up over the course of the last three days.