[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