Version 4 (modified by melissa, 9 years ago) (diff)

Some updates to list of formats for which we can generate public data.

Various enhancements to the data-driven tests

Most of these should probably be turned into tickets...

  • Reading of sub-images. Similar to the md5 test for full planes, it would be a good idea to check the md5 of a fixed-size sub-image (or at the very least, verify that an exception is not thrown).
  • Leaking file handles. File handles that are left open are known to cause a problem on Windows, so we should somehow find a way to test that there are no open file handles after close() has been called on a reader.
  • Reading planes in a random order. All of our tests right now read planes sequentially from 0 to n, but most formats should support reading in any order (compressed QuickTime is the notable exception).
  • Consistent type checking. We could add a field to the config files that gives the name of the reader that should be used for that file. Not particularly useful for files with unique extensions, but for many of the TIFF variants this could be useful.
  • There should be an option to map all of the files into memory before running the tests.
  • A lot of the config files need updating anyway, so now might be an OK time to change the config file format to something a bit more readable. What we have now is fine for files with one series, but for big plates it gets to be a bit unwieldy. Something either XML- or INI-based might be easier to work with.
  • Also, it would be nice to be able to opt out of specific tests in the config files. E.g. OME-XML sanity tests are sometimes expected to fail, so it would be better to just skip the test rather than reporting it as failed and having to re-investigate the failure every time.
  • Also also, it would be nice to be able to test metadata beyond core metadata (so we'd need to be able to define this metadata in the config file). Physical sizes, channel names, and various Instrument/Detector/Laser linkages in particular would be good to test.
  • Experiment with migrating the data-driven tests to JUnit (see also #498).
  • If a test fails because setId failed, then we should skip all subsequent tests for that file.
  • Once we have a reasonable set of public test data, set up a Hudson job to run the data-driven tests on the public test data.

Public test data

Most of the data-driven tests would benefit from having a comprehensive set of public sample data (see also #157).

Formats for which we already have public sample data:

A '*' indicates that we could generate more public data in this format.

Formats for which we can definitely generate public sample data:

  • JPEG
  • PGM
  • FITS
  • PCX
  • GIF
  • Openlab Raw
  • AVI
  • PICT
  • LIM
  • PSD
  • Targa
  • Bio-Rad Gel
  • Fake
  • ECAT-7 (minctoecat)
  • NRRD
  • JPEG-2000
  • Micromanager
  • Text
  • MINC (rawtominc)
  • NIfTI (dicomnifti)
  • Analyze 7.5 (medcon)
  • SDT
  • FV1000 .oib/.oif
  • Zeiss ZVI
  • Leica TCS
  • Aperio SVS
  • Imaris (raw)

Formats for which I need to check whether or not we can generate public sample data:

  • IPLab Mac (Ivision)
  • Deltavision
  • MRC
  • Gatan DM2
  • Imaris (HDF)
  • EPS
  • Alicona AL3D
  • Visitech
  • InCell
  • L2D
  • FEI
  • NAF
  • MRW
  • ARF
  • Oxford Instruments
  • VG-SAM
  • Hamamatsu HIS
  • WA-TOP
  • Seiko
  • TopoMetrix
  • UBM
  • Quesant
  • RHK
  • Molecular Imaging
  • JEOL
  • Amira
  • Unisoku
  • Perkin Elmer Densitometer
  • Nikon ND2
  • SimplePCI .cxd
  • Imaris (TIFF)
  • Molecular Devices Gel
  • Imacon .fff
  • LEO
  • JPK
  • Nikon NEF
  • Nikon TIFF
  • Prairie
  • Metamorph TIFF/STK/ND
  • Improvision TIFF
  • Photoshop TIFF
  • SimplePCI TIFF
  • Burleigh
  • SM-Camera
  • SBIG

Formats for which we definitely cannot generate public sample data:

  • TillVision
  • Olympus CellR/APL
  • Slidebook
  • Cellomics
  • CellWorX
  • Olympus ScanR
  • BD Pathway
  • Opera Flex
  • MIAS