Ticket #1745 (closed enhancement: wontfix)
Opened 2013-03-26T13:11:57-05:00
Last modified 2014-12-11T14:28:28-06:00
Tuple support
| Reported by: | aivar | Owned by: | curtis |
|---|---|---|---|
| Priority: | minor | Milestone: | imagej2-unscheduled |
| Component: | ImgLib2 | Version: | |
| Severity: | minor | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
Support image dimensions that hold different parameters describing the same pixel.
Change History
comment:4 Changed 2013-06-05T15:31:08-05:00 by bdezonia
- Milestone changed from imagej2-b7-ndim-data to imagej2-b8-analysis
comment:5 Changed 2013-12-06T18:21:37-06:00 by aivar
- Owner changed from aivar to curtis
- Priority changed from major to minor
- Status changed from new to assigned
- Severity changed from serious to minor
- Milestone changed from imagej2-b8-analysis to imagej2-unscheduled
There's currently no distinction between dimensions that represent different aspects of the same pixel area of the source (e.g. spectral dimensions of images such as RGB images) versus different pixels. (If the image is acquired over time the concept of 'same pixel area' gets even murkier.)
This is a useful concept in SLIM Plugin, both for the lifetime dimension of the input image, which represents the photon count histogram, and for output fitted images, with a fitted parameter dimension with parameters such as A, T, Z for each pixel.
comment:7 Changed 2014-12-11T14:25:53-06:00 by curtis
- Status changed from assigned to closed
- Resolution set to wontfix
I see three cases:
- Continuous dimensions (e.g., spectra), where interpolation between samples makes sense.
- Discrete dimensions (e.g., a "fitted parameter dimension" as described above), where the values are independent and interpolation is not sensible.
- Multiple values stored in the type itself (e.g., ARGBType).
It might be nice to have a way to note in the AxisType whether the dimension is continuous or discrete. However, I do not think that ImgLib2 should have "tuple" support in the form of a general "TupleType" or similar. Rather, multiple parallel Img/etc. objects would do the trick, especially if/when combined with a multi-interval container/aggregator that could union multiple objects together for treatment as a single Img/etc.
I'm closing this as wontfix for now, but we can revisit if/when the issue becomes a blocker for any sort of use case.
comment:8 Changed 2014-12-11T14:28:28-06:00 by curtis
Discrete/continuous issue filed at: https://github.com/imagej/imagej-common/issues/38