Fusion: display fusion in real time

[hinerm]

When fusing blocks, an intermediate image will be displayed in real time as the fused pixels are filled in. This should be helpful in determining how much progress (if any) is actually being made during the fusion process.

Only one time point/channel will be displayed at a time, and the displayed image may not perfectly represent the final fused image - as it will undergo rearrangement and post processing.

Note: as this does introduce operations per pixel during the fusion process, this was benchmarked. On an 11 minute fusion, the time cost of drawing the fusion in progress is < 20 seconds (under 3%).

Closes #8

[hinerm]

@StephanPreibisch As mentioned in the commit message, I did benchmark this and didn't notice a significant performance hit.

But because it is kind of intrusive, popping up a display, I just wanted to make sure you're OK with it.

This (and the other tickets filed today) was prompted by a local discussion with scientists at LOCI about how we can make stitching better for them.

Thanks!

[StephanPreibisch]

Hi Mark,

thanks a lot for your effort but we cannot not do this. Actually, this is how I implemented it in the first place in a former version of the stitching, but I had to remove it for several reasons.

Most importantly, any automatic processing assumes that it is done once the image is displayed, which is not true if the progress is displayed. It is impossible or at least hard to find out otherwise when it is done.

Stephan

[dscho]

I guess it should be hidden behind a checkbox that is unchecked by default.

About automatic processing assuming that things are done once the image is displayed: this is wrong. Automatic processing will call the plugin, or a method, and assume that things are done only when that method returns, even if the image(s) that is/are returned were displayed beforehand.

I wish you would have consulted with me when you tried to make that procedure work the first time round, I could have helped you.

[hinerm]

@StephanPreibisch Can you give me an example of a workflow with automatic processing that this breaks? Or can you give me more information about how you made this decision? My assumption was that, since I am displaying an intermediate ImagePlus and not the final constructed one, it wouldn't be a problem, so I'd just like to understand better why that assumption was wrong.

Also would it instead be acceptable to have a checkbox to toggle this behavior? For the basic use case where you're just using the stitching GUI to initiate a run, I am assuming that it is very unlikely if not impossible to attach these dangerous automatic processing operations, and this option makes much more sense (as it gives the user visual progress feedback).

[hinerm]

@dscho I didn't see your response as I was writing my own. If automatic processing truly waits for the plugin to return, then I think my implementation can work, because it explicitly is only displaying the image during the fusion process, before Stitching returns.

But I am still happy to put a checkbox in the gui that defaults to false, and to attempt to address any failing workflows we can identify, if that is ok with @StephanPreibisch

[StephanPreibisch]

If I remember correctly (it is about 5 years ago it got removed) it was the ImageJ Macro Recorder that could not deal with the image being displayed too early. But I am not sure any more, all I remember was that I really liked this feature but after many discussions I had to remove it :)

[dscho]

@StephanPreibisch it is too bad that there are no meaningful commit messages recording those discussions, the reasons for the breakage, and your reluctance to remove that feature. It would help us now to determine whether it is really impossible (which I seriously doubt, there is just too much I managed to work with ImageJ 1.x).

It is also too bad that we do not have any record of those breakages so we could figure out how to prevent it from happening.

The only way forward I can see is therefore to repeat exactly the same mistakes as you made five years ago, keeping proper records for future reference.

With my suggestion to have a checkbox that defaults to unchecked, this problem should be moot anyways, do you agree?

[StephanPreibisch]

We can do it, but I suspect that many people will have issues with the ImageJ Macro recording then.

One option is to make a checkbox, yes. Still, as I pointed out, I think it would be more useful to do a smaller preview with downsampled images. That seems more useful to check if the stitching of a large acquisition will provide a reasonable output. What do you guys think?

We could start with the checkbox though ...

[StephanPreibisch]

@dscho these were unfortunately the times before github, so hopefully this will never happen again :)

[hinerm]

I think it would be more useful to do a smaller preview with downsampled images

I think this serves a different purpose... To me, a preview answers the question "Will stitching do approximately what I want it to?" whereas watching stitching occur answers "It has been 20 hours of stitching, what progress has been made?"

I think both are good questions to answer, and I really like the idea of the preview. It just doesn't replace the desire for visualizing stitching...

I will add the checkbox and update this PR, and I created a separate issue for a stitching preview.

[dscho]

Thanks @hinerm!

@StephanPreibisch:

these were unfortunately the times before github, so hopefully this will never happen again :)

Well, these were the times we used Git, and commit messages capturing the story behind the changes that is not told by the diff is not something which GitHub helps you make...

Anyway, I am happy that we're good to move forward now.