Ticket #216 (closed task: fixed)

Opened 9 years ago

Last modified 6 years ago

New ImgLib container types for use with imglib-io

Reported by: curtis Owned by: curtis
Priority: critical Milestone: imagej2-b7-ndim-data
Component: I/O Version:
Severity: non-issue Keywords:
Cc: Blocked By:
Blocking: #20

Description

The bf-imglib adapter currently uses an ArrayContainerFactory to generate the container. We would like to have several new container types:

1) an array container type using one byte array per plane—useful for efficient Bio-Formats import, and useful for tools needing byte arrays (e.g., BufferedImage Java3D texturing by reference?)
2) an array container type using one matching primitive array per plane—useful for efficient access to pixels in ImageJ (e.g., getPixels)
3) as 1, but with an IFormatReader reference reading planes on demand—useful for efficient memory use for tools wanting matching primitive arrays (e.g., virtual stacks in ImageJ)
4) as 2, but with an IFormatReader reference reading planes on demand—useful for efficient memory use

Change History

comment:1 Changed 9 years ago by curtis

  • Milestone changed from biweekly-2010: Sep-20 to Oct-01 to biweekly-2011: Feb-14 to Feb-25

Type 2 now exists as Planar*Array in  mpicbg/imglib/container/basictypecontainer/array of the imglib maven branch.

The other types are less urgent so I am pushing this ticket to a later milestone.

comment:2 Changed 9 years ago by curtis

  • Owner changed from curtis to bdezonia
  • Status changed from new to assigned
  • Summary changed from New imglib container types for use with bf-imglib to New ImgLib container types for use with imglib-io
  • Component changed from bio-formats to imagej-io
  • Milestone changed from biweekly-2011: Feb-14 to Feb-25 to biweekly-2011: Mar-14 to Mar-25

The imglib-io project (formerly bf-imglib) uses Bio-Formats to import image data using PlanarContainers (#2 above). We continue to need #3 or #4 in particular, so that Bio-Formats can deliver planes on demand from disk. This will allow us to replicate ImageJ1's "virtual stack" functionality, but more flexibly.

comment:3 Changed 9 years ago by bdezonia

  • Status changed from assigned to accepted

comment:4 Changed 8 years ago by bdezonia

  • Milestone changed from biweekly-2011: Mar-14 to Mar-25 to biweekly-2011: Mar-28 to Apr-08

comment:5 Changed 8 years ago by curtis

  • Milestone changed from biweekly-2011: Apr-11 to Apr-22 to biweekly-2011: Jun-06 to Jun-17

This type of work goes hand in hand with tickets #19 and #20, and makes sense as part of 2.0-beta1 development in June.

comment:6 Changed 8 years ago by bdezonia

Am creating classes in imglib-io. Currently have an implementation of the VirtualRandomAccess class.

Note: IJ2's open as virtual stack plugin (or capability) will need to call ImgOpener with a correct factory or an initialized IFormatReader.

comment:7 Changed 8 years ago by bdezonia

  • Milestone changed from biweekly-2011: Jul-18 to Jul-29 to imagej-2.0-beta1

comment:8 Changed 8 years ago by bdezonia

I have committed some preliminary implementations in the imglib-io package. They are untested and have some annoying features.

Ideally I'd like to create a VirtualImg from an IFormatReader. But due to generics I am forced to create a VirtualImg of a specified type (i.e. VirtualImg<ShortType>). If the underlying file type does not match an exception will get thrown at construction time.

Dues to reuse of AbstractImg we need to be provided the array of dimensions. They need to match the IFormatReader's ideas of what the dimensions are.

Finally the design requires VirtualCursors and VirtualRandomAccesses to maintain the current plane of data. And each of these cursors and accessors shares a reference to the same IFormatReader. So if multiple cursors or accessors defined we'd have memory overhead and possible threading issues. Will think about this more.

comment:9 Changed 8 years ago by bdezonia

It may not be clear above but I was stating that each cursor has its own plane of data. Thus more cursors == more memory.

Also reusing AbstractImg requires dimensions to be passed to the constructor along with the IFormatReader even though the dims can be computed from the reader. We could avoid inheritance but would need to reimplement some methods. Or maybe a VirtualImg could own an AbstractImg and delegate as needed.

comment:10 Changed 8 years ago by bdezonia

Final clarification: reusing the same IFormatReader for multiple cursors and accessors could be introducing a threading issues.

comment:11 Changed 8 years ago by curtis

Right, we can't use the same IFormatReader for multiple threads. However, with the planned SciFIO refactoring of BF, we will be able to easily initialize multiple IFormatReaders on the same data file and use one per thread, without incurring a high initialization cost each time. So the problem will be solved eventually.

comment:12 Changed 8 years ago by bdezonia

Commited code that removes the annoying construction issues related to generics, dimensions, etc. Now there is a static factory method called create(String fileName). Users get back VirtualImg<?> from this method.

Threading discussed above.

Will now write some tests.

comment:13 Changed 8 years ago by bdezonia

TODO

  • write and commit tests (I have small implementation uncommitted)
  • the virtualSwap() code of VirtualImg has to hatch new RandomAccessors when a plane is loaded. determine if this is a PlanarContainer bug or if it can be remedied by an updateContainer() kind of call.
  • refactor VirtualCursor and VirtualAccessor to share some code
  • support the swapping and retrieving of planes as either primitive type arrays or always byte arrays depending upon a flag passed to the create() call.
  • eventually support multiple cached planes
  • eventually support writable data and write out when dirty and swapping
  • I have hardcoded big vs. little endian as little I think. This works on Mac. Test if its broken on Windows. If so set little based upon running platform.
  • figure out how to get TestImage loaded into project so that it is found by test runner automatically
  • add TestImage to git and commit

comment:14 Changed 8 years ago by bdezonia

Done

  • wrote small set of tests and committed along with TestImage.tif
  • test class runs and locates image correctly
  • decided not to refactor VirtualCursor and VirtualAccessor - little overlap
  • can swap and retrieve planes as byte[]'s only if desired

Todo

  • try to eliminate the repeated creation of RandomAccessors on PlaneImg when plane swapped in (bug in PlanarContainer or some such?)
  • eventually support the ability to have musltiple planes in ram and also writable data swapped out when plane is dirty
  • debug big vs. little endian issues in VirtualPlaneLoader.java

comment:15 Changed 8 years ago by bdezonia

  • Owner changed from bdezonia to curtis
  • Status changed from accepted to assigned

Done

  • eliminated need for new RandomAccessors on every plane swap
  • fixed endianness initialization
  • writable virtual images wil become a new ticket (or part of tiling ticket)

Curtis, please review my implementation at some point to confirm that what you thought was needed (some new container type I think) can be handled with existing implementation or not. If not then add details to this ticket else close. Thanks.

comment:16 Changed 8 years ago by bdezonia

Implementation of VirtualImg and related classes is in the imglib-io project in the net.imglin.io.img.virtual package.

comment:17 Changed 8 years ago by curtis

  • Priority changed from major to critical

comment:18 Changed 8 years ago by curtis

  • Status changed from assigned to accepted

comment:19 Changed 7 years ago by curtis

  • Blocking 20 added

(In #20) This ticket is now a story describing the end goal of supporting large image data. Ticket #216 (and likely others to be added later) will indicate the actual approaches and tasks used to accomplish this goal.

comment:19 Changed 7 years ago by curtis

  • Blocking 20 removed
  • Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2

comment:20 Changed 7 years ago by curtis

  • Blocking 20 added

comment:21 Changed 7 years ago by curtis

  • Blocking 9 added

comment:22 Changed 7 years ago by curtis

  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4

comment:23 Changed 7 years ago by curtis

  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5

The theme of beta5 will be more flexible data visualization and processing.

comment:24 Changed 7 years ago by bdezonia

  • Milestone changed from imagej-2.0.0-beta5 to imagej-2.0.0-beta4

This ticket cannot yet be moved to beta 5 due to blockers

comment:25 Changed 7 years ago by bdezonia

  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5

Undo last change

comment:26 Changed 7 years ago by bdezonia

  • Blocking 9 removed

comment:27 Changed 6 years ago by bdezonia

  • Status changed from accepted to reviewing

This ticket needs to be revisited now that scifio-cells is supporting CellImgs and the virtual imglib io classes are being removed.

comment:28 Changed 6 years ago by curtis

  • Status changed from reviewing to closed
  • Resolution set to fixed

As far as I'm concerned, this ticket is resolved now that we have SCIFIOCellImg in place. To elaborate on each of the four types mentioned in the description:

1) We do not have this, but do not really need it. If it proves necessary some day, we can implement it, but for now, that portion of this work is wontfix.
2) We have it; it's called PlanarImg. We've been using it. *thumbs up*
3) Same as 1 above. wontfix
4) We have that and more; it's called SCIFIOCellImg. It is actually an extension of CellImg so it can read tiles (what ImgLib refers to as "cells") on demand from the original file(s). We are also in the process of adding disk caching support so you can even have a read-write capable SCIFIOCellImg whose total data size is far larger than available RAM!

Note: See TracTickets for help on using tickets.