[Insight-users] Segmentation fault with 2.2G data but not with smaller subset

[Gaëtan Lehmann]

Le 10 août 09 à 17:19, lynx.abraxas at freenet.de a écrit :

> Hello!
>
>
> I  modified  the code to read in raw-files now because I got to know  
> that TIFF
> can have troubles storing more than 2GB data. ImageJ seems to be  
> able to  save
> it though.
>
> With  the  new  code I read in 16-bit data from the start (which is  
> a bit of a
> waste for binary data).  The  problem  is  that  the  masking   
> filter  is  not
> accepting a mask of 8-bit and a file to mask of 16-bit.

It is able to do that. You just have to provide your 8 bit image type  
as second template parameter.

See http://www.itk.org/Doxygen/html/classitk_1_1MaskImageFilter.html

>
>
> Anyway, with the 4.4GB dataset I get the following:
>
> time ~/itk/watershed07/watershed07 zs_gauss-0.5-9_ru_16bit.raw  
> zs_gauss-0.5-9_ru_ws_113101.tif 1 1 3 1 0 1 1550 1549 950
> signed danielson distance map...
> Morphological watershed...
> Creating output...
> terminate called after throwing an instance of 'itk::ExceptionObject'
>  what():  /home/ttd/localusr/include/InsightToolkit/Common/ 
> itkImportImageContainer.txx:188:
> Failed to allocate memory for image.
> Abgebrochen
>
> real    3m22.319s
> user    3m11.452s
> sys     0m10.645s
>
>
> top tells me that watershed07 did not use more than 25% of the  
> available RAM (~50GB).
> watershed07 though seems to be 64-bit:
>
> file ~/itk/watershed07/watershed07
> /home/ttd/itk/watershed07/watershed07: ELF 64-bit LSB executable,  
> x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamicall
> y linked (uses shared libs), not stripped
>
> ldd ~/itk/watershed07/watershed07
>        libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b125abcc000)
>        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b125add0000)
>        libdl.so.2 => /lib64/libdl.so.2 (0x00002b125afeb000)
>        libm.so.6 => /lib64/libm.so.6 (0x00002b125b1f0000)
>        libstdc++.so.6 => /usr/lib64/libstdc++.so.6  
> (0x00002b125b443000)
>        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b125b74b000)
>        libc.so.6 => /lib64/libc.so.6 (0x00002b125b95a000)
>        /lib64/ld-linux-x86-64.so.2 (0x00002b125a9af000)
>
>
> So I wonder why it can not allocate enough memory although there is  
> still 75% left.


I've just tried with a 8GB file in mhd format. It loads without  
problem on my system (opensolaris 64bit 24 GB RAM).
Here is what I did:

[glehmann at marvin ~]$ cat toto.mhd
ObjectType = Image
NDims = 3
BinaryData = True
BinaryDataByteOrderMSB = False
CompressedData = False
TransformMatrix = 1 0 0 0 1 0 0 0 1
Offset = 0 0 0
CenterOfRotation = 0 0 0
AnatomicalOrientation = RAI
ElementSpacing = 1 1 1
DimSize = 2048 2048 2048
ElementType = MET_UCHAR
ElementDataFile = toto.raw
[glehmann at marvin ~]$ mkfile 8g toto.raw
[glehmann at marvin ~]$ ls -lh toto.raw
-rw------- 1 glehmann staff 8,0G 2009-08-10 21:37 toto.raw
[glehmann at marvin ~]$ ipython
/usr/lib/python2.6/site-packages/IPython/Magic.py:38:  
DeprecationWarning: the sets module is deprecated
   from sets import Set

1> import itk

2> reader = itk.ImageFileReader.IUC3.New(FileName="toto.mhd")

3> reader.Update()

4> itk.size(reader)
4> itkSize3([2048, 2048, 2048])

I'm not sure what's wrong on your side, but at least it shows it can  
work :-)

On linux, the memory can be limited in limits.conf. Maybe you should  
look on that side.

Gaëtan

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090810/b1851eb3/attachment-0001.pgp>