When a tile is discarded during stitching, this tile will only be ignored in the current stitching run, but it's image name and the coordinates (0.0, 0.0, 0.0) are recorded in the TileConfiguration.registered.txt file that is written on disk.

This behavior breaks workflows where the tile configuration is calculated from one set of images and subsequently applied to other sets (e.g. channels) without re-computing the overlap.
(Filtering the (0.0, 0.0, 0.0) positions would not work, since there always is one image that truly belong to this origin position.)

The discarded tile information should either not be written to the configuration file at all, or be marked as ignored. (See also the related issue #10)

I am using the plugin in ImageJ

I have implemented a reader for my specific file format : using HandleExtraFileTypes to enable native recognition of the image in ImageJ. I can drag and drop iage for opening.

The file format is recognized by ImageJ but cannot be open by the stitching plugin.

Just tried grid stitch using column by column > down & right using these settings;

My images are name according to this grid so 1-1, 1-2, 1-2, 1-4 etc etc. When i use this for filename, Thea_1355File name..._{x}-{y}_8-8.png

I receive this error;
ERROR: Cannot find file: '/Users/romboutversluijs/Desktop/region/Thea_1355File name..._{x}-{y}_8-8.png' - abort stitching.
ERROR: Error during tile discovery, or invalid grid type. Aborting.

Hiow can we use custom named files correctly?

When stitching I often get weird results due to missing signal in overlap between images:

Seems like the setting absolute displacement threshold is not adhered.

What I expect: Should remove links between images if the absolute displacement is higher than this value, ref http://fiji.sc/Image_Stitching

It would be very helpful to me to have Eclipse style templates uploaded to the repo, as I would like any code I contribute to adhere to your desired style standards so as not to be disruptive.

See ImageJ2 for an example.

I wanted to try optimizing the plugin for my task (stitching of hundreds RGB images, currently I get out of memory). As I am new to Maven, I started from building already working project from source.

I downloaded 3.18 snapshot (recent version in Fiji distribution), imported the project to Eclipse, clicked "Run as -> Maven build -> Run". In /target directory I found 3 jars: Stitching_-3.1.8.jar, Stitching_-3.1.8-sources.jar, and Stitching_-3.1.8-tests.jar and copied Stitching_-3.1.8 to /plugins folder of a clean ImageJ distribution. The plugin appeared in plugins menus like in Fiji, but when I click "Grid/collection stitching" I get popup window saying Plugin or class not found "Stitching_Grid". Java.lang.ClassNotFoundException: Stitching_Grid. However, if I run the plugin from Eclipse (src/test/java/Main.java, Run as -> Java Application) the plugin works OK.

What am I doing wrong? Did I miss some build options?

Best,
Serge

I have 4 ome tiff files, and each single tif file contains a Z-stack Tile of 2 channels(Red channel and green channel.), and I want to stitch them using "unknown position".

In this case, was the first channel selected to do the stitching, and the second channel follows the same transformation, or the two channels are bind together forming a 2xZ(height) Z-stack and use this kind of four doubleZ-stack for stitching?
Thanks.

Below is the log:

Stitching internal version: 1.1
D:\QMDownload\7\7\1composite.tif
D:\QMDownload\7\7\2composite.tif
D:\QMDownload\7\7\3composi.tif
D:\QMDownload\7\7\4compo.tif
Found 4 files (we ignore hidden and .txt files).
Loading: D:\QMDownload\7\7\1composite.tif ...
115x161x160px, channels=2, timepoints=1 (7450 ms)
Loading: D:\QMDownload\7\7\2composite.tif ...
115x161x160px, channels=2, timepoints=1 (7388 ms)
Loading: D:\QMDownload\7\7\3composi.tif ...
115x161x160px, channels=2, timepoints=1 (8317 ms)
Loading: D:\QMDownload\7\7\4compo.tif ...
115x161x160px, channels=2, timepoints=1 (6878 ms)
1composite.tif[1] <- 2composite.tif[1]: (0.0, 0.0, 0.0) correlation (R)=0.99658525 (91328 ms)
1composite.tif[1] <- 3composi.tif[1]: (0.0, 0.0, 0.0) correlation (R)=0.99000984 (84785 ms)
1composite.tif[1] <- 4compo.tif[1]: (0.0, 0.0, 0.0) correlation (R)=0.9924897 (82371 ms)
2composite.tif[1] <- 3composi.tif[1]: (0.0, 0.0, 0.0) correlation (R)=0.99284816 (82912 ms)
2composite.tif[1] <- 4compo.tif[1]: (0.0, 0.0, 0.0) correlation (R)=0.9883379 (80999 ms)
3composi.tif[1] <- 4compo.tif[1]: (0.0, 0.0, 0.0) correlation (R)=0.9964178 (85912 ms)
Finished registration process (508534 ms).
1composite.tif: 1,3 0.0
2composite.tif: 1,3 0.0
3composi.tif: 1,3 0.0
4compo.tif: 1,3 0.0
Fuse & Write to disk (into directory 'D:\QMDownload\7\7') ...
Finished fusion (4425 ms)
Finished ... (566826 ms)

Hi,

I'm trying to stitch the images from umanager featuring xxx_yyy assignment in the filename, and the grid starts not in the left top corner, but in the top right instead. Inverting x-axis in the dialog does not work. The result is the same wrong in both cases.

Thanks!

Hi,

Th plugin does not seem to working using this type of stitching.
It load all the files well, or at least no error pops up, but the output image is the first image replicated and stitched together, example below.

Output image:
https://imgur.com/a/CSQ03

Log-file:
Stitching internal version: 1.2 Loading (0, 0): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_000_000.ome.tif ... 512x512x11px, channels=4, timepoints=1 (4036 ms) Loading (1, 0): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_001_000.ome.tif ... 512x512x11px, channels=4, timepoints=1 (2194 ms) Loading (2, 0): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_002_000.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1795 ms) Loading (3, 0): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_003_000.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1542 ms) Loading (4, 0): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_004_000.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1533 ms) Loading (0, 1): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_000_001.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1621 ms) Loading (1, 1): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_001_001.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1576 ms) Loading (2, 1): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_002_001.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1576 ms) Loading (3, 1): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_003_001.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1512 ms) Loading (4, 1): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_004_001.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1487 ms) Loading (0, 2): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_000_002.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1478 ms) Loading (1, 2): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_001_002.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1556 ms) Loading (2, 2): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_002_002.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1467 ms) Loading (3, 2): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_003_002.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1511 ms) Loading (4, 2): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_004_002.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1458 ms) Loading (0, 3): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_000_003.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1517 ms) Loading (1, 3): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_001_003.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1470 ms) Loading (2, 3): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_002_003.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1616 ms) Loading (3, 3): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_003_003.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1637 ms) Loading (4, 3): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_004_003.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1486 ms) Loading (0, 4): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_000_004.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1541 ms) Loading (1, 4): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_001_004.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1555 ms) Loading (2, 4): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_002_004.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1581 ms) Loading (3, 4): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_003_004.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1503 ms) Loading (4, 4): F:\Data\Microscopy\conv_grid_2\conv_grid_2_MMStack_1-Pos_004_004.ome.tif ... 512x512x11px, channels=4, timepoints=1 (1513 ms) conv_grid_2_MMStack_1-Pos_000_000.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](0.0,0.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_001_000.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](460.0,0.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_002_000.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](920.0,0.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_003_000.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1380.0,0.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_004_000.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1840.0,0.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_000_001.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](0.0,460.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_001_001.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](460.0,460.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_002_001.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](920.0,460.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_003_001.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1380.0,460.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_004_001.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1840.0,460.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_000_002.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](0.0,920.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_001_002.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](460.0,920.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_002_002.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](920.0,920.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_003_002.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1380.0,920.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_004_002.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1840.0,920.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_000_003.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](0.0,1380.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_001_003.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](460.0,1380.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_002_003.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](920.0,1380.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_003_003.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1380.0,1380.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_004_003.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1840.0,1380.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_000_004.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](0.0,1840.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_001_004.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](460.0,1840.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_002_004.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](920.0,1840.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_003_004.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1380.0,1840.0,0.0) 1.7976931348623157E308 conv_grid_2_MMStack_1-Pos_004_004.ome.tif - conv_grid_2_MMStack_1-Pos_000_000: [1,3](1840.0,1840.0,0.0) 1.7976931348623157E308 Fuse & Display ... Finished fusion (60613 ms) Finished ... (102455 ms)

Cheers,
Nuno Martins

When selecting a file to stitch, it would be great if we could - within the GUI - run stitching on a highly downsampled version of the dataset.

This would allow us to know ahead of time if there are any critical errors/exceptions, or if the stitching requires any special flags to be set (like inverting the axes).

Should this just be a big button that, when clicked, runs the full stitching process with downsampling specified?

It would be nice if we could cancel stitching in progress easily (e.g. through escape integration, or a dedicated button).

This could be useful if we know we've already fused the planes/tiles we're interested in, for example.

It would be nice if the Stitching plugin could take advantage of enhancements in the IJ2 framework.
Specifically:
imagej/ImageJ#25
and
imagej/ImageJ#24

These features will allow Stitching to provide more robust memory and time estimates while it's operating.

It can still operate on IJ1 data structures and such.

@bredfeldt wrote:

In Grid/Collection stitching, there is an option for increasing the overlap that is by default set to 10%. This has caused some confusion. When we are stitching using meta data, we don't need to add or increase the overlap at all, so this value should be set to 0%, right? If 0% is the right value, then maybe when it has been selected that we are stitching from meta data, the default value should be 0%, rather than 10%.

Migrated-From: http://dev.loci.wisc.edu/trac/software/ticket/771

Hello,
I realized that for stitched images saved to disk the calibration is lost. The calibration is present in the original images.

Greetings

Antonio

The current limit on the length of directory and file names is 50. My experience is that these limits are easily exceeded, resulting in erroneous results without any warning.

I'm working on moving some batch operations using this plugin to a compute cluster for a colleague. I've been trying multiple machine types (ranging from 1 to 32 cores) but I don't see that it's substantially using more than one core (no more than 20% of the cores beyond the first). I'm running "Grid/Collection stitching" with about 20 images in the grid, and have computation_parameters=[Save computation time (but use more RAM)]. Is this expected behavior?
Thanks!

When displaying a fused result, let's pop up a blank image immediately and then fill it in with fused images as they are ready. This could be very valuable when combined with #7, and in general could help with troubleshooting and understanding the stitching process.

There are two very useful options in the Pairwise Stitcher that are absent from the Grid/Collection Stitcher:

1. "Ignore zero values when fusing", and 2) "Check Peaks" slidebar.

I care more about the first one, because for Selective Plane Illumination Microscopy (SPIM) the data is has a parallelepiped shape. So we are unable to use the Grid/Collection Stitcher, because it doesn't have the option to ignore zeros. Thanks.

SCIFIO uses the SciJava plugin framework; that enables developers to support new file formats without having to change the source code of SCIFIO at all. That is a much more sustainable way to support file formats because it is decentralized.

Consequently, Stitching should use SCIFIO.

Granted, there are still problems with SCIFIO that would affect Stitching, e.g. long time spent during the file identification period, slow opening of TIFF files which could be opened quicker using ImageJ 1.x' shortcuts. Profiling this, and improving the performance, is my next task, so here is a grand opportunity for Stitching to influence the direction SCIFIO is going.

I have recently been trying to debug a macro, when I came across an odd behavior where if there is a capitalized letter anywhere in the file name, then it will not be selected for stitching. I couldn't find any reference to this on the wiki page, so I would think this is a bug.

Please allow to stop the program after the TileConfiguration.registered.txt is created. The next step that does the actual stitching requires a lot of RAM, and crashes. However, once we have the registered tile coordinates, we can stitch them ourselves using distributed super-computing code. Therefore, we do not need the actual stitched image to be produced by your software. Thanks!

When compute overlap is checked, it seems that it is possible to just discard tiles if they are below some threshold for goodness of fit.

In the cases where we have solid stage positions from metadata, at least, it seems like there is no reason to just throw these tiles away. At the least, maybe there should be an option so the user can decide if they want poorly fitting tiles discarded or retained (because certainly there must always be a "best" fit position, even if it is below a threshold).

I came here by a link from ImageJ. Im wondering how and where i need to install this to use it.

Does this go in the main script folder or some other location?

I am a python native programmer and don't know much java. But as far as I can read from the code, the GUI is embedded in the main code. Is there something I missed? Is there a way to run this as a batch on a series of folders? I would want the same settings for all folders, so basically the only thing that would change would be the directory setting.
I am not that familiar with macros, could it be done that way?

hello, we are trying to stitch two 3d tiff stacks (“tiles”): https://www.dropbox.com/sh/p26swfkmtkw772m/AACgTqMCWAC5gUDF8PPwhMKpa?dl=0

(the tile 140 should be above tile 1)

but no matter what inputs we try, we keep getting an out of bounds error when using a position file the grid stitcher.

we tried two tiles, four, and 140 tiles. we tried relaxed and stringent displacement thresholds, we tried different signs of the tile offsets in the position file.

nothing helps. also the PC has 64GB of ram, and when we look at the task manager, its not a resources issue.

finally, the pairwise stitcher is able to stitch these two stacks perfectly (see pairwise_fused.tiff). so it appears that there is some error in the grid stitcher. please help. thanks!

Hi guys,

I recently tested, that some cool features of BioFormats regarding reading CZI images lead to issues when using the GridStitching plugin. This unfortunately breaks existing workflows for our users.

The initial discussion can be found here:

ome/bioformats#2898 (comment)

In Summary this is caused by the fact the the number of detected image series within a CZI depends from the way Biofomats reads it: Either with or without pyramid levels.

Sebastien Besson already outline the possible solution for this: see bioformats issue above

It would be really cool if that could be adapted soon.

Sebi

The title says most of it.

We have a ZVI file containing multiple tiles acquired with Zeiss AxioVision. If we ask for the stitching plugin not to use "Compute Overlap", the result is affected by the % overlap provided with the slider tool.

This is odd, seeing as the system is supposed to use the metadata provided by the file ("Positions from file", "Defined by image Metadata").

I have seen issue #2 and it seems like it does not set the overlap to 0% but here the overlap should have absolutely no consequence. The positions from the metadata are absolute, are they not?

If you need the files for tests, please let me know.

Best

Oli

(Streamlining from the forum thread) - I just figured it would be better to move it here.

I’m using Grid/Collection as part of a Jython script to stitch whole wells of multichannel images, some of which are easy to stitch (DAPI) and some of which don’t stitch well on their own (eg, small foci images). I had therefore taken the strategy of aligning the DAPI images via “normal” Grid stitching, then using the TileConfiguration.registered.txt file, changing the names in it (editing _DAPI.tif to _FITC.tif or _Cy3.tif in each line of the file names), and applying that alignment to all of the other channels using the “Positions from file” option. I know that theoretically Grid/Collection can be used on multichannel data, but in my experience that had issues and this worked much more smoothly.

This was all well and good, but on a recent batch of images I realized that while all my non-DAPI channels were always aligned perfectly, the DAPI channel itself (which I’d used to create the .registered file) was not always actually aligning to the other channels correctly, typically in the top-left corner of the image. Sometimes it looked perfect, sometimes whole tiles were gone (which @imagejan pointed out was probably due to #35) , at the most concerning times they were off by 15-20 pixels.

Screenshots below - green is the nuclei as output by the first run of Grid/Collection stitching, red is the stitch I got by stitching from the TileConfiguration, teal is phalloidin). I'm most concerned about the cases with offset- I can make my DAPI channel match by going back and re-stitching it according to the .registered file at the end, so I have a workaround, but if something is off I figured you'd want to know.

LMK if I can provide any additional info!

Mr. Ctruden,
Hello! I am a computer programmer from China named Mr. Han. I am very interested in the code which is under the path of https: ∕∕ github.com∕ fiji∕ Stitching and hope to run the function of Stitching in this page mentioned. However, now I encounter unexpected troubles. That is, my download code in this page (clicking on the Download ZIP button), which hints a lack of package such as “ij”, “mpicbg”, “fiji”, “net” when I compile the task.
Therefore, please allow me to ask you where I can download the package and hope to get the specific page. In addition, I would like to consult you whether it can run the function of Stitching independently or not if just download the content of https: ∕∕ github.com∕ fiji∕ Stitching in this page. Also, if I expect to run the function of Stitching and debug the code of Stitching, I want to know what I need to do.
At last, I extend my faithful gratefulness to you and look forwared to your reply.
Sincerely yours,
Mr. Han
Emal:[email protected]

Hey,
I'm using the plugin to stitch with the "Sequential Images" function to stitch sequences of metallographic micrographs at high magnifications. I'm making those by using the manual x-y function of the sample stage. I am using FIJI on Windows 10 20H2 64-bit with an AMD Ryzen 3600 and 32GB of RAM, if this makes a difference.

I encounter the issue, that the stitching breaks as soon as the numbering on the image has 3 digits, where the plugin starts to sort the images >100 in between the rest of the files, e.g. 10, 100, 101, 102, 103,..., 11, 110, 111, 112,..., 20, 200, 201,... (See TileConfiguration.txt ). If I delete every image above filename99.tif the whole image is stitching perfectly. Without deleting the images with the numbering >99 the parts of the image are stitched perfectly with breaks caused by the jumps in-between the sequences. Modifying the Frame Range to 20 did not improve the reliability consistent enough to use it as a work around. Using the "unknown sequence" is not viable at this point as the time needed gets horrendous even on my reasonably fast PC.

It does not matter how the filename is formatted, or if I remove the filename entirely. I tried to add a leading zero, multiple leading zeros, adding a leading 99 to all files above 100 to make them last in the sorting, renaming the files into their alphabetical equivalent (aa.tif, ab.tif, ac.tif,...), removing the filename and all of these things get ignored by Fiji/the plugin. Especially the alphabetic renaming of the files mangles the sequence completely/does not even start. I checked that Fiji is not sorting the files by creation time or other attributes and these do not influence the sorting.

In the other modes of the plugin there is a mask to input the filename-formatting , which if this would be implemented in the "Sequential images"-function may fix the problem, since I have the feeling that the sorting algorithm is looking only at 2 digits, while ignoring leading zeros, instead of the whole number. I would be really happy if this could be fixed.

Greetings,
Stefan B.

PS.: I tried a cursory look at BigStitcher, but I can not find the setting that supports a simple sequence of RGB-.tif-images like the old plugin does or a tutorial on how to use BigStitcher in such a way.

Can the stitching parameters be printed in a Results table, instead of the imageJ Log? The imageJ log will occasionally close by some process in imageJ when the stitching plugin is being run from a macro, meaning that the macro will crash. If it's not possible to have the values printed from the current version, would it be possible to include the printing location as an option? Cheers!

So I know that this is a problem with Leica and Bioformats more than the stitcher, but I would ask nonetheless.

Is there a way to modify the coordinates that are read from a file's metadata before running the stitching, like multiplying each one by a certain number.

If I recall correctly the issue is that the position is given in the wrong unit and we need to correct by a factor of 10e6 or something like that... I can provide a LIF file if needed.

Kind regards

Oli

Hello,

I wanted to try this plugin to build a tile from separated images.
The issue: I have 205 images and when the confirmation window pops up with the list of the images, the list is too long so I cannot scroll down to validate my choice.
Hence I am stuck.

Please, is it possible to add a scrollbar for this window ?

Thanks !

To facilitate fusing planes that will not fit in memory, it would be ideal if we had the ability to crop regions of interest before overlap is computed.

This could also greatly speed up these operations when we only really want to view a subset of our dataset.

It is important to have this option in addition to the existing downsampling feature, as we need to be able to operate on the true data and not downsampled/modified data.

NB: it is not completely clear how we should achieve this cropping yet.
A conceivable workflow for working with datasets that won't fit in memory would be:

1. Stitch once with downsampling + Add tiles as ROIs.
2. Identify regions of interest (note that this may be post-overlap movement, so the actual stage coordinates should be used. This would require those coordinates to be reported - e.g. in the ROI title)
3. Stitch again with cropping on the desired stage X,Y stage coordinates (e.g. upper left, lower right corners)

Then, before overlap is computed, any tiles that don't fall within the specified X,Y bounding box would be discarded.

However, there is a caveat in that we also want this option to be able to accommodate data that isn't acquired in perfect rectangular planes. But perhaps a bounding box + checking for overlap is sufficient.

Hi

I have files that have a particular name r02c02f01p01-ch1sk1fk1fl1.tiff
Which I feed into the stitcher with r02c02f{ii}p01-ch1sk1fk1fl1.tiff
because I have 9 fields and they are a 3x3 stitch.

However when it tries to load the first tile, I get this error

OperettaReader initializing X:\Joao\PE\assay1__2017-07-27T14_54_29-Measurement 1\Images\r02c02f01p01-ch1sk1fk1fl1.tiff
java.io.FileNotFoundException: X:\Joao\PE\assay1__2017-07-27T14_54_29-Measurement 1\Images\r07c02f02p01-ch1sk1fk1fl1.tiff (The system cannot find the file specified)

Why is it trying to load r07c02f02p01-ch1sk1fk1fl1.tiff when I never specified this as being a variable?

These images are on a share that is mounted on a windows machine...

If I copy the files locally, it works...

this is very odd and cannot make heads or tails of it. Any help is greatly appreciated.

Oli

From an ImageJ mailing list thread:

Doing some stitching of a "large" dataset I encountered a « bug ».

Stitching parameters

• Issue : Weird pixel attribution
• DATASET :
  • Channel : 1
  • Each Z-stack: 2048x2048x92 (around 750Mb / stack)
  • Total Positions : 112 (16x7)
  • Eachtiled-slice is around 700Mb,(total around 85 Go)
• Downscaled dataset
  • Channel : 1
  • Each Z stack: 512x512x23 (around 11Mb / stack)
  • Total Positions : 112 (16x7)
  • Each tiled-slice is around 30Mb, (total around 1.25 Go)
• Computer :
  • CPU IntelXeonx64, 16 Cores, 2.6Ghz,RAM 128Gb
  • GPU : Quadro6000

If the stitching of the original dataset is done with computing the overlap. We observed a weird pixel attribution. a bug ?

If the stitching of the original dataset is done without computing the overlap. We don’t observed anymore the bug.

Using a downscaled version of the data set, we don’t observed a bug if the stitching is done with or without computing overlap

The documentation online details that ignoring z is possible by running the following line in script editor:

mpicbg.stitching.GlobalOptimization.ignoreZ = true;

However, I have found that even when I do this (after setting language to Beanshell, etc, following the instructions), the stitched image still shifts along the z-axis, causing mis-alignment.

I've already contacted Dr. Preibisch who may have already fixed this but asked me to open an issue.

@ehrenfeu wrote:

The stitching UI behaves very weird after being started by a macro command once.

Steps to reproduce (tested on Linux and Win7 x64):

• download a fresh copy of Fiji
• start
• run the stitcher via Plugins > Stitching > Grid/Collection stitching
• "normal" dialog comes up (notice the graphic representation of the selected settings)
• hit "Cancel"
• File > New > Script
• Language > ImageJ Macro
• enter run("Grid/Collection stitching");
• hit "Run"
• dialog doesn't show the graphical representation, AND allows for invalid combinations of options (e.g. "Positions from file" and "Right & Down")

I could live with the temporary workaround of not calling the stitcher from a macro for a while, however after starting it using the above described command once, the behavior stays like this. I.e. you can't run it correctly from the Plugins menu anymore either.

Cheers
~Niko

@StephanPreibisch wrote:

In order to allow the macro recording to work, it shows a simpler version when called from a macro, this is on purpose, otherwise it would not work. Usually, it is supposed to be called with a lot of parameters so that it runs automatically.

However, when running the plugin afterwards from the menu, it still thinks that it is in plugin mode. The bug seems to be on the ImageJ/Fiji side, as the call

IJ.isMacro()

still returns true although it is called through the menu. Does anybody have an idea how this can happen?

@rasband wrote:

Stephan,

You could try using IJ.macroRunning() instead of IJ.isMacro(). Here is the source for these two methods:

/** Returns true if the run(), open() or newImage() method is executing. */
public static boolean macroRunning() {
  return macroRunning;
}

/** Returns true if a macro is running, or if the run(),
    open() or newImage() method is executing. */
public static boolean isMacro() {
  return macroRunning || Interpreter.getInstance()!=null;
}

Migrated-From: http://fiji.sc/bugzilla/show_bug.cgi?id=685

I have tiled square images (2048*2048 * 4 channels, 16 bit) to be stitched.

Fiji > Stitching > Positions from file worked really well with the following TileConfiguration.txt file.

# Define the number of dimensions we are working on
dim = 2

# Define the image coordinates
000000_000001.jp2; ; (0, 0)
000000_000002.jp2; ; (1648, 0)
000000_000003.jp2; ; (3296, 0)
000000_000004.jp2; ; (4944, 0)
000000_000005.jp2; ; (4944, 1648)
000000_000006.jp2; ; (3296, 1648)
000000_000007.jp2; ; (1648, 1648)
000000_000008.jp2; ; (0, 1648)
000000_000009.jp2; ; (0, 3296)
000000_000010.jp2; ; (1648, 3296)
000000_000011.jp2; ; (3296, 3296)
000000_000012.jp2; ; (4944, 3296)
000000_000013.jp2; ; (4944, 4944)
000000_000014.jp2; ; (3296, 4944)
000000_000015.jp2; ; (1648, 4944)
000000_000016.jp2; ; (0, 4944)

However, these images are having problems (chromatic aberrations), and to correct the problems, a few pixels at the periphery were removed using MATLAB. Now they are 2035*2036 in dimension.

Because they have 4 channels in 16 bit depth, the only format I could use in MATLAB was *.ome.tiff with bfsave().

Although now they are slightly smaller, the relative distance in pixels between images remains unchanged. So I should be able to use the same coordinate as above. The TileConfiguration.txt I prepared is like this:

# Define the number of dimensions we are working on
dim = 2

# Define the image coordinates
000000_000001.ome.tiff; ; (0, 0)
000000_000002.ome.tiff; ; (1648, 0)
000000_000003.ome.tiff; ; (3296, 0)
000000_000004.ome.tiff; ; (4944, 0)
000000_000005.ome.tiff; ; (4944, 1648)
000000_000006.ome.tiff; ; (3296, 1648)
000000_000007.ome.tiff; ; (1648, 1648)
000000_000008.ome.tiff; ; (0, 1648)
000000_000009.ome.tiff; ; (0, 3296)
000000_000010.ome.tiff; ; (1648, 3296)
000000_000011.ome.tiff; ; (3296, 3296)
000000_000012.ome.tiff; ; (4944, 3296)
000000_000013.ome.tiff; ; (4944, 4944)
000000_000014.ome.tiff; ; (3296, 4944)
000000_000015.ome.tiff; ; (1648, 4944)
000000_000016.ome.tiff; ; (0, 4944)

Although running Fiji > Stitching > Positions from file of these corrected images succeeded in loading 16 images, then it resulted in the following JAVA error, related to an illegal array index.

(Fiji Is Just) ImageJ 2.0.0-rc-65/1.51u; Java 1.8.0_66 [64-bit]; Windows 7 6.1; 666MB of 24439MB (2%)
 
java.lang.ArrayIndexOutOfBoundsException: 2
	at mpicbg.stitching.CollectionStitchingImgLib.findOverlappingTiles(CollectionStitchingImgLib.java:223)
	at mpicbg.stitching.CollectionStitchingImgLib.stitchCollection(CollectionStitchingImgLib.java:49)
	at plugin.Stitching_Grid.run(Stitching_Grid.java:539)
	at ij.IJ.runUserPlugIn(IJ.java:221)
	at ij.IJ.runPlugIn(IJ.java:185)
	at ij.Executer.runCommand(Executer.java:137)
	at ij.Executer.run(Executer.java:66)
	at java.lang.Thread.run(Thread.java:745)

Without being able to debug runtime, it is very difficult to work out what's causing this error.

Fiji > Stitching > Unknown Position took forever, so I had to stop it in the middle, but at least didn't throw the same error as above.

Other test results.

Taken together, maybe I can say the following things.

• The XY size of image does not matter.
• It appears to be a multi-channels .ome.tiff specific issue

I'm prepared to send my test images and other data for you to investigate.

When I select "downsample tiles", the stitching does something strange. It puts all of my grid of tiles in one row. When I do not down-sample, with all else the same, it works as expected. Do I misunderstand what the downsample option does? I was trying to use it to same space on a really large stitched image.

I attached a screenshot of the stitching parameters.

Hello,

We tried to stitch two tiff tiles (tile_00002.tif and tile_00003.tif) here:
https://www.dropbox.com/sh/bid6iuykzvmy197/AAA8o5QsIeZ2f0pds4QFcCWla?dl=0
using the grid stitcher using the settings in gridstitch_settings.jpg and position guesses in TileConfiguration.txt

The grid stitcher failed to stitch them (see Log.txt and TileConfiguration.registered_GRID_STITCHER.txt )
However, when I use the pairwise stitcher (see pairwise_settings.jpg and pairwise_settings2.jpg), it is able to stitch them without any initial guesses (see Log.txt and pairwise_result.tif) !

Hi,

I am running the Grid/Collection stitching plugin on a dataset with 3 channels.
When running the plugin with "write to disk" I get stripe artifacts.

However when I run it with "Fuse and display" these stripes are not visible.

This is the macro I am running:

run("Grid/Collection stitching", "type=[Positions from file] " +
        "order=[Defined by image metadata] " +
        "multi_series_file=" + dir + IJ.pad(filedir, 4) + File.separator + IJ.pad(filedir, 4) + "-"  + file + ".czi " +
        "fusion_method=[Linear Blending] regression_threshold=0.35 max/avg_displacement_threshold=2.50 " +
        "absolute_displacement_threshold=3.50 compute_overlap increase_overlap=0 " +
        "subpixel_accuracy computation_parameters=[Save computation time (but use more RAM)] " +
        //"image_output=[Fuse and display]");
        "image_output=[Write to disk] output_directory=[" + fileoutput + "]");

Fiji and ImageJ are up to date.
I run it on ubuntu 16.04.

Cheers,
Christopher

As agreed between @tpietzsch, @StephanPreibisch, @ctrueden, @hinerm and myself at the ImgLib2 hackathon in May 2013, ImgLib1 is deprecated. Therefore it makes the opposite of sense to release it now. Corollary: Stitching must rid itself from the dependency to be able to be built reproducibly.

This is required before Stitching can re-enter pom-fiji.

I have a Prairie dataset I use for testing stitching. It has 2 channels and 5 z stacks. For a given Z, channel 2 should look a bit darker than channel 1. This was the case a few months ago when last tested. However, now it seems that channel 2 is identical to channel 1.

I didn't bisect to find the point of breakage yet, but will try to do so later and post that information here.

How would this handle non-overlapping tiles? My guess is since it is designed to take mechanical panorama input, it always assumes overlap.

This is the problem I'm trying to solve: http://www.foreverscape.com/art/2014/12/03/non-overlapping-image-stitching/

Is it possible to define the default background intensity for empty regions so that transmitted light images do not contain black regions?
Where in the code would be a good place to set the default value of the image?
Peter

Hi,
I've tried many variations and followed all instructions. However all I ever get is this error (below at end).
My images are taken in very standard way just moving X (column) from left to right, and then Y (next row).
Filenames are typical: testneur3d10x_L01_R01_C01.jpg, testneur3d10x_L01_R01_C02.jpg, etc.

I have tried the instructed file name notations variations:
testarr_L01_R{yy}_C{xx}.jpg
testarr_L01_R{jj}_C{ii}.jpg
testarr_L{zz}_R{yy}_C{xx}.jpg

my filenames are as specifically all like this: "testarr_L01_R01_C01.jpg"
where L is the z level, R is the row (y move) and C is the column (x move).

I have tried using {ii}, and {jj} etc; but that does not work either. Throws basically similar error.
I have the initial index set to 1.

Any help is much appreciated.

Cannot find file:
error:
Loading (0, 0): C:\AbemScan_v08\bin\x64\Debug\scan3D10xneuron02\testneur3d10x_L01_R{yy}_C{xx}.jpg ...
ERROR: Cannot find file: 'C:\AbemScan_v08\bin\x64\Debug\scan3D10xneuron02\testneur3d10x_L01_R{yy}_C{xx}.jpg' - abort stitching.
ERROR: Error during tile discovery, or invalid grid type. Aborting.

In the interest of reproducible builds, pom-fiji is slated to reference only release versions in the very, very near future. That means that we need at least one release version of Stitching.

Would you mind if I just used my script to bump it to version 2.0.0, like almost every other Fiji project?

Hello,

I am in desparate need to be able to select multiple ROIs in an image to assign them to separate groups. I cam across your ROI Picker tool, but so far failed installing this in a current version of ImageJ. Is there a possibility to provide a pre-compiled jar file, or could you point me at a solution? Thank you so much in advance!

Best, Mathias