Virtual stack reads all pixels

[hinerm]

In ImageJVirtualStack the map method is called when getProcessor is requested.

This ends up fully mapping the image, iterating all pixels in the data, defeating the purpose of being virtual.

[tpietzsch]

@hinerm Hmm, actually projector.map() should only iterate the pixels of a single slice. That's why the projector.setPosition(position[0], 2);. In getProcessor method the projector is positioned at the correct slice. Can you provide more details on the problem?

[hinerm]

@tpietzsch I can! I am trying to get File > Import > Image Sequence... in Fiji working properly with SCIFIO, such that it is backed by a SCIFIOCellImg.

My test data is a set of .fake files.. for example, creating these files on disk and using them as input to Image Sequence...:

lotsofplanes1&axes=X,Y,Z&lengths=256,256,100000.fake
lotsofplanes2&axes=X,Y,Z&lengths=256,256,100000.fake
lotsofplanes3&axes=X,Y,Z&lengths=256,256,100000.fake
lotsofplanes4&axes=X,Y,Z&lengths=256,256,100000.fake
lotsofplanes5&axes=X,Y,Z&lengths=256,256,100000.fake

if you want to reproduce this in Fiji, under Edit > Options > ImageJ2 you should have Use SCIFIO when opening files enabled, and Enable ImageJ2 data structures disabled.

As is, it takes about an hour to open the dataset this way.

The only additional testing I did was commenting out the rest of the getProcessor method which causes the dataset to open up almost immediately (but is of course all 0's).

Expected behavior would be the dataset opening almost immediately and loading planes on demand while scrolling through the dataset.

Note that there very well could be other bugs coming into play here with the ImageJ-Legacy layer. But at first look it seemed like the ImageJVirtualStack was being used as intended.

Please let me know if there's any more info I can provide or specific testing you'd like me to do. I'm also happy to dig into this more, it just wasn't an immediate priority.

[tpietzsch]

@hinerm I would be surprised if the problem lies with ImageJVirtualStack. For BigDataViewer, I have implemented exactly the same: If you File>Import>BigDataViewer... an image from a bdv hdf5 dataset, you can import it as a virtual stack, which is just ImageJFunctions.show()ing a CachedCellImg, see here. That works as expected, i.e. almost immediately shows and loads from disk (or cache) when you change slices.

If commenting out the getProcessor method solves the problem, that is a good lead. Could you try to find out from where it is called? Maybe there is some one-time-action going on, like finding min and max of the whole image? One way to verify this would be to try with a smaller image, how long it takes to change slices once the image is open (maybe use a very small cache, such that data needs to be loaded from disk when changing slices). My feeling is that it would take long until the image displays but then it's relatively fast change slices although they must be fetched from disk.

[tpietzsch]

Oh, and from my side there is no reason to make this an immediate priority. Would be just interesting to find out whats going on.

Btw. a related problem is taking a ImageJ virtual stack and wrapping that as an ImgLib Img using ImagePlusAdapter. That indeed reads all the slices into memory (easily leading to OutOfMemory). For that I have also a workaround in BigDataViewer, which wraps ImageJ virtual stacks as CachedCellImg.

[hinerm]

@tpietzsch OK I don't know how I missed this before, but it looks like it's just a limitation with the FolderOpener