⚠

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 #1594 (closed feature: wontfix)

Opened 2012-12-06T10:22:51-06:00

Last modified 2019-04-23T13:30:04-05:00

Fix obviously failing commands [compatibility]

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: imagej2-b10-compatibility
Component: Core Version:
Severity: serious Keywords:
Cc: Blocked By: #1615, #1946, #1954
Blocking:

Description

Some commands in IJ2 fail in a very apparent fashion. They should be addressed preferentially. See blockers to this ticket.

Change History

comment:1 Changed 2012-12-06T11:16:57-06:00 by bdezonia

  • Blocked By 436 added

comment:2 Changed 2012-12-06T11:33:17-06:00 by bdezonia

  • Blocked By 436 removed

comment:3 Changed 2012-12-06T12:45:38-06:00 by curtis

  • Summary changed from Fix obviously failing commands (2.0.0-beta10) to Fix obviously failing commands [compatibility]

comment:4 Changed 2013-03-20T13:29:14-05:00 by bdezonia

  • Blocked By 1615 added

comment:5 Changed 2013-07-15T16:14:04-05:00 by bdezonia

  • Blocked By 1954 added

comment:6 Changed 2013-07-31T15:47:11-05:00 by curtis

  • Blocked By 1946 added

(In #1946) 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 being 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 2019-04-23T13:30:04-05:00 by curtis

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