[Insight-users] Image index limits
Oleksandr Dzyubak
adzyubak at gmail.com
Tue Dec 22 14:54:03 EST 2009
Hi Luis,
Yes, indeed.
This time I tried both pixel types, "float" and "signed short"
and compared. The results are the same. It goes well up to
the slice # 104. From the slice # 105 and on, it's all zeros.
It is some sort of "saturation" or something specific to my machine?
Did you try on your machine? What's your result?
Regards,
Alex
Luis Ibanez wrote:
> Hi Alex,
>
> Did you changed to "float" the pixel type of
>
> ImageReadRegionOfInterestWrite.cxx ?
>
> by default the pixel type is "signed short".
>
> and your image is of pixel type "float".
>
> ITK will perform silent C-Style casting
> at the moment of reading the image.
>
>
> Please let us know,
>
>
> Thanks,
>
>
> Luis
>
>
> ----------------------------------------------
> On Mon, Dec 14, 2009 at 1:20 PM, Oleksandr Dzyubak <adzyubak at gmail.com> wrote:
>
>> Hi Luis,
>>
>> I followed the procedure 1) through 8) that you suggested.
>> All four tests have successfully passed and the results are below.
>> According to the results, the parameter 70,000L provides the image size
>> "Trying to allocate an image of size 9346 Mb " which is what I actually
>> need.
>> From these tests it looks like it should work.
>>
>> However, I just created and image using a Matlab code below.
>>
>> ***** Star Matlab code ******
>>
>> % Create single square 1340x1300x720
>> clc;
>> clear all;
>> close all;
>>
>>
>> matrix = zeros(1340, 1300, 720);
>> matrix(600:809, 600:809, :) = 1000;
>>
>> % imshow(matrix);
>>
>> fid = fopen('Bar_3Dsquare_I1000_1340x1300x720.bin', 'wb');
>> fwrite(fid, matrix, 'float');
>> status = fclose(fid);
>>
>> ******* Stop Matlab code ************
>>
>> This code exactly creates an 4.7 GB image with white square extruded along
>> the Z-derection.
>> Now I use the ITK program ImageReadRegionOfInterestWrite to sequentially
>> extract series of 100 slices as below.
>>
>> dzyubak at helium: /Square$ ./ImageReadRegionOfInterestWrite
>> Bar_3Dsquare_I1000_1340x1300x720_float.hdr
>> Bar_3Dsquare_I1000_1340x1300x720_float_s1_s100.hdr 0 0 0 1340 1300 100
>>
>> and
>>
>> dzyubak at helium: /Square$ ./ImageReadRegionOfInterestWrite
>> Bar_3Dsquare_I1000_1340x1300x720_float.hdr
>> Bar_3Dsquare_I1000_1340x1300x720_float_s100_s200.hdr 0 0 100 1340 1300 100
>>
>> I checked the Bar_3Dsquare_I1000_1340x1300x720_float.hdr image and it is OK,
>> the square goes all the way through.
>> The first set is also OK and the "white square" shows up but the second set
>> is empty. Any ideas what could cause this problem?
>>
>> Thanks,
>>
>> Alex
>>
>>
>>
>> ******** Start *******
>>
>>
>> root at helium: /BUILD# ctest -R LargeImageWrite -V
>>
>> Test command: /mnt/helium/Root_BUILDs/ITK_3_16/BUILD/bin/itkIOTests
>> itkLargeImageWriteReadTest
>> /mnt/helium/Root_BUILDs/ITK_3_16/BUILD/Testing/Temporary/LargeImage01.mhd
>> 30000L
>> Test timeout computed to be: 1500
>> Trying to allocate an image of size 1716 Mb
>> Initializing pixel values
>> Trying to write the image to disk
>> Trying to read the image back from disk
>> Comparing the pixel values.. :
>> Probe Tag Starts Stops Time (s)
>> Allocate 1 1 3.19481e-05
>> Compare 1 1 4.85127
>> Initializing 1 1 8.84029
>> Read 1 1 2.71803
>> Write 1 1 4.17017
>>
>> Test PASSED !
>> -- Process completed
>> Passed
>> 863/1701 Testing itkLargeImageWriteReadTest2
>> Test command: /mnt/helium/Root_BUILDs/ITK_3_16/BUILD/bin/itkIOTests
>> itkLargeImageWriteReadTest
>> /mnt/helium/Root_BUILDs/ITK_3_16/BUILD/Testing/Temporary/LargeImage02.mhd
>> 40000L
>> Test timeout computed to be: 1500
>> Trying to allocate an image of size 3051 Mb
>> Initializing pixel values
>> Trying to write the image to disk
>> Trying to read the image back from disk
>> Comparing the pixel values.. :
>> Probe Tag Starts Stops Time (s)
>> Allocate 1 1 3.00407e-05
>> Compare 1 1 7.89822
>> Initializing 1 1 12.6574
>> Read 1 1 4.8622
>> Write 1 1 12.6875
>>
>> Test PASSED !
>> -- Process completed
>> Passed
>> 864/1701 Testing itkLargeImageWriteConvertReadT
>> Test command: /mnt/helium/Root_BUILDs/ITK_3_16/BUILD/bin/itkIOTests
>> itkLargeImageWriteConvertReadTest
>> /mnt/helium/Root_BUILDs/ITK_3_16/BUILD/Testing/Temporary/LargeImageConvert.nrrd
>> 50000L
>> Test timeout computed to be: 1500
>> Initializing pixel values
>> Trying to write the image to disk
>> Trying to read the image back from disk
>> Probe Tag Starts Stops Time (s)
>> Allocate 1 1 3.69549e-05
>> Initializing 1 1 11.7354
>> Read 1 1 15.7987
>> Write 1 1 10.5514
>>
>> Test PASSED !
>>
>> 865/1701 Testing itkLargeImageWriteReadTest3
>> Test command: /mnt/helium/Root_BUILDs/ITK_3_16/BUILD/bin/itkIOTests
>> itkLargeImageWriteReadTest
>> /mnt/helium/Root_BUILDs/ITK_3_16/BUILD/Testing/Temporary/LargeImage03.mhd
>> 70000L
>> Test timeout computed to be: 1500
>> Trying to allocate an image of size 9346 Mb
>> Initializing pixel values
>> Trying to write the image to disk
>> Trying to read the image back from disk
>> Comparing the pixel values.. :
>> Probe Tag Starts Stops Time (s)
>> Allocate 1 1 3.19481e-05
>> Compare 1 1 24.2805
>> Initializing 1 1 40.3377
>> Read 1 1 14.4607
>> Write 1 1 32.6605
>>
>> Test PASSED !
>>
>> The following tests passed:
>> itkLargeImageWriteReadTest1
>> itkLargeImageWriteReadTest2
>> itkLargeImageWriteConvertReadTest
>> itkLargeImageWriteReadTest3
>>
>> 100% tests passed, 0 tests failed out of 4
>>
>>
>> ********* End ********
>>
>>
>>
>> On Fri, Dec 11, 2009 at 6:50 PM, Luis Ibanez <luis.ibanez at kitware.com>
>> wrote:
>>
>>> Hi Oleksandr,
>>>
>>>
>>> The components of the itk::Index are of type "long",
>>> while the components of the itk::Size are of type
>>> "unsigned long".
>>>
>>> Therefore, On Linux 64 bits, you can manage
>>> images up to the size of your memory.
>>>
>>> With your small machine of 16 CPUs and
>>> only 128 Gb of RAM you should do fine.
>>>
>>> ... and yes, I'm saying that with envy :-)
>>>
>>>
>>> On Windows 64 bits, on the other hand
>>> we are working on fixing a problem with
>>> the integer representation used in Windows.
>>>
>>>
>>> Back to your report on Linux:
>>>
>>> In the directory Insight/Testing/Code/IO
>>> we have a test for large memory that
>>> will attempt to create, write and read back
>>> and image of large size (above 2 Gb).
>>> Let's try running it in your computer.
>>>
>>> Please do the following:
>>>
>>> 1) go to the binary directory where you
>>> built ITK and do
>>>
>>> make edit_cache
>>>
>>>
>>> 2) Turn BUILD_TESTING ON
>>>
>>>
>>> 3) Go to the Advanced mode,
>>> search for
>>>
>>> ITK_COMPUTER_MEMORY_SIZE
>>>
>>> and set it to 128
>>>
>>> (yes, the units are in Gb).
>>>
>>>
>>>
>>> 4) Do, "c" for configure
>>>
>>> 5) Do, "g" to generate
>>>
>>>
>>> 6) make -j32
>>>
>>> (that shouldn't take long) :-)
>>>
>>>
>>> 7) Run the LargeImage test with
>>> the command:
>>>
>>> ctest -R LargeImageWrite -V
>>>
>>> and see if they pass.
>>>
>>> 8) Now you can take it further,
>>> by looking at the command
>>> that is used to run the tests,
>>> The last numeric argument is
>>> the number of pixels along each
>>> dimension, of the image that is
>>> created by the test.
>>>
>>> You could force this number
>>> until the total size of this 2D
>>> image is comparable to your 3D
>>> image.
>>>
>>> For example, by 70,000 the
>>> image will be of size 1,2 Gb.
>>>
>>>
>>>
>>> Please let us know what you find
>>> after running these tests.
>>>
>>>
>>> Thanks
>>>
>>>
>>> Luis
>>>
>>>
>>> --------------------------------------------------------------
>>> On Fri, Dec 11, 2009 at 4:37 PM, Oleksandr Dzyubak <adzyubak at gmail.com>
>>> wrote:
>>>
>>>> Dear users,
>>>>
>>>> I tried to process the 1340x1300x720 pixel image and after the slice
>>>> #104 I
>>>> am getting all zeros.
>>>> I checked the original image and it's good. It's full of info.
>>>> So I first decided to split that file using the
>>>> itkRegionOfInterestImageFilter class.
>>>> What I found is that all the chunks after the slice #104 are zeros
>>>> thus it's not the image processing filter that causes the problem.
>>>>
>>>> Here is my question.
>>>> Is there any limitation on an image index range?
>>>> Or in other words, what is the largest pixel volume that ITK still can
>>>> handle?
>>>>
>>>> Thanks,
>>>>
>>>> Alex
>>>>
>>>> PS.
>>>> I am using 64 bit Debian Linux.
>>>> 16 CPUs and 128 GB.
>>>>
>>>> _____________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Kitware offers ITK Training Courses, for more information visit:
>>>> http://www.kitware.com/products/protraining.html
>>>>
>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>>
>>>>
>>>>
>>
More information about the Insight-users
mailing list