[ome-devel] Discrepancies between IFormatReader and IFormatWriter

[Melissa Linkert]

Hi Roger,

> >1. The writer saveBytes method has variants which use Region objects to
> >specify a 2D tile region.  The equivalent methods are not in the reader
> >openBytes methods.  Is there a reason for this?
> >
> >    For C++ we can probably use Boost.MultiArray nD index ranges for
> >this.  Should this be fixed on the Java side?

No particular reason other than that we just haven't done it yet.

> >2. The reader uses getBitsPerPixel while the writer uses
> >getValidBitsPerPixel.  Is there are reason for this?  Which is the more
> >correct form?

There isn't a real reason for this, no.  Those methods were intended as
stop-gap solutions until the number of significant bits was added to the
data model (which is now the case).

> >3. The writer has a setCodecOptions method, but no getCodecOptions.  Is
> >there a reason for that?

Not especially, no.

> >4. The writer has not been updated to use the coreIndex/subresolution
> >API.  It's still using get/setSeries only.  While that's probably fine
> >for writing, should this not be updated to use get/setCoreIndex?

None of the supported output formats have any real way of handling resolution
data, so adding resolution support to the writer API has not been a priority.

> >5. The writer has get/setInterleaved methods.  But there are no
> >corresponding methods for DimensionOrder or use of CoreMetadata.  Why is
> >there just the one property when the other dimensions are also required?
> >  How are the main dimensions specified?

setMetadataRetrieve is expected to have been called with a minimum
amount of metadata, as defined by:

https://github.com/openmicroscopy/bioformats/blob/develop/components/formats-api/src/loci/formats/MetadataTools.java#L316

As with bits per pixel, get/setInterleaved pre-dates the inclusion of
this value in the model.

> >6. The writer uses ColorModel, but this is Java AWT-only so won't be
> >useful for C++ unless I reimplement it directly.  However, I notice the
> >reader is using get*LookupTable rather than the ColorModel classes.  Why
> >isn't the writer also using set*LookupTable?  Exactly which features of
> >the ColorModel classes are required?  If it's only for LUTs, can't we
> >just use set*LookupTable methods directly and avoid the AWT classes?

ColorModel was used in the writer API originally because most of the
writer classes were initially working with BufferedImages (and some
still do, given the use of Java's Image I/O classes).  Using some form
of color table encapsulation class in C++ would be acceptable.

> 7. Are get/setFramesPerSecond used and/or useful?  Looking at the code,
> they aren't used by the Java writer in any meaningful way?  Can these be
> omitted from the C++ code?

The frames per second setting is used in the APNG, AVI, and QuickTime
writers.  Preserving this in C++ is necessary.

> 8. Unlike IFormatReader, there's no getUnderlyingWriters to get hold of
> wrapped writers.  Is that intentional, or could this be added?

You can do this with WriterWrapper's unwrap methods and ImageWriter's
getWriters() method.  getUnderlyingReaders() is needed because the
reader that accepts the fileset may not be the reader that actually
performs the pixel data reading (e.g. in a fileset containing multiple
TIFF files and a metadata file).  In the output formats that we support,
the writer that accepts the fileset-to-be is also the one to write pixel
data - there is far less wrapping occurring in the writer stack.

If you feel strongly that any of these are things that must be changed
in the Java API, feel free to add to:

https://trac.openmicroscopy.org.uk/ome/ticket/12181

-Melissa

On Mon, Sep 08, 2014 at 02:36:28PM +0100, Roger Leigh wrote:
> On 06/09/14 11:21, Roger Leigh wrote:
> >Hi,
> >
> >While converting IFormatWriter for the C++ implementation, I ran into a
> >few minor oddities which I hope can be clarified, primarily lack of
> >symmetry with IFormatReader:
> >
> >1. The writer saveBytes method has variants which use Region objects to
> >specify a 2D tile region.  The equivalent methods are not in the reader
> >openBytes methods.  Is there a reason for this?
> >
> >    For C++ we can probably use Boost.MultiArray nD index ranges for
> >this.  Should this be fixed on the Java side?
> >
> >2. The reader uses getBitsPerPixel while the writer uses
> >getValidBitsPerPixel.  Is there are reason for this?  Which is the more
> >correct form?
> >
> >3. The writer has a setCodecOptions method, but no getCodecOptions.  Is
> >there a reason for that?
> >
> >4. The writer has not been updated to use the coreIndex/subresolution
> >API.  It's still using get/setSeries only.  While that's probably fine
> >for writing, should this not be updated to use get/setCoreIndex?
> >
> >5. The writer has get/setInterleaved methods.  But there are no
> >corresponding methods for DimensionOrder or use of CoreMetadata.  Why is
> >there just the one property when the other dimensions are also required?
> >  How are the main dimensions specified?
> >
> >6. The writer uses ColorModel, but this is Java AWT-only so won't be
> >useful for C++ unless I reimplement it directly.  However, I notice the
> >reader is using get*LookupTable rather than the ColorModel classes.  Why
> >isn't the writer also using set*LookupTable?  Exactly which features of
> >the ColorModel classes are required?  If it's only for LUTs, can't we
> >just use set*LookupTable methods directly and avoid the AWT classes?
> 
> 7. Are get/setFramesPerSecond used and/or useful?  Looking at the code,
> they aren't used by the Java writer in any meaningful way?  Can these be
> omitted from the C++ code?
> 
> 8. Unlike IFormatReader, there's no getUnderlyingWriters to get hold of
> wrapped writers.  Is that intentional, or could this be added?
> 
> 
> Thanks,
> Roger
> 
> --
> Dr Roger Leigh -- Open Microscopy Environment
> Wellcome Trust Centre for Gene Regulation and Expression,
> College of Life Sciences, University of Dundee, Dow Street,
> Dundee DD1 5EH Scotland UK   Tel: (01382) 386364
> 
> The University of Dundee is a registered Scottish Charity, No: SC015096
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel