<div dir="ltr">Hi Roger,<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">While converting IFormatWriter for the C++ implementation</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>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++.</div><div><br></div><div>Regards,</div><div>Curtis</div><div><br></div><div>[1] This promising approach was detailed on the mailing list last year: <a href="http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2013-October/002537.html">http://lists.openmicroscopy.org.uk/pipermail/ome-devel/2013-October/002537.html</a></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 6, 2014 at 5:21 AM, Roger Leigh <span dir="ltr"><<a href="mailto:r.leigh@dundee.ac.uk" target="_blank">r.leigh@dundee.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
While converting IFormatWriter for the C++ implementation, I ran into a<br>
few minor oddities which I hope can be clarified, primarily lack of<br>
symmetry with IFormatReader:<br>
<br>
1. The writer saveBytes method has variants which use Region objects to<br>
specify a 2D tile region. The equivalent methods are not in the reader<br>
openBytes methods. Is there a reason for this?<br>
<br>
For C++ we can probably use Boost.MultiArray nD index ranges for<br>
this. Should this be fixed on the Java side?<br>
<br>
2. The reader uses getBitsPerPixel while the writer uses<br>
getValidBitsPerPixel. Is there are reason for this? Which is the more<br>
correct form?<br>
<br>
3. The writer has a setCodecOptions method, but no getCodecOptions. Is<br>
there a reason for that?<br>
<br>
4. The writer has not been updated to use the coreIndex/subresolution<br>
API. It's still using get/setSeries only. While that's probably fine<br>
for writing, should this not be updated to use get/setCoreIndex?<br>
<br>
5. The writer has get/setInterleaved methods. But there are no<br>
corresponding methods for DimensionOrder or use of CoreMetadata. Why is<br>
there just the one property when the other dimensions are also required?<br>
How are the main dimensions specified?<br>
<br>
6. The writer uses ColorModel, but this is Java AWT-only so won't be<br>
useful for C++ unless I reimplement it directly. However, I notice the<br>
reader is using get*LookupTable rather than the ColorModel classes. Why<br>
isn't the writer also using set*LookupTable? Exactly which features of<br>
the ColorModel classes are required? If it's only for LUTs, can't we<br>
just use set*LookupTable methods directly and avoid the AWT classes?<br>
<br>
<br>
Thanks,<br>
Roger<br>
<br>
The University of Dundee is a registered Scottish Charity, No: SC015096<br>
______________________________<u></u>_________________<br>
ome-devel mailing list<br>
<a href="mailto:ome-devel@lists.openmicroscopy.org.uk" target="_blank">ome-devel@lists.<u></u>openmicroscopy.org.uk</a><br>
<a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel" target="_blank">http://lists.openmicroscopy.<u></u>org.uk/mailman/listinfo/ome-<u></u>devel</a><br>
</blockquote></div><br></div>