⚠

NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #216 (closed task: fixed)

Opened 2010-09-20T14:34:51-05:00

Last modified 2013-06-07T15:15:34-05:00

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 2010-09-27T12:41:30-05:00 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 2011-02-15T10:21:56-06:00 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 2011-02-15T10:37:09-06:00 by bdezonia

  • Status changed from assigned to accepted

comment:4 Changed 2011-03-14T12:50:00-05:00 by bdezonia

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

comment:5 Changed 2011-04-25T11:35:40-05:00 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 2011-07-06T17:03:19-05:00 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 2011-07-29T12:45:57-05:00 by bdezonia

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

comment:8 Changed 2011-09-02T13:26:57-05:00 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 2011-09-02T13:30:36-05:00 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 2011-09-02T13:34:07-05:00 by bdezonia

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

comment:11 Changed 2011-09-02T14:36:14-05:00 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 2011-09-02T14:58:36-05:00 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 2011-09-06T15:51:20-05:00 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 2011-09-07T11:28:05-05:00 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 2011-09-07T16:50:01-05:00 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 2011-09-07T16:53:40-05:00 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 2011-10-18T15:17:43-05:00 by curtis

  • Priority changed from major to critical

comment:18 Changed 2011-11-01T10:47:01-05:00 by curtis

  • Status changed from assigned to accepted

comment:19 Changed 2012-02-23T11:24:21-06:00 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 2012-02-23T11:24:46-06:00 by curtis

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

comment:20 Changed 2012-02-23T11:25:01-06:00 by curtis

  • Blocking 20 added

comment:21 Changed 2012-02-24T14:00:06-06:00 by curtis

  • Blocking 9 added

comment:22 Changed 2012-05-15T15:50:48-05:00 by curtis

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

comment:23 Changed 2012-08-14T09:51:21-05:00 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 2012-08-14T13:02:03-05:00 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 2012-08-14T13:03:30-05:00 by bdezonia

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

Undo last change

comment:26 Changed 2012-08-14T13:03:51-05:00 by bdezonia

  • Blocking 9 removed

comment:27 Changed 2013-05-31T15:53:44-05:00 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 2013-06-07T15:15:34-05:00 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!