Ticket #607 (closed feature: fixed)
Opened 2011-06-14T15:11:15-05:00
Last modified 2013-08-19T14:51:57-05:00
Maintain ColorTables when modifying Datasets
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: | imagej2-b8-analysis |
| Component: | Data Model | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | #1983, #1984, #1985 | |
| Blocking: |
Description
We are not yet maintaining Dataset color tables when various events happen. If you take a CZT Dataset and delete forty Z hyperplanes nothing tracks what to do with existing ColorTables.
Change History
comment:1 Changed 2011-06-21T14:05:01-05:00 by bdezonia
- Component changed from bio-formats to ij-data-model
comment:2 Changed 2011-07-08T13:52:17-05:00 by bdezonia
- Summary changed from ColorTable maintenance to Maintain ColorTables when modifying Datasets
comment:3 Changed 2011-09-21T14:53:03-05:00 by bdezonia
- Owner changed from bdezonia to curtis
- Status changed from new to assigned
Curtis, would like to get your thoughts here. Is it the case that a Dataset has either one ColorTable or one per plane? Or is it possible you could have any number of ColorTables between these extremes? Trying to determine how to handle the insertion and deletion of ColorTables when slices added and deleted. And in general how anybody who calls setImgPlus() accounts for this.
comment:4 Changed 2011-09-21T15:38:47-05:00 by bdezonia
I forgot to mention I am aware of the one ColorTable per channel case. Are there thus 3 cases for color tables: (1 per Dataset, 1 per channel, and 1 per plane)? Or more?
comment:5 Changed 2011-09-21T16:18:20-05:00 by curtis
In theory there could be any number of color tables in between. It would be best not to make assumptions. However, I believe that ImgOpener adds null color table entries so that the number of color tables always matches the total number of planes (i.e., product of dimensions beyond the first two). So it should be doable to preserve the color tables (null or otherwise) for the remaining planes, as part of a slice deletion operation, since the order and number of the tables is known. If you like, we could add more code to ImgPlus that enforces this assumption.
If someone calls setImgPlus manually, they will be passing an ImgPlus with its own set of color tables. So it's not really Dataset's problem. But any routine that wants to replace a Dataset's ImgPlus by calling that method will have to be very careful that the new ImgPlus is totally correct. When using it to modify an ImgPlus's structure, the burden is on the algorithm to maintain the correct number and placement of color tables.
That said, we can create some utility methods for better managing color tables, so that multiple algorithms that perform structural alterations can reuse color table adjustment logic. We could even model color tables as their own Img objects at some point, though that might be overkill.
comment:7 Changed 2011-12-10T09:36:56-06:00 by bdezonia
In 6d5e9b4ab07cf0eecd93ec033a3ed6c4d4e6189c began laying groundwork by making legacy layer created displays allocate their color table array with null color tables (1 color table per plane).
Need to make restructure plugins smartly maintain changes in planes and map color tables appropriately.
Also it looks like the Harmonizer calls setImgPlus(). Do we need to do something smart there as well. Is it even possible?
Investigate all uses of setImgPlus() in the IJ2 code.
comment:8 Changed 2011-12-10T09:42:22-06:00 by bdezonia
ReorderAxes is somewhat problematic if a user swaps X or Y out of the 1st two positions. This is a more general issue but does point out problem of having a planar organization of color table data.
comment:9 Changed 2012-01-18T16:43:43-06:00 by bdezonia
In f01e55702a4fe831d52bba9f49e805296af6da2b greatly improved coor table maintenance in the restructure plugins.
Remaining issues for this ticket:
- make ReorderAxes plugin maintain color tables
- see if harmonization can maintain color tables if possible (it calls setImgPlus())
- investigate all uses of setImgPlus() in code
- check all IJ2 code that gets color tables from a Dataset and make sure there are no assumptions about how many color tables exist
comment:10 Changed 2012-01-19T09:23:45-06:00 by bdezonia
In 0f4e657278e369186d1e66e656071abea9afb960 made ReorderAxes maintain color tables
comment:11 Changed 2012-01-19T12:10:15-06:00 by bdezonia
- Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2
comment:12 Changed 2012-05-14T10:57:25-05:00 by bdezonia
- Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4
comment:15 Changed 2012-08-03T10:59:49-05:00 by bdezonia
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5
comment:16 Changed 2012-10-15T12:04:57-05:00 by bdezonia
We should remember when undo is in place that an ImageDisplay's state involves both the data and the view. The 'undo' branch implementation was limited to data only. ColorTables may or may not be data oriented. Make sure that CoorTables are stored as part of ImageDIsplay's stae for undo purpose. And when the data restructuring plugins implement invertibility make sure they save the ColorTable config before data is changed.
comment:17 Changed 2013-01-22T15:16:28-06:00 by bdezonia
- Milestone changed from imagej2-b7-ndim-data to imagej2-b8-analysis
comment:18 Changed 2013-08-19T11:02:58-05:00 by bdezonia
- Type changed from defect to feature
- Blocking 1341 removed
There is really nothing left to do with this ticket. It will be a feature ticket going forward as there are a couple places where IJ2 could improve ColorTable maintenance.
comment:22 Changed 2013-08-19T14:51:57-05:00 by bdezonia
- Status changed from assigned to closed
- Resolution set to fixed