Ticket #607 (closed feature: fixed)

Opened 8 years ago

Last modified 6 years ago

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 8 years ago by bdezonia

  • Component changed from bio-formats to ij-data-model

comment:2 Changed 8 years ago by bdezonia

  • Summary changed from ColorTable maintenance to Maintain ColorTables when modifying Datasets

comment:3 Changed 8 years ago 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 8 years ago 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 8 years ago 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 8 years ago by curtis

  • Owner changed from curtis to bdezonia

comment:7 Changed 8 years ago 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 8 years ago 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 7 years ago 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 7 years ago by bdezonia

In 0f4e657278e369186d1e66e656071abea9afb960 made ReorderAxes maintain color tables

comment:11 Changed 7 years ago by bdezonia

  • Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2

comment:12 Changed 7 years ago by bdezonia

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

comment:13 Changed 7 years ago by bdezonia

  • Blocking 1241 added

comment:14 Changed 7 years ago by bdezonia

  • Blocking 1341 added; 1241 removed

comment:15 Changed 7 years ago by bdezonia

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

comment:16 Changed 7 years ago 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 6 years ago by bdezonia

  • Milestone changed from imagej2-b7-ndim-data to imagej2-b8-analysis

comment:18 Changed 6 years ago 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 6 years ago by bdezonia

  • Blocked By 1983 added

comment:20 Changed 6 years ago by bdezonia

  • Blocked By 1984 added

comment:21 Changed 6 years ago by bdezonia

  • Blocked By 1985 added

comment:22 Changed 6 years ago by bdezonia

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.