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

Fri Mar 9 07:07:40 CST 2012

Hi Curtis,

> 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?
>
...
>
> 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?

A framework to do this is already in place (at least partially) in the
net.imglib2.converter[.sampler] package. For instance, you can use
ConvertedRandomAccessible with a RealFloatSamplerConverter to convert
any RealType<T> to FloatType on the fly.

The cool thing is, that it works both ways, so this could also be used
for reading back the images...

It is not complete, and there are still open problems, e.g., addressing
NativeTypes with numEntities!=1. I just wanted to mention that something
similar to what you are looking for exists. So if you choose to progress
in that direction, it would be good, to do it in a common framework. If
I can help with adapting SamplerConverter to your needs, just let me
know.

best regards,
Tobias

On 03/08/2012 09:48 PM, Curtis Rueden wrote:
> 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 <mailto: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 <mailto: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 <mailto:Johannes.Schindelin at gmx.de>>:
>>
>>> Hi,
>>>
>>> please also note that imagej-devel at imagejdev.org
>> <mailto:imagej-devel at imagejdev.org> is now
>>> imagej-devel at imagej.net <mailto: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
>> <mailto:ImageJ-devel at imagej.net>
>> http://imagej.net/mailman/listinfo/imagej-devel
>
>
> -- Please avoid top-posting, and please make sure to reply-to-all!
>
> Mailing list web interface:
> http://groups.google.com/group/fiji-devel