Bug when cropping virtual stack

Usage & Issues
,
#1

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.

#2

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.

1 Like
#3

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.

#4

@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?

#5

@imagejan:

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:

  • Use virtualstack to figure out how I need to crop the data.
  • Write a script that produces a cropped version of the data set without loading the whole data set into memory. Probably I could use bio-formats to load and crop not too big chunks of the data set and then save those cropped chunks.

What do you think?

#6

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.

#7

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.

#8

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.

#9

@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?

#10

@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?!

#11

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

2 Likes
#12

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.

#13

@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).

#14

@ctrueden @dgault Hi Curtis, yes, I also think it would be great if the BFVirtualStack could be extended. Let’s see what they answer!

#15

The bug is still there and nothing has been done in OME.
How can we give this bug some interest ?

#16

Hi @olly, Im afraid this feature hasn’t d many requests in recent years and so hasn’t been a priority. If anyone wishes to help and contribute a solution I can certainly provide guidance and pointers and am happy to review any changes. There are also 2 different workflows to consider here, being able to combine the Bio-Formats crop on import parameters with virtual stack and secondly applying cropped values to an existing virtual stack. Do you have a preference as to which option you need?

#17

@Christian_Tischer Would BigDataProcessor work for this use case ?

1 Like
#18

Hello
I have solved the problem creating a macro that combine crop on import and virtual stack.

//this macro allow to crop on virtual stack
/*

  • already known as
  • Bug when cropping virtual stack - #10 by Christian_Tischer
  • and not solved in Bioformat
    */
    //choose file
    FILE=File.openDialog(“Select a File”);
    DIR=File.getDirectory(FILE);
    //get the file in virtual stack
    run(“Bio-Formats Importer”, “open=[”+FILE+"] color_mode=Colorized rois_import=[ROI manager] view=Hyperstack stack_order=Default use_virtual_stack");
    //enhance channels
    getDimensions(width, height, CH, slices, frames);
    for (i = 1; i <=CH; i++) {
    Stack.setChannel(i);
    run(“Enhance Contrast”, “saturated=0.35”);
    }
    Stack.setChannel(1);
    //find crop size
    setTool(“rectangle”);
    waitForUser(“Crop”, “Select the crop zone in the image”);
    getSelectionBounds(X, Y, WI, HE);
    //close virtual mode
    close();
    //reopen with BioFormat importer in crop mode with the crop size infos
    run(“Bio-Formats Importer”, “open=[”+FILE+"] color_mode=Colorized crop rois_import=[ROI manager] view=Hyperstack stack_order=Default x_coordinate_1=X y_coordinate_1=Y width_1=WI height_1=HE");
    TITRE=getTitle();
    run(“Enhance Contrast”, “saturated=0.35”);
    //save the file in the right folder
    NEWPATH=DIR+File.separator+“crop-”+TITRE;
    saveAs(“tiff”, NEWPATH);
    close();

Hope this macro can help.

2 Likes
#19

Yes, that was actually partly what is what made for, see the Crop item in:

#20

@olly your macro is in fact a clever workaround, good idea!