How to correctly set parameters for TIFF stack

[chrisroat]

I have a 2x2 set of IMS files that I turned into a TIFF stack in order to do preprocessing prior to stitching. The original XML file that can be used to do the stitching on IMS files is attached.

The TIFF filenames I generate are as follows:

'CH_0/000000/000000_000000/000000_000000_000000.tif',
'CH_0/000000/000000_005867/000000_005867_000000.tif',
'CH_0/0-5867/0-5867_000000/0-5867_000000_000000.tif',
'CH_0/0-5867/0-5867_005867/0-5867_005867_000000.tif',

I try to run a terastitcher with this command, set using parameters I see in the XML file:

                'terastitcher',
                '--test',
                '--volin_plugin=TiledXY|3Dseries',
                '--volin=/my/path',
                '--imout_depth=16',
                '--ref1=-2',
                '--ref2=1',
                '--ref3=3',
                '--vxl1=-0.3',
                '--vxl2=0.3',
                '--vxl3=2',

However, the mechanical displacement in the H direction gets set to zero, and the test image is roughly the size of a 2x1 tiling.

I'm attaching the generated xml file, which also shows several differences with the original in terms of the voxel_dims sign, the H mechanical_displacements, and the H origin.

Original

  <ref_sys ref1="-2" ref2="1" ref3="3"/>
        <voxel_dims D="1.96" H="0.3" V="-0.3"/>
        <origin D="0.0" H="0.0" V="0.0"/>
        <mechanical_displacements H="586.7" V="-586.7"/>

Generated by the above command:

    <ref_sys ref1="-2" ref2="1" ref3="3" />
    <voxel_dims V="0.3" H="-0.3" D="2" />
    <origin V="0" H="0.6141" D="0" />
    <mechanical_displacements V="586.7" H="0" />

Changing the sign of the --vxlN flags does not seem to affect anything. I tried permuting a few other things, but cannot seem to get things to align properly.

What is the right approach?

[iannellog]

I have a 2x2 set of IMS files that I turned into a TIFF stack in order to do preprocessing prior to stitching. The original XML file that can be used to do the stitching on IMS files [is attached](https://github.com/abria/TeraStitcher/files/5227967/2020-02-03_14.16.23_degas_r1_dapi_stitchtest4x4w5pct_flip.xml.txt

I understand that using this xml file you get to stitch the .ims files. Is it right?

I note that the attribute 'stack_slices' of tag 'dimensions' has value -1 and other attributes of tag Stack are missing, which means that this xml was not generated by TeraStitcher. This is a valid procedure and it should work: when you run TeraStitcher with this xml, it generates new xmls with all attributes and right values (providing that the first time you give the option --imin_plugin=IMS_HDF5)

The TIFF filenames I generate are as follows:

'CH_0/000000/000000_000000/000000_000000_000000.tif',
'CH_0/000000/000000_005867/000000_005867_000000.tif',
'CH_0/0-5867/0-5867_000000/0-5867_000000_000000.tif',
'CH_0/0-5867/0-5867_005867/0-5867_005867_000000.tif',

I try to run a terastitcher with this command, set using parameters I see in the XML file:

                'terastitcher',
                '--test',
                '--volin_plugin=TiledXY|3Dseries',
                '--volin=/my/path',
                '--imout_depth=16',
                '--ref1=-2',
                '--ref2=1',
                '--ref3=3',
                '--vxl1=-0.3',
                '--vxl2=0.3',
                '--vxl3=2',

However, the mechanical displacement in the H direction gets set to zero, and the test image is roughly the size of a 2x1 tiling.

I'm attaching the generated xml file, which also shows several differences with the original in terms of the voxel_dims sign, the H mechanical_displacements, and the H origin.

It not easy to understand what happens, but it is likely it depends on the names of your files and folders (the minus signs may be the problem: I know that TeraStitcher in some cases generates such names, but it is likely not able to manage them properly when given in input, and I never fixed this problem).

Could you not use for TIFF files the same approach you used for .ims files (i.e. the same xml, just changing the file names at attributes 'DIR_NAME')? It should work (again you have only to specify --imin_plugin=tiff3D to overwrite the defaulf 'tiff2D')

[chrisroat]

Thanks for the info. I will avoid negative displacements with Terastitcher inputs. The XML approach is what I am doing.

You are correct that the XML is generated by another source - directly by our microscope. I have always had to flip the axes when feeding it to terastitcher- perhaps that is related to the fact that the microscope often uses negative displacements and negative voxels.

On Sat, Sep 19, 2020 at 02:41 Giulio Iannello notifications@github.com wrote:

I have a 2x2 set of IMS files that I turned into a TIFF stack in order to do preprocessing prior to stitching. The original XML file that can be used to do the stitching on IMS files [is attached]( https://github.com/abria/TeraStitcher/files/5227967/2020-02-03_14.16.23_degas_r1_dapi_stitchtest4x4w5pct_flip.xml.txt

I understand that using this xml file you get to stitch the .ims files. Is it right?

I note that the attribute 'stack_slices' of tag 'dimensions' has value -1 and other attributes of tag Stack are missing, which means that this xml was not generated by TeraStitcher. This is a valid procedure and it should work: when you run TeraStitcher with this xml, it generates new xmls with all attributes and right values (providing that the first time you give the option --imin_plugin=IMS_HDF5)

The TIFF filenames I generate are as follows:

'CH_0/000000/000000_000000/000000_000000_000000.tif',

'CH_0/000000/000000_005867/000000_005867_000000.tif',

'CH_0/0-5867/0-5867_000000/0-5867_000000_000000.tif',

'CH_0/0-5867/0-5867_005867/0-5867_005867_000000.tif',

I try to run a terastitcher with this command, set using parameters I see in the XML file:

            'terastitcher',

            '--test',

            '--volin_plugin=TiledXY|3Dseries',

            '--volin=/my/path',

            '--imout_depth=16',

            '--ref1=-2',

            '--ref2=1',

            '--ref3=3',

            '--vxl1=-0.3',

            '--vxl2=0.3',

            '--vxl3=2',

However, the mechanical displacement in the H direction gets set to zero, and the test image is roughly the size of a 2x1 tiling.

I'm attaching the generated xml file https://github.com/abria/TeraStitcher/files/5228023/xml_import.xml.txt, which also shows several differences with the original in terms of the voxel_dims sign, the H mechanical_displacements, and the H origin.

It not easy to understand what happens, but it is likely it depends on the names of your files and folders (the minus signs may be the problem: I know that TeraStitcher in some cases generates such names, but it is likely not able to manage them properly when given in input, and I never fixed this problem).

Could you not use for TIFF files the same approach you used for .ims files (i.e. the same xml, just changing the file names at attributes 'DIR_NAME')? It should work (again you have only to specify --imin_plugin=tiff3D to overwrite the defaulf 'tiff2D')

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/abria/TeraStitcher/issues/75#issuecomment-695191586, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIBDYLFS6LMWNWPWHQX7ELSGR4DZANCNFSM4RNVVMKA .

[chrisroat]

With a new dataset with 5 channels, I'm seeing the following errors, which seem to be related to "interleaved" channels. I have tried to follow the instructions in the Teratools guide, sections 1.8 and appendix C, for multi-channel images. Is there a reason for limiting the # channels, and can I work around it?

My command:

'mpirun', '-n', '8', '--allow-run-as-root', 'python', '/usr/local/bin/paraconverter2_3_4.py', '--sfmt=TIFF (unstitched, 3D)', '--dfmt=TIFF (tiled, 4D)', '--fixed_tiling', '-s=/workdir/tmpnmb_0kp1/stitched_tiff/xml_import.xml', '-d=/workdir/tmpnmb_0kp1/stitched_tiff', '--height=512', '--width=512', '--depth=-1'

ERROR: image not supported by UnstitchedVolume (DIM_C=5, BYTESxCHAN=2)

and later:

FileNotFoundError: [Errno 2] No such file or directory: '/root/dims.txt'

[And FWIW, even after exiting with these errors, there are still 7-8 processes that seem to keep going....]

[iannellog]

There is no limitation in principle on the number of channels, but there are limitations in the current releases with respect to the image format of the source dataset. If the multi-channel image is stored using TIFF format (all channels in the same TIFF file) and you have more than 3 channels you must use a "planar" format with channels stored as separate components (i.e. non-interleaved). Unfortunately this format is not supported by the tiff plugins available in the current versions of TearStitcher. If you have more than three channels you must use IMS HDF5 format.

I may hypothesize that you are using planar TIFFs. In this case the error is raised because the tiff plugin manages channels as interleaved, and in this case you cannot have more than 3 channels. If you do not want to use IMS, you must store channels in separate monochromatic TIFF files and follow the procedure explained in the second part of section 1.8 (which is not easy, if you are interested I should find somewhere an example dataset and share it with you).

[chrisroat]

I store the channels in separate tiff stacks, and used the procedure in section 1.8. I import each stack in turn, and then I run all the terastitcher steps on one channel. I combine all the XML outputs (the placetiles output for one channel, and the other N-1 import files) into a single file with the MultiVolume plugin. I then process via paraconverter with sfmt of "TIFF (unstitched, 3D)".

The procedure works fine for 3 channels, but I get the error above for 5 channels.

(And yes, I have tried to avoid IMS. It is not very cloud-friendly to use HDF5)

[iannellog]

Ok, it is a bug. I remember that something similar already happened, but I need some days to deep into this.

[chrisroat]

I appreciate this. I suspect somehow my tiff stacks are being declared "interleaved", when they shouldn't be?

I've also noted that my images (when doing just 3 channels) are too short in the vertical direction. I have a 6x6 montage, and it seems like rows 2 and 3 are being left out. The XML looks OK to me. I see this in some of the logs:

|=> "V top offset negative: set to 0"

Attached are the 3 XML files, one from each channel.

CH_2_import.xml.txt CH_1_import.xml.txt CH_0_placetiles.xml.txt

[iannellog]

Chris, could you please send me all the xml files you have used in this experiment (dataset with 5 channels). I think I have found te bug, but I have to replicate the situation as much as possible to avoid introducing new bugs.

[iannellog]

I should have fixed the bug. Please test this executables (I set the buffer used by TeraConverter to the minimum to reduce memory requirements):

https://unicampus365-my.sharepoint.com/:u:/g/personal/g_iannello_unicampus_it/EVFM2wx4rSdJnobOvPAe0usBLX8hQ0utSTbVtDawjKvNVA?e=kkwwzO

Let me know if you can stitch the 5-channels image

[chrisroat]

Thank you Giulio. That is great service!

I have been hung up for 2 days on another item, but will get back to this soon.

Thanks again, Chris

On Fri, Sep 25, 2020 at 3:18 AM Giulio Iannello notifications@github.com wrote:

I should have fixed the bug. Please test this executables (I set the buffer used by TeraConverter to the minimum to reduce memory requirements):

https://unicampus365-my.sharepoint.com/:u:/g/personal/g_iannello_unicampus_it/EVFM2wx4rSdJnobOvPAe0usBLX8hQ0utSTbVtDawjKvNVA?e=kkwwzO

Let me know if you can stitch the 5-channels image

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/abria/TeraStitcher/issues/75#issuecomment-698849382, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIBDYJKS4N4CLRLGDVV3KLSHRU55ANCNFSM4RNVVMKA .

[chrisroat]

Hi Giulio,

I have finally gotten a chance to run the program. I am running it with just 3 channels to test (before going to 5), and I'm seeing the following from many (maybe all?) of the individual jobs:

munmap_chunk(): invalid pointer
Aborted (core dumped)

Is this related?

My command is as follows:

['mpirun', '-n', '16', '--allow-run-as-root', 'python', '/usr/local/bin/paraconverter.py', '--sfmt=TIFF (unstitched, 3D)', '--dfmt=TIFF (tiled, 4D)', '--fixed_tiling', '-s=/workdir/tmp4cb3mrtq/stitched_tiff/xml_import.xml', '-d=/workdir/tmp4cb3mrtq/stitched_tiff', '--height=512', '--width=512', '--depth=512']

The final volume is 10690x10678x301.

[chrisroat]

I'd be happy to take a look, if you can push your branch to github. It seems the code on this repo is older, and I don't see your recent changes.

[iannellog]

I am afraid I cannot help you much about this this looks as a memory allocation problem that can be due to a bug in our code or other issues related to your platform on site debugging would be necessary

Nevertheless I am planning to release the source code of the latest versions of TeraStitcher (i.e. 1.11 with CUDA support) on GitHub I need only a few days because I am very (very :-( ) busy in this period. I will appreciate any help in improving the code.

I hope this can help. Best.

-- Giulio

Il giorno gio 1 ott 2020 alle ore 01:35 Chris Roat notifications@github.com ha scritto:

Hi Giulio,

I have finally gotten a chance to run the program. I am running it with just 3 channels to test (before going to 5), and I'm seeing the following from many (maybe all?) of the individual jobs:

munmap_chunk(): invalid pointer Aborted (core dumped)

Is this related?

My command is as follows:

['mpirun', '-n', '16', '--allow-run-as-root', 'python', '/usr/local/bin/paraconverter.py', '--sfmt=TIFF (unstitched, 3D)', '--dfmt=TIFF (tiled, 4D)', '--fixed_tiling', '-s=/workdir/tmp4cb3mrtq/stitched_tiff/xml_import.xml', '-d=/workdir/tmp4cb3mrtq/stitched_tiff', '--height=512', '--width=512', '--depth=512']

The final volume is 10690x10678x301.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/abria/TeraStitcher/issues/75#issuecomment-701701074, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDW7VTBAXAJGD4GN7HEG3TSIO6CHANCNFSM4RNVVMKA .

--

---

Giulio Iannello Preside della Facolta' Dipartimentale di Ingegneria Universita' Campus Bio-Medico di Roma v. Alvaro del Portillo, 21 00128 Roma, Italy

Tel: +39-06-22541-9602 E-mail: g.iannello@unicampus.it Fax: +39-06-22541-9609 URL: https://scholar.google.it/citations?user=L-UJxIgAAAAJ

---

[chrisroat]

I appreciate your help in this matter.

Yes, I do understand it's a memory issue. It's likely trying to free memory that was not allocated with malloc.

Could the problem have been introduced in this recent version? I had run v1.11.10 with just the first 3 channels of our data and it was successful (but I can double check). Using v1.11.11 has the problem reported above. It would be helpful if the released code was on GitHub and there was a commit/tag for v1.11.11 and v1.11.10, so we could compare them.

(I also must include mergeddisplacements -- can you verify if that code has changed?)

[chrisroat]

@iannellog Is it possible for you to update this repo with the code for the recently released versions of the binaries?

[iannellog]

I finally got to update the source code on GitHub. Sorry for the delay. The release now include CUDA code for the align step. Unfortunately, I could not download on GitHub version 1.11.10, but only the last one (1.11.11). Nevertheless I checked the two versions and the only change relevant to your case is in file UnstitchedVolume.cpp (attached). I do not think this change can raise the error you observed.

UnstitchedVolume (rel-1.11.10).cpp.zip

[chrisroat]

Thanks. It is very helpful to have the code. I will be building them directly from source, so that I know exactly what I am testing. Is the latest commit the same as v1.11.11? Is there a commit in the repo that corresponds to 1.11.10?

[iannellog]

The latest commit is 1.11.11. Unfortunately, when I updated the repo I did not find on my disk a reliable version of 1.11.10 for which reason I did commit it on GitHub. Nevertheless the only file relevant to your problem that changed from 1.11.10 to 1.11.11 is the one I have attached in the previous comment. I am quite sure of that. Today, looking for version 1.11.10, I have found on another machine the source code I used to provide you the binaries of 1.11.10. If you need it I can put it on dropbox and send you a link.

[chrisroat]

Just wanted to leave a note that the newest version (1.11.11) seems to be working for >3 non-interleaved channels. Thank you for your work on this issue.