[ome-devel] Discrepancies between IFormatReader and IFormatWriter

Curtis Rueden ctrueden at wisc.edu
Sat Sep 6 15:14:21 BST 2014


Hi Roger,

> While converting IFormatWriter for the C++ implementation

>From this mail, I infer that a full C++ version of Bio-Formats is in the
works? And that other possible solutions such as Avian [1] have been
discarded as unsuitable? If so, I would find it very helpful if more
information about the project directions for native Bio-Formats could be
shared on ome-devel. Unless I missed a mail (and apologies if so), this is
the first I have seen talking about a language translated version of
IFormatHandler/Reader/Writer to C++.

Regards,
Curtis

[1] This promising approach was detailed on the mailing list last year:
http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2013-October/002537.html


On Sat, Sep 6, 2014 at 5:21 AM, Roger Leigh <r.leigh at dundee.ac.uk> 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?
>
>
> Thanks,
> Roger
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20140906/ecb12337/attachment.html>


More information about the ome-devel mailing list