When cropping a 5D virtual stack, the data is kind of lost and all image planes look the same.
To try this you can save the Mitosis Sample as tif and then load it via Bio-Formats Importer, checking the virtual stack option. If you then place a rectangle and apply Image>Crop, the data is gone.
It would be great if this could be fixed, because I think this would be a super useful feature to crop e.g. large SPIM data sets without having them to load into memory.
In order to crop via Image > Crop, the whole image data would still need to be loaded into memory, though. To avoid loading unnecessary data, you can use the Crop on import option of the Bio-Formats Importer, which lets you enter the dimensions of the rectangle in a separate dialog.
ImageJ 1.x is full of these sorts of limitations when it comes to virtual stacks. A goal of the ImageJ2 project is to eliminate these issues, using e.g. ImgLib2 Views as needed, as well as on-demand disk caching of virtual stack planes. But we are still a ways off from having it all available via the end user interface.
@ctrueden: Do you still think this is something that could be fixed in the IJ1 framework, I guess by Wayne?! Does Wayne actually check the IJ Forum or would I have to post somewhere else about IJ1 related issues?
Looking at: https://github.com/imagej/imagej1/blob/master/ij/VirtualStack.java
I feel it should not be too hard to crop the images upon loading: The virtualstack “just” would need to be informed by the “Crop” command about the cropping dimensions. Or am I missing something?
I checked this but it runs into the same issue as bio-formats cannot combine the virtualstack and crop on import.
One workflow could however be:
What do you think?
Support for cropping virtual stacks would be doable I think. General support for commands which alter image spatial characteristics less so, probably. @Wayne does read the forum—especially if you use a mention as I have done here.
Cropping of virtual stacks opened with File>Import>Image Sequence and File>Import>TIFF Virtual Stack (including 5D stacks) works. I do not know why it does not work with virtual stacks imported using Bio-Formats.
Bio-Formats has its own extension of VirtualStack, in order to provide the planes from its readers.
Since this is a Bio-Formats-specific issue, it should be reported as a bug to the OME team.
@Wayne: It tried loading
mitosis.zip via File>Import>TIFF Virtual Stack and then running Image>Crop. Indeed this shows the correct result, however the (V) dissappears from the image name. Does that mean that ImageJ loaded the whole file into memory during the crop?
If that is the case that would not be so useful for, e.g. handling large SPIM data.
As I mentioned above, modifying VirtualStack.java such that it is notified by Image>Crop about the new image dimension seems, to me, like the better thing to do. What do you think?
@dgault
Dear Bio-Formats team,
I load the 5D file mitosis.tif file, attached in above post, via Plugins>Bio-Formats>Bio-Formats Importer checking Use virtual stack. Using Image>Crop on this data does not work, but only shows one of the planes in the data set, no matter how one browses through z,c,t. Could this be fixed?!
Hi Christian,
I tested the crop mode in Bio-Formats using the sample data set you provided and I was certainly able to reproduce the problems you were seeing. I have opened a bug ticket to track the issue and will hopefully be able to further investigate a potential fix shortly.
https://trac.openmicroscopy.org/ome/ticket/13222#ticket
With Thanks,
David Gault
The File>Import>TIFF Virtual Stack command loads all the planes, but only one at a time. I am happy with the way Image>Crop currently works with virtual stacks. The ImageJ TIFF reader does not have a way to crop planes as they are opened so FileInfoVirtualStack, the subclass of VirtualStack used by File>Import>TIFF Virtual Stack, when switching planes, would have to read the entire plane and crop it, which would be slow.
@Christian_Tischer This could be a feature request for Bio-Formats, since the Bio-Formats API does support reading only a cropped region of each plane as it is read from disk. Similar to what @Wayne describes, the default implementation just opens the whole plane and then crops, but many readers including TIFF do implement the subregion I/O. I think the Bio-Formats VirtualStack subclass would just need to support the idea of a cropped region, as you describe (though I did not study the BFVirtualStack recently, so I could be wrong).