<div dir="ltr">Hi Mark,<div><br></div><div>Okay, I'm following four tickets for LUTs and timestamps and I can update the writer accordingly once those are settled. Thanks for that.</div><div><br></div><div>In the meantime, I looked into the native libraries issue a bit more. The purpose of the NAR plugin seems to be compiling native code and adding them to archives, but since I already have the platform specific binaries, I think there is a simpler way of doing this that doesn't rely on having to compile the native code, which you can read more about here:</div><div><br></div><div><a href="http://web.archive.org/web/20120627025240/http://www.buildanddeploy.com/node/14">http://web.archive.org/web/20120627025240/http://www.buildanddeploy.com/node/14</a><br></div><div><a href="http://web.archive.org/web/20120308042202/http://www.buildanddeploy.com/node/17">http://web.archive.org/web/20120308042202/http://www.buildanddeploy.com/node/17</a><br></div><div><br></div><div>Basically, the idea is: </div><div>1) Add the third party .jar with JNI code that calls native binaries as a dependency </div><div>2) Package native binaries (.dll, .so, or .jnilib) into separate .jar files specific to each OS/architecture. </div><div>3) Add these .jar's to the SCIFIO maven repository with a classifier flag indicating OS/arch. </div><div>4) Add dependencies that get the correct jar based on OS/arch. </div><div>5) Use maven dependency plugin to unpack these libraries at build time. </div><div>6) Use maven surefire plugin to set java.library.path so that native libraries can be found at run time.</div><div><br></div><div>I think much of this needs to happen from your end (but this is my first time using maven, so correct me if I'm wrong). I've created the .jar's holding the native code, and I have the .jar with JNI code as well that I can pass along.</div><div><br></div><div>What do you think?</div><div><br></div><div>Best,</div><div>Henry</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 9:20 AM, Mark Hiner <span dir="ltr"><<a href="mailto:hiner@wisc.edu" target="_blank">hiner@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Henry,<span class=""><br><br>>Can you offer up any examples of how to extract date/time metadata from image planes?<br><br></span></div>Of course, sorry I forgot these in my last e-mail.<br><br></div>Basically time stamps can be incorporated into Metadata by using the net.imagej.axis.LinearAxis API to set the origin and scale[1], and CalibratedAxis to set the units[2] on the time axis (Axes.TIME) of the ImageMetadata.<br><br></div>However, this process is not automated yet so only Formats which explicitly set this information would have time stamp information, and there is no API in the Plane to convert its plane index to a time stamp. So, I opened another issue to get these populated automatically[3] - at which point a Plane object should just be able to tell you its time/date stamp, for any core SCIFIO format that records this information.<span class=""><br><div><br>>My TIFF dataset was simply one of the ImageJ samples. I made it using a
pre-IJ2 version of FIJI by selecting File--Open samples--Mitosis and
saving as a TIFF.<br>>I then reopened it using SCIFIO.<br><br></div></span><div>Great, thanks. I'll do this and look into why the LUTs aren't populated.<br><br></div><div>Best,<br>Mark<br></div><div><br>[1] <a href="https://github.com/imagej/imagej-common/blob/1c96184fda188eba9d56d87364e141dbf07a286d/src/main/java/net/imagej/axis/LinearAxis.java#L44-50" target="_blank">https://github.com/imagej/imagej-common/blob/1c96184fda188eba9d56d87364e141dbf07a286d/src/main/java/net/imagej/axis/LinearAxis.java#L44-50</a><br>[2] <a href="https://github.com/imagej/imagej-common/blob/master/src/main/java/net/imagej/axis/CalibratedAxis.java#L47" target="_blank">https://github.com/imagej/imagej-common/blob/master/src/main/java/net/imagej/axis/CalibratedAxis.java#L47</a><br></div><div>[3] <a href="https://github.com/scifio/scifio/issues/240" target="_blank">https://github.com/scifio/scifio/issues/240</a><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 5:27 PM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mark,<div><br></div><div>Can you offer up any examples of how to extract date/time metadata from image planes?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Jan 15, 2015 at 4:21 PM, Mark Hiner <span dir="ltr"><<a href="mailto:hiner@wisc.edu" target="_blank">hiner@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Henry,<span><br><br>> Is it possible to include these binaries directly in the maven repository?<br><br></span></div>Not directly. But since their license allows them to be redistributed, I think what we want is to make NARs out of them[1] and put the NAR in the maven repository.<br><br></div>However, there are almost certainly limitations right now. I personally do not have experience with the nar-maven-plugin, but I would go into it expecting some hurdles.<br><br></div>On the other hand, I think your ImarisFormat is an awesome use case for the nar-maven-plugin and this is a great opportunity to work out problems and document NAR usage in SCIFIO/ImageJ2/Fiji! So I'd be happy to help investigate further.</div></blockquote><div><br></div></span><div>Okay, I'll play around with the NAR library and see what I come up with.</div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Sort of. I think the SCIFIOConfig and Writer.getColorModel API are incorrect to use java.awt.image.ColorModels. I opened a ticket[4] to update them to the ImgLib2 ColorTable class. When that ticket is complete, this is how everything should work:<br><br></div><div>* You should make an ImarisFormat.Metadata that is a trivial extension of DefaultMetadata, but implements the HasColorTable interface<br></div><div>* When your Writer is passed a SCIFIOConfig with an attached ColorTable, the framework will pass the ColorTable to the Writer's ImarisFormat.Metadata<br></div><div>* In your Writer's writePlane implementation, you would check for a ColorTable on a) the provided Plane and b) the attached Metadata and write it out as appropriate.<br><br></div><div>So asking the Plane for its ColorTable was the right thing to do.<br></div></div></div></blockquote><div><br></div></span><div>Okay, I'm watching the ticket, so once everything works as it should I'll update this. </div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>The fact that the ColorTable isn't being transferred from your original TIFF dataset is likely a bug. I'm not sure if it wasn't read properly on the TIFF side, or if it was read but didn't get passed to your ImarisFormat.Writer. Could you share your failing TIFF dataset so I can debug a bit more and figure out where it's going wrong? (note that you can use Fiji to upload a dataset[5] so that it won't be shared publicly)<br></div><div><br></div></div></div></blockquote><div><br></div></span><div>My TIFF dataset was simply one of the ImageJ samples. I made it using a pre-IJ2 version of FIJI by selecting File--Open samples--Mitosis and saving as a TIFF. I then reopened it using SCIFIO.</div><div><br></div><div>Best,</div><div>Henry</div><div><div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div><div><br></div></div></div><div><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 15, 2015 at 11:07 AM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mark,<div><br></div><div>Thanks for the quick reply!<br><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div></div>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 <a href="http://maven.imagej.net" target="_blank">http://maven.imagej.net</a>, and consumed as a normal Maven dependency by your writer. How is the native code you're using licensed? <br></div></div></div></div></blockquote><div><br></div></span><div>I don't actually need to build the native archives. They are distributed as pre built binaries on the HDF website. Is it possible to include these binaries directly in the maven repository? The license is a "BSD style open-source license." More info can be found at: <a href="http://www.hdfgroup.org/products/licenses.html" target="_blank">http://www.hdfgroup.org/products/licenses.html</a></div><span><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>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!).<br></div></div></div></blockquote><div><br></div></span><div>As I look over this again, I think that this writer is probably an exception that operates by different mechanisms than most Formats, and probably doesn't warrant a change in the API. more on this below.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div></div>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.<br><br></div>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.<br><br>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].<br><div><div><div><br></div><div>The SCIFIOConfig method you mentioned[7] is for external software to set a custom LUT when saving an image.</div></div></div></div></blockquote><div><br></div></span><div>Actually, I think the SCIFIO tutorials described the flow quite well. The library that I'm adding in to the ImarisFormat is only for writing IMS files and doesn't support reading them, so I opted to model this off of JavaFormat. There are a few basic metadata fields needed for writing, but I didn't think it necessary to create a format-specific metadata class to hold them. Since Imaris is a software for only analysis, no acquisition softwares save directly into IMS format. So the most complete set of metadata will always reside in whatever format was used to create the IMS file. If you think it would be better to create an ImarisFormat.Metadata class, I'm happy to do so, but I don't think it would affect the functionality of the format. </div><div><br></div><div>I took a look at BMPFormat, and I think the color table here is being read from a BMP file and then stored in the BMP specific metadata, right? I'm actually looking to do the opposite--write an LUT into an IMS. So then I should use the one provided by the SCIFIO config method, right?</div><div><br></div><div>How about date/time stamps? Is there any way to extract this from default metadata classes or does it need to be done in a metadata format-specific manner?</div><div><br></div><div>Best,</div><div>Henry</div><div><div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div></div><div><br><br>[1] <a href="https://github.com/maven-nar/nar-maven-plugin" target="_blank">https://github.com/maven-nar/nar-maven-plugin</a><br>[2] <a href="https://github.com/scifio/scifio-tutorials/blob/5f9212a685c18ddc0cb4500e7ac4a3f1aad1940b/core/src/main/java/io/scif/tutorials/core/T3aCustomFormats.java#L123-133" target="_blank">https://github.com/scifio/scifio-tutorials/blob/5f9212a685c18ddc0cb4500e7ac4a3f1aad1940b/core/src/main/java/io/scif/tutorials/core/T3aCustomFormats.java#L123-133</a><br>[3] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java</a><br>[4] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L90-91" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L90-91</a><br>[5] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L283-292" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L283-292</a><br>[6] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L399-400" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L399-400</a><br>[7] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/config/SCIFIOConfig.java#L264-271" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/config/SCIFIOConfig.java#L264-271</a><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Jan 14, 2015 at 3:28 PM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div>Hi Curtis and Mark,</div><div><br></div><div>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:</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>Excited to see this writer become part of SCIFIO in the near future.</div><div><br></div><div>Best,</div><div>Henry</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 16, 2014 at 4:32 PM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Henry,<span><div><br></div><div><div>> I've created a class in the io.scif.formats package for my writer.</div><div>> Since I only have the writer components, but not the reader, how</div><div>> should I go about implementing all of the component classes of Format</div>
<div>> (Metadata, Parser, Checker, Reader, Writer, Translator). The first 4</div><div>> are listed as mandatory in the tutorial, but it seems like I shouldn't</div><div>> need all of them for writing functionality alone.</div>
</div><div><br></div></span><div>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:</div><div><br></div><div>
<a href="https://github.com/scifio/scifio/issues/211" target="_blank">https://github.com/scifio/scifio/issues/211</a><br></div><div><br></div><div>Feel free to comment on that so that GitHub sends you updates if you care about progress on it.</div>
<div><br></div><div>But in the meantime, it should still be possible to create a writer-only component. For an example, see the JavaFormat:</div><div><br></div><div><a href="https://github.com/scifio/scifio/blob/scifio-0.15.4/scifio/src/main/java/io/scif/formats/JavaFormat.java" target="_blank">https://github.com/scifio/scifio/blob/scifio-0.15.4/scifio/src/main/java/io/scif/formats/JavaFormat.java</a><br>
</div><div><br></div><div>Regards,</div><div>Curtis</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 25, 2014 at 1:21 PM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Curtis,<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>Best,</div><div>Henry</div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 1, 2014 at 7:27 AM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Henry,<div><div><br></div><div><div>> Over the past couple years, I've been developing and testing a java</div>
<div>> library that is capable of writing Imaris .ims files. This library has</div><div>
> allowed me to build an ImageJ plugin that automatically stitches,</div><div>> processes, and converts OME-TIFFs from Micro-Manager into Imaris</div><div>> files, which in turn allows a significantly greater throughput of</div>
<div>> imaging data with much less effort from users.</div></div><div><br></div></div><div>Sounds great!</div><div><div><br></div><div><div>> This library has been instrumental to the workflow of users in the</div>
<div>> imaging center in which I work, and I want to find a way to share its</div>
<div>> utility with researchers everywhere. Incorporating it into the</div><div>> Bio-Formats exporter would both increase its visibility and leverage</div><div>> the multitude of formats on Bio-Formats' front end to make it usable</div>
<div>> with all types of microscopy data.</div></div><div><br></div></div><div>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!)</div>
<div><br></div><div>You could then serve your Imaris writer from its own ImageJ update site [4, 5], to make it available to all ImageJ users.</div><div><div><br></div><div><div>> In addition, I've convinced Bitplane to make their format open source,</div>
<div>> and I believe this may allow .ims files to grow beyond a proprietary</div><div>> file format into a generalized multi-resolution format useful for a</div><div>> variety of applications that deal with the visualization of extremely</div>
<div>> large stitched images.</div></div><div><br></div></div><div>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.</div>
<div><br></div><div>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].</div><div><br></div><div>Regards,</div><div>
Curtis</div>
<div><br></div><div>[1] <a href="http://loci.wisc.edu/software/scifio" target="_blank">http://loci.wisc.edu/software/scifio</a></div><div>[2] <a href="https://github.com/scifio/scifio" target="_blank">https://github.com/scifio/scifio</a></div>
<div>[3] <a href="https://github.com/scifio/scifio-tutorials" target="_blank">https://github.com/scifio/scifio-tutorials</a></div>
<div>[4] <a href="http://wiki.imagej.net/Update_Sites" target="_blank">http://wiki.imagej.net/Update_Sites</a></div><div>[5] <a href="http://wiki.imagej.net/List_of_update_sites" target="_blank">http://wiki.imagej.net/List_of_update_sites</a></div>
<div>
[6] <a href="https://github.com/scifio/scifio-lifesci" target="_blank">https://github.com/scifio/scifio-lifesci</a></div><div>[7] <a href="http://scif.io/mailman/listinfo/scifio" target="_blank">http://scif.io/mailman/listinfo/scifio</a></div>
<div>[8] <a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel/" target="_blank">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel/</a></div><div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 6:55 PM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Melissa and Curtis,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Best,</div><div>Henry</div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
SCIFIO mailing list<br>
<a href="mailto:SCIFIO@scif.io" target="_blank">SCIFIO@scif.io</a><br>
<a href="http://scif.io/mailman/listinfo/scifio" target="_blank">http://scif.io/mailman/listinfo/scifio</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 4:21 PM, Mark Hiner <span dir="ltr"><<a href="mailto:hiner@wisc.edu" target="_blank">hiner@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Henry,<span><br><br>> Is it possible to include these binaries directly in the maven repository?<br><br></span></div>Not directly. But since their license allows them to be redistributed, I think what we want is to make NARs out of them[1] and put the NAR in the maven repository.<br><br></div>However, there are almost certainly limitations right now. I personally do not have experience with the nar-maven-plugin, but I would go into it expecting some hurdles.<br><br></div>On the other hand, I think your ImarisFormat is an awesome use case for the nar-maven-plugin and this is a great opportunity to work out problems and document NAR usage in SCIFIO/ImageJ2/Fiji! So I'd be happy to help investigate further.<br><div><div><br>Also, it's worth noting the ImageJ wiki also has a higher-level discussion of using native code[2], though it is outdated (and doesn't discuss the nar-maven-plugin).<span><br><br>>Actually, I think the SCIFIO tutorials described the flow quite well.<span></span><br><br></span></div><div>Thanks for that! I still felt the need to revise the format tutorial[3], as there were some basic elements that simply weren't discussed (like ColorTables).<span><br><br>>The library that I'm adding in to the ImarisFormat is only for writing
IMS files and doesn't support reading them, so I opted to model this off
of JavaFormat.<br>>There are a few basic metadata fields needed for writing, but I didn't
think it necessary to create a format-specific metadata class to hold
them.<br>>Since Imaris is a software for only analysis, no acquisition softwares save directly into IMS format.<br>>So the most complete set of metadata will always reside in whatever format was used to create the IMS file.<br><br></span></div><div>This makes a lot of sense - thank you for the explanation. I now think your decision not to have an ImarisFormat.Metadata class is correct - except for the fact that ImarisFormat has LUTs (see below).<span><br><br>>I took a look at BMPFormat, and I think the color table here is being
read from a BMP file and then stored in the BMP specific metadata,
right? I'm actually looking to do <br>>the opposite--write an LUT into an
IMS. So then I should use the one provided by the SCIFIO config method,
right?<br><br></span></div><div>Sort of. I think the SCIFIOConfig and Writer.getColorModel API are incorrect to use java.awt.image.ColorModels. I opened a ticket[4] to update them to the ImgLib2 ColorTable class. When that ticket is complete, this is how everything should work:<br><br></div><div>* You should make an ImarisFormat.Metadata that is a trivial extension of DefaultMetadata, but implements the HasColorTable interface<br></div><div>* When your Writer is passed a SCIFIOConfig with an attached ColorTable, the framework will pass the ColorTable to the Writer's ImarisFormat.Metadata<br></div><div>* In your Writer's writePlane implementation, you would check for a ColorTable on a) the provided Plane and b) the attached Metadata and write it out as appropriate.<br><br></div><div>So asking the Plane for its ColorTable was the right thing to do.<br><br>The fact that the ColorTable isn't being transferred from your original TIFF dataset is likely a bug. I'm not sure if it wasn't read properly on the TIFF side, or if it was read but didn't get passed to your ImarisFormat.Writer. Could you share your failing TIFF dataset so I can debug a bit more and figure out where it's going wrong? (note that you can use Fiji to upload a dataset[5] so that it won't be shared publicly)<br></div><div><br></div><div>Looking forward to getting this working for you - thanks again!<br><br></div><div>Best,<br>Mark<br></div><div><br></div><div>[1] <a href="http://maven-nar.github.io/index.html" target="_blank">http://maven-nar.github.io/index.html</a><br>[2] <a href="http://imagej.net/Native" target="_blank">http://imagej.net/Native</a><br>[3] <a href="https://github.com/scifio/scifio-tutorials/commit/5780247e65b0671f1b0e4bba744bde7661114531" target="_blank">https://github.com/scifio/scifio-tutorials/commit/5780247e65b0671f1b0e4bba744bde7661114531</a><br>[4] <a href="https://github.com/scifio/scifio/issues/239" target="_blank">https://github.com/scifio/scifio/issues/239</a><br>[5] <a href="http://imagej.net/Upload_Sample_Image" target="_blank">http://imagej.net/Upload_Sample_Image</a><br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 11:07 AM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mark,<div><br></div><div>Thanks for the quick reply!<br><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div></div>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 <a href="http://maven.imagej.net" target="_blank">http://maven.imagej.net</a>, and consumed as a normal Maven dependency by your writer. How is the native code you're using licensed? <br></div></div></div></div></blockquote><div><br></div></span><div>I don't actually need to build the native archives. They are distributed as pre built binaries on the HDF website. Is it possible to include these binaries directly in the maven repository? The license is a "BSD style open-source license." More info can be found at: <a href="http://www.hdfgroup.org/products/licenses.html" target="_blank">http://www.hdfgroup.org/products/licenses.html</a></div><span><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>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!).<br></div></div></div></blockquote><div><br></div></span><div>As I look over this again, I think that this writer is probably an exception that operates by different mechanisms than most Formats, and probably doesn't warrant a change in the API. more on this below.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div></div>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.<br><br></div>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.<br><br>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].<br><div><div><div><br></div><div>The SCIFIOConfig method you mentioned[7] is for external software to set a custom LUT when saving an image.</div></div></div></div></blockquote><div><br></div></span><div>Actually, I think the SCIFIO tutorials described the flow quite well. The library that I'm adding in to the ImarisFormat is only for writing IMS files and doesn't support reading them, so I opted to model this off of JavaFormat. There are a few basic metadata fields needed for writing, but I didn't think it necessary to create a format-specific metadata class to hold them. Since Imaris is a software for only analysis, no acquisition softwares save directly into IMS format. So the most complete set of metadata will always reside in whatever format was used to create the IMS file. If you think it would be better to create an ImarisFormat.Metadata class, I'm happy to do so, but I don't think it would affect the functionality of the format. </div><div><br></div><div>I took a look at BMPFormat, and I think the color table here is being read from a BMP file and then stored in the BMP specific metadata, right? I'm actually looking to do the opposite--write an LUT into an IMS. So then I should use the one provided by the SCIFIO config method, right?</div><div><br></div><div>How about date/time stamps? Is there any way to extract this from default metadata classes or does it need to be done in a metadata format-specific manner?</div><div><br></div><div>Best,</div><div>Henry</div><div><div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div></div><div><br><br>[1] <a href="https://github.com/maven-nar/nar-maven-plugin" target="_blank">https://github.com/maven-nar/nar-maven-plugin</a><br>[2] <a href="https://github.com/scifio/scifio-tutorials/blob/5f9212a685c18ddc0cb4500e7ac4a3f1aad1940b/core/src/main/java/io/scif/tutorials/core/T3aCustomFormats.java#L123-133" target="_blank">https://github.com/scifio/scifio-tutorials/blob/5f9212a685c18ddc0cb4500e7ac4a3f1aad1940b/core/src/main/java/io/scif/tutorials/core/T3aCustomFormats.java#L123-133</a><br>[3] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java</a><br>[4] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L90-91" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L90-91</a><br>[5] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L283-292" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L283-292</a><br>[6] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L399-400" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/formats/BMPFormat.java#L399-400</a><br>[7] <a href="https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/config/SCIFIOConfig.java#L264-271" target="_blank">https://github.com/scifio/scifio/blob/37822206e9ca842bb18596ef0f0312ad3f2e6d5f/src/main/java/io/scif/config/SCIFIOConfig.java#L264-271</a><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Jan 14, 2015 at 3:28 PM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div>Hi Curtis and Mark,</div><div><br></div><div>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:</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>Excited to see this writer become part of SCIFIO in the near future.</div><div><br></div><div>Best,</div><div>Henry</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 16, 2014 at 4:32 PM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Henry,<span><div><br></div><div><div>> I've created a class in the io.scif.formats package for my writer.</div><div>> Since I only have the writer components, but not the reader, how</div><div>> should I go about implementing all of the component classes of Format</div>
<div>> (Metadata, Parser, Checker, Reader, Writer, Translator). The first 4</div><div>> are listed as mandatory in the tutorial, but it seems like I shouldn't</div><div>> need all of them for writing functionality alone.</div>
</div><div><br></div></span><div>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:</div><div><br></div><div>
<a href="https://github.com/scifio/scifio/issues/211" target="_blank">https://github.com/scifio/scifio/issues/211</a><br></div><div><br></div><div>Feel free to comment on that so that GitHub sends you updates if you care about progress on it.</div>
<div><br></div><div>But in the meantime, it should still be possible to create a writer-only component. For an example, see the JavaFormat:</div><div><br></div><div><a href="https://github.com/scifio/scifio/blob/scifio-0.15.4/scifio/src/main/java/io/scif/formats/JavaFormat.java" target="_blank">https://github.com/scifio/scifio/blob/scifio-0.15.4/scifio/src/main/java/io/scif/formats/JavaFormat.java</a><br>
</div><div><br></div><div>Regards,</div><div>Curtis</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 25, 2014 at 1:21 PM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Curtis,<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>Best,</div><div>Henry</div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 1, 2014 at 7:27 AM, Curtis Rueden <span dir="ltr"><<a href="mailto:ctrueden@wisc.edu" target="_blank">ctrueden@wisc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Henry,<div><div><br></div><div><div>> Over the past couple years, I've been developing and testing a java</div>
<div>> library that is capable of writing Imaris .ims files. This library has</div><div>
> allowed me to build an ImageJ plugin that automatically stitches,</div><div>> processes, and converts OME-TIFFs from Micro-Manager into Imaris</div><div>> files, which in turn allows a significantly greater throughput of</div>
<div>> imaging data with much less effort from users.</div></div><div><br></div></div><div>Sounds great!</div><div><div><br></div><div><div>> This library has been instrumental to the workflow of users in the</div>
<div>> imaging center in which I work, and I want to find a way to share its</div>
<div>> utility with researchers everywhere. Incorporating it into the</div><div>> Bio-Formats exporter would both increase its visibility and leverage</div><div>> the multitude of formats on Bio-Formats' front end to make it usable</div>
<div>> with all types of microscopy data.</div></div><div><br></div></div><div>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!)</div>
<div><br></div><div>You could then serve your Imaris writer from its own ImageJ update site [4, 5], to make it available to all ImageJ users.</div><div><div><br></div><div><div>> In addition, I've convinced Bitplane to make their format open source,</div>
<div>> and I believe this may allow .ims files to grow beyond a proprietary</div><div>> file format into a generalized multi-resolution format useful for a</div><div>> variety of applications that deal with the visualization of extremely</div>
<div>> large stitched images.</div></div><div><br></div></div><div>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.</div>
<div><br></div><div>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].</div><div><br></div><div>Regards,</div><div>
Curtis</div>
<div><br></div><div>[1] <a href="http://loci.wisc.edu/software/scifio" target="_blank">http://loci.wisc.edu/software/scifio</a></div><div>[2] <a href="https://github.com/scifio/scifio" target="_blank">https://github.com/scifio/scifio</a></div>
<div>[3] <a href="https://github.com/scifio/scifio-tutorials" target="_blank">https://github.com/scifio/scifio-tutorials</a></div>
<div>[4] <a href="http://wiki.imagej.net/Update_Sites" target="_blank">http://wiki.imagej.net/Update_Sites</a></div><div>[5] <a href="http://wiki.imagej.net/List_of_update_sites" target="_blank">http://wiki.imagej.net/List_of_update_sites</a></div>
<div>
[6] <a href="https://github.com/scifio/scifio-lifesci" target="_blank">https://github.com/scifio/scifio-lifesci</a></div><div>[7] <a href="http://scif.io/mailman/listinfo/scifio" target="_blank">http://scif.io/mailman/listinfo/scifio</a></div>
<div>[8] <a href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel/" target="_blank">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel/</a></div><div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 6:55 PM, Henry Pinkard <span dir="ltr"><<a href="mailto:henry.pinkard@gmail.com" target="_blank">henry.pinkard@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Melissa and Curtis,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Best,</div><div>Henry</div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
SCIFIO mailing list<br>
<a href="mailto:SCIFIO@scif.io" target="_blank">SCIFIO@scif.io</a><br>
<a href="http://scif.io/mailman/listinfo/scifio" target="_blank">http://scif.io/mailman/listinfo/scifio</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>