Ticket #1946 (closed defect: wontfix)

Opened 4 years ago

Last modified 3 years ago

Color table information can get lost

Reported by: curtis Owned by: bdezonia
Priority: minor Milestone: imagej2-b10-compatibility
Component: Legacy Compatibility Version: 2.0.0-beta-7
Severity: serious Keywords:
Cc: Blocked By:
Blocking: #1594


Here is a workflow which causes color tables to get lost:

  • File > Open Samples > Clown
  • Image > Type > Unsigned 8-bit (with "Combine channels" unchecked, clearing the "RGB Color" legacy flag)
  • Edit > Cut (legacy command to zero out the red channel)

Now the other two remaining channels 2 and 3 also have red color tables, rather than retaining their green and blue ones, respectively.

Change History

comment:1 Changed 4 years ago by curtis

The bug doesn't happen if you use File > Open to open an RGB image; see also ticket #1947.

comment:2 Changed 4 years ago by bdezonia

  • Blocking 1457 added

comment:3 Changed 4 years ago by bdezonia

The TypeChanger code changed recently such that I cannot duplicate. Once the fix-type-changer code is merged (see #1972) the ability to clear the rgb merged flag will be restored. Then retest this bug.

comment:4 Changed 4 years ago by bdezonia

fix-type-changer has been merged and I can duplicate bug.

The issue is that IJ2 supports multiple color tables for the image while IJ1 only supports a single table since its not a composite image. So when harmonizing back from IJ1 to IJ2 it gets the one color table and stamps it into every channel. The question is what should it do?

It could copy the one table to the active channel view and leave the others undisturbed. This would fix this specific problem but might not be desirable.

Or it could send a CompositeImage of mode Color to the legacy plugin and color tables will be correctly mapped. But just for images of 1-7 channels. Others would have to adopt some approach (like the one mentioned in the previous paragraph). Unfortunately this might not be a simple fix because there currently isn't support for ImagePluses becoming CompositeImages and vice versa in the harmonization code. There may indeed be reasons we need this.

ctrueden can I get your opinion on this?

comment:5 Changed 4 years ago by curtis

  • Blocking 1594 added; 1457 removed
  • Milestone changed from imagej2-b8-analysis to imagej2-b10-compatibility

This seems like a situation where the synchronizer needs to be smart about the limitations of IJ1. If the IJ2 version of the image has multiple distinct color tables, then it should certainly not overwrite all of them with the ImageJ1 color table. It would be ideal if the ImageJ1 color table could somehow be tied to the "correct" color table in ImageJ2, and then only that one would get synchronized in case of changes in ImageJ1-land. The simplest approach would be to always use the first color table of the IJ2 image for this.

In the case of the image being restructured, it becomes less clear how to maintain this mapping. But for the workflow above, no restructuring takes place—pixel values are merely zeroed out. So it might work.

However, there are many other potential compatibility issues, even if we were to employ this strategy. Because in ImageJ1-land, as you say, the color table is only red, and anyone expecting things to be otherwise (based on their perception from the modern UI) will be disappointed.

Booting this ticket to imagej2-b10-compatibility, since we have bigger fish to fry.

Last edited 4 years ago by curtis (previous) (diff)

comment:6 Changed 4 years ago by bdezonia

See also #1974

comment:7 Changed 3 years ago by curtis

  • Status changed from new to closed
  • Resolution set to wontfix

Synchronization of ImageJ1 and ImageJ2 data structures is on hold until the ImageJ2 data structures can benefit from another design iteration. See  https://github.com/imagej/imagej-common/labels/data-model for a (non-comprehensive) list.

Note: See TracTickets for help on using tickets.