Frequently Asked Questions
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
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.
LOCI is interested in harnessing OME as a practical, effective data management system for multidimensional images. Our primary contributions thus far have been:
- Stronger file format support via development of the Bio-Formats library, which provides the ability to convert third-party formats into OME-XML and OME-TIFF, import them into the OME and OMERO servers, and read them with applications such as ImageJ and VisBio.
- Open file format standards with an emphasis on compatibility and efficiency. In particular, we have created OME-TIFF and are working to improve the OME-XML schema to encompass useful information relevant to 4D light microscopy and beyond.
- Client-side tools for interacting with both the OME server and OME-XML, including the OME plugins for ImageJ for transferring data to and from an OME server, VisBio and Data Browser tools for visualizing data from an OME database, the OME-XML Java library for reading and manipulating OME-XML trees, and OME Notes application for allowing users to view and edit OME-XML metadata in their datasets.
- Every Format-specific Metadata implementation provides core meta-information such as image dimensions.
- If a Format provides a Writer, it also defines a Translator from Metadata to its Format-specific Metadata implementation. Hence, it will be possible to convert any source Format to that destination Format. (In this way, core meta-information will be preserved, but not necessarily domain-specific meta-information.)
- Extensions are possible that enable preservation of domain-specific information during translation. The extension defines its own standard Metadata implementation (e.g., OMEMetadata in the case of the OME data model). The extension also provides Translators from each supported Format-specific Metadata implementation to that standard. In the case of Writers, the extension may also choose to provide Translators from its Metadata standard back to each Format-specific Metadata implementation. If it does so, all domain-specific meta-information compatible with the defined standard can then be preserved during format conversion.
In short, by converting via standard exchange formats such as OME (or the base Metadata interface itself), translation becomes an O(M) problem, rather than an O(M2) problem.
Lastly, note that translation is generally automatically by the TranslatorService (although it can also be done manually by querying the desired Translator directly). If you ask the TranslatorService to convert from, e.g., TIFFMetadata to APNGMetadata, it first looks for a direct TIFF-to-APNG Translator, and if one is not available, it then looks for a generic Metadata-to-APNG Translator. In the future, we may extend this logic to recognize Metadata implementations such as OMEMetadata as intermediary exchange structures, and explicitly look for Translators to and from such intermediaries.
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 is under active development. New versions are released when a significant number of bugs get fixed, or when significant new features have been added. Take a look at the What's New sidebar on the VisBio home page to see the release history. To be notified of 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.