[Insight-users] Image index limits

[Oleksandr Dzyubak]

Hi Bill,

Finally I got back to my server and now I can make tests you suggested.
So I downloaded, compiled, and installed today's cvs version of the ITK.

1) Created two images.

./ImageFill_cube cubes.mhd
./ImageFill_cube cubes.hdr

Both images look perfect: two cubes are there.

2) Read and Wrote with JustReadWrite.

   a)
     ./JustReadWrite cubes.mhd cubes_mhd2mhd.mhd
     ./JustReadWrite cubes.mhd cubes_mhd2hdr.hdr

       Both images look perfect: two cubes are still there.

    b)
      ./JustReadWrite cubes.hdr cubes_hdr2hdr.hdr
      ./JustReadWrite cubes.hdr cubes_hdr2mhd.mhd

       Both images look bad: second cube is gone.

It looks like the part of ImageFileReader for Analyze75 format is bad.

Hope it helps,

Alex



Bill Lorensen wrote:
> We have been making passes through the io's to add the proper types
> for offsets. etc.
>
> Try the cvs version and see if your test works with .mdh.
>
> Bill
>
> On Tue, Jan 12, 2010 at 11:42 AM, Oleksandr Dzyubak <adzyubak at gmail.com> wrote:
>   
>> Hi Robert,
>>
>> Thanks for your help in studying this problem.
>>
>> Following your advise, I tested both
>>
>> ImageFill_Cube test.mhd
>> and
>> ImageFill_Cube test.hdr
>>
>> and in both images I see that
>> the first cube stays where it should but the second one disappeared!
>> The only reason for such different behavior on your and my machines
>> I can think of is that on my server I am using ITK 3.16
>> released on September 15, 2009 vs your ITK CVS Nov 4, 2009.
>>
>> Does that mean that IOFactory was updated somehow between these two
>> releases?
>> Well, if it was, I have to give the CVS version a try.
>>
>> But anyway, according to your findings, this issue was not fixed
>> in ImageFileReader for all formats though
>> (or, in particular, for Analyze75 format), right?
>>
>> Unfortunately all my input images are in the Analyze75 format, thus
>> any conversion would still require the Analyze75 support in ImageFileReader.
>>
>> I see that we are getting close.
>>
>> Regards,
>>
>> Alex
>>
>> On Tue, Jan 12, 2010 at 6:06 AM, <Robert.Atwood at diamond.ac.uk> wrote:
>>     
>>> Hi Kevin:
>>>
>>> Which image format did you use for your tests? I observed (see my other
>>> post) that problem using .hdr format (as described by Oleksander's
>>> original post) but not with .mhd format. I believe I observed a similar
>>> problem before with .tif stack but not with a series of .tif (or .mhd)
>>>
>>> Do you observe the problem if you use .hdr format?
>>>
>>> Thanks
>>>
>>> Robert
>>>
>>>
>>> -----Original Message-----
>>> From: insight-users-bounces at itk.org
>>> [mailto:insight-users-bounces at itk.org] On Behalf Of Kevin H. Hobbs
>>> Sent: 11 January 2010 15:01
>>> To: adzyubak at gmail.com
>>> Cc: insight-users at itk.org; Luis Ibanez
>>> Subject: Re: [Insight-users] Image index limits
>>>
>>> On 01/07/2010 05:28 PM, Oleksandr Dzyubak wrote:
>>>       
>>>> ****** End JustReadWrite.cxx ***
>>>>
>>>>         
>>> When I run this pair of programs I get two cubes in the output of the
>>> second program.
>>>
>>> I am using ITK from CVS on a 64 bit Linux workstation with 12 gigabytes
>>> of RAM (bubbles.hooperlab on the dashboard).
>>>
>>> I tried running ImageCompare on the input and output images but the
>>> machine started swapping and I cancelled the comparison.
>>>
>>>
>>> --
>>> This e-mail and any attachments may contain confidential, copyright and or
>>> privileged material, and are for the use of the intended addressee only. If
>>> you are not the intended addressee or an authorised recipient of the
>>> addressee please notify us of receipt by returning the e-mail and do not
>>> use, copy, retain, distribute or disclose the information in or attached to
>>> the e-mail.
>>> Any opinions expressed within this e-mail are those of the individual and
>>> not necessarily of Diamond Light Source Ltd.
>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>>> attachments are free from viruses and we cannot accept liability for any
>>> damage which you may sustain as a result of software viruses which may be
>>> transmitted in or with the message.
>>> Diamond Light Source Limited (company no. 4375679). Registered in England
>>> and Wales with its registered office at Diamond House, Harwell Science and
>>> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>>>
>>>
>>>
>>>
>>>       
>> _____________________________________
>> 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
>>
>>
>>