Trouble with converter.testConvert() from bio-formats-tools

Dear @OMETeam,

I’m have some issues with creating pyramidal ome.tif while using converter.testConvert() (from the ome / bio-formats-tools/ 6.2.1-SNAPSHOT )

Everything works fine when using a lif file as the input but it creates a weird result when the input file is an ids/ics (from Huygens). Neverthelss, bio-formats importer within FIJI has no trouble opening the ids/ics file.

Please find here a link to download :

  • the ome.tif from the lif (no problem)

  • the ome.tif from the ids/ics (BIG problem)

  • the ids/ics from HRM.

Thank you in advance for your help,

Best regards,


1 Like

FYI : a screenshot of the original ics/ids file:

After conversion with bftools, and resaved into ome.tiff:

Looks like the tiles are in reverse order in y.


I made an “interesting” discovery!

As I can open the ids/ics from Huygens (let’s call it H_ics) in FIJI ,I tried to re-save it as an ids/ics using the plugin Bio-formats Exporter (let’s call it BF_ics).

Using this re-saved BF_ics, I have no more issue when converting it with converter.testConvert()!

Thus I modified the header of the H_ics so it match the BF_ics. The conversion “works” but the file is flipped

The H_ics contains an extra line :

layout	coordinates	cartesian

and the parameters are different x y z t c in one case and x y z ch p for the other (see details about the headers below).

I tried changing these lines without much more success so far…

I hope this would help you find out what is going on,



BF_ics header

ics_version 1.0

filename M:\1-Silvia_Workflow\2-ics_from_HRM\ics_mod_BF.ids

layout parameters 6

layout order bits x y z t ch

layout sizes 32 20404 11596 1 1 4

layout significant_bits 32

representation format real

representation sign signed

representation compression uncompressed

representation byte_order 1 2 3 4

parameter scale 1.000000 0.201 0.201 0.109 0.0 1.0

parameter units bits micrometers micrometers micrometers seconds


H_ics header

cs_version 1.0

filename F8-rat21-merge_5d5678f3ae6da_hrm

layout parameters 6

layout order bits x y z ch p

layout sizes 32 20404 11596 1 4 1

layout coordinates cartesian

layout significant_bits 32

representation format real

representation sign signed

representation compression uncompressed

representation byte_order 1 2 3 4

parameter origin 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000

parameter scale 1.000000 0.201000 0.201000 0.109000 1.000000 1.000000

parameter units bits micrometers micrometers micrometers undefined detector

parameter labels intensity x y z ch p

1 Like

So the culprit is the line:
history software SVI-Huygens
in the ics file.

If this line is present, bftools is exporting badly the image (tiles are flipped).

If we manually remove the line, then the bftools export output is ok.

Hi Nico and Romain, thanks for your help in trying to debug this issue. As you suspect the problem looks to be with the line:

Which is leading to the Y being inverted every time openbytes is called. This leads to the rather odd tiled effect you are seeing. I am looking to see if the reader can be smarter in how it handles the coordinates in this case but may take some time to test and verify. Are you using the ImageConverter directly or is it a modified version? If its modified you may find it quicker to special case the ordering of the tile rows for SVI-Huygens files but long term a fix in the reader itself would be much preferred.

Ive opened a Trello card to track the issue:

1 Like

We are using the ImageConverter directly. Right now we’ve put a fix that detects this line beforehand and we modify it temporarily. That does the job for now.

Thanks for having looked through this,


Hi David

So this is working but the image is flipped in y, obviously. Is there the possibility to flip the image in y in the bfconvert settings ? It looks like no (, but i’d rather have a confirmation before going further.



Im afraid theres no options in bfconvert to flip or invert the pixels.

I have opened a PR which will hopefully fix the ICSReader to prevent this in future:


Perfect. We’ve taken your modified Reader and it works nicely. We’ll wait for the next release to remove this temporary patch.

Thanks again

So we’ve updated our pom files with this dependency:


However we still get flipped tiles when converting from ICS/IDS Huygens to ome.tiff (the link above in the first post is still functional, so the data are accessible):

Could it be that the patch didn’t make it to the bio-formats-tools repository ?

@NicoKiaru is ome:formats-bsd:6.3.0 which includes the ICS reader pulled as a transitive dependency of ome:bio-formats-tools:6.3.0 in your POM or is it declared separately?

1 Like

Ahah! Wonderful indeed I need to declare explicitely in the pom file:


I don’t really understand why the parent pom-scijava do not bring the correct dependency on its own, but it’s not a big deal.

As your project inherits the parent pom-scijava, if the version is not manually specified, the one declared in the parent POM will be used . The Bio-Formats versions are regurlarly bumped as part of the Bio-Formats release process (see however it might require a new release of pom-scijava in order for consumers to consume the latest version without overriding it.