[SCIFIO] Bio-Formats Imaris writer

Thu Jan 15 08:25:13 CST 2015

Hi Henry,

1) Curtis knows this topic better than me, but I believe you can use the
Maven NAR plugin[1] to build native code archives (.nar) which then can be
distributed via a maven repository, such as our http://maven.imagej.net,
and consumed as a normal Maven dependency by your writer. How is the native
code you're using licensed?

2) You're absolutely right, AbstractWriter is provided to take care of as
much boilerplate as possible, to try and keep what developers like you have
to implement to a minimum. We avoid using public/protected fields in our
libraries because of the problems they create, given that there is no way
to respond when such fields are directly modified. The way to access these
fields should be accessor/mutator methods (e.g. getMetadata(),
isInitialized(...), etc...), with the expectation that they can be
overridden if necessary. Since it feels like you're overriding too many of
these, though, could you provide some more information about what
functionality you needed to add/modify? If the API is lacking, my first
choice would be to improve AbstractWriter so that it better meets your
needs (and those of future developers!).

3) So, what you most likely want to do here is implement your own Metadata
class for the ImarisFormat. DefaultMetadata was created as a dummy class to
provide some minimal default implementation for formats that simply don't
have any metadata to store (e.g. the JavaFormat, which only writes images).
If you use DefaultMetadata, your Format should still work - but if you want
to convert an ImarisFormat image to something else (such as an .ome.tif)
you may be missing the opportunity to preserve any Imaris-specific metadata.

I think this flow was not properly described in SCIFIO. To take a step
towards improvement, I updated the custom format tutorial[2] to better
explain the role of format-specific metadata.

As to the actual LUT question, I suggest modeling the ImarisFormat after a
simple format that has a LUT - such as BMPFormat[3]. You can see that the
BMPFormat's metadata implements a HasColorTable interface[4]. It is then
the role of the Parser to populate the metadata's color table[5]. Then it
is the role of the Reader to attach the color table to a plane[6].

The SCIFIOConfig method you mentioned[7] is for external software to set a
custom LUT when saving an image.

Hope this helps. Let us know if you have more questions! Thank you for the
feedback!

Best,
Mark

[1] https://github.com/maven-nar/nar-maven-plugin
[2]
https://github.com/scifio/scifio-tutorials/blob/5f9212a685c18ddc0cb4500e7ac4a3f1aad1940b/core/src/main/java/io/scif/tutorials/core/T3aCustomFormats.java#L123-133
[3]
https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java
[4]
https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L90-91
[5]
https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L283-292
[6]
https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L399-400
[7]
https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/config/SCIFIOConfig.java#L264-271

On Wed, Jan 14, 2015 at 3:28 PM, Henry Pinkard <henry.pinkard at gmail.com>
wrote:

> Hi Curtis and Mark,
>
> Finally back to work on this project. I've created an ImarisFormat class
> in my local copy of SCIFIO and have gotten a basic version of
> ImarisFormat.Writer working. Several questions regarding this:
>
> 1) Since .ims files are a specific type of HDF5 file, I'm utilizing the
> HDF Java library to do the writing. Maven is able to record a dependency
> for the .jar file needed by this library, but I'm not sure how to indicate
> a dependency on the the native files that the library uses through the JNI.
> For testing purposes I just copied these libraries into the SCIFIO root
> directory, but this is obviously not a solution. I assume that there is an
> elegant way of doing this, since the BioFormats Imaris reader is able to
> read these files. Any thoughts?
>
> 2) I'm unsure whether to have the writer extend AbstractWriter or simply
> implement TypedWrtier. I would think that AbstractWriter is provided as a
> stub to easily extend when making writer classes, but the private access to
> all of this classes field's (metadata, initialized, etc.) mean that I have
> to extend many more methods than I would like. Could these fields be made
> protected, or should I switch to TypedWriter and have a lot of empty,
> irrelevant methods?
>
> 3) I'm able to pull all the metadata required for writing these files from
> DefaultMetadata and DefaultImageMetadata, with the exception of two things.
> First, is there a way to get the acquisition date and timestamps form
> individual planes? Second, the config.writerGetColorModel() call that I
> copied from AbstractWriter returns null, as does plane.getColorTable(). Is
> there some other way to get image lookup tables? My test code opens a Tiff
> stack saved by FIJI that has LUTs applied, so I would think they would be
> there. Is there another mechanism for getting image LUTs?
>
> Excited to see this writer become part of SCIFIO in the near future.
>
> Best,
> Henry
>
> On Wed, Jul 16, 2014 at 4:32 PM, Curtis Rueden <ctrueden at wisc.edu> wrote:
>
>> Hi Henry,
>>
>> > I've created a class in the io.scif.formats package for my writer.
>> > Since I only have the writer components, but not the reader, how
>> > should I go about implementing all of the component classes of Format
>> > (Metadata, Parser, Checker, Reader, Writer, Translator). The first 4
>> > are listed as mandatory in the tutorial, but it seems like I shouldn't
>> > need all of them for writing functionality alone.
>>
>> Agreed, it should not be necessary to create Reader or Parser components.
>> However, writer-only components are still a little rough around the edges.
>> The relevant issue is:
>>
>> https://github.com/scifio/scifio/issues/211
>>
>> Feel free to comment on that so that GitHub sends you updates if you care
>> about progress on it.
>>
>> But in the meantime, it should still be possible to create a writer-only
>> component. For an example, see the JavaFormat:
>>
>>
>> https://github.com/scifio/scifio/blob/scifio-0.15.4/scifio/src/main/java/io/scif/formats/JavaFormat.java
>>
>> Regards,
>> Curtis
>>
>>
>> On Wed, Jun 25, 2014 at 1:21 PM, Henry Pinkard <henry.pinkard at gmail.com>
>> wrote:
>>
>>> Hi Curtis,
>>>
>>> This all sounds great. I've cloned the SCIFIO core as well as the
>>> tutorials, which have been quite helpful in getting things set up.
>>>
>>> I've created a class in the io.scif.formats package for my writer. Since
>>> I only have the writer components, but not the reader, how should I go
>>> about implementing all of the component classes of Format (Metadata,
>>> Parser, Checker, Reader, Writer, Translator). The first 4 are listed as
>>> mandatory in the tutorial, but it seems like I shouldn't need all of them
>>> for writing functionality alone.
>>>
>>> Best,
>>> Henry
>>>
>>>
>>> On Sun, Jun 1, 2014 at 7:27 AM, Curtis Rueden <ctrueden at wisc.edu> wrote:
>>>
>>>> Hi Henry,
>>>>
>>>> > Over the past couple years, I've been developing and testing a java
>>>> > library that is capable of writing Imaris .ims files. This library has
>>>> > allowed me to build an ImageJ plugin that automatically stitches,
>>>> > processes, and converts OME-TIFFs from Micro-Manager into Imaris
>>>> > files, which in turn allows a significantly greater throughput of
>>>> > imaging data with much less effort from users.
>>>>
>>>> Sounds great!
>>>>
>>>> > This library has been instrumental to the workflow of users in the
>>>> > imaging center in which I work, and I want to find a way to share its
>>>> > utility with researchers everywhere. Incorporating it into the
>>>> > Bio-Formats exporter would both increase its visibility and leverage
>>>> > the multitude of formats on Bio-Formats' front end to make it usable
>>>> > with all types of microscopy data.
>>>>
>>>> Rather than implementing a Bio-Formats writer, I encourage you to check
>>>> out SCIFIO [1, 2, 3]. Though still in beta, SCIFIO is the core I/O
>>>> mechanism of ImageJ2, which is finally due for release later this week.
>>>> SCIFIO uses the SciJava plugin framework, meaning your writer would be
>>>> automatically discovered and used as appropriate with no additional work
>>>> from you. And we have recently integrated SCIFIO directly into ImageJ at
>>>> the core level, so things like File > Open now use it, including whatever
>>>> format plugins are available. (SCIFIO also has a Bio-Formats format plugin,
>>>> so that all of the BF formats work in ImageJ that way, too!)
>>>>
>>>> You could then serve your Imaris writer from its own ImageJ update site
>>>> [4, 5], to make it available to all ImageJ users.
>>>>
>>>> > In addition, I've convinced Bitplane to make their format open source,
>>>> > and I believe this may allow .ims files to grow beyond a proprietary
>>>> > file format into a generalized multi-resolution format useful for a
>>>> > variety of applications that deal with the visualization of extremely
>>>> > large stitched images.
>>>>
>>>> Glad to hear that Bitplane is willing to do this. In that case, if you
>>>> do complete a SCIFIO Imaris writer and want to donate the code upstream,
>>>> you could file a pull request against the SCIFIO LifeSci project [6] to
>>>> contribute it there, since that project houses readers & writers for _open_
>>>> life sciences formats. So if Bitplane publishes an open specification, we
>>>> would be willing to add it to the project.
>>>>
>>>> If you have any questions about SCIFIO, please feel free to use the
>>>> SCIFIO mailing list [7]. Or if you go the Bio-Formats route, you can use
>>>> ome-devel [8].
>>>>
>>>> Regards,
>>>> Curtis
>>>>
>>>> [1] http://loci.wisc.edu/software/scifio
>>>> [2] https://github.com/scifio/scifio
>>>> [3] https://github.com/scifio/scifio-tutorials
>>>> [4] http://wiki.imagej.net/Update_Sites
>>>> [5] http://wiki.imagej.net/List_of_update_sites
>>>>  [6] https://github.com/scifio/scifio-lifesci
>>>> [7] http://scif.io/mailman/listinfo/scifio
>>>> [8] http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel/
>>>>
>>>>
>>>> On Thu, May 29, 2014 at 6:55 PM, Henry Pinkard <henry.pinkard at gmail.com
>>>> > wrote:
>>>>
>>>>> Hi Melissa and Curtis,
>>>>>
>>>>> Over the past couple years, I've been developing and testing a java
>>>>> library that is capable of writing Imaris .ims files. This library has
>>>>> allowed me to build an ImageJ plugin that automatically stitches,
>>>>> processes, and converts OME-TIFFs from Micro-Manager into Imaris files,
>>>>> which in turn allows a significantly greater throughput of imaging data
>>>>> with much less effort from users.
>>>>>
>>>>> This library has been instrumental to the workflow of users in the
>>>>> imaging center in which I work, and I want to find a way to share its
>>>>> utility with researchers everywhere. Incorporating it into the Bio-Formats
>>>>> exporter would both increase its visibility and leverage the multitude of
>>>>> formats on Bio-Formats' front end to make it usable with all types of
>>>>> microscopy data. In addition, I've convinced Bitplane to make their format
>>>>> open source, and I believe this may allow .ims files to grow beyond a
>>>>> proprietary file format into a generalized multi-resolution format useful
>>>>> for a variety of applications that deal with the visualization of extremely
>>>>> large stitched images. I'm happy to rework the library in whatever ways
>>>>> make it easiest to incorporate on your end. Let me know your thoughts on
>>>>> how to best proceed.
>>>>>
>>>>> Best,
>>>>> Henry
>>>>>
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> SCIFIO mailing list
> SCIFIO at scif.io
> http://scif.io/mailman/listinfo/scifio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://scif.io/pipermail/scifio/attachments/20150115/29e2b555/attachment-0002.html>