Stitching based on metadata

I’m trying to run this program called BaSiC (an imagej plugin) that attempts to correct the discontinuity in between tiles and generates a more seamless image. However, I’ve run into a problem with the stitching portion using the Grid/collection stitching plugin on the corrected image sequences. Let me try to walk you down the pathway of this entire algorithm.

First, I’m taking the raw .czi files directly from Zen and importing them through BioFormats as a concatenated and single channel image sequence. Then, I’m saving this as an image sequence and running the BaSiC plugin. It generates an image stack of the corrected tiles which is then saved as another image sequence.

Now, the whole problem comes when I want to stitch these tiles together. In the Grid/collection stitching plugin, there are several options on the arrangement of the tiles and how to stitch them (ie grid: row by row, etc). Since my images aren’t perfect squares or rectangles, I need to select the option “positions from a files.” In doing so, I’m hoping that it can take the positions from the metadata and stitch the tiles properly. However, the format for the metadata from Zen is not the same format for the positions to be used in the stitching. Could you help me translate the metadata into a usable format for the Grid/collection stitching plugin?

Stay safe and thanks for your help!

Adding imageJ/fiji tags to put this into those forums.

As a side note, I’m having trouble visualizing what you are talking about. It might help to show a zoomed out picture of what you are trying to accomplish. I normally use Zen itself to do any stitching, so I’m not sure if you have different Scenes in the original file (and performed split scenes write files) or what.

If you took the images separately on the same slide, I’m not sure Zeiss keeps that information in the metadata as the stage position might change independently of the slide position. @sebi might know more.


Thanks for your response! Let me try to rephrase what I’m trying to do. I have tiled images from Zen as an image sequence. Previously, I would use Zen to stitch but it creates discontinuous image that makes downstream analysis harder. So, I’m using a program called BaSiC as an image correction software. Now, I want to stitch the image sequence but I’m not able to. Do you know of a good way to stitch the tiles properly?

I have explored this one plugin in FIJI called Grid/collection stitching where it can use positions from the metadata to stitch. I’m not exactly sure how to share my czi file. Do you know how to do so? If you have an email or drive, I can share it with you. As for the required format, it can be found in the Grid/collection stitching plugin. Let me know if you have any further questions. Sorry if I’m not the best at explaining this.

I usually see large files being shared through Google Drive, Firefox Send or… I forget the other one. How does the whole file look when loaded into QuPath?

Here is the file:

1 Like

Hmm, so it looks pretty much the same in Zen and QuPath to me. Though a bit overexposed in some channels.

It looks like the whole image is together. I’m not sure why it needs to be stitched? There doesn’t seem to be a lot of overlap in most places to do any correction.
If anything, it looks like the images are being taken at a slight tilt, so the focus changes across tile transitions, but I don’t know about the XY coordinates. What percent overlap were you using when you took the image? Though I guess you wanted to reduce the appearance of tiling, not so much the borders of the tiling…

Anyway, now that it is hosted, hopefully someone will be able to reproduce your workflow. I don’t have any great ideas.

I do want to point out that there are other stitching options out there, like BigStitcher, which might do more like what you are looking for… but unless there is some actual tile overlap, I’m not sure that will work either.

The main problem I have had with the Zen TIFF exports is the lack of pixel size metadata being set. So if that isn’t included, I’m guessing the chances of where the tile belongs are… slim.

1 Like

Hmm, actually, wasn’t there a way to use a text file for the normal stitcher in ImageJ? If you can look at your files and figure out which ones are at the end and beginning of lines… you might be able to write a text file out for it. Though that would NOT scale well. But if you just wanted one or two representative images, it might work.

1 Like

Hi @Sakib_Hossain

If I understood your problem properly, then you

If this is indeed the issue, then you could try the following workflow:

  • use the grid /collection stitcher on the original raw *.czi file by metadata (Positions from file > Defined by Metadata).
  • in the next menu, set the “fusion Method” to “Do not fuse images (only write tile configuration)”
  • the tool should then only write a “TileConfiguration.txt”
  • next you proceed with BaSiC
  • you then need to organise the shading corrected images in a way the TileConfiguration.txt expects them to be
  • then start again the grid/collection stitcher with “positions from file > Defined by TileConfiguration”

If this does not work for you, then you can alternatively also try the following:

  • set BaSiC to only save the flatfield and darkfield correction as images, without actually applying them
  • then use BigStitcher for the stitching of the raw .czi
  • BigStitcher supports stitching the *.czi by metadata while additionally applying a flatfield correction

Hope this helps!


Hey @CellKai,

Thanks for the workflow! I tried the first workflow that you presented and I was prompted with this error message:

Stitching internal version: 1.2
ERROR: Inconsistent series layout. Metadata says 4 tiles, but contains only 183 images/tiles.
ERROR: Error during tile discovery, or invalid grid type. Aborting.

From what I see, it seems to be mixing up the channels and tiles. Do you know why this might be happening and how to possibly fix this issue?

For the second workflow (BigStitcher), I’m unfamiliar with the plugin and trouble navigating it. Does it work with wide field images? Would I be able to use different flat/dark field corrections for each channel? Also, I shared the image above. Thanks!

1 Like

Hi again, as @Research_Associate pointed out:

the image that you have uploaded is already stitched and also fused, meaning the individual tiles are gone. As the image correction with BaSiC and also re-stitching with any tool is done on a tile-basis, it is not possible to reproduce your workflow.

When acquiring the raw data in Zen, have a look in your Zen options for stitching. What you would ideally do is set the overlap to 10%, acquire the tiles in a meandering fashion, and have the zen software already do the stitching for you (without fusion).
I am not sure where exactly in your version of Zen you can find these options, but they should be there, probably in the “tiling” or “multiposition” menu.

With this acquisition settings the image should already look much less like a “mosaic” and you might not have to do any further processing.

Hope this helps!


Hey @CellKai @Research_Associate

Thanks for your continued help! Truly appreciate it! Sorry, I should have been a little bit more clear. Czi files are weird and if you open the link onto imagej, then it appears to a fused image. However, if you follow this pathway on FIJI (Bioformats --> Bio-Formats Plugins Configuration --> Formats --> Zeiss CZI --> unselect auto-stitch), then you will be able to open the individual tiles. It also helps to select “open all series” and “concatenate series when compatible” to easily view it as an image sequence. Also, if you click display metadata and OME-XML metadata, then you can get the respective locations of the tiles. However, for whatever reason, I was prompted with the same error that I posted in my previous post. Any thoughts why the grid collection stitching plugin isn’t able to read the metadata correctly. Let me know if this makes sense and if you have any troubles getting the tiles. Thanks again!!

1 Like

Sounds like it is reading the channel count as the tile count. Have you checked the Image->Properties of your series to see how it is currently set up?

1 Like

Do you know of a way to change this? There isn’t quite an option on the grid collection stitcher to change this. So, I’m guessing that the metadata must be altered in some type of way. But, how would I achieve this? Also, let me know if you were able to recreate my workflow. If not, I’m more than happy to do a more specific step by step protocol. Thanks!

If you can’t adjust it where I described, I’m not sure. I haven’t tried myself, working on image alignment at the moment :frowning:

1 Like

Well, let me know what you come up with on the image alignment when you’re done. Thanks again; I really do appreciate you help!! Just as a side note, I’m an undergrad volunteer so I’m also a beginner on all this stuff. Sorry!

If the stack is in FIJI, can you share what it shows in terms of Properties?

Hey again,

Here is a screenshot of the properties you requested:

It looks like the number of tiles and channels is correct but the stitching plugin is mixing the two up. Any thoughts on how to correct this issue. Thanks again!

1 Like

Hi again,

I’ve retrieved the metadata XML files for the .czi image.

SH5_7316x7395or7405-4_(1)_info.xml (187.2 KB)

This should have the coordinates of each individual tile in pixels. I’m just having trouble trying to convert this information into the appropriate format for the stitching function (Grid/Collection stitching --> positions from file --> defined by tile configuration).



This is the code that I’m running to understand the root of the problem:

run("Bio-Formats Macro Extensions");

//extract list 
InputPath = getDirectory("Choose an Input Directory for Raw Files");
FileList = getFileList(InputPath);

for (j = 0; j < FileList.length; j++) {
id = InputPath+FileList[j];
print("id: "+id);

print("seriesCount: "+seriesCount);

print("imageCount (Planes):" +imageCount);

for (i = 0; i < seriesCount; i++) {
	print("#: "+i);
Ext.getPlanePositionX(positionX, i);
Ext.getPlanePositionY(positionY, i);
print("Tile#"+i+"	X = "+positionX);
print("Tile#"+i+"	Y = "+positionY);


I get this log message:
seriesCount: 183 (The series count makes sense as there are 183 tiles)
imageCount (Planes): 4 (This number doesn’t make sense as we expect it to be 183x4 as we have four channels)

Any ideas why we are getting the incorrect imageCount (Planes) number? It looks like we need Ext.getSeriesPositionX(positionX, i). Thanks!

That display does look right, so I’m guessing it is something to do with the plugin reading the metadata as you guessed. Your best bet may be to contact the authors if you want to go that way.

As fro the text file, there may be other examples around the forums, not sure. It looks like they are providing XY coordinates (and Z which they always leave as zero) for each tile, though I don’t know if that is center, top left, or if that even matters.

1 Like