Extend virtual stack implementation also for the XY plane

[oeway]

Currently the virtual stack implementation only support lazy loading along the z/t dimension, not XY plane. This make it not feasible to load large images (e.g. histopathology image). And the problem becomes more severe when we try to load remote data, e.g. zarr arrays. We came across this issue when we work with the NGFF/zarr lazy loading support in ImageJ.JS (demo: https://ij.imjoy.io/?open=https://s3.embassy.ebi.ac.uk/idr/zarr/v0.1/6001240.zarr)

I just had a discussion with @tischi and we think it would nice if this can be implemented directly in ImageJ-1, it should not be too hard and could serve as a light-weight alternative to the BigDataViewer in ImageJ-2. This will be very beneficial to enable support for large images and multi-resolution pyramid, make it possible to bridge with the ongoing efforts on developing scalable image file format (i.e. NGFF).

I am not super familiar with the code base, but it would be great if someone can look into this, and we would be really appreciate it! @rasband

[rasband]

Is there some reason why you can't create a plugin that extends VirtualStack and supports lazy loading of XY planes?

[tischi]

@rasband

Sure, extending VirtualStack would be the thing to do.

Could you help us a bit?

Which method is called when the viewer moves to a new plane?
Is it getPixels() or is it getProcessor()?

And how could we notify the viewer (i.e. trigger a repaint) when the slice data (the content of the current processor) changed, due to loading of an additional tile?

[rasband]

The getProcessor() method is called when the viewer moves to a new plane. You can trigger a repaint by calling ImagePlus.setProcessor(ImageProcessor).

[tischi]

OK, but a VirtualStack does not hold a reference to its ImagePlus, does it?

I had a brief look into VirtualStack and it seems one has to obtain it like this: ImagePlus img = WindowManager.getCurrentImage();
Could this be a bit risky in case there are several images open and the user clicked on another image?

Maybe we could create a VirtualStack that contains a method setImagePlus( ImagePlus imp ) to be sure we are updating the correct ImagePlus?

But anyway, this seems like minor issues, so I guess in principle it should be doable without too much effort, indeed.

[rasband]

The extended VirtualStack can hold a reference to the ImagePlus and have a setImagePlus() method.

[tischi]

@rasband I have another question: In case the image planes become really big (>46340^2) we will run into the 32 bit Java indexing limit for arrays. Is there anything we can do given the current architecture of the ImageProcessor?

[rasband]

The ImageProcessors created by the extended VirtualStack are for display purposes so they will not be very big.

[ctrueden]

Since it sounds like there is a solution, I'm closing this issue. But @oeway and @tischi please reopen if you still feel there is some work that needs to be done for this in the ImageJ core.

[oeway]

@tischi Do you have a chance to look into this? I am coming back to this issue and think it would be really nice to have imagej as an annotation tool for large zarr images hosted remotely. I am also wondering in that case would the ROI also work with the extended virtualstack.

[tischi]

Hi @oeway Realistically, I won't be able to work on this. Could you maybe find a student with some Java knowledge to work on this? I could help a bit with the supervision.

[dprodanov]

Dear all, @oeway <https://github.com/oeway> sounds like a Google Summer of Code project. Dimiter

…

On Sat, Dec 18, 2021 at 1:42 PM Christian Tischer ***@***.***> wrote: Hi @oeway <https://github.com/oeway> Realistically, I won't be able to work on this. Could you maybe find a student with some Java knowledge to work on this? I could help a bit with the supervision. — Reply to this email directly, view it on GitHub <#120 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANM2OO44YYE4OUNY2T42QLURR6UJANCNFSM4523ZV2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>