I agree that it is convoluted, and would benefit from simplification.
Because in ImageJ1, an
ImagePlus can have visualization settings such as position in ZCT, current LUT, current selection, and an overlay containing ROIs. Whereas in ImageJ2, a
Dataset cannot have any of those things—it is a wrapper around an ImgLib2 accessible without any associated current position. A
DatasetView wraps a
Dataset and has visualization settings; an
ImageDisplay has a list of
DataViews which can include linked
Overlay (i.e. ROI) objects. So it came to be that
ImageDisplay was the correct choice for synchronization with
Because not everything in the ImageJ1 API can be offered dynamically. ImageJ1 has some fields internally, and a radically different API than ImageJ2, so there are places where copying/translating/adapting data was needed, rather than only wrapping it. That said, we need to be wrapping things in more situations. But you cannot e.g. wrap ImageJ2
Overlay objects into ImageJ1 ROIs, because ImageJ1 ROIs are not interface-driven.
Thank you @Christian_Tischer. I am sorry to say I might be quite slow with progress on this front, although if @maarzt and I stay in frequent contact, perhaps we can move things ahead more quickly. If @fjug and @maarzt agree: perhaps @maarzt and I could have a weekly video chat to keep the improvements to ImageJ Legacy flowing? Otherwise, I fear my time is going to be saturated with the SciJava Common overhaul, ImageJ Ops, the ImageJ Launcher, continued efforts toward eliminating the ImageJ Jenkins, …