TrakEM2: Stitching overlapping images from coordinates

[André Pereira]

Hi everybody,

We are trying to stitch a very large dataset (~90GB) of overlapping images. We used the Grid/collection stitching plugin, which was able to stitch the images correctly in smaller datasets, but we ran into memory problems with the larger ones. We then switched to TrakEM2 which is doing a great job at handling the large ones.

We are, however, facing a problem with the positioning of the tiles. After importing the images using a text file with the coordinates, the tiles are not positioned in the exact position. There is a small, but important shift. We verified our coordinates in the text file and they are correct. Our reconstructions with the Grid/collection stitching plugin, for instance, are accurate.

Has anyone had this problem before?

Thanks for your help!

Kind regards,
Andre Pereira

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Peter Haub]

Hi Andre
and everybody who may concerned,

we are also facing a memory problem stitching 4000 images using the
Grid/Collection stitching plugin.
Our 8bit image has a size of more then 12 GByte (or > 12 GPixel).

I wonder if this could have something to do with the integer type
definition of the 'index' variable in the ByteArray.setValue function:
     public void setValue( final int index, final byte value )


The error message is:

(Fiji Is Just) ImageJ 2.0.0-rc-23/1.49m; Java 1.6.0_24 [64-bit]; Windows
7 6.1; 16857MB of 20000MB (84%)

java.lang.ArrayIndexOutOfBoundsException: -1741201634

     at
net.imglib2.img.basictypeaccess.array.ByteArray.setValue(ByteArray.java:68)

     at
net.imglib2.type.numeric.integer.GenericByteType.setValue(GenericByteType.java:101)

     at
net.imglib2.type.numeric.integer.UnsignedByteType.set(UnsignedByteType.java:161)

     at
net.imglib2.type.numeric.integer.UnsignedByteType.setInteger(UnsignedByteType.java:179)

     at
net.imglib2.type.numeric.integer.AbstractIntegerType.setReal(AbstractIntegerType.java:67)

     at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:1017)

     at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:972)

     at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:977)

     at mpicbg.stitching.fusion.Fusion.writeBlock(Fusion.java:916)

     at mpicbg.stitching.fusion.Fusion.fuse(Fusion.java:224)

     at plugin.Stitching_Grid.run(Stitching_Grid.java:590)


Regards,
Peter



On 09.03.2015 04:26, Andre Pereira wrote:

> Hi everybody,
>
> We are trying to stitch a very large dataset (~90GB) of overlapping images. We used the Grid/collection stitching plugin, which was able to stitch the images correctly in smaller datasets, but we ran into memory problems with the larger ones. We then switched to TrakEM2 which is doing a great job at handling the large ones.
>
> We are, however, facing a problem with the positioning of the tiles. After importing the images using a text file with the coordinates, the tiles are not positioned in the exact position. There is a small, but important shift. We verified our coordinates in the text file and they are correct. Our reconstructions with the Grid/collection stitching plugin, for instance, are accurate.
>
> Has anyone had this problem before?
>
> Thanks for your help!
>
> Kind regards,
> Andre Pereira
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Saalfeld, Stephan]

Hi Peter,

yes.  This is an intrinsic limitation of ImageJ's and AWT's internal
data structure which stores 2d image planes in integer indexed arrays.
I.e. 2d images cannot be larger than 2GPixel (e.g. 45k x 45k).  TrakEM2
and ImgLib2 enable to generate and visualize larger images but you
cannot generate a single image export for use in ImageJ or AWT (see
above).  Instead, you can export tiles and use a tile based viewer or
other external tools to combine them into a single image.

Best,
Stephan



On Mon, 2015-03-09 at 13:24 +0100, Peter Haub wrote:

> Hi Andre
> and everybody who may concerned,
>
> we are also facing a memory problem stitching 4000 images using the
> Grid/Collection stitching plugin.
> Our 8bit image has a size of more then 12 GByte (or > 12 GPixel).
>
> I wonder if this could have something to do with the integer type
> definition of the 'index' variable in the ByteArray.setValue function:
>      public void setValue( final int index, final byte value )
>
>
> The error message is:
>
> (Fiji Is Just) ImageJ 2.0.0-rc-23/1.49m; Java 1.6.0_24 [64-bit]; Windows
> 7 6.1; 16857MB of 20000MB (84%)
>
> java.lang.ArrayIndexOutOfBoundsException: -1741201634
>
>      at
> net.imglib2.img.basictypeaccess.array.ByteArray.setValue(ByteArray.java:68)
>
>      at
> net.imglib2.type.numeric.integer.GenericByteType.setValue(GenericByteType.java:101)
>
>      at
> net.imglib2.type.numeric.integer.UnsignedByteType.set(UnsignedByteType.java:161)
>
>      at
> net.imglib2.type.numeric.integer.UnsignedByteType.setInteger(UnsignedByteType.java:179)
>
>      at
> net.imglib2.type.numeric.integer.AbstractIntegerType.setReal(AbstractIntegerType.java:67)
>
>      at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:1017)
>
>      at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:972)
>
>      at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:977)
>
>      at mpicbg.stitching.fusion.Fusion.writeBlock(Fusion.java:916)
>
>      at mpicbg.stitching.fusion.Fusion.fuse(Fusion.java:224)
>
>      at plugin.Stitching_Grid.run(Stitching_Grid.java:590)
>
>
> Regards,
> Peter
>
>
>
> On 09.03.2015 04:26, Andre Pereira wrote:
> > Hi everybody,
> >
> > We are trying to stitch a very large dataset (~90GB) of overlapping images. We used the Grid/collection stitching plugin, which was able to stitch the images correctly in smaller datasets, but we ran into memory problems with the larger ones. We then switched to TrakEM2 which is doing a great job at handling the large ones.
> >
> > We are, however, facing a problem with the positioning of the tiles. After importing the images using a text file with the coordinates, the tiles are not positioned in the exact position. There is a small, but important shift. We verified our coordinates in the text file and they are correct. Our reconstructions with the Grid/collection stitching plugin, for instance, are accurate.
> >
> > Has anyone had this problem before?
> >
> > Thanks for your help!
> >
> > Kind regards,
> > Andre Pereira
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Peter,

> we are also facing a memory problem stitching 4000 images using the
> Grid/Collection stitching plugin. Our 8bit image has a size of more
> then 12 GByte (or > 12 GPixel).

ImageJ1 has a hard limit of 2 GPix per image plane. Since you are stitching
so many planes into a single fused image, you may be exceeding that limit.

It is a goal of ImageJ2 to overcome this limit, but there is still a long
road ahead.

In the meantime, you can stitch huge mosaics a piece at a time, or try
TrakEM2 -- though personally I am not able to help with TrakEM2 issues.

Regards,
Curtis


On Mon, Mar 9, 2015 at 7:24 AM, Peter Haub <[hidden email]> wrote:

> Hi Andre
> and everybody who may concerned,
>
> we are also facing a memory problem stitching 4000 images using the
> Grid/Collection stitching plugin.
> Our 8bit image has a size of more then 12 GByte (or > 12 GPixel).
>
> I wonder if this could have something to do with the integer type
> definition of the 'index' variable in the ByteArray.setValue function:
>     public void setValue( final int index, final byte value )
>
>
> The error message is:
>
> (Fiji Is Just) ImageJ 2.0.0-rc-23/1.49m; Java 1.6.0_24 [64-bit]; Windows 7
> 6.1; 16857MB of 20000MB (84%)
>
> java.lang.ArrayIndexOutOfBoundsException: -1741201634
>
>     at net.imglib2.img.basictypeaccess.array.ByteArray.setValue(ByteArray.
> java:68)
>
>     at net.imglib2.type.numeric.integer.GenericByteType.
> setValue(GenericByteType.java:101)
>
>     at net.imglib2.type.numeric.integer.UnsignedByteType.set(
> UnsignedByteType.java:161)
>
>     at net.imglib2.type.numeric.integer.UnsignedByteType.
> setInteger(UnsignedByteType.java:179)
>
>     at net.imglib2.type.numeric.integer.AbstractIntegerType.
> setReal(AbstractIntegerType.java:67)
>
>     at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:1017)
>
>     at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:972)
>
>     at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:977)
>
>     at mpicbg.stitching.fusion.Fusion.writeBlock(Fusion.java:916)
>
>     at mpicbg.stitching.fusion.Fusion.fuse(Fusion.java:224)
>
>     at plugin.Stitching_Grid.run(Stitching_Grid.java:590)
>
>
> Regards,
> Peter
>
>
>
>
> On 09.03.2015 04:26, Andre Pereira wrote:
>
>> Hi everybody,
>>
>> We are trying to stitch a very large dataset (~90GB) of overlapping
>> images. We used the Grid/collection stitching plugin, which was able to
>> stitch the images correctly in smaller datasets, but we ran into memory
>> problems with the larger ones. We then switched to TrakEM2 which is doing a
>> great job at handling the large ones.
>>
>> We are, however, facing a problem with the positioning of the tiles.
>> After importing the images using a text file with the coordinates, the
>> tiles are not positioned in the exact position. There is a small, but
>> important shift. We verified our coordinates in the text file and they are
>> correct. Our reconstructions with the Grid/collection stitching plugin, for
>> instance, are accurate.
>>
>> Has anyone had this problem before?
>>
>> Thanks for your help!
>>
>> Kind regards,
>> Andre Pereira
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Albert Cardona-2]

Andre,

Is there a calibration issue? Please could you post a few lines of the TXT
file for loading tiles, the expected positions, and the actual positions.
To obtain the actual positions, select them all and run this jython script:

from ini.trakem2.display import Display
for patch in Display.getSelected():
  print patch.getAffineTransform()

Best,

Albert

2015-03-08 23:26 GMT-04:00 Andre Pereira <[hidden email]>:

> Hi everybody,
>
> We are trying to stitch a very large dataset (~90GB) of overlapping
> images. We used the Grid/collection stitching plugin, which was able to
> stitch the images correctly in smaller datasets, but we ran into memory
> problems with the larger ones. We then switched to TrakEM2 which is doing a
> great job at handling the large ones.
>
> We are, however, facing a problem with the positioning of the tiles. After
> importing the images using a text file with the coordinates, the tiles are
> not positioned in the exact position. There is a small, but important
> shift. We verified our coordinates in the text file and they are correct.
> Our reconstructions with the Grid/collection stitching plugin, for
> instance, are accurate.
>
> Has anyone had this problem before?
>
> Thanks for your help!
>
> Kind regards,
> Andre Pereira
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
http://albert.rierol.net
http://www.janelia.org/lab/cardona-lab
http://www.ini.uzh.ch/~acardona/

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Peter Haub]

Hi Stephan,

thanks for your prompt reply.
Until now I was not aware of this principle limitation of Java:
"Arrays must be indexed by int values.." (see
http://en.wikipedia.org/wiki/Criticism_of_Java ).

Regards,
Peter

On 09.03.2015 14:32, Stephan Saalfeld wrote:

> Hi Peter,
>
> yes.  This is an intrinsic limitation of ImageJ's and AWT's internal
> data structure which stores 2d image planes in integer indexed arrays.
> I.e. 2d images cannot be larger than 2GPixel (e.g. 45k x 45k).  TrakEM2
> and ImgLib2 enable to generate and visualize larger images but you
> cannot generate a single image export for use in ImageJ or AWT (see
> above).  Instead, you can export tiles and use a tile based viewer or
> other external tools to combine them into a single image.
>
> Best,
> Stephan
>
>
>
> On Mon, 2015-03-09 at 13:24 +0100, Peter Haub wrote:
>> Hi Andre
>> and everybody who may concerned,
>>
>> we are also facing a memory problem stitching 4000 images using the
>> Grid/Collection stitching plugin.
>> Our 8bit image has a size of more then 12 GByte (or > 12 GPixel).
>>
>> I wonder if this could have something to do with the integer type
>> definition of the 'index' variable in the ByteArray.setValue function:
>>       public void setValue( final int index, final byte value )
>>
>>
>> The error message is:
>>
>> (Fiji Is Just) ImageJ 2.0.0-rc-23/1.49m; Java 1.6.0_24 [64-bit]; Windows
>> 7 6.1; 16857MB of 20000MB (84%)
>>
>> java.lang.ArrayIndexOutOfBoundsException: -1741201634
>>
>>       at
>> net.imglib2.img.basictypeaccess.array.ByteArray.setValue(ByteArray.java:68)
>>
>>       at
>> net.imglib2.type.numeric.integer.GenericByteType.setValue(GenericByteType.java:101)
>>
>>       at
>> net.imglib2.type.numeric.integer.UnsignedByteType.set(UnsignedByteType.java:161)
>>
>>       at
>> net.imglib2.type.numeric.integer.UnsignedByteType.setInteger(UnsignedByteType.java:179)
>>
>>       at
>> net.imglib2.type.numeric.integer.AbstractIntegerType.setReal(AbstractIntegerType.java:67)
>>
>>       at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:1017)
>>
>>       at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:972)
>>
>>       at mpicbg.stitching.fusion.Fusion.writeTile(Fusion.java:977)
>>
>>       at mpicbg.stitching.fusion.Fusion.writeBlock(Fusion.java:916)
>>
>>       at mpicbg.stitching.fusion.Fusion.fuse(Fusion.java:224)
>>
>>       at plugin.Stitching_Grid.run(Stitching_Grid.java:590)
>>
>>
>> Regards,
>> Peter
>>
>>
>>
>> On 09.03.2015 04:26, Andre Pereira wrote:
>>> Hi everybody,
>>>
>>> We are trying to stitch a very large dataset (~90GB) of overlapping images. We used the Grid/collection stitching plugin, which was able to stitch the images correctly in smaller datasets, but we ran into memory problems with the larger ones. We then switched to TrakEM2 which is doing a great job at handling the large ones.
>>>
>>> We are, however, facing a problem with the positioning of the tiles. After importing the images using a text file with the coordinates, the tiles are not positioned in the exact position. There is a small, but important shift. We verified our coordinates in the text file and they are correct. Our reconstructions with the Grid/collection stitching plugin, for instance, are accurate.
>>>
>>> Has anyone had this problem before?
>>>
>>> Thanks for your help!
>>>
>>> Kind regards,
>>> Andre Pereira
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[André Pereira]

Hi Albert,

Thanks for your help.

The first six lines of my file look like this:
/Volumes/MechBioSeagate1/Data/001/001_000001_034_2014-10-17T1703305049560.bmp
14273 19378 0
/Volumes/MechBioSeagate1/Data/001/001_000001_035_2014-10-17T1703305049560.bmp
17425 19374 0
/Volumes/MechBioSeagate1/Data/001/001_000001_037_2014-10-17T1703305049560.bmp
20540 13825 0
/Volumes/MechBioSeagate1/Data/001/001_000001_023_2014-10-17T1703305049560.bmp
17299 2764 0
/Volumes/MechBioSeagate1/Data/001/001_000001_022_2014-10-17T1703305049560.bmp
18902 5525 0
/Volumes/MechBioSeagate1/Data/001/001_000001_020_2014-10-17T1703305049560.bmp
22099 11052 0
(...)

I used your script to obtain the positions and got the following
AffineTransform[[1.0, 0.0, 20540.0], [0.0, 1.0, 13825.0]]
AffineTransform[[1.0, 0.0, 18902.0], [0.0, 1.0, 5525.0]]
AffineTransform[[1.0, 0.0, 14273.0], [0.0, 1.0, 19378.0]]
AffineTransform[[1.0, 0.0, 22099.0], [0.0, 1.0, 11052.0]]
AffineTransform[[1.0, 0.0, 17425.0], [0.0, 1.0, 19374.0]]
AffineTransform[[1.0, 0.0, 17299.0], [0.0, 1.0, 2764.0]]
(...)


The numbers seem to be correct, from comparing some of the lines:

/Volumes/MechBioSeagate1/Data/001/001_000001_034_2014-10-17T1703305049560.bmp
14273 19378 0
AffineTransform[[1.0, 0.0, 14273.0], [0.0, 1.0, 19378.0]]

/Volumes/MechBioSeagate1/Data/001/001_000001_037_2014-10-17T1703305049560.bmp
20540 13825 0
AffineTransform[[1.0, 0.0, 20540.0], [0.0, 1.0, 13825.0]]

/Volumes/MechBioSeagate1/Data/001/001_000001_023_2014-10-17T1703305049560.bmp
17299 2764 0
AffineTransform[[1.0, 0.0, 17299.0], [0.0, 1.0, 2764.0]]


I used Matlab scripts to plot the coordinates from both and they seem to
overlap correctly.

But I still get an incorrect alignment when visualising it in TrakEM2. By
comparing it to the output of the Grid/collection plugin, a very small
change in position and orientation (some tiles seem to rotate a tiny bit)
is visible.


On 10 March 2015 at 06:25, Albert Cardona <[hidden email]> wrote:

> Andre,
>
> Is there a calibration issue? Please could you post a few lines of the TXT
> file for loading tiles, the expected positions, and the actual positions.
> To obtain the actual positions, select them all and run this jython script:
>
> from ini.trakem2.display import Display
> for patch in Display.getSelected():
>   print patch.getAffineTransform()
>
> Best,
>
> Albert
>
> 2015-03-08 23:26 GMT-04:00 Andre Pereira <[hidden email]>:
>
> > Hi everybody,
> >
> > We are trying to stitch a very large dataset (~90GB) of overlapping
> > images. We used the Grid/collection stitching plugin, which was able to
> > stitch the images correctly in smaller datasets, but we ran into memory
> > problems with the larger ones. We then switched to TrakEM2 which is
> doing a
> > great job at handling the large ones.
> >
> > We are, however, facing a problem with the positioning of the tiles.
> After
> > importing the images using a text file with the coordinates, the tiles
> are
> > not positioned in the exact position. There is a small, but important
> > shift. We verified our coordinates in the text file and they are correct.
> > Our reconstructions with the Grid/collection stitching plugin, for
> > instance, are accurate.
> >
> > Has anyone had this problem before?
> >
> > Thanks for your help!
> >
> > Kind regards,
> > Andre Pereira
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
>
>
> --
> http://albert.rierol.net
> http://www.janelia.org/lab/cardona-lab
> http://www.ini.uzh.ch/~acardona/
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Peter Haub]

Hi Stephan,
Hi Curtis,

Thanks for your answers.
I found in fact a solution by stitching the image piecewise and combine
the results with external software.

Regards,
Peter

On 09.03.2015 19:40, Curtis Rueden wrote:
> Hi Peter,
> ...

> In the meantime, you can stitch huge mosaics a piece at a time, or try
> TrakEM2 -- though personally I am not able to help with TrakEM2 issues.
>
> Regards,
> Curtis

On 09.03.2015 14:32, Stephan Saalfeld wrote:
> Hi Peter,
> ...
>    Instead, you can export tiles and use a tile based viewer or
> other external tools to combine them into a single image.
>
> Best,
> Stephan

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Peter,

> I found in fact a solution by stitching the image piecewise and
> combine the results with external software.

Could be worth adding a section to http://imagej.net/Stitching explaining
how you did it, for others in the same situation!

Regards,
Curtis

On Thu, Mar 26, 2015 at 12:44 PM, Peter Haub <[hidden email]> wrote:

> Hi Stephan,
> Hi Curtis,
>
> Thanks for your answers.
> I found in fact a solution by stitching the image piecewise and combine
> the results with external software.
>
> Regards,
> Peter
>
> On 09.03.2015 19:40, Curtis Rueden wrote:
>
>> Hi Peter,
>> ...
>>
>
>  In the meantime, you can stitch huge mosaics a piece at a time, or try
>> TrakEM2 -- though personally I am not able to help with TrakEM2 issues.
>>
>> Regards,
>> Curtis
>>
>
> On 09.03.2015 14:32, Stephan Saalfeld wrote:
>
>> Hi Peter,
>> ...
>>    Instead, you can export tiles and use a tile based viewer or
>> other external tools to combine them into a single image.
>>
>> Best,
>> Stephan
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html