NOTICE! This is a static HTML version of a legacy LOCI Software ticket.

LOCI projects are now located on GitHub. The Bio-Formats project can be found here.

Ticket #173 (closed task: wontfix)

Opened 2007-10-08T10:40:10-05:00

Last modified 2008-03-19T15:08:04-05:00

Standard way to "fail through" to another reader

Reported by: curtis Owned by: melissa
Priority: minor Milestone:
Component: bio-formats Severity: minor
Keywords: Cc:
Blocked By: Blocking:


In some cases, there are multiple readers that can ostensibly support a given file, but in reality only one of them will manage to successfully read the file. For example, QTReader supports a number of codecs, but LegacyQTReader supports more of them via QTJava.

It would be nice if there were a way for a reader to throw an exception, something like UnimplementedException which extends FormatException, indicating that it has successfully parsed the file, found nothing wrong, but encountered a feature or aspect of the format that it can't deal with. This type of exception would indicate to ImageReader that it should "fail through" to the next matching reader, rather than die completely.

This feature should be used in many cases where multiple readers handle different features of the same file format. In particular, as we implement readers that delegate to third-party libraries such as JAI Image I/O (#172) or Sanselan (#174), we want to try our own implementations first, but fall back to the multi-format external readers last.

In some cases there may be a performance hit to this approach, so we should exercise caution in how widely we deploy it by evaluating each case individually.

Change History

comment:1 Changed 2008-03-19T15:08:04-05:00 by curtis

  • Status changed from new to closed
  • Resolution set to wontfix
  • Severity set to minor

We have moved away from using "multi-format" readers in favor of embedding multiple approaches within each format's top-level reader. For example, QTReader takes care of calling LegacyQTReader as appropriate, so LegacyQTReader itself is not on the readers.txt list.

We do have both LegacyND2Reader and ND2Reader on the list, which will need to change in order to support configurable switching between ND2 modes (see ticket #263).

We also have TiffReader, which could conceivably be used as a fallback reader any time a TIFF-specific reader tries but fails to read a particular dataset. But this functionality is hardly necessary (the user could just open the file using ImageJ's built-in TIFF support, after all).

As such, I'm closing this ticket.