Ticket #354 (closed enhancement: fixed)

Opened 11 years ago

Last modified 11 years ago

Bio-Formats writers should use the loci.common I/O classes

Reported by: curtis Owned by: melissa
Priority: minor Milestone: bio-formats-4.1
Component: bio-formats Severity: serious
Keywords: Cc: spl@…
Blocked By: Blocking:


Many of the writer subclasses in loci.formats.out were written before we standardized our I/O with loci.common.IRandomAccess. Instead of using java.io.RandomAccessFile and java.io.File, the writers should uniformly use loci.common.RAFile and loci.common.Location.


Change History

comment:1 Changed 11 years ago by curtis

  • Cc spl@… added

comment:2 Changed 11 years ago by curtis

This functionality will allow applications to more easily write image data to non-file destinations, such as output streams, by providing an alternative subclass of loci.common.IRandomAccess.

For example, an RAOutputStream class could (trivially) implement all of the java.io.DataOutput methods while throwing an "unsupported" exception for the java.io.DataInput and random access (i.e., seek) methods. Then any writer that uses only the allowed method calls would be easily streamable using an RAOutputStream with loci.common.Location.mapFile(String, IRandomAccess).

For another theoretical example, see: source:trunk/utils/ReadWriteInMemory.java

comment:3 Changed 11 years ago by curtis

One other change would be useful to facilitate this support. Currently, loci.common.RandomAccessStream has logic to decide which type of IRandomAccess object to create from the id string. This logic should be refactored into a loci.common.Location.getHandle(String) method or similar that returns an IRandomAccess object. This method would take care of the work of checking getMappedId, getMappedFile and string formatting (e.g., using RAUrl if the string starts with "http:"). Then, both RandomAccessStream and the format writers could call Location.getHandle(String) to easily leverage the mapping functionality.

comment:4 Changed 11 years ago by melissa

  • Milestone set to bio-formats-4.1.0

comment:5 Changed 11 years ago by melissa

See r4900; Location.getHandle(String) was added, and most format writers were modified to use an IRandomAccess instead of a RandomAccessFile.

comment:6 Changed 11 years ago by melissa

As of r4913, all writers except for loci.formats.out.LegacyQTWriter use loci.common.RandomAccessOutputStream to write files. As far as I know, QT Java only allows movies to be written to a file on disk, so it's probably not feasible to have LegacyQTWriter use RandomAccessOutputStream.

comment:7 Changed 11 years ago by curtis

In my opinion, this ticket will be solved once the commented out code at the bottom of source:trunk/utils/ReadWriteInMemory.java works as expected, even if it does not work with LegacyQTWriter, as long as unsupported formats throw a FormatException, IllegalStateException or something similar.

comment:8 Changed 11 years ago by melissa

  • Status changed from new to closed
  • Resolution set to fixed

(In [4919]) * Changed TiffTools.overwriteIFDValue to accept a String filename instead of a RandomAccessFile.

  • Updated loci.ome.editor.MetadataPane to use TiffTools.overwriteComment(String, String) instead of TiffTools.overwriteIFDValue.
  • Updated ReadWriteInMemory utility to take advantage of the loci.common.RABytes fixes in r4917.

Reading from/writing to files in memory should work now. Closes #354.

Note: See TracTickets for help on using tickets.