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 #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:6 Changed 2011-10-18T17:06:34-05:00 by curtis

  • Owner changed from curtis to bdezonia

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:13 Changed 2012-07-17T14:50:13-05:00 by bdezonia

  • Blocking 1241 added

comment:14 Changed 2012-07-17T14:50:47-05:00 by bdezonia

  • Blocking 1341 added; 1241 removed

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:19 Changed 2013-08-19T11:04:45-05:00 by bdezonia

  • Blocked By 1983 added

comment:20 Changed 2013-08-19T11:05:46-05:00 by bdezonia

  • Blocked By 1984 added

comment:21 Changed 2013-08-19T11:07:10-05:00 by bdezonia

  • Blocked By 1985 added

comment:22 Changed 2013-08-19T14:51:57-05:00 by bdezonia

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