[ImageJ-devel] [fiji-devel] saving images with imglib2-io

Thu Mar 8 14:48:40 CST 2012

Hi Steffi,

Thanks for the feedback!

1) We should maybe not only do this for Img, but actually for any
> RandomAccessibleInterval<NativeType>. In this way we will be able to write
> Img, Views, anything that is rectangular. The source code will be just the
> same ...
>

This is a good idea. However, there are some obstacles. In particular,
ImgPlus currently wraps an Img, and provides structural metadata (in
particular, axis labels) that is very useful for writing multidimensional
data correctly. We could expand ImgPlus to wrap any
RandomAccessibleInterval but it will require some thought.

For now, we have filed a ticket for this work, to serve as a reminder:
    http://trac.imagej.net/ticket/1063

Steffi, you've been CCed on the ticket, so will receive updates if/when we
make any progress on it.

2) Also thinking along those lines (and more into the future), is there
> maybe any way to write/read sparse data, i.e. a list of coordinates and
> associated values (net.imglib2.collection)?

Writing sparse data would be quite difficult, as Bio-Formats does not
really have an API for that. We could write zeroes or NaNs or other dummy
value for all missing data, but that's not really very efficient. It would
probably be easiest to implement a different saver to deal with this sort
of data.

3) Another issue will soon be planes that are too big to hold them in one
> java array, do you have means to write/read them? The CellImg will be able
> to hold them, and according to Stephan Saalfeld it will not take much
> longer until electron microscopy will produce such images. The current
> limit of java arrays is 2^31-1 entries which means ~46000x46000 pixels per
> plane.

At the API level, Bio-Formats already supports writing of extremely large
image planes, in that you can write out data a tile at a time. However,
this capability is only functional for a subset of formats (TIFF in
particular). Of course, we will need to update the ImgSaver to handle cases
where the byte array would be too large, by splitting the data into tiles.

> 4) Are there means to not only consider RealType? Maybe we could think of
> a way where it is enough to have just a NativeType that is able to project
> itself into a java basic type array?

As long as there is an API to express the NativeType as a java basic type
array, then yes, we could write it out. But it may be misleading. For
example, let's say a particular NativeType can be coerced into a double[]
per plane. Then Bio-Formats will convert the double[] to a byte[], set the
pixel type to FLOAT64, and write it out. But "FLOAT64" may not really
accurately describe what that data is.

Really, the only supported types that Bio-Formats can do right now are:
int8, uint8, int16, uint16, int32, uint32, float32, float64.

Perhaps another way of handling it would be to create a wrapper class in
ImgLib that converts NativeTypes to a particular sort of RealType, without
making a copy of the data, sort of like Views does for geometric
transformations. Would that solve it?

5) What also crossed my mind were Non-Native-Types and if we should somehow
> consider them at all. A generic but I guess slow and inefficient method
> would be to serialize each pixel individually?

Again, as long as the data can be expressed as a primitive array, it may be
doable. Or we can use the wrapper approach described above. I agree that
the ultimate solution of serializing each pixel would work—although beware
Java serialization's transient nature. If you serialize an object, and then
try to read it back in with a newer version of that class, it won't work.
So Java serialization is dangerous for this type of persistence.

Regards,
Curtis

P.S. Mark now has an initial working version of the PlanarImg case:

https://github.com/ctrueden/bioformats/blob/imglib-io/components/scifio/src/ome/scifio/img/ImgSaver.java

On Wed, Mar 7, 2012 at 2:13 PM, Stephan Preibisch
<stephan.preibisch at gmx.de>wrote:

> Hi Curtis & Mark,
>
> first of all thanks a lot for caring about this important issue. I felt
> this was always one of the really important things lacking in ImgLib.
> I just had a look into the source code, and it looks like a great start.
> You are right, extracting planes from other sources than PlanarImg will not
> be a big deal.
>
> I have 5 questions/comments that we might want to think about now or later:
>
> 1) We should maybe not only do this for Img, but actually for any
> RandomAccessibleInterval<NativeType>. In this way we will be able to write
> Img, Views, anything that is rectangular. The source code will be just the
> same ...
> 2) Also thinking along those lines (and more into the future), is there
> maybe any way to write/read sparse data, i.e. a list of coordinates and
> associated values (net.imglib2.collection)?
> 3) Another issue will soon be planes that are too big to hold them in one
> java array, do you have means to write/read them? The CellImg will be able
> to hold them, and according to Stephan Saalfeld it will not take much
> longer until electron microscopy will produce such images. The current
> limit of java arrays is 2^31-1 entries which means ~46000x46000 pixels per
> plane.
> 4) Are there means to not only consider RealType? Maybe we could think of
> a way where it is enough to have just a NativeType that is able to project
> itself into a java basic type array?
> 5) What also crossed my mind were Non-Native-Types and if we should
> somehow consider them at all. A generic but I guess slow and inefficient
> method would be to serialize each pixel individually?
>
> Regarding the related topic: I completely agree. Merging imglib2-io with
> Bioformats seems like just the right thing to do. It is anyway useless
> without bioformats :)
>
> Nice greetings!
> Steffi
>
>
>
> On Mar 6, 2012, at 19:45 , Curtis Rueden wrote:
>
> Hi Steffi & everyone,
>
> But Mark, maybe we should talk about the saver?
>>
>
> The work on ImgSaver is now being done in the imglib-io branch of my
> Bio-Formats Git repository:
>     https://github.com/ctrueden/bioformats/tree/imglib-io
>
> https://github.com/ctrueden/bioformats/tree/imglib-io/components/scifio/src/ome/scifio/img
>
> https://github.com/ctrueden/bioformats/blob/imglib-io/components/scifio/src/ome/scifio/img/ImgSaver.java
>
> Currently, only a skeleton of the API exists, but Mark will be continuing
> work throughout this week. Initially, we decided to implement the special
> case for PlanarImg, which will provide good performance. We will add the
> more general case after that.
>
> On a related topic: we are hoping to merge the imglib-io project into
> scifio core. As discussed at the last hackathon, the scifio.jar library now
> depends on imglib2.jar, which has several advantages. It allows SCIFIO to
> share ImgLib2's dimensional axis enumeration (Axes & AxisType), as well as
> pixel types. More importantly to end users, it enables SCIFIO to provide a
> high-level API for obtaining Img objects from a data source—if we merge
> imglib-io into scifio. Does this sound like a good plan?
>
> Regards,
> Curtis
>
>
> On Tue, Mar 6, 2012 at 5:38 PM, Stephan Preibisch <
> stephan.preibisch at gmx.de> wrote:
>
>> Hi Johannes,
>>
>> I am not, I was just looking to add it to the examples, but this can wait.
>>
>> But Mark, maybe we should talk about the saver?
>>
>> Bye bye,
>> Steffi
>>
>> Am Mar 6, 2012 um 13:57 schrieb Johannes Schindelin <
>> Johannes.Schindelin at gmx.de>:
>>
>> > Hi,
>> >
>> > please also note that imagej-devel at imagejdev.org is now
>> > imagej-devel at imagej.net.
>> >
>> > On Tue, 6 Mar 2012, Johannes Schindelin wrote:
>> >
>> >> On Tue, 6 Mar 2012, Stephan Preibisch wrote:
>> >>
>> >>> I once implemented an n-dimensional saver for imglib1 using the ImageJ
>> >>> tiff saver. I will try to port this one today, you will find it in
>> >>> ImageJFunctions.saveAsTIFFs.
>> >>
>> >> Please don't. People will start to use it and it will be incompatible
>> >> with the SCIFIO/Bio-Formats based ImgSaver. Hopefully you agree that 1)
>> >> that would be bad and 2) the ImgSaver will be more powerful, supporting
>> >> the complete Bio-Formats infrastructure.
>> >
>> > I realize that I sounded much harsher than intended. Just wanted to make
>> > sure that time is used efficiently.
>> >
>> > If you are in dear need of a saver *right now*, I recommend working with
>> > Mark Hiner on an interface so that users of your saver will
>> transparently
>> > be using the scifio-based one when that is available.
>> >
>> > Ciao,
>> > Dscho
>> >
>> > --
>> > Please avoid top-posting, and please make sure to reply-to-all!
>> >
>> > Mailing list web interface: http://groups.google.com/group/fiji-devel
>>
>> --
>> Please avoid top-posting, and please make sure to reply-to-all!
>>
>> Mailing list web interface: http://groups.google.com/group/fiji-devel
>>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120308/73ec0e58/attachment.html>