I am trying to download bioformats command line tools to use BfConvert. On this website http://www.openmicroscopy.org/site/support/bio-formats5.5/users/comlinetools/, it says to download bftools.zip that includes unix scripts and windows batch files. I am using a MAC, do I need download any other softwares or files to process the package? I have been unable to run the tools successfully in the command line. What am I missing? I have been changing the directory to the bftools directory.
the command-line bundle should be standalone and working on either OSX, Linux or Windows. For instance, the following sequence of calls should print your the version of the utility:
$ wget https://downloads.openmicroscopy.org/bio-formats/5.5.2/artifacts/bftools.zip $ unzip bftools.zip $ ./bftools/bfconvert -version
Can you let us know if that works? If it does not, can you paste the error message?
Apparently I don’t have the wget tool, but I believe there are similar download tools out there.
Here is the error I am getting:
lr6-dhcp-196-214:bftools labadmin$ $ wget https://downloads.openmicroscopy.org/bio-formats/5.5.2/artifacts/bftools.zip -bash: $: command not found lr6-dhcp-196-214:bftools labadmin$ $ unzip bftools.zip -bash: $: command not found lr6-dhcp-196-214:bftools labadmin$ $ ./bftools/bfconvert -version -bash: $: command not found lr6-dhcp-196-214:bftools labadmin$
I have manually downloaded bftools.zip and have tried to run bfconvert from the command line, but I am getting an error that the bfconvert command is also not found.
You are right,
wget is not installed by default and an alternate possibility would be
curl with something along the lines of:
$ curl -o bftools.zip https://downloads.openmicroscopy.org/bio-formats/5.5.2/artifacts/bftools.zip
We might need more information for debugging your problem including for instance the version of the operating system and the installed version of Java:
$ java -version
NB: this issue is probably deviating from the broader context of this forum which is ImageJ. Hopefully we will get it resolved soon, otherwise we might redirect your question to the OME community resources as it is specific to the Bio-Formats command-line tools.
Yeah I was able to get $ curl -o bftools.zip https://downloads.openmicroscopy.org/bio-formats/5.5.2/artifacts/bftools.zip and unzip it; however I could already do that manually and through github. I had some warnings come up when running bfconvert, is it installed properly?
lr6-dhcp-196-214:bftools labadmin$ curl -o bftools.zip https://downloads.openmicroscopy.org/bio-formats/5.5.2/artifacts/bftools.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 28.5M 100 28.5M 0 0 2279k 0 0:00:12 0:00:12 --:--:-- 2487k lr6-dhcp-196-214:bftools labadmin$ unzip bftools.zip Archive: bftools.zip creating: bftools/ inflating: bftools/bf.bat inflating: bftools/bfconvert.bat inflating: bftools/config.bat inflating: bftools/config.sh inflating: bftools/domainlist.bat inflating: bftools/formatlist.bat inflating: bftools/ijview.bat inflating: bftools/logback.xml inflating: bftools/mkfake.bat inflating: bftools/showinf.bat inflating: bftools/tiffcomment.bat inflating: bftools/xmlindent.bat inflating: bftools/xmlvalid.bat inflating: bftools/bf.sh inflating: bftools/bfconvert inflating: bftools/domainlist inflating: bftools/formatlist inflating: bftools/ijview inflating: bftools/mkfake inflating: bftools/showinf inflating: bftools/tiffcomment inflating: bftools/xmlindent inflating: bftools/xmlvalid inflating: bftools/NEWS.rst inflating: bftools/bioformats_package.jar lr6-dhcp-196-214:bftools labadmin$ ./bftools/bfconvert -version 14:59:46,340 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy] 14:59:46,340 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml] 14:59:46,341 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/Users/labadmin/Downloads/bftools/bftools/logback.xml] 14:59:46,341 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath. 14:59:46,342 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/Users/labadmin/Downloads/bftools/logback.xml] 14:59:46,342 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/Users/labadmin/Downloads/bftools/bftools/logback.xml] 14:59:46,452 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 14:59:46,461 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 14:59:46,466 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [stdout] 14:59:46,492 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property 14:59:46,521 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to INFO 14:59:46,521 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [stdout] to Logger[ROOT] 14:59:46,521 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration. 14:59:46,522 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@36f6e879 - Registering current configuration as safe fallback point Version: 5.5.2 Build date: 15 June 2017 VCS revision: 4c2f2b00a12aa8a3894c54459a4cf02d5b02e161 lr6-dhcp-196-214:bftools labadmin$ bfconvert -bash: bfconvert: command not found lr6-dhcp-196-214:bftools labadmin$ bftools -bash: bftools: command not found lr6-dhcp-196-214:bftools labadmin$ bfconvert.bat -bash: bfconvert.bat: command not found lr6-dhcp-196-214:bftools labadmin$
is the main reason for this issue i.e. you have multiple logging configuration files. Either you will want to remove the
logback.xml file from the external directory from where you are invoking
rm logback.xml && ./bftools/bfconvert -version or you can move into the command-line tools directory i.e.
cd bftools && ./bfconvert -version.
Otherwise, it seems like the command-line tools are working as expected.
Thanks for the help, the command-line tools are working as expected. I have another question regarding output file processing. Using the bfconvert tool, I am able to get tiff outputs for each image stack and channel using this format:
In the name of each image stack is relevant information:
Fish 7 WT 2xZoom_left: 512 x 512; 60 planes (2C x 30Z)
Could I modify the the output name to include relevant information from the stack title? Particularly fish number, WT label, magnification, orientation and zoom are the most important parameters.
output_series_%s_... will populate the output filename with the index of the series. Can you try
output_%n_... to use the series name instead?
For each imageJ stack file, is there a way to automate saving the metadata text file? Or can I save the voxel information in the tiff filename?
@azmanr if you are converting your files to raw TIFF, Bio-Formats will store the voxel sizes parsed from the original file using the appropriate location in the TIFF specification (see the XResolution and YResolution tags).
If you want to preserve the metadata while converting your file into a TIFF-based format, I would suggest to use Bio-Formats and export as OME-TIFF. The metadata from the original LIF file will be stored either directly using the OME Model elements and/or as additional annotations. The metadata of the resulting file should be readable by any OME-aware tool like ImageJ.
Please don’t worry about it. The goal is to help users, not be draconian about what should or should not be discussed.
I’m also trying to use bfconvert in a mac and when I run ‘./bftools/bfconvert -version’ I get the error:
Exception in thread “main” java.lang.UnsupportedClassVersionError: loci/formats/tools/ImageConverter : Unsupported major.minor version 51.0
Do you know why I get this error and how to solve it?
this exception is related to the version of Java used when running the
bfconvert utility. Java 7 or later is required since Bio-Formats 5.2.0. Could you try to download and install a recent version of Java (see e.g. the Oracle downloads), check the version of
and try to run
I want to chime in about another nice way to run the Bio-Formats command line tools on POSIX-friendly systems such as macOS or Linux (or even Windows via Cygwin or msys2), without needing to download and unpack the
bftools.zip archive: the jrun utility.
If you create the following
[shortcuts] bfconvert = ome:bio-formats-tools:loci.formats.tools.ImageConverter formatlist = ome:bio-formats-tools:loci.formats.tools.PrintFormatTable showinf = ome:bio-formats-tools:loci.formats.tools.ImageInfo tiffcomment = ome:bio-formats-tools:loci.formats.tools.TiffComment xmlindent = ome:bio-formats-tools:loci.formats.tools.XMLIndent xmlvalid = ome:bio-formats-tools:loci.formats.tools.XMLValidate [repositories] imagej.public = https://maven.imagej.net/content/groups/public
then you can type e.g.
jrun showinf myfile.tif to launch the
showinf command line tool via jrun.
Note that the jrun utility requires you to have a JRE installed, as well as
mvn, and a couple of other standard CLI tools such as
unzip. But if you already have a developer environment, you almost certainly have all of those things already. And if not, they are available from the package manager (even on Windows—use Chocolatey).
I have been using the bfconvert command-line tool to convert from .lif to .tiff. The .tiff files look fine when I open it up on Preview or other softwares; however, it looks distorted on Fiji. A line goes across the stack and goes down as I go through the z-stack Here is what it looks like:
Did you check whether the actual pixel values are corrupted, or whether it’s just a painting issue? You can use the “pixel probe” feature: mouse over the affected pixels, and check the readout in the ImageJ main window’s status bar area.
Using the pixel probe feature, the intensities of the pixels on the line are much larger. I think the actual pixel value is corrupted in Fiji, but I am only seeing the line in Fiji. When I open up the tiff file in Preview or AMIRA, there is no corruption.
I had recently switched from ome.tiff to tiff. For the same data point, I was getting more data with .tiff than .ome.tiff. But, I am not sure why that is the case when all other parameters are the same.
Thanks for the info.
Do you see a difference depending on the setting of “Use SCIFIO when opening files (BETA!)” in the Edit Options ImageJ2… dialog?
Yes, the issue does appear to be resolved. Should I continue to use this mode? When will ImageJ2 move from the beta stages into a software update?
Could you please clarify? Do you see the erroneous red lines with that option enabled, or with it disabled? The answer will tell us where the bug needs to be fixed.
It depends on your needs. Right now, using SCIFIO is better in some ways, and worse in others—hence the toggle. There are certain classes of TIFF file which ImageJ 1.x cannot normally read, but SCIFIO can, so enabling SCIFIO helps with that. And there are some image formats which have SCIFIO format plugins, which can thus be read when that option is enabled, but cannot read with it disabled. However, ImageJ 1.x is optimized for time performance reading TIFF files, so for the TIFF files it can read, it will typically do so faster than SCIFIO does. We plan to improve this situation in the future, but no one is actively working on it at the moment.
Are you asking when the SCIFIO option will stop being labeled “BETA”? That will probably happen when SCIFIO’s time performance is comparable to, or better than, ImageJ 1.x’s.
Or are you asking when ImageJ2 as a whole will stop being versioned like
2.0.0-rc-XYZ and finally go to
2.0.0? That will happen when the
imagej-common data model has been redesigned; the issues labeled
data-model are the ones which describe related work there. I do not have a timeline on this work, except to say that it is currently number 5 on my list of primary projects.