You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Putting it overly simple, what we need is some kind of "ArrayProperty + niceties" to represent stacks of images. A true workspace type is the ideal solution.
Some initial thoughts/requirements:
avoid "overheads" of workspace types like Workspace2D: no errors, no doubles, etc. (optionally)
efficient, raw storage of data
support for types like 8 and 16 bits integers, etc.
file-backed storage / lazy loading
python interface for scripting, with numpy array support.
contiguous memory blocks are convenient but, equally, deques and other sparse structures could be useful
compression
typical dimensions: X, Y, angle, time, and potentially more
terminology can be an issue when considering disparate applications and contexts
From an early discussions with Owen, it seems that it would be a good idea to create some sort of MD workspace type, drawing from IMDHistoWorkspace.
I'll start a design document for this, and we'll need a bit of discussion.
Keywords: IMAT
The text was updated successfully, but these errors were encountered:
@FedeMPouzols (2015-04-28T10:53:50):
One comment about individual images:
Presently we don't seem to have a neat solution to represent single images as workspaces that would behave as intuitive image objects. The solution implemented so far, using a vector of vectors and setImage/getImage methods in Workspace2D, was discussed here: https://github.com/mantidproject/documents/blob/master/Design/WorkspaceImageMethods.md.
As part of a recent ticket (http://trac.mantidproject.org/mantid/ticket/11575) an option has been added to LoadFITS to load images as Workspace2D objects with one spectrum per row. With this, plot2D works. The alternative, and default behavior of LoadFITS, is to create one spectrum per pixel. It turns out that the one spectrum per pixel approach is approximately 6-7 slower because of the large number of smallish Spectrum objects that need to be created. Because of this I'd be tempted to set as default the variant that loads one spectrum per row of pixels.
This ticket is about a different problem (stacks of images) which raises different/more concerns, especially about memory efficiency, but it would be a good opportunity to revisit the problem of how to represent an image as a Mantid workspace.
@OwenArnold (2015-04-28T11:03:59):
I see this as a critical task in Mantid that will have far-reaching useful consequences. Using IMDHistoWorkspace as a base type seems like a good idea, but we may need to move some things around to make that interface work well for the lean image types we need.
The IMDHistoWorkspace type has the advantages of n-dimensional iterators with some in-built and well tested functionality for neighbour finding, which is very useful to perform things like fast smoothing. The iterators also work extremely well in multi-threaded scenarios.
This issue was originally TRAC 11543
Original Reporter: @FedeMPouzols
Motivated by IMAT.
Putting it overly simple, what we need is some kind of "ArrayProperty + niceties" to represent stacks of images. A true workspace type is the ideal solution.
Some initial thoughts/requirements:
From an early discussions with Owen, it seems that it would be a good idea to create some sort of MD workspace type, drawing from IMDHistoWorkspace.
I'll start a design document for this, and we'll need a bit of discussion.
Keywords: IMAT
The text was updated successfully, but these errors were encountered: