Ticket #5997 (assigned)

Opened 8 years ago

Last modified 5 years ago

Write a generic LoadImage algorithm

Reported by: Nick Draper Owned by: Owen Arnold
Priority: major Milestone: Backlog
Component: Framework Keywords:
Cc: Blocked By:
Blocking: Tester:


Write an algorithm to load an image file to a workspace, and create a 'basic' instrument definition if we cannot match up to an existing one based on filename. This should vote to open files like any other load algorithm but not normally return a particularly high preference so other more specific loaders can override it.

File type we absolutely have to support:

  • TIFF
  • FITS

It would make sense to use a library that allows us to generically handle multiple file formats. Two that have spring to mind are:

  1. BOOST Generic image library hereafter known as GIL
  2. Freeimage

Both work by using the underlying specific libraries LibTIFF, libPNG etc, but give a consistent interface on top. FreeImage looks simpler as it is just about loading and saving images, GIL is more complex as it also supports image algorithms in a generic way, but is header only and therefore already available on all platforms.

Neither have support for FITS out of the box, but both allow a plug in mechanism to support new formats. A quick search has found a plugin for FITS in GIL. http://ds33.ncsa.uiuc.edu/trac/browser/DMS/afw/trunk/include/lsst/afw/image/fits/fits_io.h?rev=13739

Change History

comment:1 Changed 8 years ago by Owen Arnold

As far as IDFs go, We think that the best approach would be to fabricate detector IDs, and have a 1:1 detector-spectrum mapping. We can create and assign these detector ids as part of the loading routine. If the file name seems to contain an instrument, we'll have a stab at loading that instrument definition file. If not, then we'll dynamically create an instrument with a rectangular detector and set the detector list to match that provided in the file loading part of the image reader.

comment:2 Changed 8 years ago by Nick Draper

  • Milestone changed from Release 2.4 to Release 2.5

Moved at the code freeze for release 2.4

comment:3 Changed 8 years ago by Owen Arnold

Just spoke to Nick again about this one. I need to check that the work is still relevant before proceeding. Contact the EnginX team about this.

comment:4 Changed 7 years ago by Nick Draper

  • Milestone changed from Release 2.5 to Release 2.6

Moved to r2.6 at the end of r2.5

comment:5 Changed 7 years ago by Nick Draper

  • Component changed from Mantid to Framework

comment:6 Changed 7 years ago by Nick Draper

  • Milestone changed from Release 2.6 to Backlog

Moved to backlog at the code freeze for R2.6

comment:7 Changed 7 years ago by Nick Draper

  • Status changed from new to assigned

Bulk move to assigned at the introduction of the triage step

comment:8 Changed 5 years ago by Stuart Campbell

This ticket has been transferred to github issue 6843

Note: See TracTickets for help on using tickets.