http://imagej.273.s1.nabble.com/Issues-and-annoyances-with-trakem2-working-on-a-gigapixel-montage-tp5018056p5018060.html
filetypes to use in analysis. Even more I am one of the people, who
methods for image acquisition and analysis. Nowhere I ever mentioned in my
analysis. I had very specific questions regarding a popular tool developed
На 8.02.2017 г. 12:53 сл.об. "Herbie" <
JEPG-compressed images for scientific purposes is an absolute no-no. JEPG
the image content, i.e. it introduces artifacts.
> Dear friends and colleagues,
> First I want to emphasize, how astonishing and useful I find the trakem2
> package/plugin! It is really great and I am really thankful to the
> developers for puting all this effort into creating this suite for working
> with large image datasets.
> I use it mainly for creating/stitching/blending , processing and exporting
> of gigapixel montages of microscopic images into a readable software
> independent image pyramid.
> Recently I stumbled upon several issues (I don't know whether they are bugs
> or just due to limitation in the software) for which I couldn't find any
> mention and/or solution in the documentation and the forum.
>
> First I will describe what I am doing and next I will list the issues that
> bother me.
> I am creating a single layer montage with dimensions 63698 x 57218 px from
> a set of 3111 images (each 1388x1040). The images are acquired via
> axiovision and exported as single tiles (24bit RGB in either jpg or tif
> format). Before importing the images I align them using the MIST plugin and
> use the global positions generated from it to import them into trakem2 via
> text file. The resulting montage is exactly as expected and have no remarks
> about it.
> 1) I don't know if its true but it seems to me that if I use jpg as format
> for the source images they are imported faster into trakem2. However once
> the import is finished the software returns errors about generating mipmaps
> (see attached log file) and it continuously tries to regenerate them (which
> I guess keeps CPU quite busy). This happens regardless mipmaps are enabled
> or disabled in Display>Properties, and is independent from the number of
> threads assigned to mipmap generation. If I close the project and Fiji
> (even after system restart) and then I open them again the issue returns.
> This behaviour is not oberved if my source images are in tif format.
> The other issues are related to the export of a flat image (here the file
> format of the source images does not matter):
>
> 2) When I am trying to export to a tiled format (Export> Make flat
> image...>Save for web (CATMAID)) regardless of the image format I choose
> for the export I cannot change the size of the exported tiles to other than
> 256x256. The dialogue allows me to change it, but when the process finishes
> in the folder there are only 256x256 tile images. While this is not a huge
> problem, still there is difference between managing some 80000 images or
> 40000.
>
> 3) Also when I am trying to export tiled format via Export> Make flat
> image...>Save for web (CATMAID), if the patches are deselected only a
> portion of the image is exported . Regardless of the format of the source
> images and of the exported images there are only 63 rows by 63 columns of
> 256x256 tiles at zoom level 0 in the folder with the exported images. All
> metadata in the json file is correct and there are no errors reported by
> the System log or the Fiji Log. If the patches are selected with Select All
> (Ctrl + A) the image is exported in its entirety, however here comes the
> next not as much as an issue but slight discomfort.
>
> 4) The image is always exported to a quadrangular array consisting (for the
> reasons already described) of 256 rows and 256 columns of 256x256 tiles at
> zoom level 0. That is the image dimensions (63698 x 57218 px) are expanded
> to 65536x65536 and filled with black tiles. This of course take up
> additional space and need to be cropped away before uploading the image to
> our servers. I understand that this is probably because of limitations to
> the algorithm but still if there is some workaround it would have been
> better.
>
> 5) I thought that this problems (2-4) might be due to the unequal
> dimensions of the original source images and I tried to work around them by
> creating a sibling project with retiled images. Here I had another
> unexpected result - the image was exported but the larger dimension was cut
> by about 6000 pxs from the right side and than restored to the original
> size by adding black pixels , which basically cuts away the right portion
> of my image (see attached screenshot) .
>
> The workstation that I use has the following parameters:
> CPU: Intel Xeon CPU E5-2643 @3.3 GHz (2 x 8 core processors)
> RAM: 64 GB
> OS: Windows 7 64bit
> In an attachment I added the ImageJ-properties output, portion of the
> trakem2 log with the errors generating the mipmaps, and a screenshot of the
> output of the sibling project with retiled images.
>
> I hope someone will find a way to correct these problems, because surely
> they are not fatal and there are workarounds that we use, but it is
> certainly annoying.
>
> Best regards,
> Stoyan
>
> ---
> Dr. Stoyan P. Pavlov, MD, PhD
> Departament of Anatomy, Histology and Embryology
> Medical University "Prof. Dr. Paraskev Stoyanov", Varna
> Prof. Marin Drinov Str.55
> 9002 Varna
> Bulgaria
> Tel: +359 (0) 52 - 677 - 052
> e-mail:
[hidden email]
>
[hidden email]
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
>