Ticket #11543 (new)

Opened 5 years ago

Last modified 5 years ago

Design an ImageStack workspace or similar

Reported by: Federico M Pouzols Owned by: Federico M Pouzols
Priority: major Milestone: Release 3.5
Component: Framework Keywords: IMAT
Cc: owen.arnold@…, nick.draper@… Blocked By:
Blocking: Tester:

Description

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.

Change History

comment:1 Changed 5 years ago by Federico M Pouzols

  • Keywords IMAT added

comment:2 Changed 5 years ago by Federico M Pouzols

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 (#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.

comment:3 Changed 5 years ago by Owen Arnold

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.

comment:4 Changed 5 years ago by Stuart Campbell

This ticket has been transferred to github issue 12381

Note: See TracTickets for help on using tickets.