Re: bfconverter nd2 to tif

Posted by Greg on Mar 25, 2015; 1:12pm
URL: http://imagej.273.s1.nabble.com/bfconverter-nd2-to-tif-tp5012133p5012162.html

Hi Curtis,

thanks for your detailed answer ! I think you and all the people behind ImageJ/FIJI and OME are doing wonderful things to keep stuff doable and open for everyone. I am just nerved by proprietary formats which allow you to do almost nothing (Nikon Viewer is good for looking at holiday snapshots but nothing else..) !

I more or less jumped into a life cell imaging project, and I am having hard times to explain to the experimentalists why things like the swap space approach work so badly. But with your explanations I feel on safer ground now.

So ya, we have around 3500x3500 pixel slices with three channels with up to 750 frames. One slice is around 25mb and one frame therefore around 75mb. That makes around 55gb in total. Maybe that is just too much and we have to rethink our experimental design. Right now the nd2 file format seems to be broken completely on at least one machine, so conversion to a more reliable format seems to be the only way to keep things straight. I am still able to open a nd2 file on my machine in virtual hyperstack mode, and frame switching takes about 1sec. I converted them like you advised to ome.tiff format, and it takes about 30sec to open them in virtual hyperstack mode, switching takes the same time as for the nd2 format.

Right now I am stuck, because my jython plugins do not run anymore if I have a nd2 or a ome.tiff file opened in virtual hyperstack mode. I tried to start Fiji in the terminal to catch some errors, but no output. When I restart my plugins like a few times, then finally they come through and open all at once and I get a Java heap error, very weird.  When I monitor the RAM, it is around 1.3Gb used by Fiji when the virtual hyperstack finally opened the first slice. When I fire up a very basic plugin (GoTo_Coordinate.py):

from ij import IJ,ImagePlus
from java.awt import Color
from ij.gui import GenericDialog,Overlay,Roi

Color1 = Color(255,5,20,255)
def getOptions():
  gd = GenericDialog("Spatiotemporal Cell Coordinates")
  gd.addNumericField("Frame", 1, 0)  # show 2 decimals                                                                    
  gd.addNumericField("X-Coordinate", 500, 0)  # show 2 decimals                                                          
  gd.addNumericField("Y-Coordinate", 500, 0)  # show 2 decimals                                                          
  gd.addNumericField("Zoom Level", 150, 0)  # show 2 decimals                                                            
  gd.addCheckbox("Mark Coordinates", True)
  gd.showDialog()


  # Read out the options                                                                                                  
  frame = gd.getNextNumber()
  xcoord = gd.getNextNumber()
  ycoord = gd.getNextNumber()
  zoom = gd.getNextNumber()
  mark = gd.getNextBoolean()

  return int(frame),int(xcoord),int(ycoord),float(zoom),mark


frame,xcoord,ycoord,zoom,mark = getOptions()
orig = IJ.getImage()

# wors also for less than 3 channels present                                                                              
orig.setPosition(3,1,frame)
IJ.run(orig,"Set... ","zoom=" + str(zoom) + " x="+str(xcoord) + " y="+str(ycoord))

if mark:
  roi = Roi(xcoord-2,ycoord-2,3,3)
  roi.setStrokeColor(Color1)
  roi.setStrokeWidth(3)
  orig.setRoi(roi)

RAM usage jumps to 13Gb and beyond, so maybe Fiji loads the whole stack in the background ? For that little example plugin above, this happens before(!) I see the getOptions Dialog.

Best,
Greg