Ticket #1946 (closed defect: wontfix)
Opened 2013-07-12T11:29:45-05:00
Last modified 2014-08-19T11:17:21-05:00
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 |
Description
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 2013-07-12T11:31:58-05:00 by curtis
comment:3 Changed 2013-07-30T15:54:55-05:00 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 2013-07-31T15:28:09-05:00 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 2013-07-31T15:47:11-05:00 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.
comment:7 Changed 2014-08-19T11:17:21-05:00 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.
The bug doesn't happen if you use File > Open to open an RGB image; see also ticket #1947.