Change dimension order when using bfconvert

I have .tif images saved where the 3rd channel is being read by bfconvert as T(in the XYZCT) and I’d like it to be read as C as the image is a multichannel fluorescence microscope image. Is it possible to specify the dimension order of this tif when converted it to ome.tiff using bfconvert?

Thanks,
Heath

Hi Heath,

Using the bfconvert tool will maintain the original dimension order and im afraid there is no option to modify it at the moment. IF you import the image into FIJI using Bio-Formats you will have the option to ‘Swap dimensions’, this may be able to help you reorder it and export to save as a new file.

Thank you, this is what I ended up doing but I was hoping there was a more streamlined process. Is it possible to take standard .tif file on disk and add the necessary ome metadata to it(dimension order) without a full conversion to ome.tiff? I’ve found these conversions to be sometimes very long. with large planes and especially long with large planes and pyramids.

If you are confident with editing metadata then it would technically be possible to do so, likely by creating a companion XML separately (https://docs.openmicroscopy.org/ome-model/5.6.4/ome-tiff/specification.html#partial-ome-xml-metadata). The OME-XML would then have to contain a Pixels element and TIFF data elements looking something similar to https://docs.openmicroscopy.org/ome-model/5.6.4/ome-tiff/specification.html#fragment-4.

I suspect that the conversion process, while taking a bit of time and being cumbersome is probably the safest approach however.

I found that the conversion speed is related to the endianness of the tif files. The tifs I converted were saved from ImageJ with the big (motorola) format and bfconvert is VERY slow (i.e. pyramidal conversion is 2hrs in big vs several minutes when saved in ‘little’ format). Changing this option in the ImageJ Edit -> Options -> Input/Output window is good. However, the imageJ bio-formats exporter always writes to ‘Big’ endianness. Perhaps this should default to ‘little’ given bfconvert’s speed with conversion of the ‘Big’ byte-order.

@nheathpatterson thanks for following up. Agreed that switching the endianness would explain large conversion times.

The behavior you are seeing surprises me as my expectation is that the ImageJ plugin just like the command-line utility will respect the endianness of the original image. As a minimal example, the following macro exports two test images of opposite endianness:

run("Bio-Formats Importer", "open=/tmp/test&little=false.fake color_mode=Default display_metadata display_ome-xml rois_import=[ROI manager] view=Hyperstack stack_order=XYCZT use_virtual_stack");
run("Bio-Formats Exporter", "save=/tmp/test&little=false.ome.tiff export compression=Uncompressed");
run("Bio-Formats Importer", "open=/tmp/test&little=true.fake color_mode=Default display_metadata display_ome-xml rois_import=[ROI manager] view=Hyperstack stack_order=XYCZT use_virtual_stack");
run("Bio-Formats Exporter", "save=/tmp/test&little=true.ome.tiff export compression=Uncompressed");

and on disk, the endianness is identical to the original:

$ file /tmp/test\&little\=false.ome.tiff 
/tmp/test&little=false.ome.tiff: TIFF image data, big-endian, direntries=16, height=0, bps=8, compression=none, PhotometricIntepretation=BlackIsZero, description=<?xml version="1.0" encoding="UTF-8" standalone="no"?><!-- Warning: this comment is an OME-XML , width=0
$ file /tmp/test\&little\=true.ome.tiff 
/tmp/test&little=true.ome.tiff: TIFF image data, little-endian, direntries=16, height=512, bps=8, compression=none, PhotometricIntepretation=BlackIsZero, description=<?xml version="1.0" encoding="UTF-8" standalone="no"?><!-- Warning: this comment is an OME-XML , width=512

Do you have code and/or samples allowing reproduce the endianness inversion issue you are seeing?