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

Design an ImageStack workspace or similar #12381

Closed
mantid-builder opened this issue Apr 14, 2015 · 3 comments
Closed

Design an ImageStack workspace or similar #12381

mantid-builder opened this issue Apr 14, 2015 · 3 comments
Assignees
Labels
Framework Issues and pull requests related to components in the Framework
Milestone

Comments

@mantid-builder
Copy link
Collaborator

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:

  • 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

@mantid-builder
Copy link
Collaborator Author

@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.

@mantid-builder mantid-builder added Framework Issues and pull requests related to components in the Framework Imaging labels Jun 3, 2015
@mantid-builder mantid-builder added this to the Release 3.5 milestone Jun 3, 2015
@NickDraper NickDraper modified the milestones: Release 3.5, Release 3.6 Sep 14, 2015
@FedeMPouzols
Copy link
Contributor

@NickDraper
Copy link
Contributor

closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues and pull requests related to components in the Framework
Projects
None yet
Development

No branches or pull requests

3 participants