Frequently Asked Questions
Bock Labs Server
The Bock Labs Server is LOCI’s way to centrally store the data that LOCI researchers create. It’s for storing anything you want. You can store raw images, Excel spreadsheets, Word Documents, and more.
No. The Bock Labs Server is meant to be your primary storage location for the data you create, not just a backup of your computer. The Bock Labs Server can be added to your computer's desktop the same way as an external hard drive, so it's possible for you to work on your images from multiple locations without having to worry about synchronizing files across multiple computers.
- No more flash drives or FTP.
- It's accessible from any computer that has an internet connection.
- It is password protected.
- It’s easy to share data with other LOCI members.
- It’s backed-up in case of hardware failure.
- No more syncing files across multiple computers.
- It's possible to go back and retrieve deleted files.
The FTP server isn't backed up, nor is it as secure as the Bock Labs server. LOCI's goal is to keep the FTP server, but have only infrequent and non-UW users use it.
No. The Bock Labs Server has been set up so that while you can easily see other people's data, only you can delete your own data.
Once you are connected to the server, Fiji will treat it the same way as a local hard drive or flash drive. When you open files, you may have to search for your directory. On the shared computer list, click data.ad.bocklabs.wisc.edu. Click on LOCI, and then your user account. Since ImageJ remembers where you last opened files, you should not have to do this often.
Also, if you are on a Mac or followed the "Map Network Drive" option on a PC, you can drag and drop files from the network drive onto the Bio-Formats shortcut screen.
See the Coverslips page for information on coverslips.
See the Objective Specifications page for details on objectives.
High magnification non-immersion objectives are designed to be used with air between the front lens and the cover glass. Most objectives are designed to used with a standard cover glass thickness of 0.17 millimeters (a number 1.5 cover glass). When air objectives with high numerical apertures (0.8 or greater) are used, variations of just a few micometers in cover glass thickness can cause image degradation. Abberations get worse as the cover glass thickness increases. A correction collar is used to compensate for these errors. The collar allows for adjustment of the positioning of the central lens group within the objective. This correction is also used with objectives intended to be used with water or glycerin immersion media.
The OME Consortium
Absolutely, we encourage you to contribute. We welcome all additional help in developing effective software and promoting open standards in microscopy. A detailed list of member labs and active participants can be found on the OME website on the Development Teams, Contributors and Commercial Partners pages.
Historically, OME has not been funded directly, since the software and file formats themselves are not hypothesis-driven research. Rather, OME has been developed to facilitate specific research with an acute need for such tools.
LOCI's OME work is NSF- and NIH-funded through research grants. The Goldberg lab is funded directly through NIH. Development of OME in the Swedlow lab is supported by the Wellcome Trust and the BBSRC.
Java's time performance has been comparable to C++ for many years now, especially in the realm of file I/O where SCIFIO is focused. According to one thorough study performed in 2005, "Java often outperforms C++ in operations such as memory allocation and file I/O while C++ often outperforms Java in arithmetic and trigonometric operations." This statement is corroborated in an earlier study from 2004 that also includes an I/O benchmark: "If we exclude the trigonometry component, Java performed virtually identically to Visual C++, the fastest of Microsoft's languages." Some of the theoretical basis for such results is discussed in another 2004 article, which also finds that "Java performance on numerical code is comparable to that of C++, with hints that Java's relative performance is continuing to improve."
We have seen two refutations (, ) of these figures, but neither includes an I/O benchmark, and according to their results Java's computational performance is within a factor of two of C++'s. Even from a pessimistic perspective, we believe the trade-off is acceptable when considering the other advantages of Java such as cross-platform deployment, widespread support and ease of development. As the second article above states: "It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster."
From a practical perspective, we use Java because it is cross-platform and widely used, with a vast array of libraries for handling common programming tasks. C++ or Python would also have been reasonable choices, but we chose Java because it is easier than C++ and faster than Python, with a larger assortment of de facto standard libraries (e.g., Swing) than either.
Java is also one of the easiest languages from which to deploy cross-platform software. In contrast to C++, which has a large number of complex platform issues to consider, and Python, which leans heavily on C and C++ for many of its components (e.g., NumPy and SciPy), Java code is compiled one time into platform-independent byte code, which can be deployed as is to all supported platforms. And despite this enormous flexibility, Java manages to provide time performance nearly equal to C++, often better in the case of I/O operations.
Historically, LOCI's software projects grew around efforts to harness VisAD, a Java component library for interactive and collaborative visualization and analysis of numerical data, within our VisBio application for visualization of multidimensional microscopy data. We also added support for several microscopy formats to VisAD before splitting the code into a standalone library, Bio-Formats. The choice to use Java and VisAD (rather than, e.g., C++ and VTK) was partially motivated by the fact that LOCI's lead software architect Curtis Rueden was already an expert on Java and VisAD technologies. Choosing Java also enabled cross-platform integration with ImageJ, one of the most popular freely available image processing tools in the life sciences field, as well as with the OMERO system for visualization, management, and annotation of microscopy data.
For the best performance, a fast CPU is needed—at least 1 GHz for Macintosh, or 2 GHz for Windows and Linux machines. VisBio can run on slower machines, but some features may seem sluggish, particularly animation. Since VisBio is written in Java, and Java is rather slow on the Mac, we recommend a strong system if you are running Mac OS X—a G5 will perform much better than an older G4.
We strongly recommend at least 512 MB of system RAM, and suggest 1 GB or more for memory intensive features such as volume rendering of large datasets. Lastly, for a responsive 3D display, a good video card is recommended. Any recent card should provide enough performance for VisBio's needs.
The GPL allows you to make as many copies of the software as you want, and even create derivative works of the software, as long as those works are also distributed according to the GPL's terms. However, it prohibits using any of VisBio's code in a commercial product, so that VisBio and all derivative works remain free for everyone to use.
VisBio development has ceased in favor of ImageJ2. Our eventual plan is to integrate VisBio's unique functionality into ImageJ as a VisBio plugin suite.
Historically, we released new versions when a significant number of bugs were fixed, or when significant new features were added. Take a look at the What's New sidebar on the VisBio home page to see the release history. To be notified of any future releases, sign up for the LOCI software mailing list.
VisBio was written by Curtis Rueden of the Laboratory for Optical and Computational Instrumentation (LOCI), White Laboratory of the Laboratory of Molecular Biology, University of Wisconsin-Madison, with contributions from Melissa Linkert and Eric Kjellman.
Thanks to John White, Kevin Eliceiri, Bill Hibbard, Bill Mohler, Ilya Goldberg, Dennis Fan, Gerard Ziemski and everyone at the White Lab for ideas and assistance.
VisBio used to link all thumbnails into the displays simultaneously. This strategy had the advantage of improving animation performance. Unfortunately, other functions such as color adjustments became slower and slower as the amount of thumbnail data increased. Even worse, VisBio's memory requirements became unreasonable with sufficient thumbnail data linked to the displays.
As of v2.20, VisBio links thumbnails into the displays only as needed. You will notice substantial speed improvements among several features, as well as vast memory usage improvements, especially with larger datasets (datasets that once required more than 1 GB of RAM now need less than 100 MB). However, because this on-the-fly thumbnail linkage is more CPU intensive, animation at high frame rates requires a fast processor to keep up.
For the next major release of VisBio, we plan to investigate techniques for improving animation performance, such as the use of by-reference texturing in Java3D.
You can alter the X, Y and Z aspect ratios directly by typing values into the "Aspect ratio" text boxes on the display panel.
Some of the color Openlab datasets we have encountered store images in a rather interesting fashion. First, there are three single-channel images in a row—a red channel, a green channel, and a blue channel—each with values ranging from 0 to 4,095. This data is probably the originally collected data, stored in full 12-bit depth (for a total of 36 bits per image). For some reason, the file then contains one color image of the same information at 24-bit resolution (each of R, G and B ranging from 0 to 255).
This discrepancy in color ranges makes VisBio's color mapping job difficult. Fortunately, there is an easy way to avoid this issue altogether, using VisBio's subsampling ability.
What you probably want is to visualize just the full-color images. Remember that the image ordering inside the file is RGBC,RGBC,RGBC (red, green, blue, full-color; etc.). You want a data object containing only every fourth channel, starting with image #4.
After importing your dataset, click Add > Subsampling. Choose a name, then click the Edit button to alter its parameters. Change the starting image for the appropriate dimension from 1 to 4, and change the step from 1 to 4. Click Apply, map the sampling to one of VisBio's displays, and you're set!
If it appeared inside a window called the "Error console," you can copy the contents and paste it into an email message to the mailing list. Drag the mouse across the text to select it, then press the key combination to copy it. (On Windows, the command is Ctrl+C. On Mac OS X it's Command+C.) Paste the error into the email message, along with detailed steps on how to reproduce it. The author is committed to eliminating program bugs.
VisBio writes all error messages to a file called "errors.log" in the VisBio directory. First, check that file to see whether the error output is present.
Alternately, you can take a screen capture. (On Windows, hitting "Print Screen" copies the current screen into the clipboard, which you could then paste into an image editing program such as Paint, then save it to a JPEG or other image file.)
Also, it is possible that VisBio is not locked up, but that there is a modal dialog box (such as the Colors dialog box) waiting to be closed before text can be copied from the error console.
This problem occurs on machines with certain memory configurations when the system is unable to allocate enough RAM to the JVM's maximum heap. By default, VisBio uses up to 512 MB of RAM. If you increased that value (using the System tab) beyond the amount of physical RAM on your machine, VisBio may no longer start up properly. How to correct the issue depends on which platform you are running.
Windows: Double-click "VisBio.bat" within your VisBio directory. When VisBio starts up, use the System Information panel to set the value back to 512. Or you can edit the "launcher.cfg" file, and change the "-mx####m" value back to "-mx512m" (the default). Save the file and try to launch VisBio again.
Macintosh: Option-click the VisBio icon and choose "Show package contents" from the menu. Navigate into the "Contents" folder, then double-click the Info.plist file. Navigate through the tree to the "-Xmx####m" entry and change it back to "-Xmx512m" (the default). Save the file and try to launch VisBio again.
Linux: Edit the "visbio" script, and change the "-mx####m" value back to "-mx512m" (the default). Save the script and try to launch VisBio again.
This behavior is a known issue that we have observed on our Mac OS X systems. Since no error message is generated, the problem is difficult to diagnose.
Fortunately, the bug seems fairly rare. If you force quit the program and restart, VisBio will most likely start up normally.
This crash occurs due to a bug in QuickTime for Java. Typically, the data loads fine, but VisBio crashes when attempting to visualize it. Only certain Windows systems seem to be affected, and it may no longer be an issue with newer versions of QuickTime (we have no confirmed reports of it occurring with QuickTime v7.0). If you experience this problem, first verify that it is Openlab-specific rather than a crash that happens no matter what you are trying to visualize. If you are certain you are experiencing an Openlab-specific issue, try upgrading to the latest version of QuickTime.
This issue usually occurs due to a bug with certain video card drivers. There are two ways for Java3D to render data on Windows: OpenGL and Direct3D. By default, VisBio uses Direct3D, which seems to work on most configurations.
If you experience crashes, blank displays or other problems when attempting to visualize data, you can try switching to the OpenGL renderer by clicking the "Change" button next to the renderer listed on the System Information panel.
To check whether your video card supports Direct3D or OpenGL, see the list of video cards tested with VisBio.
First of all, VisBio can allocate up to 512 MB of RAM for its use "out of the box." You can reduce the out of memory errors by allowing VisBio to utilize more memory. To do so, bring up the System Information panel (Window -> System Information) and click the "Change..." button next to the "Memory maximum" box. We recommend allocating up to 3/4 your physical memory to VisBio for best results (e.g., if you have 1 GB of RAM, put in 768 MB). See the "Changing the memory limit" topic in VisBio's built-in help for more details.
VisBio's memory usage is largely determined by the number of simultaneous pixels in the 3D display. By default, VisBio subsamples the current stack's images to 192x192, to help improve memory usage (the current image in the 2D display is not subsampled in this manner, and is displayed at full resolution). Note that these limits are adjustable in VisBio's options ("Preferences" on Mac OS X).
Effectively, then, memory usage is a function of the number of slices in the 3D display. You can create a subsampling by selecting the dataset to subsample, clicking "Add >" and choosing "Subsampling" from the popup menu. See the "Subsampling" topic in VisBio's help for more information.
This problem occurs with early releases of QuickTime v7.0 for Windows. If VisBio reports your QuickTime version as expired on the System Information panel, you can fix the problem by redownloading and reinstalling QuickTime.