From ktsirkou at gmail.com  Sun Nov  2 15:46:51 2014
From: ktsirkou at gmail.com (Konstantinos Tsirkou)
Date: Sun, 02 Nov 2014 21:46:51 +0100
Subject: [ITK-users] Reading Dicom Image from BLOB object Stord in a Database
Message-ID: <5456983B.80803@gmail.com>

Hello all,

I am facing a sitiuation where i have a Database (Oracle) that on a 
table that stores
multimedia i have a column that stores as binary data from a incoming file.
I have to read the Binary data and load it as Dicom object using gdcmIO 
module.
So far i haven't found a clean way to do this.
What i am doing so far is tha i read the dinary data and by reading the 
huge Dicom Specifications documents
i can identify the pixel data and almost all the metadat information 
only if the transfer syntax is "Explicit VR"
and then by using the importImageFilter i create an itk image object.
But the above is not working on encapsulated jpeg or jpeg2000 images.

So i wanted to ask if ther is a way to load the whole binary data that i 
have as a memory buffer to an itk image type?

Thank you very much,
Much regards,
Kostas

From rogerbramon at gmail.com  Mon Nov  3 05:13:51 2014
From: rogerbramon at gmail.com (Roger Bramon Feixas)
Date: Mon, 3 Nov 2014 11:13:51 +0100
Subject: [ITK-users] [ITK] Error compiling msvc2010 + ITK4.6 + Qt
In-Reply-To: <CAMAf15PvLr1_TENtygmv-4b3PT3B1deXPpgRJ20VBVRRevhvnQ@mail.gmail.com>
References: <5446873A.7070500@imnc.in2p3.fr>
 <930E7D31-ACFE-4ECF-8EAD-E8D3B6081B92@mail.nih.gov>
 <54475B84.5020906@imnc.in2p3.fr> <54492AB3.2030006@imnc.in2p3.fr>
 <CALzTN-SFe3MOqJ9DYOyvWkdjG1PcgcXE9p_TtN6cOgXUZt2BUg@mail.gmail.com>
 <544A073B.4080905@imnc.in2p3.fr>
 <CALzTN-SCiw9zYULhhZx2BpGR45Rt3PBvXb6Qq2YMY8zqJZpiug@mail.gmail.com>
 <CAMAf15PvLr1_TENtygmv-4b3PT3B1deXPpgRJ20VBVRRevhvnQ@mail.gmail.com>
Message-ID: <CAMAf15NRMkodau4DPonONrFB2ho2q8UOp_JbXfjt0ef3MsPKqQ@mail.gmail.com>

Dear all,

I solved the problem. Shell32.lib system library needs to be added to qmake
LIBS variable because it includes CommandLineToArgvW function. I think it
is required since 4.6.0 which includes commit
http://itk.org/gitweb?p=ITK.git;a=commit;h=f29c354194e45dcb12d4d0b8765f0c3a9deeab78

HTH,

Roger

On Fri, Oct 31, 2014 at 6:55 PM, Roger Bramon Feixas <rogerbramon at gmail.com>
wrote:

> Hi,
>
> I also have this link problem trying to build using msvc2013_opengl + ITK
> 4.6.1 + VTK 6.1 + GDCM 2.4.4 + Qt 5.3.2. We are using qmake as well.
>
> Any suggestion will be appreciated.
>
> Many thanks,
>
> Roger
>
> On Fri, Oct 24, 2014 at 4:57 PM, Matt McCormick <
> matt.mccormick at kitware.com> wrote:
>
>> Hi Fran?oise,
>>
>>
>> CMake is recommended -- it will avoid this problem and others.  It
>> works well with Qt.
>>
>> Thanks,
>> Matt
>>
>> On Fri, Oct 24, 2014 at 4:00 AM, Fran?oise Lefebvre
>> <lefebvre at imnc.in2p3.fr> wrote:
>> >
>> > No, I'm not.  I have always used a .pro file and qmake.
>> >
>> > Le 23/10/2014 23:37, Matt McCormick a ?crit :
>> >
>> >> Hi,
>> >>
>> >> Are you using CMake to configure your project?
>> >>
>> >> Matt
>> >>
>> >> On Thu, Oct 23, 2014 at 12:20 PM, Fran?oise Lefebvre
>> >> <lefebvre at imnc.in2p3.fr> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I also tried on Windows 8,msvc2012_opengl and Qt5.3. I get exactly the
>> >>> same
>> >>> link error.
>> >>>
>> >>> FL
>> >>>
>> >>>
>> >>> Le 22/10/2014 09:23, Fran?oise Lefebvre a ?crit :
>> >>>
>> >>>> Yes I did.
>> >>>>
>> >>>> Le 21/10/2014 19:18, Bradley Lowekamp a ?crit :
>> >>>>>
>> >>>>> Did you try the latest 4.6.1 release?
>> >>>>>
>> >>>>> Brad
>> >>>>>
>> >>>>> On Oct 21, 2014, at 12:18 PM, Fran?oise Lefebvre
>> >>>>> <lefebvre at imnc.in2p3.fr>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> ITK 4.6 was succesfully build using cmake2.8.10.2, the default
>> >>>>>> parameters and the Module_ITKReview on.
>> >>>>>>
>> >>>>>> I am now trying to compile a program developed in C++ using Qt5.1.1
>> >>>>>> and
>> >>>>>> Microsoft Visual C++ express 2010 on Windows 7.
>> >>>>>>
>> >>>>>> I get the following link error :
>> >>>>>>
>> >>>>>> 1>itksys-4.6.lib(EncodingCXX.obj) : error LNK2019: symbole externe
>> non
>> >>>>>> r?solu __imp__CommandLineToArgvW at 8 r?f?renc? dans la fonction
>> "public:
>> >>>>>> static class itksys::Encoding::CommandLineArguments __cdecl
>> >>>>>> itksys::Encoding::CommandLineArguments::Main(int,char const * const
>> >>>>>> *)"
>> >>>>>> (?Main at CommandLineArguments@Encoding at itksys@@SA?AV123 at HPBQBD@Z)
>> >>>>>>
>> >>>>>> I didn't get this error when compiling with itk4.3 .
>> >>>>>>
>> >>>>>> Any hint ?
>> >>>>>>
>> >>>>>> Thank you for your help,
>> >>>>>>
>> >>>>>> F. Lefebvre
>> >>>>>>
>> >>>>>> _____________________________________
>> >>>>>> 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.php
>> >>>>>>
>> >>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>> >>>>>> _______________________________________________
>> >>>>>> Community mailing list
>> >>>>>> Community at itk.org
>> >>>>>> http://public.kitware.com/mailman/listinfo/community
>> >>>>
>> >>>>
>> >>> _____________________________________
>> >>> 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.php
>> >>>
>> >>> 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://public.kitware.com/mailman/listinfo/insight-users
>> >
>> >
>> > --
>> > Fran?oise LEFEBVRE
>> > IMNC (Imagerie et Mod?lisation en Neurobiologie et Canc?rologie)
>> > Campus d'Orsay - B?t 440
>> > 91405 ORSAY Cedex
>> > 01 69 15 51 87
>> >
>> _____________________________________
>> 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.php
>>
>> 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://public.kitware.com/mailman/listinfo/insight-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141103/bd08c262/attachment.html>

From Olivier.Commowick at inria.fr  Mon Nov  3 09:39:53 2014
From: Olivier.Commowick at inria.fr (Olivier Commowick)
Date: Mon, 3 Nov 2014 15:39:53 +0100
Subject: [ITK-users] VectorImage vs image of vectors
Message-ID: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>

Hello all,

I encountered some weird behavior in ITK. For some reason, I have in my code some vector images that I need to smooth using a Gaussian filter. It appears that whether the image is stored as a VectorImage or an Image of itk Vectors is actually extremely important in terms of performance for this task. Namely, if using VectorImages, the processing time can be much worse (30s vs 1s with an image of vectors). My problem is that I cannot really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim > since I do not know Size at compilation time.

Looking deeper into the code, I have two questions for whoever would know about these images: 
- the first one is on the Variable length vector: it seems to me that the operator= method always starts by destroying current data, even if the vector size is the same. It doesn?t seem really efficient so I was wondering if there was any reason for that
- the second one is on the VectorImage itself: is there something in it that would justify the computation times to be much worse ?

If someone has any info on which image type I should be using or why VectorImage would be slower, I would be grateful.

Thanks in advance

---

Olivier Commowick, Ph.D.
Research Scientist
INRIA Rennes - Bretagne Atlantique, VISAGES Team
Campus de Beaulieu
35042 Rennes
FRANCE

Phone: +33 2 99 84 25 92
Email: Olivier.Commowick at inria.fr
Web: http://olivier.commowick.org/






From blowekamp at mail.nih.gov  Mon Nov  3 09:58:35 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 3 Nov 2014 09:58:35 -0500
Subject: [ITK-users] VectorImage vs image of vectors
In-Reply-To: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
References: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
Message-ID: <118DE5D3-1862-45B6-BEB1-37E2C8A90B82@mail.nih.gov>

Hello,

What specific Gaussian filter are you running?

One common cause of an VectorImage algorithm being overly slow is that there is an over use of temporaries which require excessive memory allocation done on a per-pixel basis. Because the Image of Vectors is templated on the size of the vector, the pixel can be stored on the stack, and not required the allocation. With this considered many slow algorithms can fairly easily be improved by reusing temporaries, or writing a specilized method for the VectorImage.

Brad

On Nov 3, 2014, at 9:39 AM, Olivier Commowick <Olivier.Commowick at inria.fr> wrote:

> Hello all,
> 
> I encountered some weird behavior in ITK. For some reason, I have in my code some vector images that I need to smooth using a Gaussian filter. It appears that whether the image is stored as a VectorImage or an Image of itk Vectors is actually extremely important in terms of performance for this task. Namely, if using VectorImages, the processing time can be much worse (30s vs 1s with an image of vectors). My problem is that I cannot really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim > since I do not know Size at compilation time.
> 
> Looking deeper into the code, I have two questions for whoever would know about these images: 
> - the first one is on the Variable length vector: it seems to me that the operator= method always starts by destroying current data, even if the vector size is the same. It doesn?t seem really efficient so I was wondering if there was any reason for that
> - the second one is on the VectorImage itself: is there something in it that would justify the computation times to be much worse ?
> 
> If someone has any info on which image type I should be using or why VectorImage would be slowGeer, I would be grateful.
> 
> Thanks in advance
> 
> ---
> 
> Olivier Commowick, Ph.D.
> Research Scientist
> INRIA Rennes - Bretagne Atlantique, VISAGES Team
> Campus de Beaulieu
> 35042 Rennes
> FRANCE
> 
> Phone: +33 2 99 84 25 92
> Email: Olivier.Commowick at inria.fr
> Web: http://olivier.commowick.org/
> 
> 
> 
> 
> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users


From Olivier.Commowick at inria.fr  Mon Nov  3 10:04:19 2014
From: Olivier.Commowick at inria.fr (Olivier Commowick)
Date: Mon, 3 Nov 2014 16:04:19 +0100
Subject: [ITK-users] VectorImage vs image of vectors
In-Reply-To: <118DE5D3-1862-45B6-BEB1-37E2C8A90B82@mail.nih.gov>
References: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
 <118DE5D3-1862-45B6-BEB1-37E2C8A90B82@mail.nih.gov>
Message-ID: <F2042767-ECD9-4DA1-BC49-04D47CB15872@inria.fr>

Hello

The Gaussian filter used is the YVV gaussian filter that is available as an external module of ITK. It is true that it seems to be using quite a lot of temporaries. I will try to have a look into that.

As for building options, I have compiled in release mode.

Thanks
Olivier

> On Nov 3, 2014, at 15:58 , Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
> Hello,
> 
> What specific Gaussian filter are you running?
> 
> One common cause of an VectorImage algorithm being overly slow is that there is an over use of temporaries which require excessive memory allocation done on a per-pixel basis. Because the Image of Vectors is templated on the size of the vector, the pixel can be stored on the stack, and not required the allocation. With this considered many slow algorithms can fairly easily be improved by reusing temporaries, or writing a specilized method for the VectorImage.
> 
> Brad
> 
> On Nov 3, 2014, at 9:39 AM, Olivier Commowick <Olivier.Commowick at inria.fr> wrote:
> 
>> Hello all,
>> 
>> I encountered some weird behavior in ITK. For some reason, I have in my code some vector images that I need to smooth using a Gaussian filter. It appears that whether the image is stored as a VectorImage or an Image of itk Vectors is actually extremely important in terms of performance for this task. Namely, if using VectorImages, the processing time can be much worse (30s vs 1s with an image of vectors). My problem is that I cannot really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim > since I do not know Size at compilation time.
>> 
>> Looking deeper into the code, I have two questions for whoever would know about these images: 
>> - the first one is on the Variable length vector: it seems to me that the operator= method always starts by destroying current data, even if the vector size is the same. It doesn?t seem really efficient so I was wondering if there was any reason for that
>> - the second one is on the VectorImage itself: is there something in it that would justify the computation times to be much worse ?
>> 
>> If someone has any info on which image type I should be using or why VectorImage would be slowGeer, I would be grateful.
>> 
>> Thanks in advance
>> 
>> ---
>> 
>> Olivier Commowick, Ph.D.
>> Research Scientist
>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>> Campus de Beaulieu
>> 35042 Rennes
>> FRANCE
>> 
>> Phone: +33 2 99 84 25 92
>> Email: Olivier.Commowick at inria.fr
>> Web: http://olivier.commowick.org/
>> 
>> 
>> 
>> 
>> 
>> _____________________________________
>> 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.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-users
> 


---

Olivier Commowick, Ph.D.
Research Scientist
INRIA Rennes - Bretagne Atlantique, VISAGES Team
Campus de Beaulieu
35042 Rennes
FRANCE

Phone: +33 2 99 84 25 92
Email: Olivier.Commowick at inria.fr
Web: http://olivier.commowick.org/






From norman-k-williams at uiowa.edu  Mon Nov  3 11:18:12 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Mon, 3 Nov 2014 16:18:12 +0000
Subject: [ITK-users] VectorImage vs image of vectors
In-Reply-To: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
References: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
Message-ID: <D07D0372.C69A%norman-k-williams@uiowa.edu>

2 observations:

1. I think the redundant SetSize you mentioned is almost certainly
unnecessary.  I?ve seen similar unnecessary vector/array sizing other
places in ITK; I think it arose out of an abundance of caution, and just
never showed up on anyone?s optimization radar yet.

2. There?s a technique you can use to get around the
itk::Image<itk::Vector<TScalar,TVecLength>, TDim> problem, if there is a
small, finite number of possible vector lengths.  Put the code using the
vector image inside a function templated over TVecLength.  Then at
runtime, determine the vector length and invoke the template function with
that vector length.

E.G.

template<typename TScalar,unsigned NVecLength, unsigned NDim>
void DoSomething()
{
  typedef itk::Image< itk::Vector<TScalar, NVecLength>, NDim > ImageType;
        ...
}

int main(int,char *[])
{
  ...
  switch(vecLength)
  {
  case 3:
     DoSomething<double,3,3>();
     break;
  case 11:
     DoSomething<double,11,3>();
  ?
  }
}

This is of course in most cases bad C++ programming practice, but it does
allow you to accommodate different data types in a program.

On 11/3/14, 8:39 AM, "Olivier Commowick" <Olivier.Commowick at inria.fr>
wrote:

>Hello all,
>
>I encountered some weird behavior in ITK. For some reason, I have in my
>code some vector images that I need to smooth using a Gaussian filter. It
>appears that whether the image is stored as a VectorImage or an Image of
>itk Vectors is actually extremely important in terms of performance for
>this task. Namely, if using VectorImages, the processing time can be much
>worse (30s vs 1s with an image of vectors). My problem is that I cannot
>really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim >
>since I do not know Size at compilation time.
>
>Looking deeper into the code, I have two questions for whoever would know
>about these images:
>- the first one is on the Variable length vector: it seems to me that the
>operator= method always starts by destroying current data, even if the
>vector size is the same. It doesn?t seem really efficient so I was
>wondering if there was any reason for that
>- the second one is on the VectorImage itself: is there something in it
>that would justify the computation times to be much worse ?
>
>If someone has any info on which image type I should be using or why
>VectorImage would be slower, I would be grateful.
>
>Thanks in advance
>
>---
>
>Olivier Commowick, Ph.D.
>Research Scientist
>INRIA Rennes - Bretagne Atlantique, VISAGES Team
>Campus de Beaulieu
>35042 Rennes
>FRANCE
>
>Phone: +33 2 99 84 25 92
>Email: Olivier.Commowick at inria.fr
>Web: http://olivier.commowick.org/
>
>
>
>
>
>_____________________________________
>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.php
>
>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://public.kitware.com/mailman/listinfo/insight-users



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________

From lluna.nova at gmail.com  Mon Nov  3 14:06:05 2014
From: lluna.nova at gmail.com (=?UTF-8?B?UG9sIE1vbnPDsyBQdXJ0w60=?=)
Date: Mon, 3 Nov 2014 20:06:05 +0100
Subject: [ITK-users] Loading a specifing region of an image from disk
Message-ID: <CALAZn4grvcugbkSgJnC=KLYjFYJ=79PDVNQss1+SdYT0U=R0Ww@mail.gmail.com>

Hello everyone.

Two simple questions:

1.- How to set the RequestedRegion on a writer.
2.- Will the pipeline only load the requested region, including the reader?

By reading the itksoftware manual, section 8.3 Streaming Large Data it
looks like by default reader filters only load the requested region.

We want to extract a specific region of a large 3D tiff image that does not
fit in memory. This has to be as fast as possible.

I've taken a look at streaming, althought it's not exactly what we want
since we don't want to process the full image.

I've tried myself but I can't get to write just the requested region.

The code:

int main( int argc, char* argv[] )
{

  typedef unsigned char              PixelType;
  typedef itk::Image< PixelType, 3 > ImageType;

  typedef itk::ImageFileReader< ImageType > ReaderFilterType;
  ReaderFilterType::Pointer reader = ReaderFilterType::New();
  reader->SetFileName("../data/
Madrid_Train.tif");
  ImageType::RegionType largest =
reader->GetOutput()->GetLargestPossibleRegion();
  ImageType::SizeType size   = largest.GetSize();
  ImageType::IndexType index = largest.GetIndex();

  ImageType::RegionType half;
  half.SetIndex(0,index[0] + 0.25*size[0]);
  half.SetIndex(1,index[1] + 0.25*size[1]);
  half.SetIndex(2,index[2] + 0.25*size[2]);

  half.SetSize(0,0.5*size[0]);
  half.SetSize(1,0.5*size[1]);
  half.SetSize(2,0.5*size[2]);

  typedef itk::ImageFileWriter< ImageType > WriterFilterType;
  WriterFilterType::Pointer writer = WriterFilterType::New();
  writer->SetFileName("image.tif");
  reader->GetOutput()->SetRequestedRegion(half);
  writer->SetInput(reader->GetOutput());

  try
    {
    //streamingFilter->Update();
    writer->Update();
    }
  catch( itk::ExceptionObject & error )
    {
    std::cerr << "Error: " << error << std::endl;
    return EXIT_FAILURE;
    }

  return EXIT_SUCCESS;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141103/5488b71b/attachment.html>

From blowekamp at mail.nih.gov  Mon Nov  3 15:37:17 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 3 Nov 2014 15:37:17 -0500
Subject: [ITK-users] SimpleITK - Reading different DICOM serie
In-Reply-To: <CACDxx9jAj+EB63gvi+2uegWcu-E1V7tPXy7QuDxsxin6N2=RWQ@mail.gmail.com>
References: <CACDxx9jAj+EB63gvi+2uegWcu-E1V7tPXy7QuDxsxin6N2=RWQ@mail.gmail.com>
Message-ID: <26879E67-D42E-4A53-9309-7CD933EC3FD0@mail.nih.gov>

Hello,

What version of ITK and SimpleITK are you using?

Thanks,
Brad

On Oct 31, 2014, at 7:03 PM, Guillaume Lema?tre <g.lemaitre58 at gmail.com> wrote:

> Hi all,
> 
> I am currently using SimpleITK with python to read directly some DICOM data.
> My dataset is corresponding to an MRI modality composed of 40 series. Each serie is a 3D volume.
> 
> I would like to read the serie one-by-one. As a minimal example, I can post the following code:
> 
> reader = sitk.ImageSeriesReader()
> # For each serie found
> for serie in reader.GetGDCMSeriesIDs(path_to_data):
>     # Get the dicom filename corresponding to the current serie
>     dicom_names = reader.GetGDCMSeriesFileNames(path_to_data, serie)
>     reader.SetFileNames(dicom_names)
>     image = reader.Execute()
> 
> I got the following error:
> 
> WARNING: In /home/lemaitre/anaconda/conda-bld/work/build/ITK/Modules/IO/GDCM/src/itkGDCMSeriesFileNames.cxx, line 138
> GDCMSeriesFileNames (0x3078840): No Series were found
> 
> However, the output of reader.GetGDCMSeriesIDs(path_to_data) seems ok:
> ('1.2.826.0.1.3680043.2.1125.1.12083572272639445972057901411530444',
>  ............................ 40 lines ...........................
>  '1.2.826.0.1.3680043.2.1125.1.98804240625293208256969403455867278')
> 
> So my question is the following. What is the right way to passing the serieID to the GetGDCMSeriesFileNames() function.
> 
> Thanks in advance,
> 
> Best regards,
> -- 
> LEMA?TRE Guillaume
> PhD Candiate
> MSc Erasmus Mundus ViBOT (Vision-roBOTic)
> MSc Business Innovation and Technology Management
> 
> g.lemaitre58 at gmail.com
> 
> 
> ViCOROB - Computer Vision and Robotic Team
> Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
> Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59 
> http://vicorob.udg.es/
> LE2I - Le Creusot
> IUT Le Creusot, Laboratoire LE2I, 12 rue de la Fonderie, 71200 Le Creusot
> Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97 
> http://le2i.cnrs.fr
>         
> https://sites.google.com/site/glemaitre58/
> Vice - Chairman of A.S.C. Fours UFOLEP
> Chairman of A.S.C. Fours FFC
> Webmaster of http://ascfours.free.fr
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141103/aad0febf/attachment.html>

From blowekamp at mail.nih.gov  Mon Nov  3 15:38:18 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 3 Nov 2014 15:38:18 -0500
Subject: [ITK-users] Loading a specifing region of an image from disk
In-Reply-To: <CALAZn4grvcugbkSgJnC=KLYjFYJ=79PDVNQss1+SdYT0U=R0Ww@mail.gmail.com>
References: <CALAZn4grvcugbkSgJnC=KLYjFYJ=79PDVNQss1+SdYT0U=R0Ww@mail.gmail.com>
Message-ID: <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov>

Hello,

You might find this article useful I wrote on streaming ImageIO [1].


> 1.- How to set the RequestedRegion on a writer.

I am not sure what you are wanting to do. Are you wanting to extract a region from the input file and write a partial sub image?

There are two modes for the writer to drive this. 1) streaming - the sequential writing of sub-region of the whole image 2) pasting - updating a sub-region of an existing image file.


> 2.- Will the pipeline only load the requested region, including the reader?

The pipeline has a series of steps which include propagating a requested region, and giving each filter the opportunity to enlarge this region. I have frequently assemble pipelines which perform out-of-core processing as you desire. However all filters in the pipeline must support streaming, and not enlarging the requested region to the largest possible region.

Additionally the ImageIO for the reader and writer must also support streaming. There are several ImageIO's which support streaming reading (MRC,MetaIO, VTK, Nift, JPEG2000, etc), I believe that only MRC, VTK and MetaIO  fully support it for writing. So TIFF is currently not there.

Recently I have been working on improving the itkTIFFImageIO [2], and have performance gains of upto 3-5X from the prior version. However, I haven't gotten to adding streaming yet. It's is a back burner project for me to add support for stream reading to it, so that may be coming shortly ( this poking helps ). However, adding stream and paste writing is not planned.

Let's look at your code.

> I've tried myself but I can't get to write just the requested region.
> 
> The code:
> 
> int main( int argc, char* argv[] )
> {
> 
>   typedef unsigned char              PixelType;
>   typedef itk::Image< PixelType, 3 > ImageType;
> 
>   typedef itk::ImageFileReader< ImageType > ReaderFilterType;
>   ReaderFilterType::Pointer reader = ReaderFilterType::New();
>   reader->SetFileName("../data/
> Madrid_Train.tif");
>   ImageType::RegionType largest = reader->GetOutput()->GetLargestPossibleRegion();
>   ImageType::SizeType size   = largest.GetSize();
>   ImageType::IndexType index = largest.GetIndex();
> 
>   ImageType::RegionType half;
>   half.SetIndex(0,index[0] + 0.25*size[0]);
>   half.SetIndex(1,index[1] + 0.25*size[1]);
>   half.SetIndex(2,index[2] + 0.25*size[2]);
> 
>   half.SetSize(0,0.5*size[0]);
>   half.SetSize(1,0.5*size[1]);
>   half.SetSize(2,0.5*size[2]);
> 
>   typedef itk::ImageFileWriter< ImageType > WriterFilterType;
>   WriterFilterType::Pointer writer = WriterFilterType::New();
>   writer->SetFileName("image.tif");
>   reader->GetOutput()->SetRequestedRegion(half);
>   writer->SetInput(reader->GetOutput());
> 
>   try
>     {
>     //streamingFilter->Update();
>     writer->Update();
>     }
>   catch( itk::ExceptionObject & error )
>     {
>     std::cerr << "Error: " << error << std::endl;
>     return EXIT_FAILURE;
>     }

Unfortunately this is not the way the pipeline works. The reader does not actually read and update the image until the pipeline is updated. I would recommend additional reading about how a pipeline architecture works, perhaps from the ITK software guide or an VTK book.

For this case you should add in an ExtractImageFilter, or a CropImageFilter.

Brad




[1] http://www.kitware.com/media/html/IOStreamingInITK.html
[2] https://github.com/InsightSoftwareConsortium/ITK/commits/master/Modules/IO/TIFF
[3] http://www.itk.org/Doxygen/html/IO_2VisibleHumanStreamReadWrite_8cxx-example.html


On Nov 3, 2014, at 2:06 PM, Pol Mons? Purt? <lluna.nova at gmail.com> wrote:

> Hello everyone.
> 
> Two simple questions:
> 
> 
> By reading the itksoftware manual, section 8.3 Streaming Large Data it looks like by default reader filters only load the requested region.
> 
> We want to extract a specific region of a large 3D tiff image that does not fit in memory. This has to be as fast as possible.
> 
> I've taken a look at streaming, althought it's not exactly what we want since we don't want to process the full image.
> 
>   return EXIT_SUCCESS;
> }
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users


From g.lemaitre58 at gmail.com  Mon Nov  3 15:47:33 2014
From: g.lemaitre58 at gmail.com (=?UTF-8?Q?Guillaume_Lema=C3=AEtre?=)
Date: Mon, 3 Nov 2014 21:47:33 +0100
Subject: [ITK-users] SimpleITK - Reading different DICOM serie
In-Reply-To: <26879E67-D42E-4A53-9309-7CD933EC3FD0@mail.nih.gov>
References: <CACDxx9jAj+EB63gvi+2uegWcu-E1V7tPXy7QuDxsxin6N2=RWQ@mail.gmail.com>
 <26879E67-D42E-4A53-9309-7CD933EC3FD0@mail.nih.gov>
Message-ID: <CACDxx9hwcZjM+MopSJTjFGEVFxujO-5=4Y6-EqOepvZNZFBM8g@mail.gmail.com>

Hi Brad,

I build Simple-ITK from anaconda recipes.
Checking the conda-build directory, it seems SimpleITK 0.9.0 and ITK 4.6.1

Cheers,

On 3 November 2014 21:37, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> Hello,
>
> What version of ITK and SimpleITK are you using?
>
> Thanks,
> Brad
>
> On Oct 31, 2014, at 7:03 PM, Guillaume Lema?tre <g.lemaitre58 at gmail.com>
> wrote:
>
> Hi all,
>
> I am currently using SimpleITK with python to read directly some DICOM
> data.
> My dataset is corresponding to an MRI modality composed of 40 series. Each
> serie is a 3D volume.
>
> I would like to read the serie one-by-one. As a minimal example, I can
> post the following code:
>
> reader = sitk.ImageSeriesReader()
> # For each serie found
> for serie in reader.GetGDCMSeriesIDs(path_to_data):
>     # Get the dicom filename corresponding to the current serie
>     dicom_names = reader.GetGDCMSeriesFileNames(path_to_data, serie)
>     reader.SetFileNames(dicom_names)
>     image = reader.Execute()
>
> I got the following error:
>
> WARNING: In
> /home/lemaitre/anaconda/conda-bld/work/build/ITK/Modules/IO/GDCM/src/itkGDCMSeriesFileNames.cxx,
> line 138
> GDCMSeriesFileNames (0x3078840): No Series were found
>
> However, the output of reader.GetGDCMSeriesIDs(path_to_data) seems ok:
> ('1.2.826.0.1.3680043.2.1125.1.12083572272639445972057901411530444',
>  ............................ 40 lines ...........................
>  '1.2.826.0.1.3680043.2.1125.1.98804240625293208256969403455867278')
>
> So my question is the following. What is the right way to passing the
> serieID to the GetGDCMSeriesFileNames() function.
>
> Thanks in advance,
>
> Best regards,
> --
>
>
>
>
> *LEMA?TRE GuillaumePhD CandiateMSc Erasmus Mundus ViBOT
> (Vision-roBOTic)MSc Business Innovation and Technology Management*
> g.lemaitre58 at gmail.com
>
>
> *ViCOROB - Computer Vision and Robotic Team*
> Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
> Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59
> http://vicorob.udg.es/
>
> *LE2I - Le Creusot*IUT Le Creusot, Laboratoire LE2I, 12 rue de la
> Fonderie, 71200 Le Creusot
> Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97
> http://le2i.cnrs.fr
>
> https://sites.google.com/site/glemaitre58/
> Vice - Chairman of A.S.C. Fours UFOLEP
> Chairman of A.S.C. Fours FFC
> Webmaster of http://ascfours.free.fr
>  _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>
>
>


-- 




*LEMA?TRE GuillaumePhD CandiateMSc Erasmus Mundus ViBOT (Vision-roBOTic)MSc
Business Innovation and Technology Management*
g.lemaitre58 at gmail.com

*ViCOROB - Computer Vision and Robotic Team*
Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59
http://vicorob.udg.es/

*LE2I - Le Creusot*IUT Le Creusot, Laboratoire LE2I, 12 rue de la Fonderie,
71200 Le Creusot
Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97
http://le2i.cnrs.fr

https://sites.google.com/site/glemaitre58/
Vice - Chairman of A.S.C. Fours UFOLEP
Chairman of A.S.C. Fours FFC
Webmaster of http://ascfours.free.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141103/6deb6dd0/attachment-0001.html>

From dchen at mail.nih.gov  Mon Nov  3 16:23:16 2014
From: dchen at mail.nih.gov (David Chen)
Date: Mon, 3 Nov 2014 16:23:16 -0500
Subject: [ITK-users] SimpleITK - Reading different DICOM serie
References: <A704C754-782C-4DA9-B23C-FFBC8EA586F3@mail.nih.gov>
Message-ID: <D91D2989-E817-40FA-BDE7-B3E483FF0D35@mail.nih.gov>

Hi Guillaume

What version of SimpleITK are you running?  I tried your script using the current git master, and it doesn?t work for me.  But when I ran it using SimpleITK 0.8.0 it does.  So clearing something has gone wrong that we have to figure out.  For now, try and use 0.8.0.


Cheers,
Dave


> From: Guillaume Lema?tre <g.lemaitre58 at gmail.com>
> Subject: [ITK-users] SimpleITK - Reading different DICOM serie
> Date: October 31, 2014 at 7:03:36 PM EDT
> To: "insight-users at itk.org" <insight-users at itk.org>
> 
> Hi all,
> 
> I am currently using SimpleITK with python to read directly some DICOM data.
> My dataset is corresponding to an MRI modality composed of 40 series. Each serie is a 3D volume.
> 
> I would like to read the serie one-by-one. As a minimal example, I can post the following code:
> 
> reader = sitk.ImageSeriesReader()
> # For each serie found
> for serie in reader.GetGDCMSeriesIDs(path_to_data):
>     # Get the dicom filename corresponding to the current serie
>     dicom_names = reader.GetGDCMSeriesFileNames(path_to_data, serie)
>     reader.SetFileNames(dicom_names)
>     image = reader.Execute()
> 
> I got the following error:
> 
> WARNING: In /home/lemaitre/anaconda/conda-bld/work/build/ITK/Modules/IO/GDCM/src/itkGDCMSeriesFileNames.cxx, line 138
> GDCMSeriesFileNames (0x3078840): No Series were found
> 
> However, the output of reader.GetGDCMSeriesIDs(path_to_data) seems ok:
> ('1.2.826.0.1.3680043.2.1125.1.12083572272639445972057901411530444',
>  ............................ 40 lines ...........................
>  '1.2.826.0.1.3680043.2.1125.1.98804240625293208256969403455867278')
> 
> So my question is the following. What is the right way to passing the serieID to the GetGDCMSeriesFileNames() function.
> 
> Thanks in advance,
> 
> Best regards,
> -- 
> LEMA?TRE Guillaume
> PhD Candiate
> MSc Erasmus Mundus ViBOT (Vision-roBOTic)
> MSc Business Innovation and Technology Management
> 
> g.lemaitre58 at gmail.com
> 
> 
> ViCOROB - Computer Vision and Robotic Team
> Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
> Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59 
> http://vicorob.udg.es/
> LE2I - Le Creusot
> IUT Le Creusot, Laboratoire LE2I, 12 rue de la Fonderie, 71200 Le Creusot
> Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97 
> http://le2i.cnrs.fr
>         
> https://sites.google.com/site/glemaitre58/
> Vice - Chairman of A.S.C. Fours UFOLEP
> Chairman of A.S.C. Fours FFC
> Webmaster of http://ascfours.free.fr
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141103/aa5330af/attachment.html>

From g.lemaitre58 at gmail.com  Mon Nov  3 16:38:36 2014
From: g.lemaitre58 at gmail.com (=?UTF-8?Q?Guillaume_Lema=C3=AEtre?=)
Date: Mon, 3 Nov 2014 22:38:36 +0100
Subject: [ITK-users] SimpleITK - Reading different DICOM serie
In-Reply-To: <D91D2989-E817-40FA-BDE7-B3E483FF0D35@mail.nih.gov>
References: <A704C754-782C-4DA9-B23C-FFBC8EA586F3@mail.nih.gov>
 <D91D2989-E817-40FA-BDE7-B3E483FF0D35@mail.nih.gov>
Message-ID: <CACDxx9jJBa=cgrmE871_m994rf4Q9_f3awzpsOGUT+OEBLOLBA@mail.gmail.com>

Hi Dave

I build SimpleITK through anaconda recipe. I check and the versions are:
SimpleITK 0.9.0 and ITK 4.6.1
I will downgrade the build to be able to work. Let me know if I can help to
fix this issue.

Cheers,

On 3 November 2014 22:23, David Chen <dchen at mail.nih.gov> wrote:

> Hi Guillaume
>
> What version of SimpleITK are you running?  I tried your script using the
> current git master, and it doesn?t work for me.  But when I ran it using
> SimpleITK 0.8.0 it does.  So clearing something has gone wrong that we have
> to figure out.  For now, try and use 0.8.0.
>
>
> Cheers,
> Dave
>
>
> *From: *Guillaume Lema?tre <g.lemaitre58 at gmail.com>
> *Subject: **[ITK-users] SimpleITK - Reading different DICOM serie*
> *Date: *October 31, 2014 at 7:03:36 PM EDT
> *To: *"insight-users at itk.org" <insight-users at itk.org>
>
>
> Hi all,
>
> I am currently using SimpleITK with python to read directly some DICOM
> data.
> My dataset is corresponding to an MRI modality composed of 40 series. Each
> serie is a 3D volume.
>
> I would like to read the serie one-by-one. As a minimal example, I can
> post the following code:
>
> reader = sitk.ImageSeriesReader()
> # For each serie found
> for serie in reader.GetGDCMSeriesIDs(path_to_data):
>     # Get the dicom filename corresponding to the current serie
>     dicom_names = reader.GetGDCMSeriesFileNames(path_to_data, serie)
>     reader.SetFileNames(dicom_names)
>     image = reader.Execute()
>
> I got the following error:
>
> WARNING: In
> /home/lemaitre/anaconda/conda-bld/work/build/ITK/Modules/IO/GDCM/src/itkGDCMSeriesFileNames.cxx,
> line 138
> GDCMSeriesFileNames (0x3078840): No Series were found
>
> However, the output of reader.GetGDCMSeriesIDs(path_to_data) seems ok:
> ('1.2.826.0.1.3680043.2.1125.1.12083572272639445972057901411530444',
>  ............................ 40 lines ...........................
>  '1.2.826.0.1.3680043.2.1125.1.98804240625293208256969403455867278')
>
> So my question is the following. What is the right way to passing the
> serieID to the GetGDCMSeriesFileNames() function.
>
> Thanks in advance,
>
> Best regards,
> --
>
>
>
>
> *LEMA?TRE GuillaumePhD CandiateMSc Erasmus Mundus ViBOT
> (Vision-roBOTic)MSc Business Innovation and Technology Management*
> g.lemaitre58 at gmail.com
>
>
> *ViCOROB - Computer Vision and Robotic Team*
> Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
> Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59
> http://vicorob.udg.es/
>
> *LE2I - Le Creusot*IUT Le Creusot, Laboratoire LE2I, 12 rue de la
> Fonderie, 71200 Le Creusot
> Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97
> http://le2i.cnrs.fr
> https://sites.google.com/site/glemaitre58/
> Vice - Chairman of A.S.C. Fours UFOLEP
> Chairman of A.S.C. Fours FFC
> Webmaster of http://ascfours.free.fr
>
> _____________________________________
>
> 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.php
>
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>
>
>


-- 




*LEMA?TRE GuillaumePhD CandiateMSc Erasmus Mundus ViBOT (Vision-roBOTic)MSc
Business Innovation and Technology Management*
g.lemaitre58 at gmail.com

*ViCOROB - Computer Vision and Robotic Team*
Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59
http://vicorob.udg.es/

*LE2I - Le Creusot*IUT Le Creusot, Laboratoire LE2I, 12 rue de la Fonderie,
71200 Le Creusot
Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97
http://le2i.cnrs.fr

https://sites.google.com/site/glemaitre58/
Vice - Chairman of A.S.C. Fours UFOLEP
Chairman of A.S.C. Fours FFC
Webmaster of http://ascfours.free.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141103/33dccc34/attachment.html>

From lluna.nova at gmail.com  Mon Nov  3 17:58:40 2014
From: lluna.nova at gmail.com (=?UTF-8?B?UG9sIE1vbnPDsyBQdXJ0w60=?=)
Date: Mon, 3 Nov 2014 23:58:40 +0100
Subject: [ITK-users] Loading a specifing region of an image from disk
In-Reply-To: <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov>
References: <CALAZn4grvcugbkSgJnC=KLYjFYJ=79PDVNQss1+SdYT0U=R0Ww@mail.gmail.com>
 <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov>
Message-ID: <CALAZn4gyB6_yHKWSD83fcy9fvguiNmFk2GEDTgRaYMpYYC995Q@mail.gmail.com>

Hello Bradley,

Thank you for your suggestions! I'm glad somebody is working on tif
streaming :) I answer below:


2014-11-03 21:38 GMT+01:00 Bradley Lowekamp <blowekamp at mail.nih.gov>:

> Hello,
>
> You might find this article useful I wrote on streaming ImageIO [1].
>
>
I've read the article early this afternoon and I found it very good and
encouraging. Specially *"The other difference is that the reader fully
supports streaming and only reads the required region from the file."*

That is exactly what we need. I was just wondering wether it splitted the
volume and took the chunks that intersected with the requested one or if it
really just loaded the requested one. I replicated that code taking out the
processing and just having a reader and a writer, but I didn't know how to
test that indeed it was just loading that requested piece.

So after reading your comments here I think streaming is the way to go. Can
you assert that only the requested region will be read?

>
> > 1.- How to set the RequestedRegion on a writer.
>
> I am not sure what you are wanting to do. Are you wanting to extract a
> region from the input file and write a partial sub image?
>
> There are two modes for the writer to drive this. 1) streaming - the
> sequential writing of sub-region of the whole image 2) pasting - updating a
> sub-region of an existing image file.
>
>
I didn't expect that some would support reading but not writing. Actually
it's not mandatory for what we intend to do:

implifying, we have a huge image that we can't (and won't) load to disk.
Fortunatelly we are only interested in some specific chunks of it. So we
need to find a way to read those chunks, compute a simple operation and
then we can discard them. I wanted to write to check that indeed we were
retrieving the ROI and not the full image. We can't afford the reader to
read the whole image. We don't want to process the full image.

>
> > 2.- Will the pipeline only load the requested region, including the
> reader?
>
> The pipeline has a series of steps which include propagating a requested
> region, and giving each filter the opportunity to enlarge this region. I
> have frequently assemble pipelines which perform out-of-core processing as
> you desire. However all filters in the pipeline must support streaming, and
> not enlarging the requested region to the largest possible region.
>
>
Yes, I've seen that not many support streaming. But in our case we would
just need a reader that can read a specific region.


> Additionally the ImageIO for the reader and writer must also support
> streaming. There are several ImageIO's which support streaming reading
> (MRC,MetaIO, VTK, Nift, JPEG2000, etc), I believe that only MRC, VTK and
> MetaIO  fully support it for writing. So TIFF is currently not there.
>

Yeah, we were thinking on using HDF5, but maybe you have some idea on what
would be best. That's another topic thought.

>
> Recently I have been working on improving the itkTIFFImageIO [2], and have
> performance gains of upto 3-5X from the prior version. However, I haven't
> gotten to adding streaming yet. It's is a back burner project for me to add
> support for stream reading to it, so that may be coming shortly ( this
> poking helps ). However, adding stream and paste writing is not planned.
>
>
Good work! 3-5x! That might be of interest actually for something else we
have. Can we pull your code?


> Let's look at your code.
>
> > I've tried myself but I can't get to write just the requested region.
> >
> > The code:
> >
> > int main( int argc, char* argv[] )
> > {
> >
> >   typedef unsigned char              PixelType;
> >   typedef itk::Image< PixelType, 3 > ImageType;
> >
> >   typedef itk::ImageFileReader< ImageType > ReaderFilterType;
> >   ReaderFilterType::Pointer reader = ReaderFilterType::New();
> >   reader->SetFileName("../data/
> > Madrid_Train.tif");
> >   ImageType::RegionType largest =
> reader->GetOutput()->GetLargestPossibleRegion();
> >   ImageType::SizeType size   = largest.GetSize();
> >   ImageType::IndexType index = largest.GetIndex();
> >
> >   ImageType::RegionType half;
> >   half.SetIndex(0,index[0] + 0.25*size[0]);
> >   half.SetIndex(1,index[1] + 0.25*size[1]);
> >   half.SetIndex(2,index[2] + 0.25*size[2]);
> >
> >   half.SetSize(0,0.5*size[0]);
> >   half.SetSize(1,0.5*size[1]);
> >   half.SetSize(2,0.5*size[2]);
> >
> >   typedef itk::ImageFileWriter< ImageType > WriterFilterType;
> >   WriterFilterType::Pointer writer = WriterFilterType::New();
> >   writer->SetFileName("image.tif");
> >   reader->GetOutput()->SetRequestedRegion(half);
> >   writer->SetInput(reader->GetOutput());
> >
> >   try
> >     {
> >     //streamingFilter->Update();
> >     writer->Update();
> >     }
> >   catch( itk::ExceptionObject & error )
> >     {
> >     std::cerr << "Error: " << error << std::endl;
> >     return EXIT_FAILURE;
> >     }
>
> Unfortunately this is not the way the pipeline works. The reader does not
> actually read and update the image until the pipeline is updated. I would
> recommend additional reading about how a pipeline architecture works,
> perhaps from the ITK software guide or an VTK book.
>
> For this case you should add in an ExtractImageFilter, or a
> CropImageFilter.
>
>
But if I use Extract or Crop, the reader is still loading the full image to
disk, isn't it?


> Brad
>
> Thank you for the article, I'll reproduce and let you know how it went.
>



> [1] http://www.kitware.com/media/html/IOStreamingInITK.html
> [2]
> https://github.com/InsightSoftwareConsortium/ITK/commits/master/Modules/IO/TIFF
> [3]
> http://www.itk.org/Doxygen/html/IO_2VisibleHumanStreamReadWrite_8cxx-example.html
>
>
> On Nov 3, 2014, at 2:06 PM, Pol Mons? Purt? <lluna.nova at gmail.com> wrote:
>
> > Hello everyone.
> >
> > Two simple questions:
> >
> >
> > By reading the itksoftware manual, section 8.3 Streaming Large Data it
> looks like by default reader filters only load the requested region.
> >
> > We want to extract a specific region of a large 3D tiff image that does
> not fit in memory. This has to be as fast as possible.
> >
> > I've taken a look at streaming, althought it's not exactly what we want
> since we don't want to process the full image.
> >
> >   return EXIT_SUCCESS;
> > }
> > _____________________________________
> > 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.php
> >
> > 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://public.kitware.com/mailman/listinfo/insight-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141103/9d7df4f0/attachment.html>

From lefebvre at imnc.in2p3.fr  Tue Nov  4 09:17:20 2014
From: lefebvre at imnc.in2p3.fr (=?UTF-8?B?RnJhbsOnb2lzZSBMZWZlYnZyZQ==?=)
Date: Tue, 04 Nov 2014 15:17:20 +0100
Subject: [ITK-users] [ITK] Error compiling msvc2010 + ITK4.6 + Qt
In-Reply-To: <CAMAf15NRMkodau4DPonONrFB2ho2q8UOp_JbXfjt0ef3MsPKqQ@mail.gmail.com>
References: <5446873A.7070500@imnc.in2p3.fr>
 <930E7D31-ACFE-4ECF-8EAD-E8D3B6081B92@mail.nih.gov>
 <54475B84.5020906@imnc.in2p3.fr> <54492AB3.2030006@imnc.in2p3.fr>
 <CALzTN-SFe3MOqJ9DYOyvWkdjG1PcgcXE9p_TtN6cOgXUZt2BUg@mail.gmail.com>
 <544A073B.4080905@imnc.in2p3.fr>
 <CALzTN-SCiw9zYULhhZx2BpGR45Rt3PBvXb6Qq2YMY8zqJZpiug@mail.gmail.com>
 <CAMAf15PvLr1_TENtygmv-4b3PT3B1deXPpgRJ20VBVRRevhvnQ@mail.gmail.com>
 <CAMAf15NRMkodau4DPonONrFB2ho2q8UOp_JbXfjt0ef3MsPKqQ@mail.gmail.com>
Message-ID: <5458DFF0.3010307@imnc.in2p3.fr>

Hi,

It works, thank you very much Roger.

Fran?oise

Le 03/11/2014 11:13, Roger Bramon Feixas a ?crit :
> Dear all,
>
> I solved the problem. Shell32.lib system library needs to be added to 
> qmake LIBS variable because it includes CommandLineToArgvW function. I 
> think it is required since 4.6.0 which includes commit 
> http://itk.org/gitweb?p=ITK.git;a=commit;h=f29c354194e45dcb12d4d0b8765f0c3a9deeab78 
>
>
> HTH,
>
> Roger
>
> On Fri, Oct 31, 2014 at 6:55 PM, Roger Bramon Feixas 
> <rogerbramon at gmail.com <mailto:rogerbramon at gmail.com>> wrote:
>
>     Hi,
>
>     I also have this link problem trying to build using
>     msvc2013_opengl + ITK 4.6.1 + VTK 6.1 + GDCM 2.4.4 + Qt 5.3.2. We
>     are using qmake as well.
>
>     Any suggestion will be appreciated.
>
>     Many thanks,
>
>     Roger
>
>     On Fri, Oct 24, 2014 at 4:57 PM, Matt McCormick
>     <matt.mccormick at kitware.com <mailto:matt.mccormick at kitware.com>>
>     wrote:
>
>         Hi Fran?oise,
>
>
>         CMake is recommended -- it will avoid this problem and others.  It
>         works well with Qt.
>
>         Thanks,
>         Matt
>
>         On Fri, Oct 24, 2014 at 4:00 AM, Fran?oise Lefebvre
>         <lefebvre at imnc.in2p3.fr <mailto:lefebvre at imnc.in2p3.fr>> wrote:
>         >
>         > No, I'm not.  I have always used a .pro file and qmake.
>         >
>         > Le 23/10/2014 23:37, Matt McCormick a ?crit :
>         >
>         >> Hi,
>         >>
>         >> Are you using CMake to configure your project?
>         >>
>         >> Matt
>         >>
>         >> On Thu, Oct 23, 2014 at 12:20 PM, Fran?oise Lefebvre
>         >> <lefebvre at imnc.in2p3.fr <mailto:lefebvre at imnc.in2p3.fr>> wrote:
>         >>>
>         >>> Hi,
>         >>>
>         >>> I also tried on Windows 8,msvc2012_opengl and Qt5.3. I get
>         exactly the
>         >>> same
>         >>> link error.
>         >>>
>         >>> FL
>         >>>
>         >>>
>         >>> Le 22/10/2014 09:23, Fran?oise Lefebvre a ?crit :
>         >>>
>         >>>> Yes I did.
>         >>>>
>         >>>> Le 21/10/2014 19:18, Bradley Lowekamp a ?crit :
>         >>>>>
>         >>>>> Did you try the latest 4.6.1 release?
>         >>>>>
>         >>>>> Brad
>         >>>>>
>         >>>>> On Oct 21, 2014, at 12:18 PM, Fran?oise Lefebvre
>         >>>>> <lefebvre at imnc.in2p3.fr <mailto:lefebvre at imnc.in2p3.fr>>
>         >>>>> wrote:
>         >>>>>
>         >>>>>> Hi,
>         >>>>>>
>         >>>>>> ITK 4.6 was succesfully build using cmake2.8.10.2, the
>         default
>         >>>>>> parameters and the Module_ITKReview on.
>         >>>>>>
>         >>>>>> I am now trying to compile a program developed in C++
>         using Qt5.1.1
>         >>>>>> and
>         >>>>>> Microsoft Visual C++ express 2010 on Windows 7.
>         >>>>>>
>         >>>>>> I get the following link error :
>         >>>>>>
>         >>>>>> 1>itksys-4.6.lib(EncodingCXX.obj) : error LNK2019:
>         symbole externe non
>         >>>>>> r?solu __imp__CommandLineToArgvW at 8 r?f?renc? dans la
>         fonction "public:
>         >>>>>> static class itksys::Encoding::CommandLineArguments __cdecl
>         >>>>>> itksys::Encoding::CommandLineArguments::Main(int,char
>         const * const
>         >>>>>> *)"
>         >>>>>>
>         (?Main at CommandLineArguments@Encoding at itksys@@SA?AV123 at HPBQBD@Z)
>         >>>>>>
>         >>>>>> I didn't get this error when compiling with itk4.3 .
>         >>>>>>
>         >>>>>> Any hint ?
>         >>>>>>
>         >>>>>> Thank you for your help,
>         >>>>>>
>         >>>>>> F. Lefebvre
>         >>>>>>
>         >>>>>> _____________________________________
>         >>>>>> Powered by www.kitware.com <http://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.php
>         >>>>>>
>         >>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>         >>>>>> _______________________________________________
>         >>>>>> Community mailing list
>         >>>>>> Community at itk.org <mailto:Community at itk.org>
>         >>>>>> http://public.kitware.com/mailman/listinfo/community
>         >>>>
>         >>>>
>         >>> _____________________________________
>         >>> Powered by www.kitware.com <http://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.php
>         >>>
>         >>> 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://public.kitware.com/mailman/listinfo/insight-users
>         >
>         >
>         > --
>         > Fran?oise LEFEBVRE
>         > IMNC (Imagerie et Mod?lisation en Neurobiologie et Canc?rologie)
>         > Campus d'Orsay - B?t 440
>         > 91405 ORSAY Cedex
>         > 01 69 15 51 87
>         >
>         _____________________________________
>         Powered by www.kitware.com <http://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.php
>
>         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://public.kitware.com/mailman/listinfo/insight-users
>
>
>

-- 
Fran?oise LEFEBVRE
IMNC (Imagerie et Mod?lisation en Neurobiologie et Canc?rologie)
Campus d'Orsay - B?t 440
91405 ORSAY Cedex
01 69 15 51 87

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141104/7229bd35/attachment.html>

From blowekamp at mail.nih.gov  Tue Nov  4 09:31:39 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 4 Nov 2014 09:31:39 -0500
Subject: [ITK-users] Loading a specifing region of an image from disk
In-Reply-To: <CALAZn4gyB6_yHKWSD83fcy9fvguiNmFk2GEDTgRaYMpYYC995Q@mail.gmail.com>
References: <CALAZn4grvcugbkSgJnC=KLYjFYJ=79PDVNQss1+SdYT0U=R0Ww@mail.gmail.com>
 <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov>
 <CALAZn4gyB6_yHKWSD83fcy9fvguiNmFk2GEDTgRaYMpYYC995Q@mail.gmail.com>
Message-ID: <A3D51948-302C-4FEC-98A0-C26897DBE7A5@mail.nih.gov>

Discussion inline below:

On Nov 3, 2014, at 5:58 PM, Pol Mons? Purt? <lluna.nova at gmail.com> wrote:

> I've read the article early this afternoon and I found it very good and encouraging. Specially "The other difference is that the reader fully supports streaming and only reads the required region from the file."
>  
> That is exactly what we need. I was just wondering wether it splitted the volume and took the chunks that intersected with the requested one or if it really just loaded the requested one. I replicated that code taking out the processing and just having a reader and a writer, but I didn't know how to test that indeed it was just loading that requested piece.

For the ImageIO file formats I wrote which are just headers with binary data, they can read an arbitrary ImageIORegion and don't read any more. Practically however, its extremely in efficient to not read complete contiguous scanlines as there is to much random access and it slows down. For Tiff ( similar to some JPEG2000 formats), the image is encoded as strips or tiles. The underlying libtiff library can only easily decode these entire chunks, so the plan is that the requested region will be expanded by the image io to the union of the strips/tiles needed to read the requested region.
> 
> 
> > 2.- Will the pipeline only load the requested region, including the reader?
> 
> The pipeline has a series of steps which include propagating a requested region, and giving each filter the opportunity to enlarge this region. I have frequently assemble pipelines which perform out-of-core processing as you desire. However all filters in the pipeline must support streaming, and not enlarging the requested region to the largest possible region.
> 
> 
> Yes, I've seen that not many support streaming. But in our case we would just need a reader that can read a specific region. 
>  
> Additionally the ImageIO for the reader and writer must also support streaming. There are several ImageIO's which support streaming reading (MRC,MetaIO, VTK, Nift, JPEG2000, etc), I believe that only MRC, VTK and MetaIO  fully support it for writing. So TIFF is currently not there.
> 
> Yeah, we were thinking on using HDF5, but maybe you have some idea on what would be best. That's another topic thought.

I find the the header + raw image data are rather efficient for random access of the whole image. These files are archived with compression, and decompressed when needed. 

> 
> Recently I have been working on improving the itkTIFFImageIO [2], and have performance gains of upto 3-5X from the prior version. However, I haven't gotten to adding streaming yet. It's is a back burner project for me to add support for stream reading to it, so that may be coming shortly ( this poking helps ). However, adding stream and paste writing is not planned.
> 
> 
> Good work! 3-5x! That might be of interest actually for something else we have. Can we pull your code?

Its in ITK master please test :)
> 
> For this case you should add in an ExtractImageFilter, or a CropImageFilter.
> 
> 
> But if I use Extract or Crop, the reader is still loading the full image to disk, isn't it?

Nope. The only the sub-region is requested to the reader, and if the reader supports streaming that region will be read.

I'd suggest reading section 13.3 of the ITK Software guide a couple times. And then assemble the pipeline Reader->Extract, and printing the output of each filter for each step in Extract->UpdateOutputInformation(), Extract->PropagateRequestedRegion() and then Extract->UpdateOutputData(). This will help you to under stand the step in the pipeline execution.

Brad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141104/ecb94c4e/attachment.html>

From noreply at insightsoftwareconsortium.org  Tue Nov  4 11:27:09 2014
From: noreply at insightsoftwareconsortium.org (MIDAS Journal)
Date: Tue,  4 Nov 2014 11:27:09 -0500 (EST)
Subject: [ITK-users] New Submission: A novel atlas-selection approach for
	multi-atlas based segmentation using the correlation of
	inter-atlas similarities
Message-ID: <20141104162709.5E1E43D6C331@insightsoftwareconsortium.org>

Hello,

A new submission has been added to the MIDAS Journal.

Title: A novel atlas-selection approach for multi-atlas based segmentation using the correlation of inter-atlas similarities
Authors: Raudaschl P., Fritscher K., Zaffino P., Sharp G., Spadea M., Schubert R.
Abstract: Automated segmentation is a frequently applied task in the course of medical imaging. Furthermore, it is a substantial component of image-guided radiotherapy. Atlas based segmentation is one of the most frequently used approach for automated segmentation. Especially for multi-atlas based segmentation, segmentation quality and speed largely depends on the underlying registration and atlas selection strategy. In this work an atlas selection strategy that is based on the correlation of inter-atlas similarities within a set of atlas images is presented. Segmentation quality is analyzed by calculating dice coefficients and 95% Hausdorff distances for the left and right parotid with respect to different numbers of atlases. Results are compared to other state of the art atlas selection strategies. It can be shown that the developed atlas selection technique performs slightly better than NMI-based selection if a low number of atlases is used.

Download and review this publication at: http://hdl.handle.net/10380/3501

Generated by the MIDAS Journal

You are receiving this email because you asked to be informed by the MIDAS Journal for new submissions. To change your email preference visit http://www.midasjournal.org/ .

From noreply at insightsoftwareconsortium.org  Tue Nov  4 11:27:39 2014
From: noreply at insightsoftwareconsortium.org (MIDAS Journal)
Date: Tue,  4 Nov 2014 11:27:39 -0500 (EST)
Subject: [ITK-users] New Submission: Multimodal Analysis of Vasogenic Edema
	in Glioblastoma Patients for Radiotherapy Planning
Message-ID: <20141104162739.87FF33D6C3BC@insightsoftwareconsortium.org>

Hello,

A new submission has been added to the MIDAS Journal.

Title: Multimodal Analysis of Vasogenic Edema in Glioblastoma Patients for Radiotherapy Planning
Authors: L?? M., Delingette H., Kalpathy-Cramer J., Gerstner E., Shih H., Batchelor T., Unkelbach J., Ayache N.
Abstract: Glioblastoma (GBM) is the most common type of primary
brain tumor, which is characterized by an infiltrative growth pattern.
In current practice, radiotherapy planning is primarily based upon T2
FLAIR MRI despite its known lack of specificity in the detection of tu-
mor infiltration. While hyperintensity on T2 FLAIR is widely considered
to represent infiltrative tumor, it may also be caused by the presence
of vasogenic edema (VE), caused by a leakage of fluid into the brain
parenchyma. Distinguishing VE from infiltrative tumor could have im-
pact on improving radiotherapy planning. In this paper we study a data
set of 17 GBM patients treated with anti-angiogenic therapy for which
a fast decrease of T2 FLAIR hypersignal is observed, which indicates
the resolution of VE. We investigate if multimodal MRI acquisitions in-
cluding diffusion tensor imaging can distinguish between VE and tumor
infiltration prior to therapy. Using a random forest classifier, we show
that, in this study, morphological information based on the contrast en-
hanced T1 image explains up to 75% of the extent of VE. The information
from different imaging modalities did not significantly improve the clas-
sification. We then show that delineating the VE prior to therapy can
have substantial impact on radiotherapy target delineation, leading to
smaller treatment volumes and reducing potentially harmful radiation
dose to normal brain tissue.


Download and review this publication at: http://hdl.handle.net/10380/3500

Generated by the MIDAS Journal

You are receiving this email because you asked to be informed by the MIDAS Journal for new submissions. To change your email preference visit http://www.midasjournal.org/ .

From lluna.nova at gmail.com  Tue Nov  4 12:34:37 2014
From: lluna.nova at gmail.com (=?UTF-8?B?UG9sIE1vbnPDsyBQdXJ0w60=?=)
Date: Tue, 4 Nov 2014 18:34:37 +0100
Subject: [ITK-users] Loading a specifing region of an image from disk
In-Reply-To: <A3D51948-302C-4FEC-98A0-C26897DBE7A5@mail.nih.gov>
References: <CALAZn4grvcugbkSgJnC=KLYjFYJ=79PDVNQss1+SdYT0U=R0Ww@mail.gmail.com>
 <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov>
 <CALAZn4gyB6_yHKWSD83fcy9fvguiNmFk2GEDTgRaYMpYYC995Q@mail.gmail.com>
 <A3D51948-302C-4FEC-98A0-C26897DBE7A5@mail.nih.gov>
Message-ID: <CALAZn4h6jRHLqSXbM4QNDgskPExdq4qAOq-W8UJcxPREBvZs7A@mail.gmail.com>

2014-11-04 15:31 GMT+01:00 Bradley Lowekamp <blowekamp at mail.nih.gov>:

> Discussion inline below:
>
> On Nov 3, 2014, at 5:58 PM, Pol Mons? Purt? <lluna.nova at gmail.com> wrote:
>
> I've read the article early this afternoon and I found it very good and
> encouraging. Specially *"The other difference is that the reader fully
> supports streaming and only reads the required region from the file."*
>
> That is exactly what we need. I was just wondering wether it splitted the
> volume and took the chunks that intersected with the requested one or if it
> really just loaded the requested one. I replicated that code taking out the
> processing and just having a reader and a writer, but I didn't know how to
> test that indeed it was just loading that requested piece.
>
>
> For the ImageIO file formats I wrote which are just headers with binary
> data, they can read an arbitrary ImageIORegion and don't read any more.
> Practically however, its extremely in efficient to not read complete
> contiguous scanlines as there is to much random access and it slows down.
> For Tiff ( similar to some JPEG2000 formats), the image is encoded as
> strips or tiles. The underlying libtiff library can only easily decode
> these entire chunks, so the plan is that the requested region will be
> expanded by the image io to the union of the strips/tiles needed to read
> the requested region.
>
>
>
>> > 2.- Will the pipeline only load the requested region, including the
>> reader?
>>
>> The pipeline has a series of steps which include propagating a requested
>> region, and giving each filter the opportunity to enlarge this region. I
>> have frequently assemble pipelines which perform out-of-core processing as
>> you desire. However all filters in the pipeline must support streaming, and
>> not enlarging the requested region to the largest possible region.
>>
>>
> Yes, I've seen that not many support streaming. But in our case we would
> just need a reader that can read a specific region.
>
>
>> Additionally the ImageIO for the reader and writer must also support
>> streaming. There are several ImageIO's which support streaming reading
>> (MRC,MetaIO, VTK, Nift, JPEG2000, etc), I believe that only MRC, VTK and
>> MetaIO  fully support it for writing. So TIFF is currently not there.
>>
>
> Yeah, we were thinking on using HDF5, but maybe you have some idea on what
> would be best. That's another topic thought.
>
>
> I find the the header + raw image data are rather efficient for random
> access of the whole image. These files are archived with compression, and
> decompressed when needed.
>

Yes indeed.


>
>
>> Recently I have been working on improving the itkTIFFImageIO [2], and
>> have performance gains of upto 3-5X from the prior version. However, I
>> haven't gotten to adding streaming yet. It's is a back burner project for
>> me to add support for stream reading to it, so that may be coming shortly (
>> this poking helps ). However, adding stream and paste writing is not
>> planned.
>>
>>
> Good work! 3-5x! That might be of interest actually for something else we
> have. Can we pull your code?
>
>
> Its in ITK master please test :)
>

Will do.


>
>> For this case you should add in an ExtractImageFilter, or a
>> CropImageFilter.
>>
>>
> But if I use Extract or Crop, the reader is still loading the full image
> to disk, isn't it?
>
>
> Nope. The only the sub-region is requested to the reader, and if the
> reader supports streaming that region will be read.
>
> I'd suggest reading section 13.3 of the ITK Software guide a couple times.
> And then assemble the pipeline Reader->Extract, and printing the output of
> each filter for each step in Extract->UpdateOutputInformation(),
> Extract->PropagateRequestedRegion() and then Extract->UpdateOutputData().
> This will help you to under stand the step in the pipeline execution.
>
>
So do readers (hdf5 for example) transparently do streaming? Or do I have
to set the reader imageIO so that it know that it has to stream?

Section 13.3? There are 9 sections, which one do you refer to? I think I
get what you mean and I'll split up the process to undrstand it better as
you suggest.

Meanwhile, below I paste a piece of code more close to what we would like
to do. The code results in exception because the ImageIO starts at index
[0,0,0] while piece1 starts at 51,80,5 and therefore the Extract fails. I
didn't understand how to set the index on a ImageIO. Then I saw that in
your article you put the whole ImageIO and then you just select one slice
with coronalSlice (which would be my piece1/2). I tried that too, although
I wonder what's the difference with not specifying ImageIO and read
normally. setting imageio1/2 to the full image failes on the reader, saying
that it expected  24300094 bytes (that's the size of the image, so it's
trying to load all I guess), but read 411866 bytes.

How can I do this right? And how would the code change if I were to use
HDF5?

the code:

int main( int argc, char* argv[] )
{

   const unsigned int Dimension = 3;

  typedef unsigned char              PixelType;
  typedef itk::Image< PixelType, Dimension > ImageType;

  typedef itk::ImageFileReader< ImageType > ReaderFilterType;
  ReaderFilterType::Pointer reader1 = ReaderFilterType::New();
  reader1->SetFileName("../data/image.raw");

  //size is not known until we load the image
//  ImageType::RegionType largest =
reader1->GetOutput()->GetLargestPossibleRegion();
//  ImageType::SizeType size   = largest.GetSize();
//  ImageType::IndexType index = largest.GetIndex();

  ImageType::IndexType start;
  start.Fill(0);

  ImageType::SizeType size;
  size[0] = 511;
  size[1] = 806;
  size[2] = 59;

  ImageType::RegionType largest(start,size);

  ReaderFilterType::Pointer reader2 = ReaderFilterType::New();
  reader2->SetFileName("../data/image.raw");

  ImageType::RegionType piece1;
  piece1.SetIndex(0,start[0] + 0.1*size[0]);
  piece1.SetIndex(1,start[1] + 0.1*size[1]);
  piece1.SetIndex(2,start[2] + 0.1*size[2]);

  piece1.SetSize(0,0.1*size[0]);
  piece1.SetSize(1,0.1*size[1]);
  piece1.SetSize(2,0.1*size[2]);

  ImageType::RegionType piece2;
  piece2.SetIndex(0,start[0] + 0.5*size[0]);
  piece2.SetIndex(1,start[1] + 0.5*size[1]);
  piece2.SetIndex(2,start[2] + 0.5*size[2]);

  piece2.SetSize(piece1.GetSize());

  std::cout << "largest: " << largest << std::endl;
  std::cout << "piece1: "  << piece1  << std::endl;
  std::cout << "piece2: "  << piece2  << std::endl;

  typedef itk::RawImageIO <PixelType, Dimension> ImageIOType;
  ImageIOType::Pointer imageio1 = ImageIOType::New();
  ImageIOType::Pointer imageio2 = ImageIOType::New();

  imageio1->SetDimensions(0,piece1.GetSize()[0]);
  imageio1->SetDimensions(1,piece1.GetSize()[1]);
  imageio1->SetDimensions(2,piece1.GetSize()[2]);


imageio1->SetHeaderSize(piece1.GetSize()[0]*piece1.GetSize()[1]*piece1.GetSize()[2]);

  imageio2->SetDimensions(0,piece2.GetSize()[0]);
  imageio2->SetDimensions(1,piece2.GetSize()[1]);
  imageio2->SetDimensions(2,piece2.GetSize()[2]);


imageio2->SetHeaderSize(piece2.GetSize()[0]*piece2.GetSize()[1]*piece2.GetSize()[2]);

  reader1->SetImageIO(imageio1);
  reader2->SetImageIO(imageio2);

  //this should now work
  reader1->UpdateOutputInformation();
  reader2->UpdateOutputInformation();

  std::cout << "reader largest " <<
reader1->GetOutput()->GetLargestPossibleRegion() << std::endl;

  typedef itk::ExtractImageFilter< ImageType, ImageType > ExtractFilterType;
  ExtractFilterType::Pointer extract1 = ExtractFilterType::New();
  ExtractFilterType::Pointer extract2 = ExtractFilterType::New();
  extract1->SetExtractionRegion(piece1);
  extract2->SetExtractionRegion(piece2);
  extract1->SetInput(reader1->GetOutput());
  extract2->SetInput(reader2->GetOutput());
#if ITK_VERSION_MAJOR >= 4
  extract1->SetDirectionCollapseToIdentity();
  extract2->SetDirectionCollapseToIdentity();
#endif

  try
  {
      extract1->Update();
      extract2->Update();
  }
  catch( itk::ExceptionObject & error )
  {
      std::cerr << "Extract error: " << error << std::endl;
      return EXIT_FAILURE;
  }

  typedef itk::SubtractImageFilter <ImageType, ImageType >
     SubtractImageFilterType;

   SubtractImageFilterType::Pointer subtractFilter
     = SubtractImageFilterType::New ();
   subtractFilter->SetInput1(extract1->GetOutput());
   subtractFilter->SetInput2(extract2->GetOutput());


  typedef itk::ImageFileWriter< ImageType > WriterFilterType;
  WriterFilterType::Pointer writer = WriterFilterType::New();
  writer->SetFileName("image_out.raw");
  writer->SetInput(subtractFilter->GetOutput());

  try
    {
    writer->Update();
    }
  catch( itk::ExceptionObject & error )
    {
    std::cerr << "Error: " << error << std::endl;
    return EXIT_FAILURE;
    }

  return EXIT_SUCCESS;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141104/7d61f278/attachment.html>

From g.lemaitre58 at gmail.com  Wed Nov  5 04:25:20 2014
From: g.lemaitre58 at gmail.com (=?UTF-8?Q?Guillaume_Lema=C3=AEtre?=)
Date: Wed, 5 Nov 2014 10:25:20 +0100
Subject: [ITK-users] SimpleITK - Reading different DICOM serie
In-Reply-To: <CACDxx9jJBa=cgrmE871_m994rf4Q9_f3awzpsOGUT+OEBLOLBA@mail.gmail.com>
References: <A704C754-782C-4DA9-B23C-FFBC8EA586F3@mail.nih.gov>
 <D91D2989-E817-40FA-BDE7-B3E483FF0D35@mail.nih.gov>
 <CACDxx9jJBa=cgrmE871_m994rf4Q9_f3awzpsOGUT+OEBLOLBA@mail.gmail.com>
Message-ID: <CACDxx9gdwbj8ThDx46XVmqsDZZGaEGfeNTG9QAY1dXYaS1n1GQ@mail.gmail.com>

Hi all,

I build again the SimpleITK using the tag v0.8.0 from the git. Making the
same experiment, I do not get the same error of serie not found.
However, I have an issue as problematic since that whatever the serie ID
passed as argument, the dicom_names return belong to the first ID serie.

Did anybody got the issue with 0.8.0 build?

Cheers,

On 3 November 2014 22:38, Guillaume Lema?tre <g.lemaitre58 at gmail.com> wrote:

> Hi Dave
>
> I build SimpleITK through anaconda recipe. I check and the versions are:
> SimpleITK 0.9.0 and ITK 4.6.1
> I will downgrade the build to be able to work. Let me know if I can help
> to fix this issue.
>
> Cheers,
>
> On 3 November 2014 22:23, David Chen <dchen at mail.nih.gov> wrote:
>
>> Hi Guillaume
>>
>> What version of SimpleITK are you running?  I tried your script using the
>> current git master, and it doesn?t work for me.  But when I ran it using
>> SimpleITK 0.8.0 it does.  So clearing something has gone wrong that we have
>> to figure out.  For now, try and use 0.8.0.
>>
>>
>> Cheers,
>> Dave
>>
>>
>> *From: *Guillaume Lema?tre <g.lemaitre58 at gmail.com>
>> *Subject: **[ITK-users] SimpleITK - Reading different DICOM serie*
>> *Date: *October 31, 2014 at 7:03:36 PM EDT
>> *To: *"insight-users at itk.org" <insight-users at itk.org>
>>
>>
>> Hi all,
>>
>> I am currently using SimpleITK with python to read directly some DICOM
>> data.
>> My dataset is corresponding to an MRI modality composed of 40 series.
>> Each serie is a 3D volume.
>>
>> I would like to read the serie one-by-one. As a minimal example, I can
>> post the following code:
>>
>> reader = sitk.ImageSeriesReader()
>> # For each serie found
>> for serie in reader.GetGDCMSeriesIDs(path_to_data):
>>     # Get the dicom filename corresponding to the current serie
>>     dicom_names = reader.GetGDCMSeriesFileNames(path_to_data, serie)
>>     reader.SetFileNames(dicom_names)
>>     image = reader.Execute()
>>
>> I got the following error:
>>
>> WARNING: In
>> /home/lemaitre/anaconda/conda-bld/work/build/ITK/Modules/IO/GDCM/src/itkGDCMSeriesFileNames.cxx,
>> line 138
>> GDCMSeriesFileNames (0x3078840): No Series were found
>>
>> However, the output of reader.GetGDCMSeriesIDs(path_to_data) seems ok:
>> ('1.2.826.0.1.3680043.2.1125.1.12083572272639445972057901411530444',
>>  ............................ 40 lines ...........................
>>  '1.2.826.0.1.3680043.2.1125.1.98804240625293208256969403455867278')
>>
>> So my question is the following. What is the right way to passing the
>> serieID to the GetGDCMSeriesFileNames() function.
>>
>> Thanks in advance,
>>
>> Best regards,
>> --
>>
>>
>>
>>
>> *LEMA?TRE GuillaumePhD CandiateMSc Erasmus Mundus ViBOT
>> (Vision-roBOTic)MSc Business Innovation and Technology Management*
>> g.lemaitre58 at gmail.com
>>
>>
>> *ViCOROB - Computer Vision and Robotic Team*
>> Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
>> Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59
>> http://vicorob.udg.es/
>>
>> *LE2I - Le Creusot*IUT Le Creusot, Laboratoire LE2I, 12 rue de la
>> Fonderie, 71200 Le Creusot
>> Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97
>> http://le2i.cnrs.fr
>> https://sites.google.com/site/glemaitre58/
>> Vice - Chairman of A.S.C. Fours UFOLEP
>> Chairman of A.S.C. Fours FFC
>> Webmaster of http://ascfours.free.fr
>>
>> _____________________________________
>>
>> 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.php
>>
>>
>> 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://public.kitware.com/mailman/listinfo/insight-users
>>
>>
>>
>
>
> --
>
>
>
>
> *LEMA?TRE GuillaumePhD CandiateMSc Erasmus Mundus ViBOT
> (Vision-roBOTic)MSc Business Innovation and Technology Management*
> g.lemaitre58 at gmail.com
>
> *ViCOROB - Computer Vision and Robotic Team*
> Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
> Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59
> http://vicorob.udg.es/
>
> *LE2I - Le Creusot*IUT Le Creusot, Laboratoire LE2I, 12 rue de la
> Fonderie, 71200 Le Creusot
> Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97
> http://le2i.cnrs.fr
>
> https://sites.google.com/site/glemaitre58/
> Vice - Chairman of A.S.C. Fours UFOLEP
> Chairman of A.S.C. Fours FFC
> Webmaster of http://ascfours.free.fr
>



-- 




*LEMA?TRE GuillaumePhD CandiateMSc Erasmus Mundus ViBOT (Vision-roBOTic)MSc
Business Innovation and Technology Management*
g.lemaitre58 at gmail.com

*ViCOROB - Computer Vision and Robotic Team*
Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59
http://vicorob.udg.es/

*LE2I - Le Creusot*IUT Le Creusot, Laboratoire LE2I, 12 rue de la Fonderie,
71200 Le Creusot
Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97
http://le2i.cnrs.fr

https://sites.google.com/site/glemaitre58/
Vice - Chairman of A.S.C. Fours UFOLEP
Chairman of A.S.C. Fours FFC
Webmaster of http://ascfours.free.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141105/4f7ab048/attachment.html>

From deratwu at hotmail.de  Wed Nov  5 05:40:14 2014
From: deratwu at hotmail.de (Michael_A)
Date: Wed, 5 Nov 2014 03:40:14 -0700 (MST)
Subject: [ITK-users] Simple Resampling delivers empty image
Message-ID: <1415184014461-34867.post@n7.nabble.com>

Hello people,

i could need your help regarding resampling. I seem to forget something
small, but important, yet just cant find it...

I have 2 NIFTI Images. One has been written by an ITK resampler, the other
was written by the Softeware "VINCI".
I want to do a squared difference of the images (via ITK filter) yet they
are not in the same direction!
One has:
1 0 0
0 1 0
0 0 1

the other has:
-1 0 0
0 -1 0
0 0 1

so i want to resample the image of the one into the others direction. I flip
it via the FLIP-Filter and then
resample it. But the resampled Image is completely empty! Why?
My code is:

int main(int argc, char **argv)
{
  static const unsigned int    ImageDimension = 3;
  typedef  signed short    PixelType;

  typedef itk::Image< PixelType, ImageDimension >  ImageType;
  //
  //   Read the Fixed and Moving images.
  // 
  typedef itk::ImageFileReader< ImageType  > FixedImageReaderType;
  typedef itk::ImageFileReader< ImageType > MovingImageReaderType;

  FixedImageReaderType::Pointer  fixedImageReader  =
FixedImageReaderType::New();
  MovingImageReaderType::Pointer movingImageReader =
MovingImageReaderType::New();

  fixedImageReader->SetFileName(  argv[1] );
  movingImageReader->SetFileName( argv[2] );

  typedef itk::ImageRegistrationMethod< 
                                    ImageType, 
                                    ImageType >    RegistrationType;
  typedef itk::VersorRigid3DTransform< double > RigidTransformType;
  typedef itk:: LinearInterpolateImageFunction< 
                                    ImageType,
                                    double          >    InterpolatorType;				    
  typedef itk::ResampleImageFilter< ImageType, ImageType >   
ResampleFilterType;
  typedef itk::ImageFileWriter< ImageType >  WriterType;
  WriterType::Pointer writer = WriterType::New(); 

  writer->SetFileName( argv[3]);

  InterpolatorType::Pointer   interpolator  = InterpolatorType::New();
  RigidTransformType::Pointer transform = RigidTransformType::New();
  ResampleFilterType::Pointer resample = ResampleFilterType::New();
  
   typedef itk::FlipImageFilter< ImageType > FilterType;
   FilterType::Pointer filter = FilterType::New();

   typedef FilterType::FlipAxesArrayType FlipAxesArrayType;
   FlipAxesArrayType flipArray;

   flipArray[0] = atoi( argv[4] );

   flipArray[1] = atoi( argv[5] );
   
   flipArray[2] = atoi( argv[6] );

   filter->SetFlipAxes( flipArray );
   filter->SetInput(movingImage);
   filter->Update();
   
  resample->SetTransform( transform );
  resample->SetInterpolator(interpolator);
  resample->SetInput( filter->GetOutput() );
  resample->SetSize(   
fixedImageReader->GetOutput()->GetLargestPossibleRegion().GetSize() );
  resample->SetOutputOrigin(  fixedImageReader->GetOutput()->GetOrigin() );
  resample->SetOutputSpacing( fixedImageReader->GetOutput()->GetSpacing() );
  resample->SetOutputDirection(
fixedImageReader->GetOutput()->GetDirection() );
  resample->SetDefaultPixelValue( 0 );

      try
      {
      resample->Update();
      }
    catch( itk::ExceptionObject & err ) 
      { 
      std::cerr << "ExceptionObject caught !" << std::endl; 
      std::cerr << err << std::endl; 
      return EXIT_FAILURE;
      } 
  
  writer->SetInput(resample->GetOutput());

    std::cout << "Writing Resampled Image..." << std::endl;
    try
      {
      writer->Update();
      }
    catch( itk::ExceptionObject & err ) 
      { 
      std::cerr << "ExceptionObject caught !" << std::endl; 
      std::cerr << err << std::endl; 
      return EXIT_FAILURE;
      } 
      
 return EXIT_SUCCESS;
}


Headers are all included of course. Can somebody help me with this?
Thanks in advance,
Michael




--
View this message in context: http://itk-users.7.n7.nabble.com/Simple-Resampling-delivers-empty-image-tp34867.html
Sent from the ITK - Users mailing list archive at Nabble.com.

From noreply at insightsoftwareconsortium.org  Wed Nov  5 12:43:36 2014
From: noreply at insightsoftwareconsortium.org (MIDAS Journal)
Date: Wed,  5 Nov 2014 12:43:36 -0500 (EST)
Subject: [ITK-users] New Submission: Pseudo-CT generation from multiple MR
	images for small animal irradiation
Message-ID: <20141105174336.250763D6C3B6@insightsoftwareconsortium.org>

Hello,

A new submission has been added to the MIDAS Journal.

Title: Pseudo-CT generation from multiple MR images for small animal irradiation
Authors: Gutierrez Diaz S., Van Holen R., Descamps B., Vanhove C.
Abstract: Introduction. Computed tomography (CT) is the standard imaging modality for radiation therapy treatment planning (RTTP) because of its ability to provide information on electron density. However, magnetic resonance (MR) imaging provides superior soft tissue contrast, especially in small animal imaging, facilitating the precise selection of the target volume. This makes the technique interesting for irradiation of brain tumors. The aim of this study was to present an MR-only based workflow for RTTP on a small animal radiation research platform (SARRP) by investigating the potential of probabilistic classification of voxels using multiple MR sequences.
Methods. Six female Fisher rats were anesthetized using isoflurane and individually fixed on an in-house made multimodality bed before starting MR and CT acquisitions. MR measurements were performed on a 7-Tesla system using a rat brain volume coil. Four different MR sequences were acquired for each animal, including a T1-weighted (MDEFT) sequence, a T2-weighted (RARE) sequence, an ultra-short echo time sequence with 20 ??s echo time (UTE1) and an ultra- short echo time sequence with 2 ms echo time (UTE2). UTE offers the opportunity to acquire images from proton-poor structures with very short transverse relaxation times, such as bone, by using a rapid readout of the fast decaying signal. Following MR, the animals were moved to the SARRP to start a cone-beam CT (CB-CT) by acquiring 720 projections over 360??. Cone-beam CT projection data were reconstructed by filtered back-projection to obtain the standard-CT for RTTP. Then the images were bias field corrected and manually co-registe
 red to the CB-CT. After that, images were segmented in three tissue classes (air, soft tissue and bone) with k-means for the CB-CT and fuzzy c-means segmentation algorithm (FCM) for the MR images with multiple MR images as input. The membership probability can be between 0 and 1, with one indicating 100% probability and zero indicating 0% probability to belong to a specific tissue class. To obtain a pseudo-CT image, voxels were assigned to the tissue class having the highest membership probability. The dice coefficient was used to evaluate the correctness of the segmentation for soft-tissue and bone. The pseudo-CT images with the highest similarity index were used for further radiotherapy treatment planning (RTTP), in addition, to the standard UTE1-UTE2. The target of the RTTP that was selected in the primary cortex (M1) and three different beam arrangements were investigated to compare CB-CT and MR-based dose calculations. The dose plans were a single static beam of 3x3 mm, using a
  single arc (3x3 mm beam size, 120?? arc, couch at 0??), and three non-coplanar arcs (3x3 mm beam size, 120?? arc, couch at 0??, 45?? and 90??). Dose distributions were calculated using the TPS of the SARRP and cumulative dose volume histograms (DVHs) of the target and normal brain tissue were obtained for the three dose plans.
Results The highest dice coefficient was obtained for the T1-UTE1-T2 combination, which was used for further RTTP. The contribution of bone to the total dice coefficient did not exceed 27%. However, bone accounts for only 2% of the image, therefore a misclassified bone pixel has a bigger effect in the dice coefficient than a misclassified soft tissue pixel. Using only 1 beam, both MR combinations underestimate the dose to be delivered to the target. When more complex beam configurations were used to irradiate the target, very small differences were observed between CB-CT and MR based dose calculations.

Download and review this publication at: http://hdl.handle.net/10380/3502

Generated by the MIDAS Journal

You are receiving this email because you asked to be informed by the MIDAS Journal for new submissions. To change your email preference visit http://www.midasjournal.org/ .

From joel.schaerer at laposte.net  Thu Nov  6 05:47:49 2014
From: joel.schaerer at laposte.net (=?UTF-8?B?Sm/Dq2wgU2NoYWVyZXI=?=)
Date: Thu, 06 Nov 2014 11:47:49 +0100
Subject: [ITK-users] Mini-pipeline filters don't obey SetNumberOfThreads()
Message-ID: <545B51D5.3040700@laposte.net>

Hi all,

I have noticed that a few filters don't give exactly the same output 
depending on the number of threads they are run with. While this is 
unlikely to change results in a meaningful way, it makes things more 
difficult to test and debug since results vary from machine to machine. 
I unfortunately don't have the time to dig deeper into this, but I know 
that the MattesMutualInformationMetric has this problem, and I suspect 
either the NormalizeImageFilter or the MultiResolutionImagePyramid to 
have it too.

This brings me to the second problem, which is that forcing the number 
of threads on mini-pipeline filters such as the NormalizeImageFilter 
doesn't work. That is, calling normalize_filter->SetNumberOfThreads(1) 
doesn't work as expected. The reason is actually pretty simple: the 
filter simply does not pass the information to the filters inside the 
mini-pipeline. I believe most other mini-pipeline filters will have the 
same problem.

Since the mini-pipeline filters are not accessible from outside the 
class, I am left with using 
itk::MultiThreader::SetGlobalMaximumNumberOfThreads which is of course 
not very satisfactory.

I don't see how to fix the problem without calling SetNumberOfThreads on 
each mini-pipline filter... Hopefully someone will have a better idea!

Joel

From millerjv at gmail.com  Thu Nov  6 07:39:13 2014
From: millerjv at gmail.com (Jim Miller)
Date: Thu, 6 Nov 2014 07:39:13 -0500
Subject: [ITK-users] Mini-pipeline filters don't obey
	SetNumberOfThreads()
In-Reply-To: <545B51D5.3040700@laposte.net>
References: <545B51D5.3040700@laposte.net>
Message-ID: <5B7D995E-4B90-4923-A794-8A2B5E5CB428@gmail.com>

That is a good point. The number of threads should be propagated down to the mini filters. This needs to be handled by the filter developers, much like properly managing the requested regions. 

We will have to think if there is a way to do this in a generic manner that may make it easier for the developer. 

In the interim, if you need to a filter that uses mini pipelines to behave like this while not restricting other filters, you might be able to tap into the start and end methods to manipulate the global number of threads as each of the filters that uses a mini pipeline executes.  

Jim

> On Nov 6, 2014, at 5:47 AM, Jo?l Schaerer <joel.schaerer at laposte.net> wrote:
> 
> This brings me to the second problem, which is that forcing the number of threads on mini-pipeline filters such as the NormalizeImageFilter doesn't work. That is, calling normalize_filter->SetNumberOfThreads(1) doesn't work as expected. The reason is actually pretty simple: the filter simply does not pass the information to the filters inside the mini-pipeline. I believe most other mini-pipeline filters will have the same problem.
> 
> Since the mini-pipeline filters are not accessible from outside the class, I am left with using itk::MultiThreader::SetGlobalMaximumNumberOfThreads which is of course not very satisfactory.
> 
> I don't see how to fix the problem without calling SetNumberOfThreads on each mini-pipline filter... Hopefully someone will have a better idea!

From coconetlero at gmail.com  Thu Nov  6 08:56:03 2014
From: coconetlero at gmail.com (Zian Fanti)
Date: Thu, 6 Nov 2014 14:56:03 +0100
Subject: [ITK-users] Processing Time for ICP
Message-ID: <CAAMPYw3ZDCyOdywLmm5h71u-qUB1rwVD+Mduq1qvqPeYLmXr+w@mail.gmail.com>

I made a variation of the TKv4/IterativeClosestPoint3 example. The
only change consist in that I read the fixed and moving mesh with the
vtkPolyDataReader and then transform to itkMesh with the vtkPolyDataToitkMesh
[1]

I want to know what are the averages times of processing two meshes?

In my computer the processing time for the moving mesh with 17787
nodes and the fixed mesh with 51100 and 100 iteratios, its around of
one and a half hour. It is fine?

My computer running with a:
Intel core i7-3770K at 3.5Ghz
16 GB of ram
Windows 7, 64-bit


[1] https://github.com/InsightSoftwareConsortium/ITKApps/blob/master/DeformableModelSimplexMesh/vtkPolyDataToitkMesh.cxx

Thanks in advance


-- 
Atte:
Zian Fanti Guti?rrez
CLIMBING???
IT'S NOT JUST OUR LIFESTYLE......... iT'S OUR WAY OF LIFE
coconetlero at gmail.com

From blowekamp at mail.nih.gov  Thu Nov  6 09:24:45 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Thu, 6 Nov 2014 09:24:45 -0500
Subject: [ITK-users] Mini-pipeline filters don't obey
	SetNumberOfThreads()
In-Reply-To: <5B7D995E-4B90-4923-A794-8A2B5E5CB428@gmail.com>
References: <545B51D5.3040700@laposte.net>
 <5B7D995E-4B90-4923-A794-8A2B5E5CB428@gmail.com>
Message-ID: <8EF71AE8-EF9E-4E66-A2F1-12073E8E0B9A@mail.nih.gov>

Hello,

This is a case where I am reminded a lot of Qt's hierarchical object ownership. If one filter owns another then certain properties could be inherited.

While SimpleITK's code generation system there is a possible a way to generate tests for most filters to determine if the filters respect the number of threads. This could be an fun project.

However practically, given that almost always only a single pipeline is being executed per process, I have found that setting the ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS environmental variable sufficient as a corse control. Now if one was working on concurrently running multiple pipeline is a single process the file grain control of number of threads per filter would be more important.

Brad

On Nov 6, 2014, at 7:39 AM, Jim Miller <millerjv at gmail.com> wrote:

> That is a good point. The number of threads should be propagated down to the mini filters. This needs to be handled by the filter developers, much like properly managing the requested regions. 
> 
> We will have to think if there is a way to do this in a generic manner that may make it easier for the developer. 
> 
> In the interim, if you need to a filter that uses mini pipelines to behave like this while not restricting other filters, you might be able to tap into the start and end methods to manipulate the global number of threads as each of the filters that uses a mini pipeline executes.  
> 
> Jim
> 
>> On Nov 6, 2014, at 5:47 AM, Jo?l Schaerer <joel.schaerer at laposte.net> wrote:
>> 
>> This brings me to the second problem, which is that forcing the number of threads on mini-pipeline filters such as the NormalizeImageFilter doesn't work. That is, calling normalize_filter->SetNumberOfThreads(1) doesn't work as expected. The reason is actually pretty simple: the filter simply does not pass the information to the filters inside the mini-pipeline. I believe most other mini-pipeline filters will have the same problem.
>> 
>> Since the mini-pipeline filters are not accessible from outside the class, I am left with using itk::MultiThreader::SetGlobalMaximumNumberOfThreads which is of course not very satisfactory.
>> 
>> I don't see how to fix the problem without calling SetNumberOfThreads on each mini-pipline filter... Hopefully someone will have a better idea!
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users


From bill.lorensen at gmail.com  Thu Nov  6 10:55:56 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 6 Nov 2014 10:55:56 -0500
Subject: [ITK-users] Processing Time for ICP
In-Reply-To: <CAAMPYw3ZDCyOdywLmm5h71u-qUB1rwVD+Mduq1qvqPeYLmXr+w@mail.gmail.com>
References: <CAAMPYw3ZDCyOdywLmm5h71u-qUB1rwVD+Mduq1qvqPeYLmXr+w@mail.gmail.com>
Message-ID: <CADZJ4hPp14-rX7ZKT+Xv3oQqj4Yrimwm403gLZht8qhHJqaKEA@mail.gmail.com>

Is this a Debug or Release build. Debug builds on Windows can be an
order of magnitude slower.


On Thu, Nov 6, 2014 at 8:56 AM, Zian Fanti <coconetlero at gmail.com> wrote:
> I made a variation of the TKv4/IterativeClosestPoint3 example. The
> only change consist in that I read the fixed and moving mesh with the
> vtkPolyDataReader and then transform to itkMesh with the vtkPolyDataToitkMesh
> [1]
>
> I want to know what are the averages times of processing two meshes?
>
> In my computer the processing time for the moving mesh with 17787
> nodes and the fixed mesh with 51100 and 100 iteratios, its around of
> one and a half hour. It is fine?
>
> My computer running with a:
> Intel core i7-3770K at 3.5Ghz
> 16 GB of ram
> Windows 7, 64-bit
>
>
> [1] https://github.com/InsightSoftwareConsortium/ITKApps/blob/master/DeformableModelSimplexMesh/vtkPolyDataToitkMesh.cxx
>
> Thanks in advance
>
>
> --
> Atte:
> Zian Fanti Guti?rrez
> CLIMBING???
> IT'S NOT JUST OUR LIFESTYLE......... iT'S OUR WAY OF LIFE
> coconetlero at gmail.com
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users



-- 
Unpaid intern in BillsBasement at noware dot com

From coconetlero at gmail.com  Thu Nov  6 11:17:42 2014
From: coconetlero at gmail.com (Zian Fanti)
Date: Thu, 6 Nov 2014 17:17:42 +0100
Subject: [ITK-users] Processing Time for ICP
In-Reply-To: <CADZJ4hPp14-rX7ZKT+Xv3oQqj4Yrimwm403gLZht8qhHJqaKEA@mail.gmail.com>
References: <CAAMPYw3ZDCyOdywLmm5h71u-qUB1rwVD+Mduq1qvqPeYLmXr+w@mail.gmail.com>
 <CADZJ4hPp14-rX7ZKT+Xv3oQqj4Yrimwm403gLZht8qhHJqaKEA@mail.gmail.com>
Message-ID: <CAAMPYw1YtWQZPij=aFOa=YcuHCqyqpoHHZf7wLytwuChuL4_2Q@mail.gmail.com>

It is a Release build with ITK version 4.5.2



On Thu, Nov 6, 2014 at 4:55 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Is this a Debug or Release build. Debug builds on Windows can be an
> order of magnitude slower.
>
>
> On Thu, Nov 6, 2014 at 8:56 AM, Zian Fanti <coconetlero at gmail.com> wrote:
>> I made a variation of the TKv4/IterativeClosestPoint3 example. The
>> only change consist in that I read the fixed and moving mesh with the
>> vtkPolyDataReader and then transform to itkMesh with the vtkPolyDataToitkMesh
>> [1]
>>
>> I want to know what are the averages times of processing two meshes?
>>
>> In my computer the processing time for the moving mesh with 17787
>> nodes and the fixed mesh with 51100 and 100 iteratios, its around of
>> one and a half hour. It is fine?
>>
>> My computer running with a:
>> Intel core i7-3770K at 3.5Ghz
>> 16 GB of ram
>> Windows 7, 64-bit
>>
>>
>> [1] https://github.com/InsightSoftwareConsortium/ITKApps/blob/master/DeformableModelSimplexMesh/vtkPolyDataToitkMesh.cxx
>>
>> Thanks in advance
>>
>>
>> --
>> Atte:
>> Zian Fanti Guti?rrez
>> CLIMBING???
>> IT'S NOT JUST OUR LIFESTYLE......... iT'S OUR WAY OF LIFE
>> coconetlero at gmail.com
>> _____________________________________
>> 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.php
>>
>> 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://public.kitware.com/mailman/listinfo/insight-users
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com

From arnheim66 at googlemail.com  Fri Nov  7 04:37:50 2014
From: arnheim66 at googlemail.com (Arnheim Blanchr)
Date: Fri, 7 Nov 2014 10:37:50 +0100
Subject: [ITK-users] 3D Noise Power Spectrum ITK
Message-ID: <CALU0xtAsmmiXfj14y7EA+jJNByTsoswY7MoFqpVpT-14DXicYQ@mail.gmail.com>

Hi
I would like to calculate the Noise Power Spectrum of 3D images.
Has anybody done this with ITK and could possibly help?

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141107/6058bab4/attachment.html>

From matt.mccormick at kitware.com  Fri Nov  7 09:15:48 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Fri, 7 Nov 2014 09:15:48 -0500
Subject: [ITK-users] 3D Noise Power Spectrum ITK
In-Reply-To: <CALU0xtAsmmiXfj14y7EA+jJNByTsoswY7MoFqpVpT-14DXicYQ@mail.gmail.com>
References: <CALU0xtAsmmiXfj14y7EA+jJNByTsoswY7MoFqpVpT-14DXicYQ@mail.gmail.com>
Message-ID: <CALzTN-S-uCbQvW65WbouejSPAsQb7gW8GE4GyEPjMn4VW9Q-eQ@mail.gmail.com>

Hi Arnheim,

This is a good example:

  http://itk.org/ITKExamples/src/Filtering/FFT/ComputeImageSpectralDensity/Documentation.html

HTH,
Matt

On Fri, Nov 7, 2014 at 4:37 AM, Arnheim Blanchr
<arnheim66 at googlemail.com> wrote:
> Hi
> I would like to calculate the Noise Power Spectrum of 3D images.
> Has anybody done this with ITK and could possibly help?
>
> Thank you
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>

From Olivier.Commowick at inria.fr  Mon Nov 10 11:28:58 2014
From: Olivier.Commowick at inria.fr (Olivier Commowick)
Date: Mon, 10 Nov 2014 17:28:58 +0100
Subject: [ITK-users] VectorImage vs image of vectors
In-Reply-To: <D07D0372.C69A%norman-k-williams@uiowa.edu>
References: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
 <D07D0372.C69A%norman-k-williams@uiowa.edu>
Message-ID: <69392D76-B649-453C-A1E9-3A79CBA63A39@inria.fr>

Hi,

I finally took some time to test this further using ITK smoothing filters. Here is an example file that illustrates my problem. Running it in some profiler, it appears that the time is truly lost in allocations and freeing elements (variable length vectors, method AllocateElements and free) when browsing elements in a vector image (while this doesn?t happen for images of itk vectors). Looking into it, there is a part of itk vectorimage I didn?t know about which is the accessor classes and functors. 

Would someone have an explanation of the system itself and if it might spend its time creating variable length vectors, or if the problem would come from somewhere else ? Nothing urgent though, I took the second technique in the previous email for my urgent things.

Thanks in advance
Olivier



> On Nov 3, 2014, at 17:18 , Williams, Norman K <norman-k-williams at uiowa.edu> wrote:
> 
> 2 observations:
> 
> 1. I think the redundant SetSize you mentioned is almost certainly
> unnecessary.  I?ve seen similar unnecessary vector/array sizing other
> places in ITK; I think it arose out of an abundance of caution, and just
> never showed up on anyone?s optimization radar yet.
> 
> 2. There?s a technique you can use to get around the
> itk::Image<itk::Vector<TScalar,TVecLength>, TDim> problem, if there is a
> small, finite number of possible vector lengths.  Put the code using the
> vector image inside a function templated over TVecLength.  Then at
> runtime, determine the vector length and invoke the template function with
> that vector length.
> 
> E.G.
> 
> template<typename TScalar,unsigned NVecLength, unsigned NDim>
> void DoSomething()
> {
>  typedef itk::Image< itk::Vector<TScalar, NVecLength>, NDim > ImageType;
>        ...
> }
> 
> int main(int,char *[])
> {
>  ...
>  switch(vecLength)
>  {
>  case 3:
>     DoSomething<double,3,3>();
>     break;
>  case 11:
>     DoSomething<double,11,3>();
>  ?
>  }
> }
> 
> This is of course in most cases bad C++ programming practice, but it does
> allow you to accommodate different data types in a program.
> 
> On 11/3/14, 8:39 AM, "Olivier Commowick" <Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>>
> wrote:
> 
>> Hello all,
>> 
>> I encountered some weird behavior in ITK. For some reason, I have in my
>> code some vector images that I need to smooth using a Gaussian filter. It
>> appears that whether the image is stored as a VectorImage or an Image of
>> itk Vectors is actually extremely important in terms of performance for
>> this task. Namely, if using VectorImages, the processing time can be much
>> worse (30s vs 1s with an image of vectors). My problem is that I cannot
>> really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim >
>> since I do not know Size at compilation time.
>> 
>> Looking deeper into the code, I have two questions for whoever would know
>> about these images:
>> - the first one is on the Variable length vector: it seems to me that the
>> operator= method always starts by destroying current data, even if the
>> vector size is the same. It doesn?t seem really efficient so I was
>> wondering if there was any reason for that
>> - the second one is on the VectorImage itself: is there something in it
>> that would justify the computation times to be much worse ?
>> 
>> If someone has any info on which image type I should be using or why
>> VectorImage would be slower, I would be grateful.
>> 
>> Thanks in advance
>> 
>> ---
>> 
>> Olivier Commowick, Ph.D.
>> Research Scientist
>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>> Campus de Beaulieu
>> 35042 Rennes
>> FRANCE
>> 
>> Phone: +33 2 99 84 25 92
>> Email: Olivier.Commowick at inria.fr
>> Web: http://olivier.commowick.org/
>> 
>> 
>> 
>> 
>> 
>> _____________________________________
>> 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.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-users
> 
> 
> 
> ________________________________
> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
> ________________________________


---

Olivier Commowick, Ph.D.
Research Scientist
INRIA Rennes - Bretagne Atlantique, VISAGES Team
Campus de Beaulieu
35042 Rennes
FRANCE

Phone: +33 2 99 84 25 92
Email: Olivier.Commowick at inria.fr
Web: http://olivier.commowick.org/





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141110/0d4249ef/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smoothingTest.cxx
Type: application/octet-stream
Size: 2300 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141110/0d4249ef/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141110/0d4249ef/attachment-0003.html>

From blowekamp at mail.nih.gov  Mon Nov 10 12:02:42 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 10 Nov 2014 12:02:42 -0500
Subject: [ITK-users] VectorImage vs image of vectors
In-Reply-To: <69392D76-B649-453C-A1E9-3A79CBA63A39@inria.fr>
References: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
 <D07D0372.C69A%norman-k-williams@uiowa.edu>
 <69392D76-B649-453C-A1E9-3A79CBA63A39@inria.fr>
Message-ID: <707234F5-EAB5-447D-A1C8-476433B3AD11@mail.nih.gov>

The underlying interaction with the buffer and the accessor is rather complicated. But the results of a access to the image is a reference not a copy.

I believe The problem with this filer and the VectorImage is the number temporaries created in these blocks:

https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkRecursiveSeparableImageFilter.hxx#L105-L123

each of the terms creates a temporary variable length vector which causes an memory allocation.

I'll think about the best way to do this. I bet with out much trouble we can get 10-30x performance restoration... here.

Brad


On Nov 10, 2014, at 11:28 AM, Olivier Commowick <Olivier.Commowick at inria.fr> wrote:

> Hi,
> 
> I finally took some time to test this further using ITK smoothing filters. Here is an example file that illustrates my problem. Running it in some profiler, it appears that the time is truly lost in allocations and freeing elements (variable length vectors, method AllocateElements and free) when browsing elements in a vector image (while this doesn?t happen for images of itk vectors). Looking into it, there is a part of itk vectorimage I didn?t know about which is the accessor classes and functors. 
> 
> Would someone have an explanation of the system itself and if it might spend its time creating variable length vectors, or if the problem would come from somewhere else ? Nothing urgent though, I took the second technique in the previous email  for my urgent things.
> 
> Thanks in advance
> Olivier
> 
> 
>> On Nov 3, 2014, at 17:18 , Williams, Norman K <norman-k-williams at uiowa.edu> wrote:
>> 
>> 2 observations:
>> 
>> 1. I think the redundant SetSize you mentioned is almost certainly
>> unnecessary.  I?ve seen similar unnecessary vector/array sizing other
>> places in ITK; I think it arose out of an abundance of caution, and just
>> never showed up on anyone?s optimization radar yet.
>> 
>> 2. There?s a technique you can use to get around the
>> itk::Image<itk::Vector<TScalar,TVecLength>, TDim> problem, if there is a
>> small, finite number of possible vector lengths.  Put the code using the
>> vector image inside a function templated over TVecLength.  Then at
>> runtime, determine the vector length and invoke the template function with
>> that vector length.
>> 
>> E.G.
>> 
>> template<typename TScalar,unsigned NVecLength, unsigned NDim>
>> void DoSomething()
>> {
>>  typedef itk::Image< itk::Vector<TScalar, NVecLength>, NDim > ImageType;
>>        ...
>> }
>> 
>> int main(int,char *[])
>> {
>>  ...
>>  switch(vecLength)
>>  {
>>  case 3:
>>     DoSomething<double,3,3>();
>>     break;
>>  case 11:
>>     DoSomething<double,11,3>();
>>  ?
>>  }
>> }
>> 
>> This is of course in most cases bad C++ programming practice, but it does
>> allow you to accommodate different data types in a program.
>> 
>> On 11/3/14, 8:39 AM, "Olivier Commowick" <Olivier.Commowick at inria.fr>
>> wrote:
>> 
>>> Hello all,
>>> 
>>> I encountered some weird behavior in ITK. For some reason, I have in my
>>> code some vector images that I need to smooth using a Gaussian filter. It
>>> appears that whether the image is stored as a VectorImage or an Image of
>>> itk Vectors is actually extremely important in terms of performance for
>>> this task. Namely, if using VectorImages, the processing time can be much
>>> worse (30s vs 1s with an image of vectors). My problem is that I cannot
>>> really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim >
>>> since I do not know Size at compilation time.
>>> 
>>> Looking deeper into the code, I have two questions for whoever would know
>>> about these images:
>>> - the first one is on the Variable length vector: it seems to me that the
>>> operator= method always starts by destroying current data, even if the
>>> vector size is the same. It doesn?t seem really efficient so I was
>>> wondering if there was any reason for that
>>> - the second one is on the VectorImage itself: is there something in it
>>> that would justify the computation times to be much worse ?
>>> 
>>> If someone has any info on which image type I should be using or why
>>> VectorImage would be slower, I would be grateful.
>>> 
>>> Thanks in advance
>>> 
>>> ---
>>> 
>>> Olivier Commowick, Ph.D.
>>> Research Scientist
>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>> Campus de Beaulieu
>>> 35042 Rennes
>>> FRANCE
>>> 
>>> Phone: +33 2 99 84 25 92
>>> Email: Olivier.Commowick at inria.fr
>>> Web: http://olivier.commowick.org/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _____________________________________
>>> 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.php
>>> 
>>> 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://public.kitware.com/mailman/listinfo/insight-users
>> 
>> 
>> 
>> ________________________________
>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>> ________________________________
> 
> 
> ---
> 
> Olivier Commowick, Ph.D.
> Research Scientist
> INRIA Rennes - Bretagne Atlantique, VISAGES Team
> Campus de Beaulieu
> 35042 Rennes
> FRANCE
> 
> Phone: +33 2 99 84 25 92
> Email: Olivier.Commowick at inria.fr
> Web: http://olivier.commowick.org/
> 
> 
> 
> 
> 
> <smoothingTest.cxx>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141110/8aac907e/attachment.html>

From blowekamp at mail.nih.gov  Mon Nov 10 15:20:26 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 10 Nov 2014 15:20:26 -0500
Subject: [ITK-users] [ITK]  VectorImage vs image of vectors
In-Reply-To: <707234F5-EAB5-447D-A1C8-476433B3AD11@mail.nih.gov>
References: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
 <D07D0372.C69A%norman-k-williams@uiowa.edu>
 <69392D76-B649-453C-A1E9-3A79CBA63A39@inria.fr>
 <707234F5-EAB5-447D-A1C8-476433B3AD11@mail.nih.gov>
Message-ID: <5CA334E1-1DEA-42AA-B6E3-CC6DB4B5DD65@mail.nih.gov>

Hello,

Thanks for providing the test case, and the report of this performance issue.

Please find the following patch in gerrit:

http://review.source.kitware.com/#/c/17928/

Initial performance of your test

$ ./bin/smoothingTest 
Fast filter time: 5.558
Slow filter time: 33.7993

After patch:

$  ./bin/smoothingTest 
Fast filter time: 5.50313
Slow filter time: 2.4181

It appears the labels are now wrong :) I'm really amazed with what I presume is the good auto-vectorization SSE optimization that clang 6.0 compiler was able to do. There are other more complicated memory layout optimization that could be done, but I see no need. So I am getting a 13.9X speed up on my laptop.

Please test to see if this works for you too.

Brad



On Nov 10, 2014, at 12:02 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> The underlying interaction with the buffer and the accessor is rather complicated. But the results of a access to the image is a reference not a copy.
> 
> I believe The problem with this filer and the VectorImage is the number temporaries created in these blocks:
> 
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkRecursiveSeparableImageFilter.hxx#L105-L123
> 
> each of the terms creates a temporary variable length vector which causes an memory allocation.
> 
> I'll think about the best way to do this. I bet with out much trouble we can get 10-30x performance restoration... here.
> 
> Brad
> 
> 
> On Nov 10, 2014, at 11:28 AM, Olivier Commowick <Olivier.Commowick at inria.fr> wrote:
> 
>> Hi,
>> 
>> I finally took some time to test this further using ITK smoothing filters. Here is an example file that illustrates my problem. Running it in some profiler, it appears that the time is truly lost in allocations and freeing elements (variable length vectors, method AllocateElements and free) when browsing elements in a vector image (while this doesn?t happen for images of itk vectors). Looking into it, there is a part of itk vectorimage I didn?t know about which is the accessor classes and functors. 
>> 
>> Would someone have an explanation of the system itself and if it might spend its time creating variable length vectors, or if the problem would come from somewhere else ? Nothing urgent though, I took the second technique in the previous email for my urgent things.
>> 
>> Thanks in advance
>> Olivier
>> 
>> 
>>> On Nov 3, 2014, at 17:18 , Williams, Norman K <norman-k-williams at uiowa.edu> wrote:
>>> 
>>> 2 observations:
>>> 
>>> 1. I think the redundant SetSize you mentioned is almost certainly
>>> unnecessary.  I?ve seen similar unnecessary vector/array sizing other
>>> places in ITK; I think it arose out of an abundance of caution, and just
>>> never showed up on anyone?s optimization radar yet.
>>> 
>>> 2. There?s a technique you can use to get around the
>>> itk::Image<itk::Vector<TScalar,TVecLength>, TDim> problem, if there is a
>>> small, finite number of possible vector lengths.  Put the code using the
>>> vector image inside a function templated over TVecLength.  Then at
>>> runtime, determine the vector length and invoke the template function with
>>> that vector length.
>>> 
>>> E.G.
>>> 
>>> template<typename TScalar,unsigned NVecLength, unsigned NDim>
>>> void DoSomething()
>>> {
>>>  typedef itk::Image< itk::Vector<TScalar, NVecLength>, NDim > ImageType;
>>>        ...
>>> }
>>> 
>>> int main(int,char *[])
>>> {
>>>  ...
>>>  switch(vecLength)
>>>  {
>>>  case 3:
>>>     DoSomething<double,3,3>();
>>>     break;
>>>  case 11:
>>>     DoSomething<double,11,3>();
>>>  ?
>>>  }
>>> }
>>> 
>>> This is of course in most cases bad C++ programming practice, but it does
>>> allow you to accommodate different data types in a program.
>>> 
>>> On 11/3/14, 8:39 AM, "Olivier Commowick" <Olivier.Commowick at inria.fr>
>>> wrote:
>>> 
>>>> Hello all,
>>>> 
>>>> I encountered some weird behavior in ITK. For some reason, I have in my
>>>> code some vector images that I need to smooth using a Gaussian filter. It
>>>> appears that whether the image is stored as a VectorImage or an Image of
>>>> itk Vectors is actually extremely important in terms of performance for
>>>> this task. Namely, if using VectorImages, the processing time can be much
>>>> worse (30s vs 1s with an image of vectors). My problem is that I cannot
>>>> really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim >
>>>> since I do not know Size at compilation time.
>>>> 
>>>> Looking deeper into the code, I have two questions for whoever would know
>>>> about these images:
>>>> - the first one is on the Variable length vector: it seems to me that the
>>>> operator= method always starts by destroying current data, even if the
>>>> vector size is the same. It doesn?t seem really efficient so I was
>>>> wondering if there was any reason for that
>>>> - the second one is on the VectorImage itself: is there something in it
>>>> that would justify the computation times to be much worse ?
>>>> 
>>>> If someone has any info on which image type I should be using or why
>>>> VectorImage would be slower, I would be grateful.
>>>> 
>>>> Thanks in advance
>>>> 
>>>> ---
>>>> 
>>>> Olivier Commowick, Ph.D.
>>>> Research Scientist
>>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>>> Campus de Beaulieu
>>>> 35042 Rennes
>>>> FRANCE
>>>> 
>>>> Phone: +33 2 99 84 25 92
>>>> Email: Olivier.Commowick at inria.fr
>>>> Web: http://olivier.commowick.org/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _____________________________________
>>>> 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.php
>>>> 
>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>> 
>>> 
>>> 
>>> ________________________________
>>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>>> ________________________________
>> 
>> 
>> ---
>> 
>> Olivier Commowick, Ph.D.
>> Research Scientist
>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>> Campus de Beaulieu
>> 35042 Rennes
>> FRANCE
>> 
>> Phone: +33 2 99 84 25 92
>> Email: Olivier.Commowick at inria.fr
>> Web: http://olivier.commowick.org/
>> 
>> 
>> 
>> 
>> 
>> <smoothingTest.cxx>
> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141110/6f6dd5ba/attachment.html>

From rekha.pyage at gmail.com  Tue Nov 11 00:26:29 2014
From: rekha.pyage at gmail.com (rekhap)
Date: Mon, 10 Nov 2014 22:26:29 -0700 (MST)
Subject: [ITK-users] rescaling the volume
Message-ID: <1415683589888-34880.post@n7.nabble.com>

hello all,

I am attempting to rescale an image in its physical space while keeping
the same number of voxels.  My image is 512 x 512 x 48 voxels (spacing:
0.782 x 0.782 x 5.0)
 
tried using itkResamplefilter, ScaleTransform but the number of voxels is
changing and sometimes the data is getting lost.

Any help is deeply appreciated


Thank you.......



--
View this message in context: http://itk-users.7.n7.nabble.com/rescaling-the-volume-tp34880.html
Sent from the ITK - Users mailing list archive at Nabble.com.

From rekha.pyage at gmail.com  Tue Nov 11 04:03:10 2014
From: rekha.pyage at gmail.com (rekhap)
Date: Tue, 11 Nov 2014 02:03:10 -0700 (MST)
Subject: [ITK-users] Simple Resampling delivers empty image
In-Reply-To: <1415184014461-34867.post@n7.nabble.com>
References: <1415184014461-34867.post@n7.nabble.com>
Message-ID: <1415696590890-34881.post@n7.nabble.com>

even i have faced this but it was wen i had not setup the origin....




--
View this message in context: http://itk-users.7.n7.nabble.com/Simple-Resampling-delivers-empty-image-tp34867p34881.html
Sent from the ITK - Users mailing list archive at Nabble.com.

From Olivier.Commowick at inria.fr  Tue Nov 11 06:23:03 2014
From: Olivier.Commowick at inria.fr (Olivier Commowick)
Date: Tue, 11 Nov 2014 12:23:03 +0100
Subject: [ITK-users] [ITK]  VectorImage vs image of vectors
In-Reply-To: <5CA334E1-1DEA-42AA-B6E3-CC6DB4B5DD65@mail.nih.gov>
References: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
 <D07D0372.C69A%norman-k-williams@uiowa.edu>
 <69392D76-B649-453C-A1E9-3A79CBA63A39@inria.fr>
 <707234F5-EAB5-447D-A1C8-476433B3AD11@mail.nih.gov>
 <5CA334E1-1DEA-42AA-B6E3-CC6DB4B5DD65@mail.nih.gov>
Message-ID: <DC63CB39-5BE9-4307-A8C0-A2F57E2E804D@inria.fr>

Hello

It works perfectly fine for me as well (I get 0.22s for slow vs 1.6s for fast), the labels are indeed wrong now :) I even wonder if we shouldn?t extend this patch to itk vector object in the filter, but that would make the code rather ugly.

Thanks
Olivier

> On Nov 10, 2014, at 21:20 , Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
> Hello,
> 
> Thanks for providing the test case, and the report of this performance issue.
> 
> Please find the following patch in gerrit:
> 
> http://review.source.kitware.com/#/c/17928/ <http://review.source.kitware.com/#/c/17928/>
> 
> Initial performance of your test
> 
> $ ./bin/smoothingTest 
> Fast filter time: 5.558
> Slow filter time: 33.7993
> 
> After patch:
> 
> $  ./bin/smoothingTest 
> Fast filter time: 5.50313
> Slow filter time: 2.4181
> 
> It appears the labels are now wrong :) I'm really amazed with what I presume is the good auto-vectorization SSE optimization that clang 6.0 compiler was able to do. There are other more complicated memory layout optimization that could be done, but I see no need. So I am getting a 13.9X speed up on my laptop.
> 
> Please test to see if this works for you too.
> 
> Brad
> 
> 
> 
> On Nov 10, 2014, at 12:02 PM, Bradley Lowekamp <blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>> wrote:
> 
>> The underlying interaction with the buffer and the accessor is rather complicated. But the results of a access to the image is a reference not a copy.
>> 
>> I believe The problem with this filer and the VectorImage is the number temporaries created in these blocks:
>> 
>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkRecursiveSeparableImageFilter.hxx#L105-L123 <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkRecursiveSeparableImageFilter.hxx#L105-L123>
>> 
>> each of the terms creates a temporary variable length vector which causes an memory allocation.
>> 
>> I'll think about the best way to do this. I bet with out much trouble we can get 10-30x performance restoration... here.
>> 
>> Brad
>> 
>> 
>> On Nov 10, 2014, at 11:28 AM, Olivier Commowick <Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>> wrote:
>> 
>>> Hi,
>>> 
>>> I finally took some time to test this further using ITK smoothing filters. Here is an example file that illustrates my problem. Running it in some profiler, it appears that the time is truly lost in allocations and freeing elements (variable length vectors, method AllocateElements and free) when browsing elements in a vector image (while this doesn?t happen for images of itk vectors). Looking into it, there is a part of itk vectorimage I didn?t know about which is the accessor classes and functors. 
>>> 
>>> Would someone have an explanation of the system itself and if it might spend its time creating variable length vectors, or if the problem would come from somewhere else ? Nothing urgent though, I took the second technique in the previous email for my urgent things.
>>> 
>>> Thanks in advance
>>> Olivier
>>> 
>>> 
>>>> On Nov 3, 2014, at 17:18 , Williams, Norman K <norman-k-williams at uiowa.edu <mailto:norman-k-williams at uiowa.edu>> wrote:
>>>> 
>>>> 2 observations:
>>>> 
>>>> 1. I think the redundant SetSize you mentioned is almost certainly
>>>> unnecessary.  I?ve seen similar unnecessary vector/array sizing other
>>>> places in ITK; I think it arose out of an abundance of caution, and just
>>>> never showed up on anyone?s optimization radar yet.
>>>> 
>>>> 2. There?s a technique you can use to get around the
>>>> itk::Image<itk::Vector<TScalar,TVecLength>, TDim> problem, if there is a
>>>> small, finite number of possible vector lengths.  Put the code using the
>>>> vector image inside a function templated over TVecLength.  Then at
>>>> runtime, determine the vector length and invoke the template function with
>>>> that vector length.
>>>> 
>>>> E.G.
>>>> 
>>>> template<typename TScalar,unsigned NVecLength, unsigned NDim>
>>>> void DoSomething()
>>>> {
>>>>  typedef itk::Image< itk::Vector<TScalar, NVecLength>, NDim > ImageType;
>>>>        ...
>>>> }
>>>> 
>>>> int main(int,char *[])
>>>> {
>>>>  ...
>>>>  switch(vecLength)
>>>>  {
>>>>  case 3:
>>>>     DoSomething<double,3,3>();
>>>>     break;
>>>>  case 11:
>>>>     DoSomething<double,11,3>();
>>>>  ?
>>>>  }
>>>> }
>>>> 
>>>> This is of course in most cases bad C++ programming practice, but it does
>>>> allow you to accommodate different data types in a program.
>>>> 
>>>> On 11/3/14, 8:39 AM, "Olivier Commowick" <Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>>
>>>> wrote:
>>>> 
>>>>> Hello all,
>>>>> 
>>>>> I encountered some weird behavior in ITK. For some reason, I have in my
>>>>> code some vector images that I need to smooth using a Gaussian filter. It
>>>>> appears that whether the image is stored as a VectorImage or an Image of
>>>>> itk Vectors is actually extremely important in terms of performance for
>>>>> this task. Namely, if using VectorImages, the processing time can be much
>>>>> worse (30s vs 1s with an image of vectors). My problem is that I cannot
>>>>> really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim >
>>>>> since I do not know Size at compilation time.
>>>>> 
>>>>> Looking deeper into the code, I have two questions for whoever would know
>>>>> about these images:
>>>>> - the first one is on the Variable length vector: it seems to me that the
>>>>> operator= method always starts by destroying current data, even if the
>>>>> vector size is the same. It doesn?t seem really efficient so I was
>>>>> wondering if there was any reason for that
>>>>> - the second one is on the VectorImage itself: is there something in it
>>>>> that would justify the computation times to be much worse ?
>>>>> 
>>>>> If someone has any info on which image type I should be using or why
>>>>> VectorImage would be slower, I would be grateful.
>>>>> 
>>>>> Thanks in advance
>>>>> 
>>>>> ---
>>>>> 
>>>>> Olivier Commowick, Ph.D.
>>>>> Research Scientist
>>>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>>>> Campus de Beaulieu
>>>>> 35042 Rennes
>>>>> FRANCE
>>>>> 
>>>>> Phone: +33 2 99 84 25 92
>>>>> Email: Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>
>>>>> Web: http://olivier.commowick.org/ <http://olivier.commowick.org/>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _____________________________________
>>>>> Powered by www.kitware.com <http://www.kitware.com/>
>>>>> 
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>>>>> 
>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>> http://www.kitware.com/products/protraining.php <http://www.kitware.com/products/protraining.php>
>>>>> 
>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>> http://www.itk.org/Wiki/ITK_FAQ <http://www.itk.org/Wiki/ITK_FAQ>
>>>>> 
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/insight-users <http://public.kitware.com/mailman/listinfo/insight-users>
>>>> 
>>>> 
>>>> 
>>>> ________________________________
>>>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>>>> ________________________________
>>> 
>>> 
>>> ---
>>> 
>>> Olivier Commowick, Ph.D.
>>> Research Scientist
>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>> Campus de Beaulieu
>>> 35042 Rennes
>>> FRANCE
>>> 
>>> Phone: +33 2 99 84 25 92
>>> Email: Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>
>>> Web: http://olivier.commowick.org/ <http://olivier.commowick.org/>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> <smoothingTest.cxx>
>> 
>> _____________________________________
>> Powered by www.kitware.com <http://www.kitware.com/>
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://www.kitware.com/products/protraining.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-users
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/mailman/listinfo/community
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141111/ba830821/attachment-0001.html>

From brad at lowekamp.net  Tue Nov 11 07:04:12 2014
From: brad at lowekamp.net (Bradley Lowekamp)
Date: Tue, 11 Nov 2014 07:04:12 -0500
Subject: [ITK-users] [ITK]  VectorImage vs image of vectors
In-Reply-To: <DC63CB39-5BE9-4307-A8C0-A2F57E2E804D@inria.fr>
References: <A9636B05-3B5C-4430-83C9-67EB0B8DF378@inria.fr>
 <D07D0372.C69A%norman-k-williams@uiowa.edu>
 <69392D76-B649-453C-A1E9-3A79CBA63A39@inria.fr>
 <707234F5-EAB5-447D-A1C8-476433B3AD11@mail.nih.gov>
 <5CA334E1-1DEA-42AA-B6E3-CC6DB4B5DD65@mail.nih.gov>
 <DC63CB39-5BE9-4307-A8C0-A2F57E2E804D@inria.fr>
Message-ID: <C2B92910-AE1E-4D99-B434-51F09BAE32A4@mail.nih.gov>

Hello

Please check the result to see if they are correct. Patch set 4 has all the tests passing. My initial report had some bugs. And the the two versions are now about the same performance. however there is still room for improvement. 


> On Nov 11, 2014, at 6:23 AM, Olivier Commowick <Olivier.Commowick at inria.fr> wrote:
> 
> Hello
> 
> It works perfectly fine for me as well (I get 0.22s for slow vs 1.6s for fast), the labels are indeed wrong now :) I even wonder if we shouldn?t extend this patch to itk vector object in the filter, but that would make the code rather ugly.
> 
> Thanks
> Olivier
> 
>> On Nov 10, 2014, at 21:20 , Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>> 
>> Hello,
>> 
>> Thanks for providing the test case, and the report of this performance issue.
>> 
>> Please find the following patch in gerrit:
>> 
>> http://review.source.kitware.com/#/c/17928/
>> 
>> Initial performance of your test
>> 
>> $ ./bin/smoothingTest 
>> Fast filter time: 5.558
>> Slow filter time: 33.7993
>> 
>> After patch:
>> 
>> $  ./bin/smoothingTest 
>> Fast filter time: 5.50313
>> Slow filter time: 2.4181
>> 
>> It appears the labels are now wrong :) I'm really amazed with what I presume is the good auto-vectorization SSE optimization that clang 6.0 compiler was able to do. There are other more complicated memory layout optimization that could be done, but I see no need. So I am getting a 13.9X speed up on my laptop.
>> 
>> Please test to see if this works for you too.
>> 
>> Brad
>> 
>> 
>> 
>>> On Nov 10, 2014, at 12:02 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>> 
>>> The underlying interaction with the buffer and the accessor is rather complicated. But the results of a access to the image is a reference not a copy.
>>> 
>>> I believe The problem with this filer and the VectorImage is the number temporaries created in these blocks:
>>> 
>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkRecursiveSeparableImageFilter.hxx#L105-L123
>>> 
>>> each of the terms creates a temporary variable length vector which causes an memory allocation.
>>> 
>>> I'll think about the best way to do this. I bet with out much trouble we can get 10-30x performance restoration... here.
>>> 
>>> Brad
>>> 
>>> 
>>>> On Nov 10, 2014, at 11:28 AM, Olivier Commowick <Olivier.Commowick at inria.fr> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I finally took some time to test this further using ITK smoothing filters. Here is an example file that illustrates my problem. Running it in some profiler, it appears that the time is truly lost in allocations and freeing elements (variable length vectors, method AllocateElements and free) when browsing elements in a vector image (while this doesn?t happen for images of itk vectors). Looking into it, there is a part of itk vectorimage I didn?t know about which is the accessor classes and functors. 
>>>> 
>>>> Would someone have an explanation of the system itself and if it might spend its time creating variable length vectors, or if the problem would come from somewhere else ? Nothing urgent though, I took the second technique in the previous email for my urgent things.
>>>> 
>>>> Thanks in advance
>>>> Olivier
>>>> 
>>>> 
>>>>> On Nov 3, 2014, at 17:18 , Williams, Norman K <norman-k-williams at uiowa.edu> wrote:
>>>>> 
>>>>> 2 observations:
>>>>> 
>>>>> 1. I think the redundant SetSize you mentioned is almost certainly
>>>>> unnecessary.  I?ve seen similar unnecessary vector/array sizing other
>>>>> places in ITK; I think it arose out of an abundance of caution, and just
>>>>> never showed up on anyone?s optimization radar yet.
>>>>> 
>>>>> 2. There?s a technique you can use to get around the
>>>>> itk::Image<itk::Vector<TScalar,TVecLength>, TDim> problem, if there is a
>>>>> small, finite number of possible vector lengths.  Put the code using the
>>>>> vector image inside a function templated over TVecLength.  Then at
>>>>> runtime, determine the vector length and invoke the template function with
>>>>> that vector length.
>>>>> 
>>>>> E.G.
>>>>> 
>>>>> template<typename TScalar,unsigned NVecLength, unsigned NDim>
>>>>> void DoSomething()
>>>>> {
>>>>>  typedef itk::Image< itk::Vector<TScalar, NVecLength>, NDim > ImageType;
>>>>>        ...
>>>>> }
>>>>> 
>>>>> int main(int,char *[])
>>>>> {
>>>>>  ...
>>>>>  switch(vecLength)
>>>>>  {
>>>>>  case 3:
>>>>>     DoSomething<double,3,3>();
>>>>>     break;
>>>>>  case 11:
>>>>>     DoSomething<double,11,3>();
>>>>>  ?
>>>>>  }
>>>>> }
>>>>> 
>>>>> This is of course in most cases bad C++ programming practice, but it does
>>>>> allow you to accommodate different data types in a program.
>>>>> 
>>>>> On 11/3/14, 8:39 AM, "Olivier Commowick" <Olivier.Commowick at inria.fr>
>>>>> wrote:
>>>>> 
>>>>>> Hello all,
>>>>>> 
>>>>>> I encountered some weird behavior in ITK. For some reason, I have in my
>>>>>> code some vector images that I need to smooth using a Gaussian filter. It
>>>>>> appears that whether the image is stored as a VectorImage or an Image of
>>>>>> itk Vectors is actually extremely important in terms of performance for
>>>>>> this task. Namely, if using VectorImages, the processing time can be much
>>>>>> worse (30s vs 1s with an image of vectors). My problem is that I cannot
>>>>>> really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim >
>>>>>> since I do not know Size at compilation time.
>>>>>> 
>>>>>> Looking deeper into the code, I have two questions for whoever would know
>>>>>> about these images:
>>>>>> - the first one is on the Variable length vector: it seems to me that the
>>>>>> operator= method always starts by destroying current data, even if the
>>>>>> vector size is the same. It doesn?t seem really efficient so I was
>>>>>> wondering if there was any reason for that
>>>>>> - the second one is on the VectorImage itself: is there something in it
>>>>>> that would justify the computation times to be much worse ?
>>>>>> 
>>>>>> If someone has any info on which image type I should be using or why
>>>>>> VectorImage would be slower, I would be grateful.
>>>>>> 
>>>>>> Thanks in advance
>>>>>> 
>>>>>> ---
>>>>>> 
>>>>>> Olivier Commowick, Ph.D.
>>>>>> Research Scientist
>>>>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>>>>> Campus de Beaulieu
>>>>>> 35042 Rennes
>>>>>> FRANCE
>>>>>> 
>>>>>> Phone: +33 2 99 84 25 92
>>>>>> Email: Olivier.Commowick at inria.fr
>>>>>> Web: http://olivier.commowick.org/
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _____________________________________
>>>>>> 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.php
>>>>>> 
>>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>>>> 
>>>>> 
>>>>> 
>>>>> ________________________________
>>>>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>>>>> ________________________________
>>>> 
>>>> 
>>>> ---
>>>> 
>>>> Olivier Commowick, Ph.D.
>>>> Research Scientist
>>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>>> Campus de Beaulieu
>>>> 35042 Rennes
>>>> FRANCE
>>>> 
>>>> Phone: +33 2 99 84 25 92
>>>> Email: Olivier.Commowick at inria.fr
>>>> Web: http://olivier.commowick.org/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> <smoothingTest.cxx>
>>> 
>>> _____________________________________
>>> 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.php
>>> 
>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>> _______________________________________________
>>> Community mailing list
>>> Community at itk.org
>>> http://public.kitware.com/mailman/listinfo/community
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141111/d53fa41e/attachment.html>

From zeinsalah at gmail.com  Wed Nov 12 07:43:03 2014
From: zeinsalah at gmail.com (Zein Salah)
Date: Wed, 12 Nov 2014 13:43:03 +0100
Subject: [ITK-users] Otsu Filter for object/background separation
Message-ID: <CADiSopNLpxu4V+W+fbMz_+Wfet3qv_GvekS+9nK46TLMd8GiAA@mail.gmail.com>

Hello,

I have been using the otsu filter for doing object-from-background
separation. However, I noticed that the filter always comes out with an
separation threshold, even if the image does NOT actually have a
"reasonable" background, see the attached image, e.g..

My question is: is it possible to control the filter in such a way that it
only generate a threshold if there is really a background?

Practically, I could, in a post-processing step,  do a decision weather the
separation is feasible or not, e.g. computing the comparing the statistics
of the two separated areas (average intensity, variance, etc.). But I
thought the otsu filter already does such things internally, right? Is it
possible to inquire such data from the filter?

Any ideas would be welcome!!

Much thanks,

Zein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141112/ff5ee64a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: obj-bg.jpg
Type: image/jpeg
Size: 142924 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141112/ff5ee64a/attachment-0001.jpg>

From indianzeppelin at gmail.com  Wed Nov 12 08:14:50 2014
From: indianzeppelin at gmail.com (Girish Mallya Udupi)
Date: Wed, 12 Nov 2014 13:14:50 +0000
Subject: [ITK-users] [ITK] Otsu Filter for object/background separation
In-Reply-To: <CADiSopNLpxu4V+W+fbMz_+Wfet3qv_GvekS+9nK46TLMd8GiAA@mail.gmail.com>
References: <CADiSopNLpxu4V+W+fbMz_+Wfet3qv_GvekS+9nK46TLMd8GiAA@mail.gmail.com>
Message-ID: <CAA+VR6isWQDHzOj--n0f2iPiceg+1EbBjBPXc+p7us+ZWStejQ@mail.gmail.com>

Hi Zein,

As you might know, Otsu's method *assumes *that the histogram of the image
is bi-modal. i.e., there are two classes of pixels forming two peaks
separated by a valley.
All the method (and the corresponding ITK filter) does is calculate the
threshold which maximizes the inter-class variance and apply it on the
image.


On Wed, Nov 12, 2014 at 12:43 PM, Zein Salah <zeinsalah at gmail.com> wrote:

> Hello,
>
> I have been using the otsu filter for doing object-from-background
> separation. However, I noticed that the filter always comes out with an
> separation threshold, even if the image does NOT actually have a
> "reasonable" background, see the attached image, e.g..
>
> My question is: is it possible to control the filter in such a way that it
> only generate a threshold if there is really a background?
>
> Practically, I could, in a post-processing step,  do a decision weather
> the separation is feasible or not, e.g. computing the comparing the
> statistics of the two separated areas (average intensity, variance, etc.).
> But I thought the otsu filter already does such things internally, right?
> Is it possible to inquire such data from the filter?
>
> Any ideas would be welcome!!
>
> Much thanks,
>
> Zein
>
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community
>
>


-- 
Regards,
Girish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141112/27897f7c/attachment.html>

From bill.lorensen at gmail.com  Wed Nov 12 09:51:07 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 12 Nov 2014 09:51:07 -0500
Subject: [ITK-users] rescaling of volume
In-Reply-To: <CAE8+oFbP++MCp48rdrxRcj8nzJ3OxdtuJOyNaA1tFL6wSEmWfg@mail.gmail.com>
References: <CAE8+oFbP++MCp48rdrxRcj8nzJ3OxdtuJOyNaA1tFL6wSEmWfg@mail.gmail.com>
Message-ID: <CADZJ4hOkMnvcBTAGXpGr+v4VNh_L4BJCTWGbmWmWyFGW0rxixQ@mail.gmail.com>

Do want to scale it anoint the center of the volume?
On Nov 12, 2014 4:18 AM, "Rekha Pyage" <rekha.pyage at gmail.com> wrote:

> hello bill..
>
> i am new to itk but m stuck up with the task of rescaling..
> m using MRI data.. my main aim is to change the spacing but number of
> voxels and slices should be same as the input.. only physical extent should
> change.. i have been trying from past 15 days.. hope u help me...
>
> waiting for the positive response..
>
> --
> with regards
> rekha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141112/ceba8482/attachment.html>

From bill.lorensen at gmail.com  Wed Nov 12 10:43:53 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 12 Nov 2014 10:43:53 -0500
Subject: [ITK-users] rescaling of volume
In-Reply-To: <CAE8+oFZQibNko86_0qHwU-VEt5ZNEJB1yrYDT+PZMEkiGN0cOg@mail.gmail.com>
References: <CAE8+oFbP++MCp48rdrxRcj8nzJ3OxdtuJOyNaA1tFL6wSEmWfg@mail.gmail.com>
 <CADZJ4hOkMnvcBTAGXpGr+v4VNh_L4BJCTWGbmWmWyFGW0rxixQ@mail.gmail.com>
 <CAE8+oFZQibNko86_0qHwU-VEt5ZNEJB1yrYDT+PZMEkiGN0cOg@mail.gmail.com>
Message-ID: <CADZJ4hNXKa=aHp+AMDfUVfEe5Gmeot7cypV9UuVNLT_Xn0mcJQ@mail.gmail.com>

Please keep the users list involved.

This example may help you get started:
http://www.itk.org/Wiki/ITK/Examples/ImageProcessing/ScaleTransform


On Wed, Nov 12, 2014 at 10:37 AM, Rekha Pyage <rekha.pyage at gmail.com> wrote:
> Yes..  Only spacing should be increased or decreased n number of voxels shud
> remain same.. N physical extent should change according to the spacing..
>
> On Nov 12, 2014 8:21 PM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>>
>> Do want to scale it anoint the center of the volume?
>>
>> On Nov 12, 2014 4:18 AM, "Rekha Pyage" <rekha.pyage at gmail.com> wrote:
>>>
>>> hello bill..
>>>
>>> i am new to itk but m stuck up with the task of rescaling..
>>> m using MRI data.. my main aim is to change the spacing but number of
>>> voxels and slices should be same as the input.. only physical extent should
>>> change.. i have been trying from past 15 days.. hope u help me...
>>>
>>> waiting for the positive response..
>>>
>>> --
>>> with regards
>>> rekha



-- 
Unpaid intern in BillsBasement at noware dot com

From iyas.hamdan at gmail.com  Thu Nov 13 06:30:46 2014
From: iyas.hamdan at gmail.com (Iyas Hamdan)
Date: Thu, 13 Nov 2014 12:30:46 +0100
Subject: [ITK-users] problem using VTKImageToImageFilter
Message-ID: <CANH4YVjsRKbXyK3ybsOr1pypXsUtnK36G8L=ojsP4aLbcTKTYg@mail.gmail.com>

Hi everyone!
I'm trying to read two DICOM series with VTK, and then register those two
volumes using ITK, so in this contexte I would have to convert the
vtkImageData into itk::Image.

What i'm doing is the following:

typedef itk::Image< signed short, 3> ImageType;
typedef itk::VTKImageToImageFilter< ImageType >  VTKImageToImageFilterType;
VTKImageToImageFilterType::Pointer connector =
VTKImageToImageFilterType::New();
connector->SetInput(ImageVTK);
connector->Update();

Where ImageVTK is my 3D volume and I visualized it so its reading the Dicom
series correctly.

But I'm always getting this error when I reach the update():
VTKImageToImageFilter: Input scalar type is float but should be short.

So what am I doing wrong here ?

thanks in advance,

Iyas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/33fd54fa/attachment.html>

From bill.lorensen at gmail.com  Thu Nov 13 08:14:56 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 13 Nov 2014 08:14:56 -0500
Subject: [ITK-users] problem using VTKImageToImageFilter
In-Reply-To: <CANH4YVjsRKbXyK3ybsOr1pypXsUtnK36G8L=ojsP4aLbcTKTYg@mail.gmail.com>
References: <CANH4YVjsRKbXyK3ybsOr1pypXsUtnK36G8L=ojsP4aLbcTKTYg@mail.gmail.com>
Message-ID: <CADZJ4hMJQV2gxNDM8c2KYBDJoFHZ2vnnMGFT2othafW=np_gUw@mail.gmail.com>

It is telling you that the VTK image is float. Try printing the vtk image
ImageVTK->Print(std::cout);


On Thu, Nov 13, 2014 at 6:30 AM, Iyas Hamdan <iyas.hamdan at gmail.com> wrote:
> Hi everyone!
> I'm trying to read two DICOM series with VTK, and then register those two
> volumes using ITK, so in this contexte I would have to convert the
> vtkImageData into itk::Image.
>
> What i'm doing is the following:
>
> typedef itk::Image< signed short, 3> ImageType;
> typedef itk::VTKImageToImageFilter< ImageType >  VTKImageToImageFilterType;
> VTKImageToImageFilterType::Pointer connector =
> VTKImageToImageFilterType::New();
> connector->SetInput(ImageVTK);
> connector->Update();
>
> Where ImageVTK is my 3D volume and I visualized it so its reading the Dicom
> series correctly.
>
> But I'm always getting this error when I reach the update():
> VTKImageToImageFilter: Input scalar type is float but should be short.
>
> So what am I doing wrong here ?
>
> thanks in advance,
>
> Iyas
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>



-- 
Unpaid intern in BillsBasement at noware dot com

From matimontg at gmail.com  Thu Nov 13 08:56:11 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Thu, 13 Nov 2014 10:56:11 -0300
Subject: [ITK-users] White Background on rotated image
Message-ID: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>

Hi,

I'm running this example:
http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html

and I'm getting this result which is fine *but I need the white sections
left due to the rotation to be black.* how can I achieve this?


?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/a0c7980b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.JPG
Type: image/jpeg
Size: 74098 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/a0c7980b/attachment-0001.jpe>

From blowekamp at mail.nih.gov  Thu Nov 13 08:59:34 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Thu, 13 Nov 2014 08:59:34 -0500
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
Message-ID: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>

Hello,

Check out the ImageToImageFilter::SetDefaultPixelValue method [1].

Brad

[1] http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be

On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com> wrote:

> Hi,
> 
> I'm running this example: 
> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
> 
> and I'm getting this result which is fine but I need the white sections left due to the rotation to be black. how can I achieve this?
> 
> <Capture.JPG>
> ?
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/aaf76675/attachment.html>

From matimontg at gmail.com  Thu Nov 13 09:27:10 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Thu, 13 Nov 2014 11:27:10 -0300
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
Message-ID: <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>

Bradley, I must say you're the man! that did the trick, thanks a lot!

On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Hello,
>
> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
>
> Brad
>
> [1]
> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
>
> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com> wrote:
>
> Hi,
>
> I'm running this example:
>
> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>
> and I'm getting this result which is fine *but I need the white sections
> left due to the rotation to be black.* how can I achieve this?
>
> <Capture.JPG>
> ?
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/fa4829d9/attachment.html>

From matimontg at gmail.com  Thu Nov 13 09:30:22 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Thu, 13 Nov 2014 11:30:22 -0300
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
Message-ID: <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>

I have one more question, it seems the writer method removes lot of tags
from the image, is there an option to keep the original tags such as
patient name, model, manufacture etc?

On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <matimontg at gmail.com>
wrote:

> Bradley, I must say you're the man! that did the trick, thanks a lot!
>
> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp <blowekamp at mail.nih.gov
> > wrote:
>
>> Hello,
>>
>> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
>>
>> Brad
>>
>> [1]
>> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
>>
>> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I'm running this example:
>>
>> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>>
>> and I'm getting this result which is fine *but I need the white sections
>> left due to the rotation to be black.* how can I achieve this?
>>
>> <Capture.JPG>
>> ?
>> _____________________________________
>> 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.php
>>
>> 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://public.kitware.com/mailman/listinfo/insight-users
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/b5de7a6a/attachment.html>

From blowekamp at mail.nih.gov  Thu Nov 13 09:36:32 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Thu, 13 Nov 2014 09:36:32 -0500
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
 <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
Message-ID: <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>

Hello again,

This is a non-trivial task where caution in needed to determine which tags should be copied. But here is a basic example here:
http://itk.org/Wiki/ITK/Examples/DICOM/ResampleDICOM

Brad

On Nov 13, 2014, at 9:30 AM, Matias Montroull <matimontg at gmail.com> wrote:

> I have one more question, it seems the writer method removes lot of tags from the image, is there an option to keep the original tags such as patient name, model, manufacture etc?
> 
> On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <matimontg at gmail.com> wrote:
> Bradley, I must say you're the man! that did the trick, thanks a lot!
> 
> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Hello,
> 
> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
> 
> Brad
> 
> [1] http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
> 
> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com> wrote:
> 
>> Hi,
>> 
>> I'm running this example: 
>> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>> 
>> and I'm getting this result which is fine but I need the white sections left due to the rotation to be black. how can I achieve this?
>> 
>> <Capture.JPG>
>> ?
>> _____________________________________
>> 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.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-users
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/dc56c1eb/attachment.html>

From matimontg at gmail.com  Thu Nov 13 12:14:26 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Thu, 13 Nov 2014 14:14:26 -0300
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
 <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
 <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>
Message-ID: <CAKKNfuLOaoJ6RG6-BexkJutf9CikQOcrYR=-DJox-BbKNqHdwA@mail.gmail.com>

Bradley, as soon as I enter this line of code:

typedef itk::GDCMImageIO ImageIOType;
ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
writer->SetImageIO(gdcmImageIO);

I get a bad image as result.. any ideas what could it be?

On Thu, Nov 13, 2014 at 11:36 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Hello again,
>
> This is a non-trivial task where caution in needed to determine which tags
> should be copied. But here is a basic example here:
> http://itk.org/Wiki/ITK/Examples/DICOM/ResampleDICOM
>
> Brad
>
> On Nov 13, 2014, at 9:30 AM, Matias Montroull <matimontg at gmail.com> wrote:
>
> I have one more question, it seems the writer method removes lot of tags
> from the image, is there an option to keep the original tags such as
> patient name, model, manufacture etc?
>
> On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <matimontg at gmail.com>
> wrote:
>
>> Bradley, I must say you're the man! that did the trick, thanks a lot!
>>
>> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp <
>> blowekamp at mail.nih.gov> wrote:
>>
>>> Hello,
>>>
>>> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
>>>
>>> Brad
>>>
>>> [1]
>>> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
>>>
>>> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I'm running this example:
>>>
>>> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>>>
>>> and I'm getting this result which is fine *but I need the white
>>> sections left due to the rotation to be black.* how can I achieve this?
>>>
>>> <Capture.JPG>
>>> ?
>>> _____________________________________
>>> 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.php
>>>
>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/b5bfd1bf/attachment.html>

From matimontg at gmail.com  Thu Nov 13 12:16:24 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Thu, 13 Nov 2014 14:16:24 -0300
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CAKKNfuLOaoJ6RG6-BexkJutf9CikQOcrYR=-DJox-BbKNqHdwA@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
 <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
 <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>
 <CAKKNfuLOaoJ6RG6-BexkJutf9CikQOcrYR=-DJox-BbKNqHdwA@mail.gmail.com>
Message-ID: <CAKKNfuLwkB-VVg0KOkVWqjWwZ-2+p-iNm6txnCH5qi4wM_3TMA@mail.gmail.com>

never mind, it was my bad. The InputPixelType was unsigned char and should
have been unsigned short

On Thu, Nov 13, 2014 at 2:14 PM, Matias Montroull <matimontg at gmail.com>
wrote:

> Bradley, as soon as I enter this line of code:
>
> typedef itk::GDCMImageIO ImageIOType;
> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
> writer->SetImageIO(gdcmImageIO);
>
> I get a bad image as result.. any ideas what could it be?
>
> On Thu, Nov 13, 2014 at 11:36 AM, Bradley Lowekamp <blowekamp at mail.nih.gov
> > wrote:
>
>> Hello again,
>>
>> This is a non-trivial task where caution in needed to determine which
>> tags should be copied. But here is a basic example here:
>> http://itk.org/Wiki/ITK/Examples/DICOM/ResampleDICOM
>>
>> Brad
>>
>> On Nov 13, 2014, at 9:30 AM, Matias Montroull <matimontg at gmail.com>
>> wrote:
>>
>> I have one more question, it seems the writer method removes lot of tags
>> from the image, is there an option to keep the original tags such as
>> patient name, model, manufacture etc?
>>
>> On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <matimontg at gmail.com>
>> wrote:
>>
>>> Bradley, I must say you're the man! that did the trick, thanks a lot!
>>>
>>> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp <
>>> blowekamp at mail.nih.gov> wrote:
>>>
>>>> Hello,
>>>>
>>>> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
>>>>
>>>> Brad
>>>>
>>>> [1]
>>>> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
>>>>
>>>> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm running this example:
>>>>
>>>> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>>>>
>>>> and I'm getting this result which is fine *but I need the white
>>>> sections left due to the rotation to be black.* how can I achieve this?
>>>>
>>>> <Capture.JPG>
>>>> ?
>>>> _____________________________________
>>>> 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.php
>>>>
>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>>>
>>>>
>>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/d9dbdc5a/attachment.html>

From matimontg at gmail.com  Thu Nov 13 12:18:07 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Thu, 13 Nov 2014 14:18:07 -0300
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CAKKNfuLwkB-VVg0KOkVWqjWwZ-2+p-iNm6txnCH5qi4wM_3TMA@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
 <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
 <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>
 <CAKKNfuLOaoJ6RG6-BexkJutf9CikQOcrYR=-DJox-BbKNqHdwA@mail.gmail.com>
 <CAKKNfuLwkB-VVg0KOkVWqjWwZ-2+p-iNm6txnCH5qi4wM_3TMA@mail.gmail.com>
Message-ID: <CAKKNfuL1PQjYe9PEhbEsqeMP_XoVoxawLMHypzXiT5mnWzmtHA@mail.gmail.com>

Now I have another question. This example is just for one file, is there a
way to do it for a directory containing a set of DICOM files?

On Thu, Nov 13, 2014 at 2:16 PM, Matias Montroull <matimontg at gmail.com>
wrote:

> never mind, it was my bad. The InputPixelType was unsigned char and should
> have been unsigned short
>
> On Thu, Nov 13, 2014 at 2:14 PM, Matias Montroull <matimontg at gmail.com>
> wrote:
>
>> Bradley, as soon as I enter this line of code:
>>
>> typedef itk::GDCMImageIO ImageIOType;
>> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
>> writer->SetImageIO(gdcmImageIO);
>>
>> I get a bad image as result.. any ideas what could it be?
>>
>> On Thu, Nov 13, 2014 at 11:36 AM, Bradley Lowekamp <
>> blowekamp at mail.nih.gov> wrote:
>>
>>> Hello again,
>>>
>>> This is a non-trivial task where caution in needed to determine which
>>> tags should be copied. But here is a basic example here:
>>> http://itk.org/Wiki/ITK/Examples/DICOM/ResampleDICOM
>>>
>>> Brad
>>>
>>> On Nov 13, 2014, at 9:30 AM, Matias Montroull <matimontg at gmail.com>
>>> wrote:
>>>
>>> I have one more question, it seems the writer method removes lot of tags
>>> from the image, is there an option to keep the original tags such as
>>> patient name, model, manufacture etc?
>>>
>>> On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <matimontg at gmail.com>
>>> wrote:
>>>
>>>> Bradley, I must say you're the man! that did the trick, thanks a lot!
>>>>
>>>> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp <
>>>> blowekamp at mail.nih.gov> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
>>>>>
>>>>> Brad
>>>>>
>>>>> [1]
>>>>> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
>>>>>
>>>>> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm running this example:
>>>>>
>>>>> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>>>>>
>>>>> and I'm getting this result which is fine *but I need the white
>>>>> sections left due to the rotation to be black.* how can I achieve
>>>>> this?
>>>>>
>>>>> <Capture.JPG>
>>>>> ?
>>>>> _____________________________________
>>>>> 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.php
>>>>>
>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/0ecf93a6/attachment.html>

From matt.mccormick at kitware.com  Thu Nov 13 12:34:26 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 13 Nov 2014 12:34:26 -0500
Subject: [ITK-users] rescaling of volume
In-Reply-To: <CADZJ4hNXKa=aHp+AMDfUVfEe5Gmeot7cypV9UuVNLT_Xn0mcJQ@mail.gmail.com>
References: <CAE8+oFbP++MCp48rdrxRcj8nzJ3OxdtuJOyNaA1tFL6wSEmWfg@mail.gmail.com>
 <CADZJ4hOkMnvcBTAGXpGr+v4VNh_L4BJCTWGbmWmWyFGW0rxixQ@mail.gmail.com>
 <CAE8+oFZQibNko86_0qHwU-VEt5ZNEJB1yrYDT+PZMEkiGN0cOg@mail.gmail.com>
 <CADZJ4hNXKa=aHp+AMDfUVfEe5Gmeot7cypV9UuVNLT_Xn0mcJQ@mail.gmail.com>
Message-ID: <CALzTN-Qx+dvx+zy5Vg9T1poh7PBjxO3rzh52mvSM3ZxHGzm6Wg@mail.gmail.com>

Hi Rekha,

If you want to change the image spacing, it can be done like this [1].

HTH,
Matt

[1] http://itk.org/ITKExamples/src/Filtering/ImageGrid/ChangeImageOriginSpacingOrDirection/Documentation.html

On Wed, Nov 12, 2014 at 10:43 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Please keep the users list involved.
>
> This example may help you get started:
> http://www.itk.org/Wiki/ITK/Examples/ImageProcessing/ScaleTransform
>
>
> On Wed, Nov 12, 2014 at 10:37 AM, Rekha Pyage <rekha.pyage at gmail.com> wrote:
>> Yes..  Only spacing should be increased or decreased n number of voxels shud
>> remain same.. N physical extent should change according to the spacing..
>>
>> On Nov 12, 2014 8:21 PM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>>>
>>> Do want to scale it anoint the center of the volume?
>>>
>>> On Nov 12, 2014 4:18 AM, "Rekha Pyage" <rekha.pyage at gmail.com> wrote:
>>>>
>>>> hello bill..
>>>>
>>>> i am new to itk but m stuck up with the task of rescaling..
>>>> m using MRI data.. my main aim is to change the spacing but number of
>>>> voxels and slices should be same as the input.. only physical extent should
>>>> change.. i have been trying from past 15 days.. hope u help me...
>>>>
>>>> waiting for the positive response..
>>>>
>>>> --
>>>> with regards
>>>> rekha
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users

From matt.mccormick at kitware.com  Thu Nov 13 12:37:28 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 13 Nov 2014 12:37:28 -0500
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CAKKNfuL1PQjYe9PEhbEsqeMP_XoVoxawLMHypzXiT5mnWzmtHA@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
 <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
 <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>
 <CAKKNfuLOaoJ6RG6-BexkJutf9CikQOcrYR=-DJox-BbKNqHdwA@mail.gmail.com>
 <CAKKNfuLwkB-VVg0KOkVWqjWwZ-2+p-iNm6txnCH5qi4wM_3TMA@mail.gmail.com>
 <CAKKNfuL1PQjYe9PEhbEsqeMP_XoVoxawLMHypzXiT5mnWzmtHA@mail.gmail.com>
Message-ID: <CALzTN-Tn7mHJZfTOE2Gg7hu-mi1e=aokxKxqJ97sKbFf3ffaBw@mail.gmail.com>

Hi Matias,

This example may have a hint on how to write a series [1].

HTH,
Matt

[1] http://itk.org/Doxygen/html/IO_2ImageReadDicomSeriesWrite_8cxx-example.html

On Thu, Nov 13, 2014 at 12:18 PM, Matias Montroull <matimontg at gmail.com> wrote:
> Now I have another question. This example is just for one file, is there a
> way to do it for a directory containing a set of DICOM files?
>
> On Thu, Nov 13, 2014 at 2:16 PM, Matias Montroull <matimontg at gmail.com>
> wrote:
>>
>> never mind, it was my bad. The InputPixelType was unsigned char and should
>> have been unsigned short
>>
>> On Thu, Nov 13, 2014 at 2:14 PM, Matias Montroull <matimontg at gmail.com>
>> wrote:
>>>
>>> Bradley, as soon as I enter this line of code:
>>>
>>> typedef itk::GDCMImageIO ImageIOType;
>>> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
>>> writer->SetImageIO(gdcmImageIO);
>>>
>>> I get a bad image as result.. any ideas what could it be?
>>>
>>> On Thu, Nov 13, 2014 at 11:36 AM, Bradley Lowekamp
>>> <blowekamp at mail.nih.gov> wrote:
>>>>
>>>> Hello again,
>>>>
>>>> This is a non-trivial task where caution in needed to determine which
>>>> tags should be copied. But here is a basic example here:
>>>> http://itk.org/Wiki/ITK/Examples/DICOM/ResampleDICOM
>>>>
>>>> Brad
>>>>
>>>> On Nov 13, 2014, at 9:30 AM, Matias Montroull <matimontg at gmail.com>
>>>> wrote:
>>>>
>>>> I have one more question, it seems the writer method removes lot of tags
>>>> from the image, is there an option to keep the original tags such as patient
>>>> name, model, manufacture etc?
>>>>
>>>> On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <matimontg at gmail.com>
>>>> wrote:
>>>>>
>>>>> Bradley, I must say you're the man! that did the trick, thanks a lot!
>>>>>
>>>>> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp
>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
>>>>>>
>>>>>> Brad
>>>>>>
>>>>>> [1]
>>>>>> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
>>>>>>
>>>>>> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm running this example:
>>>>>>
>>>>>> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>>>>>>
>>>>>> and I'm getting this result which is fine but I need the white
>>>>>> sections left due to the rotation to be black. how can I achieve this?
>>>>>>
>>>>>> <Capture.JPG>
>>>>>>
>>>>>> _____________________________________
>>>>>> 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.php
>>>>>>
>>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>

From matimontg at gmail.com  Thu Nov 13 13:26:19 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Thu, 13 Nov 2014 15:26:19 -0300
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CALzTN-Tn7mHJZfTOE2Gg7hu-mi1e=aokxKxqJ97sKbFf3ffaBw@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
 <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
 <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>
 <CAKKNfuLOaoJ6RG6-BexkJutf9CikQOcrYR=-DJox-BbKNqHdwA@mail.gmail.com>
 <CAKKNfuLwkB-VVg0KOkVWqjWwZ-2+p-iNm6txnCH5qi4wM_3TMA@mail.gmail.com>
 <CAKKNfuL1PQjYe9PEhbEsqeMP_XoVoxawLMHypzXiT5mnWzmtHA@mail.gmail.com>
 <CALzTN-Tn7mHJZfTOE2Gg7hu-mi1e=aokxKxqJ97sKbFf3ffaBw@mail.gmail.com>
Message-ID: <CAKKNfuJJPA6gwa4fNMegkXH8T=t+D4XnFw-nk49dTrHPg5N-3Q@mail.gmail.com>

Thanks Matt, I'll give it a try

On Thu, Nov 13, 2014 at 2:37 PM, Matt McCormick <matt.mccormick at kitware.com>
wrote:

> Hi Matias,
>
> This example may have a hint on how to write a series [1].
>
> HTH,
> Matt
>
> [1]
> http://itk.org/Doxygen/html/IO_2ImageReadDicomSeriesWrite_8cxx-example.html
>
> On Thu, Nov 13, 2014 at 12:18 PM, Matias Montroull <matimontg at gmail.com>
> wrote:
> > Now I have another question. This example is just for one file, is there
> a
> > way to do it for a directory containing a set of DICOM files?
> >
> > On Thu, Nov 13, 2014 at 2:16 PM, Matias Montroull <matimontg at gmail.com>
> > wrote:
> >>
> >> never mind, it was my bad. The InputPixelType was unsigned char and
> should
> >> have been unsigned short
> >>
> >> On Thu, Nov 13, 2014 at 2:14 PM, Matias Montroull <matimontg at gmail.com>
> >> wrote:
> >>>
> >>> Bradley, as soon as I enter this line of code:
> >>>
> >>> typedef itk::GDCMImageIO ImageIOType;
> >>> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
> >>> writer->SetImageIO(gdcmImageIO);
> >>>
> >>> I get a bad image as result.. any ideas what could it be?
> >>>
> >>> On Thu, Nov 13, 2014 at 11:36 AM, Bradley Lowekamp
> >>> <blowekamp at mail.nih.gov> wrote:
> >>>>
> >>>> Hello again,
> >>>>
> >>>> This is a non-trivial task where caution in needed to determine which
> >>>> tags should be copied. But here is a basic example here:
> >>>> http://itk.org/Wiki/ITK/Examples/DICOM/ResampleDICOM
> >>>>
> >>>> Brad
> >>>>
> >>>> On Nov 13, 2014, at 9:30 AM, Matias Montroull <matimontg at gmail.com>
> >>>> wrote:
> >>>>
> >>>> I have one more question, it seems the writer method removes lot of
> tags
> >>>> from the image, is there an option to keep the original tags such as
> patient
> >>>> name, model, manufacture etc?
> >>>>
> >>>> On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <
> matimontg at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Bradley, I must say you're the man! that did the trick, thanks a lot!
> >>>>>
> >>>>> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp
> >>>>> <blowekamp at mail.nih.gov> wrote:
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
> >>>>>>
> >>>>>> Brad
> >>>>>>
> >>>>>> [1]
> >>>>>>
> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
> >>>>>>
> >>>>>> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm running this example:
> >>>>>>
> >>>>>>
> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
> >>>>>>
> >>>>>> and I'm getting this result which is fine but I need the white
> >>>>>> sections left due to the rotation to be black. how can I achieve
> this?
> >>>>>>
> >>>>>> <Capture.JPG>
> >>>>>>
> >>>>>> _____________________________________
> >>>>>> 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.php
> >>>>>>
> >>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
> > _____________________________________
> > 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.php
> >
> > 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://public.kitware.com/mailman/listinfo/insight-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141113/17f3bb05/attachment.html>

From rekha.pyage at gmail.com  Fri Nov 14 04:13:50 2014
From: rekha.pyage at gmail.com (rekhap)
Date: Fri, 14 Nov 2014 02:13:50 -0700 (MST)
Subject: [ITK-users] rescaling of volume
In-Reply-To: <CALzTN-Qx+dvx+zy5Vg9T1poh7PBjxO3rzh52mvSM3ZxHGzm6Wg@mail.gmail.com>
References: <CADZJ4hOkMnvcBTAGXpGr+v4VNh_L4BJCTWGbmWmWyFGW0rxixQ@mail.gmail.com>
 <CADZJ4hNXKa=aHp+AMDfUVfEe5Gmeot7cypV9UuVNLT_Xn0mcJQ@mail.gmail.com>
 <CALzTN-Qx+dvx+zy5Vg9T1poh7PBjxO3rzh52mvSM3ZxHGzm6Wg@mail.gmail.com>
Message-ID: <1415956430247-34901.post@n7.nabble.com>

thanku matt.

this is what i wanted.. but it is not fine for the z-direction... when i
increased the spacing in all direction.. z-direction is getting shrunk...





--
View this message in context: http://itk-users.7.n7.nabble.com/Re-ITK-users-rescaling-of-volume-tp34886p34901.html
Sent from the ITK - Users mailing list archive at Nabble.com.

From rekha.pyage at gmail.com  Fri Nov 14 05:18:30 2014
From: rekha.pyage at gmail.com (rekhap)
Date: Fri, 14 Nov 2014 03:18:30 -0700 (MST)
Subject: [ITK-users] rescaling of volume
In-Reply-To: <1415956430247-34901.post@n7.nabble.com>
References: <CADZJ4hOkMnvcBTAGXpGr+v4VNh_L4BJCTWGbmWmWyFGW0rxixQ@mail.gmail.com>
 <CADZJ4hNXKa=aHp+AMDfUVfEe5Gmeot7cypV9UuVNLT_Xn0mcJQ@mail.gmail.com>
 <CALzTN-Qx+dvx+zy5Vg9T1poh7PBjxO3rzh52mvSM3ZxHGzm6Wg@mail.gmail.com>
 <1415956430247-34901.post@n7.nabble.com>
Message-ID: <1415960310794-34902.post@n7.nabble.com>

can we set different spacing for different direction???



--
View this message in context: http://itk-users.7.n7.nabble.com/Re-ITK-users-rescaling-of-volume-tp34886p34902.html
Sent from the ITK - Users mailing list archive at Nabble.com.

From rekha.pyage at gmail.com  Fri Nov 14 06:25:24 2014
From: rekha.pyage at gmail.com (rekhap)
Date: Fri, 14 Nov 2014 04:25:24 -0700 (MST)
Subject: [ITK-users] rescaling of volume
In-Reply-To: <CALzTN-Qx+dvx+zy5Vg9T1poh7PBjxO3rzh52mvSM3ZxHGzm6Wg@mail.gmail.com>
References: <CADZJ4hOkMnvcBTAGXpGr+v4VNh_L4BJCTWGbmWmWyFGW0rxixQ@mail.gmail.com>
 <CADZJ4hNXKa=aHp+AMDfUVfEe5Gmeot7cypV9UuVNLT_Xn0mcJQ@mail.gmail.com>
 <CALzTN-Qx+dvx+zy5Vg9T1poh7PBjxO3rzh52mvSM3ZxHGzm6Wg@mail.gmail.com>
Message-ID: <1415964324566-34903.post@n7.nabble.com>

thanku matt..

this is what i was searching for..

but the output of the filter is not as expected when volume is rendered.
 original spacing is 0.85*0.85*7.07 amd wen i changed it to 0.1*0.1*1
instead of reducing the volume it has increased.. 



--
View this message in context: http://itk-users.7.n7.nabble.com/Re-ITK-users-rescaling-of-volume-tp34886p34903.html
Sent from the ITK - Users mailing list archive at Nabble.com.

From iyas.hamdan at gmail.com  Fri Nov 14 08:24:51 2014
From: iyas.hamdan at gmail.com (Iyas Hamdan)
Date: Fri, 14 Nov 2014 14:24:51 +0100
Subject: [ITK-users] problem using VTKImageToImageFilter
In-Reply-To: <CADZJ4hMJQV2gxNDM8c2KYBDJoFHZ2vnnMGFT2othafW=np_gUw@mail.gmail.com>
References: <CANH4YVjsRKbXyK3ybsOr1pypXsUtnK36G8L=ojsP4aLbcTKTYg@mail.gmail.com>
 <CADZJ4hMJQV2gxNDM8c2KYBDJoFHZ2vnnMGFT2othafW=np_gUw@mail.gmail.com>
Message-ID: <CANH4YVg6cV71aKDFh0wKq03G3z+A9O-rZ2RFTChBjboEfytz7A@mail.gmail.com>

Hi,

Thank you Bill for your answer,
And yes the type of my image is in fact float.

So is it that I cant convert a VTKimage of type float to a itkImage of type
short using this filter ? would that be the problem here ?
because other than that, I dont think there is a way of defining the input
image type for VTKImageToImageFilter, it only takes one parameter which is
the type of the output image.

So my only option here would be to cast my input type to match the output
type since its not implemented in the VTKImageToImageFilter right ?

thanks in advance,

Iyas



On Thu, Nov 13, 2014 at 2:14 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> It is telling you that the VTK image is float. Try printing the vtk image
> ImageVTK->Print(std::cout);
>
>
> On Thu, Nov 13, 2014 at 6:30 AM, Iyas Hamdan <iyas.hamdan at gmail.com>
> wrote:
> > Hi everyone!
> > I'm trying to read two DICOM series with VTK, and then register those two
> > volumes using ITK, so in this contexte I would have to convert the
> > vtkImageData into itk::Image.
> >
> > What i'm doing is the following:
> >
> > typedef itk::Image< signed short, 3> ImageType;
> > typedef itk::VTKImageToImageFilter< ImageType >
> VTKImageToImageFilterType;
> > VTKImageToImageFilterType::Pointer connector =
> > VTKImageToImageFilterType::New();
> > connector->SetInput(ImageVTK);
> > connector->Update();
> >
> > Where ImageVTK is my 3D volume and I visualized it so its reading the
> Dicom
> > series correctly.
> >
> > But I'm always getting this error when I reach the update():
> > VTKImageToImageFilter: Input scalar type is float but should be short.
> >
> > So what am I doing wrong here ?
> >
> > thanks in advance,
> >
> > Iyas
> >
> > _____________________________________
> > 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.php
> >
> > 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://public.kitware.com/mailman/listinfo/insight-users
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141114/a0aaca19/attachment.html>

From matimontg at gmail.com  Fri Nov 14 08:28:21 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Fri, 14 Nov 2014 10:28:21 -0300
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CAKKNfuJJPA6gwa4fNMegkXH8T=t+D4XnFw-nk49dTrHPg5N-3Q@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
 <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
 <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>
 <CAKKNfuLOaoJ6RG6-BexkJutf9CikQOcrYR=-DJox-BbKNqHdwA@mail.gmail.com>
 <CAKKNfuLwkB-VVg0KOkVWqjWwZ-2+p-iNm6txnCH5qi4wM_3TMA@mail.gmail.com>
 <CAKKNfuL1PQjYe9PEhbEsqeMP_XoVoxawLMHypzXiT5mnWzmtHA@mail.gmail.com>
 <CALzTN-Tn7mHJZfTOE2Gg7hu-mi1e=aokxKxqJ97sKbFf3ffaBw@mail.gmail.com>
 <CAKKNfuJJPA6gwa4fNMegkXH8T=t+D4XnFw-nk49dTrHPg5N-3Q@mail.gmail.com>
Message-ID: <CAKKNfuKsZDV8faNbZ-Fd==ShTbd+1UyL3VY0ks2485H9sV6HFg@mail.gmail.com>

I'm having hard times following the code in the example. RIght now I have
been able to rotate a dcm file one at a time, now I would like to input a
directory and output another directory with  the rotated images, I would
need some guidance for this task.
Can I just set the input as directory instead of a file for example?

On Thu, Nov 13, 2014 at 3:26 PM, Matias Montroull <matimontg at gmail.com>
wrote:

> Thanks Matt, I'll give it a try
>
> On Thu, Nov 13, 2014 at 2:37 PM, Matt McCormick <
> matt.mccormick at kitware.com> wrote:
>
>> Hi Matias,
>>
>> This example may have a hint on how to write a series [1].
>>
>> HTH,
>> Matt
>>
>> [1]
>> http://itk.org/Doxygen/html/IO_2ImageReadDicomSeriesWrite_8cxx-example.html
>>
>> On Thu, Nov 13, 2014 at 12:18 PM, Matias Montroull <matimontg at gmail.com>
>> wrote:
>> > Now I have another question. This example is just for one file, is
>> there a
>> > way to do it for a directory containing a set of DICOM files?
>> >
>> > On Thu, Nov 13, 2014 at 2:16 PM, Matias Montroull <matimontg at gmail.com>
>> > wrote:
>> >>
>> >> never mind, it was my bad. The InputPixelType was unsigned char and
>> should
>> >> have been unsigned short
>> >>
>> >> On Thu, Nov 13, 2014 at 2:14 PM, Matias Montroull <matimontg at gmail.com
>> >
>> >> wrote:
>> >>>
>> >>> Bradley, as soon as I enter this line of code:
>> >>>
>> >>> typedef itk::GDCMImageIO ImageIOType;
>> >>> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
>> >>> writer->SetImageIO(gdcmImageIO);
>> >>>
>> >>> I get a bad image as result.. any ideas what could it be?
>> >>>
>> >>> On Thu, Nov 13, 2014 at 11:36 AM, Bradley Lowekamp
>> >>> <blowekamp at mail.nih.gov> wrote:
>> >>>>
>> >>>> Hello again,
>> >>>>
>> >>>> This is a non-trivial task where caution in needed to determine which
>> >>>> tags should be copied. But here is a basic example here:
>> >>>> http://itk.org/Wiki/ITK/Examples/DICOM/ResampleDICOM
>> >>>>
>> >>>> Brad
>> >>>>
>> >>>> On Nov 13, 2014, at 9:30 AM, Matias Montroull <matimontg at gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>> I have one more question, it seems the writer method removes lot of
>> tags
>> >>>> from the image, is there an option to keep the original tags such as
>> patient
>> >>>> name, model, manufacture etc?
>> >>>>
>> >>>> On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <
>> matimontg at gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Bradley, I must say you're the man! that did the trick, thanks a
>> lot!
>> >>>>>
>> >>>>> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp
>> >>>>> <blowekamp at mail.nih.gov> wrote:
>> >>>>>>
>> >>>>>> Hello,
>> >>>>>>
>> >>>>>> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
>> >>>>>>
>> >>>>>> Brad
>> >>>>>>
>> >>>>>> [1]
>> >>>>>>
>> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
>> >>>>>>
>> >>>>>> On Nov 13, 2014, at 8:56 AM, Matias Montroull <matimontg at gmail.com
>> >
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> I'm running this example:
>> >>>>>>
>> >>>>>>
>> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>> >>>>>>
>> >>>>>> and I'm getting this result which is fine but I need the white
>> >>>>>> sections left due to the rotation to be black. how can I achieve
>> this?
>> >>>>>>
>> >>>>>> <Capture.JPG>
>> >>>>>>
>> >>>>>> _____________________________________
>> >>>>>> 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.php
>> >>>>>>
>> >>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>> > _____________________________________
>> > 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.php
>> >
>> > 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://public.kitware.com/mailman/listinfo/insight-users
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141114/45ff0dbc/attachment-0001.html>

From iyas.hamdan at gmail.com  Fri Nov 14 08:50:31 2014
From: iyas.hamdan at gmail.com (Iyas Hamdan)
Date: Fri, 14 Nov 2014 14:50:31 +0100
Subject: [ITK-users] problem using VTKImageToImageFilter
In-Reply-To: <CANH4YVg6cV71aKDFh0wKq03G3z+A9O-rZ2RFTChBjboEfytz7A@mail.gmail.com>
References: <CANH4YVjsRKbXyK3ybsOr1pypXsUtnK36G8L=ojsP4aLbcTKTYg@mail.gmail.com>
 <CADZJ4hMJQV2gxNDM8c2KYBDJoFHZ2vnnMGFT2othafW=np_gUw@mail.gmail.com>
 <CANH4YVg6cV71aKDFh0wKq03G3z+A9O-rZ2RFTChBjboEfytz7A@mail.gmail.com>
Message-ID: <CANH4YVieTV6RJG_B_+AdqfvFMxJgETJMkGANj70TYz-mpSOo_Q@mail.gmail.com>

I've just tried the vtkImageCast and put the output type to short and now
everything works just fine,

Thanks,

Iyas

On Fri, Nov 14, 2014 at 2:24 PM, Iyas Hamdan <iyas.hamdan at gmail.com> wrote:

> Hi,
>
> Thank you Bill for your answer,
> And yes the type of my image is in fact float.
>
> So is it that I cant convert a VTKimage of type float to a itkImage of
> type short using this filter ? would that be the problem here ?
> because other than that, I dont think there is a way of defining the input
> image type for VTKImageToImageFilter, it only takes one parameter which is
> the type of the output image.
>
> So my only option here would be to cast my input type to match the output
> type since its not implemented in the VTKImageToImageFilter right ?
>
> thanks in advance,
>
> Iyas
>
>
>
> On Thu, Nov 13, 2014 at 2:14 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
>> It is telling you that the VTK image is float. Try printing the vtk image
>> ImageVTK->Print(std::cout);
>>
>>
>> On Thu, Nov 13, 2014 at 6:30 AM, Iyas Hamdan <iyas.hamdan at gmail.com>
>> wrote:
>> > Hi everyone!
>> > I'm trying to read two DICOM series with VTK, and then register those
>> two
>> > volumes using ITK, so in this contexte I would have to convert the
>> > vtkImageData into itk::Image.
>> >
>> > What i'm doing is the following:
>> >
>> > typedef itk::Image< signed short, 3> ImageType;
>> > typedef itk::VTKImageToImageFilter< ImageType >
>> VTKImageToImageFilterType;
>> > VTKImageToImageFilterType::Pointer connector =
>> > VTKImageToImageFilterType::New();
>> > connector->SetInput(ImageVTK);
>> > connector->Update();
>> >
>> > Where ImageVTK is my 3D volume and I visualized it so its reading the
>> Dicom
>> > series correctly.
>> >
>> > But I'm always getting this error when I reach the update():
>> > VTKImageToImageFilter: Input scalar type is float but should be short.
>> >
>> > So what am I doing wrong here ?
>> >
>> > thanks in advance,
>> >
>> > Iyas
>> >
>> > _____________________________________
>> > 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.php
>> >
>> > 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://public.kitware.com/mailman/listinfo/insight-users
>> >
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141114/ca853199/attachment.html>

From blowekamp at mail.nih.gov  Fri Nov 14 09:53:06 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 14 Nov 2014 09:53:06 -0500
Subject: [ITK-users] TIFFImageIO refactoring, please test
Message-ID: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>

Greetings,

I have recently refactored ITK's TIFFImageIO to remove a significant amount of dead code, and improve performance up to 3-5X. A number of bug related to reading BigTIFF files have been addressed. Additionally, Tiff tags are now place into the Meta-DataDictionary to allow access to additional TIFF fields such as OME-XML tags ( Originally contributed by Richard Beare http://www.insight-journal.org/browse/publication/728 ).

Significant performance improvements were made to both scalar images and palette images. Handling of certain orientations are now "better" handled, while not changing how the default TOPLEFT orientation is loaded or written. There were a number of cases which appear unreachable and illogical such as support from Zeiss two-componet types, and support for some type of SGI tiled tiff as a 3D image. These were removed.

If you are an active user of TIFF images with ITK, please checkout the latest ITK master and test the refactored TIFFImageIO.

Thanks,
Brad

p.s. Here is the git log for the recent changes.

$git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..

commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Fri Oct 31 14:25:13 2014 -0400

    ENH: adding TIFFImageIO test for RGB palette images
    
    Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0

commit 9adc54c7f53b4da84a41f500d561ae494cb85158
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Fri Oct 24 13:42:02 2014 -0400

    BUG: Adding missing parentheses around boolean expression
    
    Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79

commit 40afd95161727be3274f8094ce19fe45e2c3aa50
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Wed Oct 22 15:05:39 2014 -0400

    PERF: Refactor color table lookup
    
    Change to use a index lookup for the color and gray scale
    palettes. The remove excessive exception checking done on a per pixel
    basis with the GetColor method. Additionally the InitializeColor
    method was change do initialize the color palette variables.
    
    An exception no longer occurs when an index exceeds the number of
    entries in a palette. Instead a module operator is used to prevent
    out of bounds memory access.
    
    Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9

commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Fri Oct 3 09:01:28 2014 -0400

    ENH: Refactor per pixel conversion function to per scan-line method
    
    This patch changes the implementation of conversion from the TIFF
    scanline buffer from a function call on each pixel to a function call
    per scanline. The enable efficient copying of similar scanline and
    better reuse of variables for palette look ups.
    
    This can increase the performance of reading grayscale images by up to
    3X for cached files.
    
    Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059

commit 8e488f40e8cb7defa046700798b77e3944ac33c9
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Tue Sep 30 08:56:58 2014 -0400

    ENH: RGBA read images should stay unchanged.
    
    The image that are read with the TIFFReadRGBAImage should not have
    their pixel types converted. This libtiff method always read images
    into an ABGR uint8 format. When the tiff file is read by this method
    it should report that uint8 and RGBA is the component an pixel type
    for the image. This allows the standard ITK buffer conversion to be
    performed.
    
    This change remove extra cases and template instantiations.
    
    Additionally the RGBAImageToBuffer method was flipping the image along
    the y-axis, this has been more explicitly done with the call to
    TIFFReadRGBAImageOriented.
    
    Change-Id: I022b12921d406edb09730f905213b0db811f1bd4

commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Fri Sep 26 14:04:09 2014 -0400

    ENH: Remove support for TIFF tile as 3D and dead code
    
    This TIFF file format is a file which contains a list of directories,
    if there are no directories in the file it's not a valid tiff. Code
    which supported 3D tiles was conditioned on a file with no directories
    and no data. Additional code was removed related to a private SGI tag
    TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
    invalid case.
    
    Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6

commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Mon Oct 6 10:01:50 2014 -0400

    BUG: Address Coverity warning about null pointer dereferences
    
    The patch addressed the following Coverity warnings:
    
    ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
    itkTIFFImageIO.cxx:
    1192 in itk::TIFFImageIO::ReadTIFFTags()()
    
    ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
    itkTIFFImageIO.cxx:
    1096 in itk::TIFFImageIO::ReadTIFFTags()()
    
    ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
    itkTIFFImageIO.cxx:
    1100 in itk::TIFFImageIO::ReadTIFFTags()()
    Last login: Fri Oct  3 19:47:29 on ttys004
    
    Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da

commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Fri Sep 26 11:04:38 2014 -0400

    ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
    
    Refactoring of the pixelOffset to include the number of components
    remove the need for a separate block for RGB multi-component files.

commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Wed Sep 24 15:00:54 2014 -0400

    ENH: add arbitrary TIFF TAGs to meta-data dictionary
    
    A more general approach to adding custom tiff tags to the meta-data
    dictionary has been used based on the implementation of libtiff's
    PrintDirectory method and the libtiff "Defining New TIFF Tags"
    documentation.
    
    Additionally a new test image was added generated in Photoshop, which
    has a novel pixel layout, and also contains additional tag types such
    as byte, and size specified ascii.
    
    Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d

commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Mon Sep 22 15:08:36 2014 -0400

    BUG: Use array delete operator for array new allocations
    
    Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150

commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Tue Sep 23 11:14:15 2014 -0400

    STYLE: Fix minor kwstyle defects in test and test results
    
    Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846

commit 869f3275120646829b27d5cd75c23800d9df01cd
Author: Richard Beare <Richard.Beare at ieee.org>
Date:   Tue Sep 23 11:11:34 2014 -0400

    ENH: Include TIFF tags in the MetaDataDictionary
    
    Add contribution from the Insight Journal:
    http://hdl.handle.net/10380/3170
    
    Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0

commit c7a76c9acb319862647a651a2060dd3fb16560d7
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Mon Sep 22 14:46:44 2014 -0400

    BUG: Remove dead separated plannar code, add test
    
    The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
    preceded by a unreachable due to a conditional and exception
    check. Support for this configuration remains in the TIFFReadRGBAImage
    method. A test for the configuration has been added.
    
    A new input image is added from the from the libTiff test images:
    
    PlanarConfiguration = 2 (separated samples)
    -------------------------------------------
    oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
    
    Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04

commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Mon Sep 22 13:32:23 2014 -0400

    BUG: Fix right oriented tiff images
    
    The TIFFImageIO::ReadGenericImage method correctly handled top-left
    oriented images, and bottom-right image, however images oriented with
    right were non-correctly handled. These cases are now handled
    correctly by the TIFFRGBAImage generic path.
    
    New test images of the cthead1 image were added which have been
    flipped the to the different orientation, and the matching orientation
    tag specified so that they should all be read as equivalent
    images. These have been added as a test case.
    
    Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15

commit 6263f4389026f1bd770054e86c428b56629d705b
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Thu Sep 18 16:20:41 2014 -0400

    ENH: Refactor duplicated code to read a page
    
    Created a method to read a single page or sub-image in a tiff
    file. Simular code was both in the ReadVolume method for 3-d and the
    Read method for 2-d. The code block from ReadVolume was used because
    it contained more typed cases. There for this patch does improve the
    2d reading capabilities for tiffio, so that they are consistent with
    the 3d.
    
    Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443

commit 233571f1e626917bce872e450907bc8e8521e371
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Thu Sep 18 14:59:58 2014 -0400

    ENH: Refactor method to convert RGBA image to output buffer
    
    BUG: Address overflow issue when computing page offset with
    TIFFReadRGBAImage method.
    
    Extract repeated code to convert from ReadRGBAImage to output image
    type.
    
    Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b

commit 1cd59825fa65f1123726a32f67c1a443015b40ec
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Thu Sep 18 11:30:41 2014 -0400

    BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO )
    
    There are no tests for this branch of code. It only works in 3D under
    certain cases. There are apparent bugs in the code such as not setting
    all of the input image, and logically dead branches. Some downloaded
    test images for similar described format do not load. This may effect
    files with the extensions tif, tiff, or lsm.
    
    Removal of this code will enable expansion of the current code to more
    generically support multi-sample per pixel images.
    
    For more robust reading of this type of image the SCIFIO remote
    module should be used.
    
    Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e

commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Tue Sep 16 15:31:52 2014 -0400

    ENH: Refactor GenericReadImage into template function
    
    Reduce code duplication by using template method.
    
    Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0

commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Tue Sep 16 12:09:59 2014 -0400

    ENH: Refactor ReadTwoSamplePerPixelImage into template function
    
    Reduce code duplication by using template method.
    
    Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e

commit 0b573136d636613217df9683ea846db8039f9312
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Tue Sep 16 11:12:45 2014 -0400

    ENH: Extract TiffReaderInternal to separate file
    
    Refactored private class to be in separate private header.
    
    Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d

commit 6791b4a3613aade07e3f11f765f1316faf03b113
Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:   Mon Sep 15 16:46:26 2014 -0400

    BUG: Fix overflows computing size of read tiff image
    
    When multiplying the height and width of an tiff image (32-bits),
    at least one element should be converted to size_t to help prevent
    numeric overflow.
    
    This change enables reading of larger RGB and large 2D image, that
    were previously truncated when reading. This does not address
    potential buffer overflow or resource limits which could occur.
    
    Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a

commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
Author: Matt McCormick <matt.mccormick at kitware.com>
Date:   Mon Aug 25 00:35:48 2014 -0400

    COMP: Do not use _stat64 with MinGW-32.
    
    Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
    including _stat64.  Do not use use _stat64 in TIFFImageIO when building with
    MinGW-32.
    
    Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141114/5772acb5/attachment.html>

From bill.lorensen at gmail.com  Fri Nov 14 10:04:52 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 14 Nov 2014 10:04:52 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
Message-ID: <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>

Brad,

I recently added tiled image reading to VTK's tiff reader. Do you
think that would be useful in IUTK. I don't know how often tiled tiff
images are encountered.

BTW I do not mean tiled pyramid tiff images.

Bill

On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Greetings,
>
> I have recently refactored ITK's TIFFImageIO to remove a significant amount
> of dead code, and improve performance up to 3-5X. A number of bug related to
> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
> place into the Meta-DataDictionary to allow access to additional TIFF fields
> such as OME-XML tags ( Originally contributed by Richard Beare
> http://www.insight-journal.org/browse/publication/728 ).
>
> Significant performance improvements were made to both scalar images and
> palette images. Handling of certain orientations are now "better" handled,
> while not changing how the default TOPLEFT orientation is loaded or written.
> There were a number of cases which appear unreachable and illogical such as
> support from Zeiss two-componet types, and support for some type of SGI
> tiled tiff as a 3D image. These were removed.
>
> If you are an active user of TIFF images with ITK, please checkout the
> latest ITK master and test the refactored TIFFImageIO.
>
> Thanks,
> Brad
>
> p.s. Here is the git log for the recent changes.
>
> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>
> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Oct 31 14:25:13 2014 -0400
>
>     ENH: adding TIFFImageIO test for RGB palette images
>
>     Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>
> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Oct 24 13:42:02 2014 -0400
>
>     BUG: Adding missing parentheses around boolean expression
>
>     Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>
> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Wed Oct 22 15:05:39 2014 -0400
>
>     PERF: Refactor color table lookup
>
>     Change to use a index lookup for the color and gray scale
>     palettes. The remove excessive exception checking done on a per pixel
>     basis with the GetColor method. Additionally the InitializeColor
>     method was change do initialize the color palette variables.
>
>     An exception no longer occurs when an index exceeds the number of
>     entries in a palette. Instead a module operator is used to prevent
>     out of bounds memory access.
>
>     Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>
> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Oct 3 09:01:28 2014 -0400
>
>     ENH: Refactor per pixel conversion function to per scan-line method
>
>     This patch changes the implementation of conversion from the TIFF
>     scanline buffer from a function call on each pixel to a function call
>     per scanline. The enable efficient copying of similar scanline and
>     better reuse of variables for palette look ups.
>
>     This can increase the performance of reading grayscale images by up to
>     3X for cached files.
>
>     Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>
> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 30 08:56:58 2014 -0400
>
>     ENH: RGBA read images should stay unchanged.
>
>     The image that are read with the TIFFReadRGBAImage should not have
>     their pixel types converted. This libtiff method always read images
>     into an ABGR uint8 format. When the tiff file is read by this method
>     it should report that uint8 and RGBA is the component an pixel type
>     for the image. This allows the standard ITK buffer conversion to be
>     performed.
>
>     This change remove extra cases and template instantiations.
>
>     Additionally the RGBAImageToBuffer method was flipping the image along
>     the y-axis, this has been more explicitly done with the call to
>     TIFFReadRGBAImageOriented.
>
>     Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>
> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Sep 26 14:04:09 2014 -0400
>
>     ENH: Remove support for TIFF tile as 3D and dead code
>
>     This TIFF file format is a file which contains a list of directories,
>     if there are no directories in the file it's not a valid tiff. Code
>     which supported 3D tiles was conditioned on a file with no directories
>     and no data. Additional code was removed related to a private SGI tag
>     TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>     invalid case.
>
>     Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>
> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Oct 6 10:01:50 2014 -0400
>
>     BUG: Address Coverity warning about null pointer dereferences
>
>     The patch addressed the following Coverity warnings:
>
>     ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>     itkTIFFImageIO.cxx:
>     1192 in itk::TIFFImageIO::ReadTIFFTags()()
>
>     ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>     itkTIFFImageIO.cxx:
>     1096 in itk::TIFFImageIO::ReadTIFFTags()()
>
>     ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>     itkTIFFImageIO.cxx:
>     1100 in itk::TIFFImageIO::ReadTIFFTags()()
>     Last login: Fri Oct  3 19:47:29 on ttys004
>
>     Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>
> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Sep 26 11:04:38 2014 -0400
>
>     ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>
>     Refactoring of the pixelOffset to include the number of components
>     remove the need for a separate block for RGB multi-component files.
>
> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Wed Sep 24 15:00:54 2014 -0400
>
>     ENH: add arbitrary TIFF TAGs to meta-data dictionary
>
>     A more general approach to adding custom tiff tags to the meta-data
>     dictionary has been used based on the implementation of libtiff's
>     PrintDirectory method and the libtiff "Defining New TIFF Tags"
>     documentation.
>
>     Additionally a new test image was added generated in Photoshop, which
>     has a novel pixel layout, and also contains additional tag types such
>     as byte, and size specified ascii.
>
>     Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>
> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Sep 22 15:08:36 2014 -0400
>
>     BUG: Use array delete operator for array new allocations
>
>     Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>
> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 23 11:14:15 2014 -0400
>
>     STYLE: Fix minor kwstyle defects in test and test results
>
>     Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>
> commit 869f3275120646829b27d5cd75c23800d9df01cd
> Author: Richard Beare <Richard.Beare at ieee.org>
> Date:   Tue Sep 23 11:11:34 2014 -0400
>
>     ENH: Include TIFF tags in the MetaDataDictionary
>
>     Add contribution from the Insight Journal:
>     http://hdl.handle.net/10380/3170
>
>     Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>
> commit c7a76c9acb319862647a651a2060dd3fb16560d7
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Sep 22 14:46:44 2014 -0400
>
>     BUG: Remove dead separated plannar code, add test
>
>     The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>     preceded by a unreachable due to a conditional and exception
>     check. Support for this configuration remains in the TIFFReadRGBAImage
>     method. A test for the configuration has been added.
>
>     A new input image is added from the from the libTiff test images:
>
>     PlanarConfiguration = 2 (separated samples)
>     -------------------------------------------
>     oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>
>     Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>
> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Sep 22 13:32:23 2014 -0400
>
>     BUG: Fix right oriented tiff images
>
>     The TIFFImageIO::ReadGenericImage method correctly handled top-left
>     oriented images, and bottom-right image, however images oriented with
>     right were non-correctly handled. These cases are now handled
>     correctly by the TIFFRGBAImage generic path.
>
>     New test images of the cthead1 image were added which have been
>     flipped the to the different orientation, and the matching orientation
>     tag specified so that they should all be read as equivalent
>     images. These have been added as a test case.
>
>     Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>
> commit 6263f4389026f1bd770054e86c428b56629d705b
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Thu Sep 18 16:20:41 2014 -0400
>
>     ENH: Refactor duplicated code to read a page
>
>     Created a method to read a single page or sub-image in a tiff
>     file. Simular code was both in the ReadVolume method for 3-d and the
>     Read method for 2-d. The code block from ReadVolume was used because
>     it contained more typed cases. There for this patch does improve the
>     2d reading capabilities for tiffio, so that they are consistent with
>     the 3d.
>
>     Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>
> commit 233571f1e626917bce872e450907bc8e8521e371
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Thu Sep 18 14:59:58 2014 -0400
>
>     ENH: Refactor method to convert RGBA image to output buffer
>
>     BUG: Address overflow issue when computing page offset with
>     TIFFReadRGBAImage method.
>
>     Extract repeated code to convert from ReadRGBAImage to output image
>     type.
>
>     Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>
> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Thu Sep 18 11:30:41 2014 -0400
>
>     BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
> )
>
>     There are no tests for this branch of code. It only works in 3D under
>     certain cases. There are apparent bugs in the code such as not setting
>     all of the input image, and logically dead branches. Some downloaded
>     test images for similar described format do not load. This may effect
>     files with the extensions tif, tiff, or lsm.
>
>     Removal of this code will enable expansion of the current code to more
>     generically support multi-sample per pixel images.
>
>     For more robust reading of this type of image the SCIFIO remote
>     module should be used.
>
>     Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>
> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 16 15:31:52 2014 -0400
>
>     ENH: Refactor GenericReadImage into template function
>
>     Reduce code duplication by using template method.
>
>     Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>
> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 16 12:09:59 2014 -0400
>
>     ENH: Refactor ReadTwoSamplePerPixelImage into template function
>
>     Reduce code duplication by using template method.
>
>     Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>
> commit 0b573136d636613217df9683ea846db8039f9312
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 16 11:12:45 2014 -0400
>
>     ENH: Extract TiffReaderInternal to separate file
>
>     Refactored private class to be in separate private header.
>
>     Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>
> commit 6791b4a3613aade07e3f11f765f1316faf03b113
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Sep 15 16:46:26 2014 -0400
>
>     BUG: Fix overflows computing size of read tiff image
>
>     When multiplying the height and width of an tiff image (32-bits),
>     at least one element should be converted to size_t to help prevent
>     numeric overflow.
>
>     This change enables reading of larger RGB and large 2D image, that
>     were previously truncated when reading. This does not address
>     potential buffer overflow or resource limits which could occur.
>
>     Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>
> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
> Author: Matt McCormick <matt.mccormick at kitware.com>
> Date:   Mon Aug 25 00:35:48 2014 -0400
>
>     COMP: Do not use _stat64 with MinGW-32.
>
>     Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>     including _stat64.  Do not use use _stat64 in TIFFImageIO when building
> with
>     MinGW-32.
>
>     Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>
>
>
>
> _______________________________________________
> 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://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>



-- 
Unpaid intern in BillsBasement at noware dot com

From blowekamp at mail.nih.gov  Fri Nov 14 10:19:02 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 14 Nov 2014 10:19:02 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
Message-ID: <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>

Bill,

There was a tile block of code before, but that was not covered, looked unreachable and was removed.

Currently there are two ways that a tiff page can be read with the TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method from libtiff is fairly robust but reads the image into an RGBA buffer so is not memory efficient. Our custom method uses the scanline method [1], which should work with both stripped and tiled pages. 

But please test, and add a test? I'm not 100% if there is a test image for tiled images.

Where the difference between stripped and tiled images would really matter is streaming, but that is not there...yet.

Brad

[1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines


On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:

> Brad,
> 
> I recently added tiled image reading to VTK's tiff reader. Do you
> think that would be useful in IUTK. I don't know how often tiled tiff
> images are encountered.
> 
> BTW I do not mean tiled pyramid tiff images.
> 
> Bill
> 
> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Greetings,
>> 
>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>> of dead code, and improve performance up to 3-5X. A number of bug related to
>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>> such as OME-XML tags ( Originally contributed by Richard Beare
>> http://www.insight-journal.org/browse/publication/728 ).
>> 
>> Significant performance improvements were made to both scalar images and
>> palette images. Handling of certain orientations are now "better" handled,
>> while not changing how the default TOPLEFT orientation is loaded or written.
>> There were a number of cases which appear unreachable and illogical such as
>> support from Zeiss two-componet types, and support for some type of SGI
>> tiled tiff as a 3D image. These were removed.
>> 
>> If you are an active user of TIFF images with ITK, please checkout the
>> latest ITK master and test the refactored TIFFImageIO.
>> 
>> Thanks,
>> Brad
>> 
>> p.s. Here is the git log for the recent changes.
>> 
>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>> 
>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 31 14:25:13 2014 -0400
>> 
>>    ENH: adding TIFFImageIO test for RGB palette images
>> 
>>    Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>> 
>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 24 13:42:02 2014 -0400
>> 
>>    BUG: Adding missing parentheses around boolean expression
>> 
>>    Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>> 
>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Wed Oct 22 15:05:39 2014 -0400
>> 
>>    PERF: Refactor color table lookup
>> 
>>    Change to use a index lookup for the color and gray scale
>>    palettes. The remove excessive exception checking done on a per pixel
>>    basis with the GetColor method. Additionally the InitializeColor
>>    method was change do initialize the color palette variables.
>> 
>>    An exception no longer occurs when an index exceeds the number of
>>    entries in a palette. Instead a module operator is used to prevent
>>    out of bounds memory access.
>> 
>>    Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>> 
>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 3 09:01:28 2014 -0400
>> 
>>    ENH: Refactor per pixel conversion function to per scan-line method
>> 
>>    This patch changes the implementation of conversion from the TIFF
>>    scanline buffer from a function call on each pixel to a function call
>>    per scanline. The enable efficient copying of similar scanline and
>>    better reuse of variables for palette look ups.
>> 
>>    This can increase the performance of reading grayscale images by up to
>>    3X for cached files.
>> 
>>    Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>> 
>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 30 08:56:58 2014 -0400
>> 
>>    ENH: RGBA read images should stay unchanged.
>> 
>>    The image that are read with the TIFFReadRGBAImage should not have
>>    their pixel types converted. This libtiff method always read images
>>    into an ABGR uint8 format. When the tiff file is read by this method
>>    it should report that uint8 and RGBA is the component an pixel type
>>    for the image. This allows the standard ITK buffer conversion to be
>>    performed.
>> 
>>    This change remove extra cases and template instantiations.
>> 
>>    Additionally the RGBAImageToBuffer method was flipping the image along
>>    the y-axis, this has been more explicitly done with the call to
>>    TIFFReadRGBAImageOriented.
>> 
>>    Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>> 
>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Sep 26 14:04:09 2014 -0400
>> 
>>    ENH: Remove support for TIFF tile as 3D and dead code
>> 
>>    This TIFF file format is a file which contains a list of directories,
>>    if there are no directories in the file it's not a valid tiff. Code
>>    which supported 3D tiles was conditioned on a file with no directories
>>    and no data. Additional code was removed related to a private SGI tag
>>    TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>>    invalid case.
>> 
>>    Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>> 
>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Oct 6 10:01:50 2014 -0400
>> 
>>    BUG: Address Coverity warning about null pointer dereferences
>> 
>>    The patch addressed the following Coverity warnings:
>> 
>>    ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>>    itkTIFFImageIO.cxx:
>>    1192 in itk::TIFFImageIO::ReadTIFFTags()()
>> 
>>    ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>>    itkTIFFImageIO.cxx:
>>    1096 in itk::TIFFImageIO::ReadTIFFTags()()
>> 
>>    ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>>    itkTIFFImageIO.cxx:
>>    1100 in itk::TIFFImageIO::ReadTIFFTags()()
>>    Last login: Fri Oct  3 19:47:29 on ttys004
>> 
>>    Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>> 
>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Sep 26 11:04:38 2014 -0400
>> 
>>    ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>> 
>>    Refactoring of the pixelOffset to include the number of components
>>    remove the need for a separate block for RGB multi-component files.
>> 
>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Wed Sep 24 15:00:54 2014 -0400
>> 
>>    ENH: add arbitrary TIFF TAGs to meta-data dictionary
>> 
>>    A more general approach to adding custom tiff tags to the meta-data
>>    dictionary has been used based on the implementation of libtiff's
>>    PrintDirectory method and the libtiff "Defining New TIFF Tags"
>>    documentation.
>> 
>>    Additionally a new test image was added generated in Photoshop, which
>>    has a novel pixel layout, and also contains additional tag types such
>>    as byte, and size specified ascii.
>> 
>>    Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>> 
>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 15:08:36 2014 -0400
>> 
>>    BUG: Use array delete operator for array new allocations
>> 
>>    Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>> 
>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 23 11:14:15 2014 -0400
>> 
>>    STYLE: Fix minor kwstyle defects in test and test results
>> 
>>    Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>> 
>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>> Author: Richard Beare <Richard.Beare at ieee.org>
>> Date:   Tue Sep 23 11:11:34 2014 -0400
>> 
>>    ENH: Include TIFF tags in the MetaDataDictionary
>> 
>>    Add contribution from the Insight Journal:
>>    http://hdl.handle.net/10380/3170
>> 
>>    Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>> 
>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 14:46:44 2014 -0400
>> 
>>    BUG: Remove dead separated plannar code, add test
>> 
>>    The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>>    preceded by a unreachable due to a conditional and exception
>>    check. Support for this configuration remains in the TIFFReadRGBAImage
>>    method. A test for the configuration has been added.
>> 
>>    A new input image is added from the from the libTiff test images:
>> 
>>    PlanarConfiguration = 2 (separated samples)
>>    -------------------------------------------
>>    oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>> 
>>    Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>> 
>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 13:32:23 2014 -0400
>> 
>>    BUG: Fix right oriented tiff images
>> 
>>    The TIFFImageIO::ReadGenericImage method correctly handled top-left
>>    oriented images, and bottom-right image, however images oriented with
>>    right were non-correctly handled. These cases are now handled
>>    correctly by the TIFFRGBAImage generic path.
>> 
>>    New test images of the cthead1 image were added which have been
>>    flipped the to the different orientation, and the matching orientation
>>    tag specified so that they should all be read as equivalent
>>    images. These have been added as a test case.
>> 
>>    Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>> 
>> commit 6263f4389026f1bd770054e86c428b56629d705b
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 16:20:41 2014 -0400
>> 
>>    ENH: Refactor duplicated code to read a page
>> 
>>    Created a method to read a single page or sub-image in a tiff
>>    file. Simular code was both in the ReadVolume method for 3-d and the
>>    Read method for 2-d. The code block from ReadVolume was used because
>>    it contained more typed cases. There for this patch does improve the
>>    2d reading capabilities for tiffio, so that they are consistent with
>>    the 3d.
>> 
>>    Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>> 
>> commit 233571f1e626917bce872e450907bc8e8521e371
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 14:59:58 2014 -0400
>> 
>>    ENH: Refactor method to convert RGBA image to output buffer
>> 
>>    BUG: Address overflow issue when computing page offset with
>>    TIFFReadRGBAImage method.
>> 
>>    Extract repeated code to convert from ReadRGBAImage to output image
>>    type.
>> 
>>    Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>> 
>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 11:30:41 2014 -0400
>> 
>>    BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>> )
>> 
>>    There are no tests for this branch of code. It only works in 3D under
>>    certain cases. There are apparent bugs in the code such as not setting
>>    all of the input image, and logically dead branches. Some downloaded
>>    test images for similar described format do not load. This may effect
>>    files with the extensions tif, tiff, or lsm.
>> 
>>    Removal of this code will enable expansion of the current code to more
>>    generically support multi-sample per pixel images.
>> 
>>    For more robust reading of this type of image the SCIFIO remote
>>    module should be used.
>> 
>>    Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>> 
>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 15:31:52 2014 -0400
>> 
>>    ENH: Refactor GenericReadImage into template function
>> 
>>    Reduce code duplication by using template method.
>> 
>>    Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>> 
>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 12:09:59 2014 -0400
>> 
>>    ENH: Refactor ReadTwoSamplePerPixelImage into template function
>> 
>>    Reduce code duplication by using template method.
>> 
>>    Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>> 
>> commit 0b573136d636613217df9683ea846db8039f9312
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 11:12:45 2014 -0400
>> 
>>    ENH: Extract TiffReaderInternal to separate file
>> 
>>    Refactored private class to be in separate private header.
>> 
>>    Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>> 
>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 15 16:46:26 2014 -0400
>> 
>>    BUG: Fix overflows computing size of read tiff image
>> 
>>    When multiplying the height and width of an tiff image (32-bits),
>>    at least one element should be converted to size_t to help prevent
>>    numeric overflow.
>> 
>>    This change enables reading of larger RGB and large 2D image, that
>>    were previously truncated when reading. This does not address
>>    potential buffer overflow or resource limits which could occur.
>> 
>>    Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>> 
>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>> Author: Matt McCormick <matt.mccormick at kitware.com>
>> Date:   Mon Aug 25 00:35:48 2014 -0400
>> 
>>    COMP: Do not use _stat64 with MinGW-32.
>> 
>>    Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>>    including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>> with
>>    MinGW-32.
>> 
>>    Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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://kitware.com/products/protraining.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-developers
>> 
> 
> 
> 
> -- 
> Unpaid intern in BillsBasement at noware dot com


From bill.lorensen at gmail.com  Fri Nov 14 10:25:12 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 14 Nov 2014 10:25:12 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
Message-ID: <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>

There is a TIFFReadTile call in lib tiff. I some tiled images I will
try with the updated itk reader. I'll be really syprised if it works
since reading tiled images is tricky and took quite a bit of code.

I'll keep you posted.

Bill

On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Bill,
>
> There was a tile block of code before, but that was not covered, looked unreachable and was removed.
>
> Currently there are two ways that a tiff page can be read with the TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method from libtiff is fairly robust but reads the image into an RGBA buffer so is not memory efficient. Our custom method uses the scanline method [1], which should work with both stripped and tiled pages.
>
> But please test, and add a test? I'm not 100% if there is a test image for tiled images.
>
> Where the difference between stripped and tiled images would really matter is streaming, but that is not there...yet.
>
> Brad
>
> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>
>
> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
>> Brad,
>>
>> I recently added tiled image reading to VTK's tiff reader. Do you
>> think that would be useful in IUTK. I don't know how often tiled tiff
>> images are encountered.
>>
>> BTW I do not mean tiled pyramid tiff images.
>>
>> Bill
>>
>> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>>> Greetings,
>>>
>>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>>> of dead code, and improve performance up to 3-5X. A number of bug related to
>>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>>> such as OME-XML tags ( Originally contributed by Richard Beare
>>> http://www.insight-journal.org/browse/publication/728 ).
>>>
>>> Significant performance improvements were made to both scalar images and
>>> palette images. Handling of certain orientations are now "better" handled,
>>> while not changing how the default TOPLEFT orientation is loaded or written.
>>> There were a number of cases which appear unreachable and illogical such as
>>> support from Zeiss two-componet types, and support for some type of SGI
>>> tiled tiff as a 3D image. These were removed.
>>>
>>> If you are an active user of TIFF images with ITK, please checkout the
>>> latest ITK master and test the refactored TIFFImageIO.
>>>
>>> Thanks,
>>> Brad
>>>
>>> p.s. Here is the git log for the recent changes.
>>>
>>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>>>
>>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Fri Oct 31 14:25:13 2014 -0400
>>>
>>>    ENH: adding TIFFImageIO test for RGB palette images
>>>
>>>    Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>>>
>>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Fri Oct 24 13:42:02 2014 -0400
>>>
>>>    BUG: Adding missing parentheses around boolean expression
>>>
>>>    Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>>>
>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Wed Oct 22 15:05:39 2014 -0400
>>>
>>>    PERF: Refactor color table lookup
>>>
>>>    Change to use a index lookup for the color and gray scale
>>>    palettes. The remove excessive exception checking done on a per pixel
>>>    basis with the GetColor method. Additionally the InitializeColor
>>>    method was change do initialize the color palette variables.
>>>
>>>    An exception no longer occurs when an index exceeds the number of
>>>    entries in a palette. Instead a module operator is used to prevent
>>>    out of bounds memory access.
>>>
>>>    Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>>>
>>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Fri Oct 3 09:01:28 2014 -0400
>>>
>>>    ENH: Refactor per pixel conversion function to per scan-line method
>>>
>>>    This patch changes the implementation of conversion from the TIFF
>>>    scanline buffer from a function call on each pixel to a function call
>>>    per scanline. The enable efficient copying of similar scanline and
>>>    better reuse of variables for palette look ups.
>>>
>>>    This can increase the performance of reading grayscale images by up to
>>>    3X for cached files.
>>>
>>>    Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>>>
>>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Tue Sep 30 08:56:58 2014 -0400
>>>
>>>    ENH: RGBA read images should stay unchanged.
>>>
>>>    The image that are read with the TIFFReadRGBAImage should not have
>>>    their pixel types converted. This libtiff method always read images
>>>    into an ABGR uint8 format. When the tiff file is read by this method
>>>    it should report that uint8 and RGBA is the component an pixel type
>>>    for the image. This allows the standard ITK buffer conversion to be
>>>    performed.
>>>
>>>    This change remove extra cases and template instantiations.
>>>
>>>    Additionally the RGBAImageToBuffer method was flipping the image along
>>>    the y-axis, this has been more explicitly done with the call to
>>>    TIFFReadRGBAImageOriented.
>>>
>>>    Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>>>
>>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Fri Sep 26 14:04:09 2014 -0400
>>>
>>>    ENH: Remove support for TIFF tile as 3D and dead code
>>>
>>>    This TIFF file format is a file which contains a list of directories,
>>>    if there are no directories in the file it's not a valid tiff. Code
>>>    which supported 3D tiles was conditioned on a file with no directories
>>>    and no data. Additional code was removed related to a private SGI tag
>>>    TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>>>    invalid case.
>>>
>>>    Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>>>
>>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Mon Oct 6 10:01:50 2014 -0400
>>>
>>>    BUG: Address Coverity warning about null pointer dereferences
>>>
>>>    The patch addressed the following Coverity warnings:
>>>
>>>    ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>>>    itkTIFFImageIO.cxx:
>>>    1192 in itk::TIFFImageIO::ReadTIFFTags()()
>>>
>>>    ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>>>    itkTIFFImageIO.cxx:
>>>    1096 in itk::TIFFImageIO::ReadTIFFTags()()
>>>
>>>    ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>>>    itkTIFFImageIO.cxx:
>>>    1100 in itk::TIFFImageIO::ReadTIFFTags()()
>>>    Last login: Fri Oct  3 19:47:29 on ttys004
>>>
>>>    Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>>>
>>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Fri Sep 26 11:04:38 2014 -0400
>>>
>>>    ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>>>
>>>    Refactoring of the pixelOffset to include the number of components
>>>    remove the need for a separate block for RGB multi-component files.
>>>
>>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Wed Sep 24 15:00:54 2014 -0400
>>>
>>>    ENH: add arbitrary TIFF TAGs to meta-data dictionary
>>>
>>>    A more general approach to adding custom tiff tags to the meta-data
>>>    dictionary has been used based on the implementation of libtiff's
>>>    PrintDirectory method and the libtiff "Defining New TIFF Tags"
>>>    documentation.
>>>
>>>    Additionally a new test image was added generated in Photoshop, which
>>>    has a novel pixel layout, and also contains additional tag types such
>>>    as byte, and size specified ascii.
>>>
>>>    Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>>>
>>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Mon Sep 22 15:08:36 2014 -0400
>>>
>>>    BUG: Use array delete operator for array new allocations
>>>
>>>    Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>>>
>>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Tue Sep 23 11:14:15 2014 -0400
>>>
>>>    STYLE: Fix minor kwstyle defects in test and test results
>>>
>>>    Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>>>
>>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>>> Author: Richard Beare <Richard.Beare at ieee.org>
>>> Date:   Tue Sep 23 11:11:34 2014 -0400
>>>
>>>    ENH: Include TIFF tags in the MetaDataDictionary
>>>
>>>    Add contribution from the Insight Journal:
>>>    http://hdl.handle.net/10380/3170
>>>
>>>    Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>>>
>>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Mon Sep 22 14:46:44 2014 -0400
>>>
>>>    BUG: Remove dead separated plannar code, add test
>>>
>>>    The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>>>    preceded by a unreachable due to a conditional and exception
>>>    check. Support for this configuration remains in the TIFFReadRGBAImage
>>>    method. A test for the configuration has been added.
>>>
>>>    A new input image is added from the from the libTiff test images:
>>>
>>>    PlanarConfiguration = 2 (separated samples)
>>>    -------------------------------------------
>>>    oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>>>
>>>    Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>>>
>>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Mon Sep 22 13:32:23 2014 -0400
>>>
>>>    BUG: Fix right oriented tiff images
>>>
>>>    The TIFFImageIO::ReadGenericImage method correctly handled top-left
>>>    oriented images, and bottom-right image, however images oriented with
>>>    right were non-correctly handled. These cases are now handled
>>>    correctly by the TIFFRGBAImage generic path.
>>>
>>>    New test images of the cthead1 image were added which have been
>>>    flipped the to the different orientation, and the matching orientation
>>>    tag specified so that they should all be read as equivalent
>>>    images. These have been added as a test case.
>>>
>>>    Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>>>
>>> commit 6263f4389026f1bd770054e86c428b56629d705b
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Thu Sep 18 16:20:41 2014 -0400
>>>
>>>    ENH: Refactor duplicated code to read a page
>>>
>>>    Created a method to read a single page or sub-image in a tiff
>>>    file. Simular code was both in the ReadVolume method for 3-d and the
>>>    Read method for 2-d. The code block from ReadVolume was used because
>>>    it contained more typed cases. There for this patch does improve the
>>>    2d reading capabilities for tiffio, so that they are consistent with
>>>    the 3d.
>>>
>>>    Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>>>
>>> commit 233571f1e626917bce872e450907bc8e8521e371
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Thu Sep 18 14:59:58 2014 -0400
>>>
>>>    ENH: Refactor method to convert RGBA image to output buffer
>>>
>>>    BUG: Address overflow issue when computing page offset with
>>>    TIFFReadRGBAImage method.
>>>
>>>    Extract repeated code to convert from ReadRGBAImage to output image
>>>    type.
>>>
>>>    Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>>>
>>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Thu Sep 18 11:30:41 2014 -0400
>>>
>>>    BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>>> )
>>>
>>>    There are no tests for this branch of code. It only works in 3D under
>>>    certain cases. There are apparent bugs in the code such as not setting
>>>    all of the input image, and logically dead branches. Some downloaded
>>>    test images for similar described format do not load. This may effect
>>>    files with the extensions tif, tiff, or lsm.
>>>
>>>    Removal of this code will enable expansion of the current code to more
>>>    generically support multi-sample per pixel images.
>>>
>>>    For more robust reading of this type of image the SCIFIO remote
>>>    module should be used.
>>>
>>>    Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>>>
>>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Tue Sep 16 15:31:52 2014 -0400
>>>
>>>    ENH: Refactor GenericReadImage into template function
>>>
>>>    Reduce code duplication by using template method.
>>>
>>>    Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>>>
>>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Tue Sep 16 12:09:59 2014 -0400
>>>
>>>    ENH: Refactor ReadTwoSamplePerPixelImage into template function
>>>
>>>    Reduce code duplication by using template method.
>>>
>>>    Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>>>
>>> commit 0b573136d636613217df9683ea846db8039f9312
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Tue Sep 16 11:12:45 2014 -0400
>>>
>>>    ENH: Extract TiffReaderInternal to separate file
>>>
>>>    Refactored private class to be in separate private header.
>>>
>>>    Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>>>
>>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date:   Mon Sep 15 16:46:26 2014 -0400
>>>
>>>    BUG: Fix overflows computing size of read tiff image
>>>
>>>    When multiplying the height and width of an tiff image (32-bits),
>>>    at least one element should be converted to size_t to help prevent
>>>    numeric overflow.
>>>
>>>    This change enables reading of larger RGB and large 2D image, that
>>>    were previously truncated when reading. This does not address
>>>    potential buffer overflow or resource limits which could occur.
>>>
>>>    Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>>>
>>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>>> Author: Matt McCormick <matt.mccormick at kitware.com>
>>> Date:   Mon Aug 25 00:35:48 2014 -0400
>>>
>>>    COMP: Do not use _stat64 with MinGW-32.
>>>
>>>    Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>>>    including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>>> with
>>>    MinGW-32.
>>>
>>>    Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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://kitware.com/products/protraining.php
>>>
>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>



-- 
Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Fri Nov 14 10:45:38 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 14 Nov 2014 10:45:38 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
Message-ID: <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>

Wow. The new itk tiff reader sad my tiled images.

On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> There is a TIFFReadTile call in lib tiff. I some tiled images I will
> try with the updated itk reader. I'll be really syprised if it works
> since reading tiled images is tricky and took quite a bit of code.
>
> I'll keep you posted.
>
> Bill
>
> On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Bill,
>>
>> There was a tile block of code before, but that was not covered, looked unreachable and was removed.
>>
>> Currently there are two ways that a tiff page can be read with the TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method from libtiff is fairly robust but reads the image into an RGBA buffer so is not memory efficient. Our custom method uses the scanline method [1], which should work with both stripped and tiled pages.
>>
>> But please test, and add a test? I'm not 100% if there is a test image for tiled images.
>>
>> Where the difference between stripped and tiled images would really matter is streaming, but that is not there...yet.
>>
>> Brad
>>
>> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>>
>>
>> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>
>>> Brad,
>>>
>>> I recently added tiled image reading to VTK's tiff reader. Do you
>>> think that would be useful in IUTK. I don't know how often tiled tiff
>>> images are encountered.
>>>
>>> BTW I do not mean tiled pyramid tiff images.
>>>
>>> Bill
>>>
>>> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
>>> <blowekamp at mail.nih.gov> wrote:
>>>> Greetings,
>>>>
>>>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>>>> of dead code, and improve performance up to 3-5X. A number of bug related to
>>>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>>>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>>>> such as OME-XML tags ( Originally contributed by Richard Beare
>>>> http://www.insight-journal.org/browse/publication/728 ).
>>>>
>>>> Significant performance improvements were made to both scalar images and
>>>> palette images. Handling of certain orientations are now "better" handled,
>>>> while not changing how the default TOPLEFT orientation is loaded or written.
>>>> There were a number of cases which appear unreachable and illogical such as
>>>> support from Zeiss two-componet types, and support for some type of SGI
>>>> tiled tiff as a 3D image. These were removed.
>>>>
>>>> If you are an active user of TIFF images with ITK, please checkout the
>>>> latest ITK master and test the refactored TIFFImageIO.
>>>>
>>>> Thanks,
>>>> Brad
>>>>
>>>> p.s. Here is the git log for the recent changes.
>>>>
>>>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>>>>
>>>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Fri Oct 31 14:25:13 2014 -0400
>>>>
>>>>    ENH: adding TIFFImageIO test for RGB palette images
>>>>
>>>>    Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>>>>
>>>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Fri Oct 24 13:42:02 2014 -0400
>>>>
>>>>    BUG: Adding missing parentheses around boolean expression
>>>>
>>>>    Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>>>>
>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Wed Oct 22 15:05:39 2014 -0400
>>>>
>>>>    PERF: Refactor color table lookup
>>>>
>>>>    Change to use a index lookup for the color and gray scale
>>>>    palettes. The remove excessive exception checking done on a per pixel
>>>>    basis with the GetColor method. Additionally the InitializeColor
>>>>    method was change do initialize the color palette variables.
>>>>
>>>>    An exception no longer occurs when an index exceeds the number of
>>>>    entries in a palette. Instead a module operator is used to prevent
>>>>    out of bounds memory access.
>>>>
>>>>    Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>>>>
>>>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Fri Oct 3 09:01:28 2014 -0400
>>>>
>>>>    ENH: Refactor per pixel conversion function to per scan-line method
>>>>
>>>>    This patch changes the implementation of conversion from the TIFF
>>>>    scanline buffer from a function call on each pixel to a function call
>>>>    per scanline. The enable efficient copying of similar scanline and
>>>>    better reuse of variables for palette look ups.
>>>>
>>>>    This can increase the performance of reading grayscale images by up to
>>>>    3X for cached files.
>>>>
>>>>    Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>>>>
>>>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Tue Sep 30 08:56:58 2014 -0400
>>>>
>>>>    ENH: RGBA read images should stay unchanged.
>>>>
>>>>    The image that are read with the TIFFReadRGBAImage should not have
>>>>    their pixel types converted. This libtiff method always read images
>>>>    into an ABGR uint8 format. When the tiff file is read by this method
>>>>    it should report that uint8 and RGBA is the component an pixel type
>>>>    for the image. This allows the standard ITK buffer conversion to be
>>>>    performed.
>>>>
>>>>    This change remove extra cases and template instantiations.
>>>>
>>>>    Additionally the RGBAImageToBuffer method was flipping the image along
>>>>    the y-axis, this has been more explicitly done with the call to
>>>>    TIFFReadRGBAImageOriented.
>>>>
>>>>    Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>>>>
>>>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Fri Sep 26 14:04:09 2014 -0400
>>>>
>>>>    ENH: Remove support for TIFF tile as 3D and dead code
>>>>
>>>>    This TIFF file format is a file which contains a list of directories,
>>>>    if there are no directories in the file it's not a valid tiff. Code
>>>>    which supported 3D tiles was conditioned on a file with no directories
>>>>    and no data. Additional code was removed related to a private SGI tag
>>>>    TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>>>>    invalid case.
>>>>
>>>>    Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>>>>
>>>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Mon Oct 6 10:01:50 2014 -0400
>>>>
>>>>    BUG: Address Coverity warning about null pointer dereferences
>>>>
>>>>    The patch addressed the following Coverity warnings:
>>>>
>>>>    ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>>>>    itkTIFFImageIO.cxx:
>>>>    1192 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>
>>>>    ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>>>>    itkTIFFImageIO.cxx:
>>>>    1096 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>
>>>>    ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>>>>    itkTIFFImageIO.cxx:
>>>>    1100 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>    Last login: Fri Oct  3 19:47:29 on ttys004
>>>>
>>>>    Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>>>>
>>>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Fri Sep 26 11:04:38 2014 -0400
>>>>
>>>>    ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>>>>
>>>>    Refactoring of the pixelOffset to include the number of components
>>>>    remove the need for a separate block for RGB multi-component files.
>>>>
>>>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Wed Sep 24 15:00:54 2014 -0400
>>>>
>>>>    ENH: add arbitrary TIFF TAGs to meta-data dictionary
>>>>
>>>>    A more general approach to adding custom tiff tags to the meta-data
>>>>    dictionary has been used based on the implementation of libtiff's
>>>>    PrintDirectory method and the libtiff "Defining New TIFF Tags"
>>>>    documentation.
>>>>
>>>>    Additionally a new test image was added generated in Photoshop, which
>>>>    has a novel pixel layout, and also contains additional tag types such
>>>>    as byte, and size specified ascii.
>>>>
>>>>    Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>>>>
>>>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Mon Sep 22 15:08:36 2014 -0400
>>>>
>>>>    BUG: Use array delete operator for array new allocations
>>>>
>>>>    Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>>>>
>>>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Tue Sep 23 11:14:15 2014 -0400
>>>>
>>>>    STYLE: Fix minor kwstyle defects in test and test results
>>>>
>>>>    Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>>>>
>>>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>>>> Author: Richard Beare <Richard.Beare at ieee.org>
>>>> Date:   Tue Sep 23 11:11:34 2014 -0400
>>>>
>>>>    ENH: Include TIFF tags in the MetaDataDictionary
>>>>
>>>>    Add contribution from the Insight Journal:
>>>>    http://hdl.handle.net/10380/3170
>>>>
>>>>    Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>>>>
>>>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Mon Sep 22 14:46:44 2014 -0400
>>>>
>>>>    BUG: Remove dead separated plannar code, add test
>>>>
>>>>    The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>>>>    preceded by a unreachable due to a conditional and exception
>>>>    check. Support for this configuration remains in the TIFFReadRGBAImage
>>>>    method. A test for the configuration has been added.
>>>>
>>>>    A new input image is added from the from the libTiff test images:
>>>>
>>>>    PlanarConfiguration = 2 (separated samples)
>>>>    -------------------------------------------
>>>>    oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>>>>
>>>>    Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>>>>
>>>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Mon Sep 22 13:32:23 2014 -0400
>>>>
>>>>    BUG: Fix right oriented tiff images
>>>>
>>>>    The TIFFImageIO::ReadGenericImage method correctly handled top-left
>>>>    oriented images, and bottom-right image, however images oriented with
>>>>    right were non-correctly handled. These cases are now handled
>>>>    correctly by the TIFFRGBAImage generic path.
>>>>
>>>>    New test images of the cthead1 image were added which have been
>>>>    flipped the to the different orientation, and the matching orientation
>>>>    tag specified so that they should all be read as equivalent
>>>>    images. These have been added as a test case.
>>>>
>>>>    Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>>>>
>>>> commit 6263f4389026f1bd770054e86c428b56629d705b
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Thu Sep 18 16:20:41 2014 -0400
>>>>
>>>>    ENH: Refactor duplicated code to read a page
>>>>
>>>>    Created a method to read a single page or sub-image in a tiff
>>>>    file. Simular code was both in the ReadVolume method for 3-d and the
>>>>    Read method for 2-d. The code block from ReadVolume was used because
>>>>    it contained more typed cases. There for this patch does improve the
>>>>    2d reading capabilities for tiffio, so that they are consistent with
>>>>    the 3d.
>>>>
>>>>    Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>>>>
>>>> commit 233571f1e626917bce872e450907bc8e8521e371
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Thu Sep 18 14:59:58 2014 -0400
>>>>
>>>>    ENH: Refactor method to convert RGBA image to output buffer
>>>>
>>>>    BUG: Address overflow issue when computing page offset with
>>>>    TIFFReadRGBAImage method.
>>>>
>>>>    Extract repeated code to convert from ReadRGBAImage to output image
>>>>    type.
>>>>
>>>>    Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>>>>
>>>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Thu Sep 18 11:30:41 2014 -0400
>>>>
>>>>    BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>>>> )
>>>>
>>>>    There are no tests for this branch of code. It only works in 3D under
>>>>    certain cases. There are apparent bugs in the code such as not setting
>>>>    all of the input image, and logically dead branches. Some downloaded
>>>>    test images for similar described format do not load. This may effect
>>>>    files with the extensions tif, tiff, or lsm.
>>>>
>>>>    Removal of this code will enable expansion of the current code to more
>>>>    generically support multi-sample per pixel images.
>>>>
>>>>    For more robust reading of this type of image the SCIFIO remote
>>>>    module should be used.
>>>>
>>>>    Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>>>>
>>>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Tue Sep 16 15:31:52 2014 -0400
>>>>
>>>>    ENH: Refactor GenericReadImage into template function
>>>>
>>>>    Reduce code duplication by using template method.
>>>>
>>>>    Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>>>>
>>>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Tue Sep 16 12:09:59 2014 -0400
>>>>
>>>>    ENH: Refactor ReadTwoSamplePerPixelImage into template function
>>>>
>>>>    Reduce code duplication by using template method.
>>>>
>>>>    Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>>>>
>>>> commit 0b573136d636613217df9683ea846db8039f9312
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Tue Sep 16 11:12:45 2014 -0400
>>>>
>>>>    ENH: Extract TiffReaderInternal to separate file
>>>>
>>>>    Refactored private class to be in separate private header.
>>>>
>>>>    Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>>>>
>>>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>> Date:   Mon Sep 15 16:46:26 2014 -0400
>>>>
>>>>    BUG: Fix overflows computing size of read tiff image
>>>>
>>>>    When multiplying the height and width of an tiff image (32-bits),
>>>>    at least one element should be converted to size_t to help prevent
>>>>    numeric overflow.
>>>>
>>>>    This change enables reading of larger RGB and large 2D image, that
>>>>    were previously truncated when reading. This does not address
>>>>    potential buffer overflow or resource limits which could occur.
>>>>
>>>>    Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>>>>
>>>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>>>> Author: Matt McCormick <matt.mccormick at kitware.com>
>>>> Date:   Mon Aug 25 00:35:48 2014 -0400
>>>>
>>>>    COMP: Do not use _stat64 with MinGW-32.
>>>>
>>>>    Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>>>>    including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>>>> with
>>>>    MinGW-32.
>>>>
>>>>    Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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://kitware.com/products/protraining.php
>>>>
>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>>
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Fri Nov 14 10:46:32 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 14 Nov 2014 10:46:32 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
 <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
Message-ID: <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>

Meant to say:
Wow. The new itk tiff reader read my tiled images.


On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Wow. The new itk tiff reader sad my tiled images.
>
> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> There is a TIFFReadTile call in lib tiff. I some tiled images I will
>> try with the updated itk reader. I'll be really syprised if it works
>> since reading tiled images is tricky and took quite a bit of code.
>>
>> I'll keep you posted.
>>
>> Bill
>>
>> On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>>> Bill,
>>>
>>> There was a tile block of code before, but that was not covered, looked unreachable and was removed.
>>>
>>> Currently there are two ways that a tiff page can be read with the TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method from libtiff is fairly robust but reads the image into an RGBA buffer so is not memory efficient. Our custom method uses the scanline method [1], which should work with both stripped and tiled pages.
>>>
>>> But please test, and add a test? I'm not 100% if there is a test image for tiled images.
>>>
>>> Where the difference between stripped and tiled images would really matter is streaming, but that is not there...yet.
>>>
>>> Brad
>>>
>>> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>>>
>>>
>>> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>
>>>> Brad,
>>>>
>>>> I recently added tiled image reading to VTK's tiff reader. Do you
>>>> think that would be useful in IUTK. I don't know how often tiled tiff
>>>> images are encountered.
>>>>
>>>> BTW I do not mean tiled pyramid tiff images.
>>>>
>>>> Bill
>>>>
>>>> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
>>>> <blowekamp at mail.nih.gov> wrote:
>>>>> Greetings,
>>>>>
>>>>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>>>>> of dead code, and improve performance up to 3-5X. A number of bug related to
>>>>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>>>>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>>>>> such as OME-XML tags ( Originally contributed by Richard Beare
>>>>> http://www.insight-journal.org/browse/publication/728 ).
>>>>>
>>>>> Significant performance improvements were made to both scalar images and
>>>>> palette images. Handling of certain orientations are now "better" handled,
>>>>> while not changing how the default TOPLEFT orientation is loaded or written.
>>>>> There were a number of cases which appear unreachable and illogical such as
>>>>> support from Zeiss two-componet types, and support for some type of SGI
>>>>> tiled tiff as a 3D image. These were removed.
>>>>>
>>>>> If you are an active user of TIFF images with ITK, please checkout the
>>>>> latest ITK master and test the refactored TIFFImageIO.
>>>>>
>>>>> Thanks,
>>>>> Brad
>>>>>
>>>>> p.s. Here is the git log for the recent changes.
>>>>>
>>>>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>>>>>
>>>>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Fri Oct 31 14:25:13 2014 -0400
>>>>>
>>>>>    ENH: adding TIFFImageIO test for RGB palette images
>>>>>
>>>>>    Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>>>>>
>>>>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Fri Oct 24 13:42:02 2014 -0400
>>>>>
>>>>>    BUG: Adding missing parentheses around boolean expression
>>>>>
>>>>>    Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>>>>>
>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Wed Oct 22 15:05:39 2014 -0400
>>>>>
>>>>>    PERF: Refactor color table lookup
>>>>>
>>>>>    Change to use a index lookup for the color and gray scale
>>>>>    palettes. The remove excessive exception checking done on a per pixel
>>>>>    basis with the GetColor method. Additionally the InitializeColor
>>>>>    method was change do initialize the color palette variables.
>>>>>
>>>>>    An exception no longer occurs when an index exceeds the number of
>>>>>    entries in a palette. Instead a module operator is used to prevent
>>>>>    out of bounds memory access.
>>>>>
>>>>>    Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>>>>>
>>>>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Fri Oct 3 09:01:28 2014 -0400
>>>>>
>>>>>    ENH: Refactor per pixel conversion function to per scan-line method
>>>>>
>>>>>    This patch changes the implementation of conversion from the TIFF
>>>>>    scanline buffer from a function call on each pixel to a function call
>>>>>    per scanline. The enable efficient copying of similar scanline and
>>>>>    better reuse of variables for palette look ups.
>>>>>
>>>>>    This can increase the performance of reading grayscale images by up to
>>>>>    3X for cached files.
>>>>>
>>>>>    Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>>>>>
>>>>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Tue Sep 30 08:56:58 2014 -0400
>>>>>
>>>>>    ENH: RGBA read images should stay unchanged.
>>>>>
>>>>>    The image that are read with the TIFFReadRGBAImage should not have
>>>>>    their pixel types converted. This libtiff method always read images
>>>>>    into an ABGR uint8 format. When the tiff file is read by this method
>>>>>    it should report that uint8 and RGBA is the component an pixel type
>>>>>    for the image. This allows the standard ITK buffer conversion to be
>>>>>    performed.
>>>>>
>>>>>    This change remove extra cases and template instantiations.
>>>>>
>>>>>    Additionally the RGBAImageToBuffer method was flipping the image along
>>>>>    the y-axis, this has been more explicitly done with the call to
>>>>>    TIFFReadRGBAImageOriented.
>>>>>
>>>>>    Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>>>>>
>>>>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Fri Sep 26 14:04:09 2014 -0400
>>>>>
>>>>>    ENH: Remove support for TIFF tile as 3D and dead code
>>>>>
>>>>>    This TIFF file format is a file which contains a list of directories,
>>>>>    if there are no directories in the file it's not a valid tiff. Code
>>>>>    which supported 3D tiles was conditioned on a file with no directories
>>>>>    and no data. Additional code was removed related to a private SGI tag
>>>>>    TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>>>>>    invalid case.
>>>>>
>>>>>    Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>>>>>
>>>>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Mon Oct 6 10:01:50 2014 -0400
>>>>>
>>>>>    BUG: Address Coverity warning about null pointer dereferences
>>>>>
>>>>>    The patch addressed the following Coverity warnings:
>>>>>
>>>>>    ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>>>>>    itkTIFFImageIO.cxx:
>>>>>    1192 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>
>>>>>    ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>>>>>    itkTIFFImageIO.cxx:
>>>>>    1096 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>
>>>>>    ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>>>>>    itkTIFFImageIO.cxx:
>>>>>    1100 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>    Last login: Fri Oct  3 19:47:29 on ttys004
>>>>>
>>>>>    Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>>>>>
>>>>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Fri Sep 26 11:04:38 2014 -0400
>>>>>
>>>>>    ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>>>>>
>>>>>    Refactoring of the pixelOffset to include the number of components
>>>>>    remove the need for a separate block for RGB multi-component files.
>>>>>
>>>>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Wed Sep 24 15:00:54 2014 -0400
>>>>>
>>>>>    ENH: add arbitrary TIFF TAGs to meta-data dictionary
>>>>>
>>>>>    A more general approach to adding custom tiff tags to the meta-data
>>>>>    dictionary has been used based on the implementation of libtiff's
>>>>>    PrintDirectory method and the libtiff "Defining New TIFF Tags"
>>>>>    documentation.
>>>>>
>>>>>    Additionally a new test image was added generated in Photoshop, which
>>>>>    has a novel pixel layout, and also contains additional tag types such
>>>>>    as byte, and size specified ascii.
>>>>>
>>>>>    Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>>>>>
>>>>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Mon Sep 22 15:08:36 2014 -0400
>>>>>
>>>>>    BUG: Use array delete operator for array new allocations
>>>>>
>>>>>    Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>>>>>
>>>>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Tue Sep 23 11:14:15 2014 -0400
>>>>>
>>>>>    STYLE: Fix minor kwstyle defects in test and test results
>>>>>
>>>>>    Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>>>>>
>>>>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>>>>> Author: Richard Beare <Richard.Beare at ieee.org>
>>>>> Date:   Tue Sep 23 11:11:34 2014 -0400
>>>>>
>>>>>    ENH: Include TIFF tags in the MetaDataDictionary
>>>>>
>>>>>    Add contribution from the Insight Journal:
>>>>>    http://hdl.handle.net/10380/3170
>>>>>
>>>>>    Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>>>>>
>>>>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Mon Sep 22 14:46:44 2014 -0400
>>>>>
>>>>>    BUG: Remove dead separated plannar code, add test
>>>>>
>>>>>    The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>>>>>    preceded by a unreachable due to a conditional and exception
>>>>>    check. Support for this configuration remains in the TIFFReadRGBAImage
>>>>>    method. A test for the configuration has been added.
>>>>>
>>>>>    A new input image is added from the from the libTiff test images:
>>>>>
>>>>>    PlanarConfiguration = 2 (separated samples)
>>>>>    -------------------------------------------
>>>>>    oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>>>>>
>>>>>    Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>>>>>
>>>>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Mon Sep 22 13:32:23 2014 -0400
>>>>>
>>>>>    BUG: Fix right oriented tiff images
>>>>>
>>>>>    The TIFFImageIO::ReadGenericImage method correctly handled top-left
>>>>>    oriented images, and bottom-right image, however images oriented with
>>>>>    right were non-correctly handled. These cases are now handled
>>>>>    correctly by the TIFFRGBAImage generic path.
>>>>>
>>>>>    New test images of the cthead1 image were added which have been
>>>>>    flipped the to the different orientation, and the matching orientation
>>>>>    tag specified so that they should all be read as equivalent
>>>>>    images. These have been added as a test case.
>>>>>
>>>>>    Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>>>>>
>>>>> commit 6263f4389026f1bd770054e86c428b56629d705b
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Thu Sep 18 16:20:41 2014 -0400
>>>>>
>>>>>    ENH: Refactor duplicated code to read a page
>>>>>
>>>>>    Created a method to read a single page or sub-image in a tiff
>>>>>    file. Simular code was both in the ReadVolume method for 3-d and the
>>>>>    Read method for 2-d. The code block from ReadVolume was used because
>>>>>    it contained more typed cases. There for this patch does improve the
>>>>>    2d reading capabilities for tiffio, so that they are consistent with
>>>>>    the 3d.
>>>>>
>>>>>    Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>>>>>
>>>>> commit 233571f1e626917bce872e450907bc8e8521e371
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Thu Sep 18 14:59:58 2014 -0400
>>>>>
>>>>>    ENH: Refactor method to convert RGBA image to output buffer
>>>>>
>>>>>    BUG: Address overflow issue when computing page offset with
>>>>>    TIFFReadRGBAImage method.
>>>>>
>>>>>    Extract repeated code to convert from ReadRGBAImage to output image
>>>>>    type.
>>>>>
>>>>>    Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>>>>>
>>>>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Thu Sep 18 11:30:41 2014 -0400
>>>>>
>>>>>    BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>>>>> )
>>>>>
>>>>>    There are no tests for this branch of code. It only works in 3D under
>>>>>    certain cases. There are apparent bugs in the code such as not setting
>>>>>    all of the input image, and logically dead branches. Some downloaded
>>>>>    test images for similar described format do not load. This may effect
>>>>>    files with the extensions tif, tiff, or lsm.
>>>>>
>>>>>    Removal of this code will enable expansion of the current code to more
>>>>>    generically support multi-sample per pixel images.
>>>>>
>>>>>    For more robust reading of this type of image the SCIFIO remote
>>>>>    module should be used.
>>>>>
>>>>>    Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>>>>>
>>>>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Tue Sep 16 15:31:52 2014 -0400
>>>>>
>>>>>    ENH: Refactor GenericReadImage into template function
>>>>>
>>>>>    Reduce code duplication by using template method.
>>>>>
>>>>>    Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>>>>>
>>>>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Tue Sep 16 12:09:59 2014 -0400
>>>>>
>>>>>    ENH: Refactor ReadTwoSamplePerPixelImage into template function
>>>>>
>>>>>    Reduce code duplication by using template method.
>>>>>
>>>>>    Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>>>>>
>>>>> commit 0b573136d636613217df9683ea846db8039f9312
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Tue Sep 16 11:12:45 2014 -0400
>>>>>
>>>>>    ENH: Extract TiffReaderInternal to separate file
>>>>>
>>>>>    Refactored private class to be in separate private header.
>>>>>
>>>>>    Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>>>>>
>>>>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>> Date:   Mon Sep 15 16:46:26 2014 -0400
>>>>>
>>>>>    BUG: Fix overflows computing size of read tiff image
>>>>>
>>>>>    When multiplying the height and width of an tiff image (32-bits),
>>>>>    at least one element should be converted to size_t to help prevent
>>>>>    numeric overflow.
>>>>>
>>>>>    This change enables reading of larger RGB and large 2D image, that
>>>>>    were previously truncated when reading. This does not address
>>>>>    potential buffer overflow or resource limits which could occur.
>>>>>
>>>>>    Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>>>>>
>>>>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>>>>> Author: Matt McCormick <matt.mccormick at kitware.com>
>>>>> Date:   Mon Aug 25 00:35:48 2014 -0400
>>>>>
>>>>>    COMP: Do not use _stat64 with MinGW-32.
>>>>>
>>>>>    Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>>>>>    including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>>>>> with
>>>>>    MinGW-32.
>>>>>
>>>>>    Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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://kitware.com/products/protraining.php
>>>>>
>>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From matimontg at gmail.com  Fri Nov 14 10:56:53 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Fri, 14 Nov 2014 12:56:53 -0300
Subject: [ITK-users] White Background on rotated image
In-Reply-To: <CAKKNfuKsZDV8faNbZ-Fd==ShTbd+1UyL3VY0ks2485H9sV6HFg@mail.gmail.com>
References: <CAKKNfuJeT6cbRvxvz3fJOyc8C0dkPfXvWVdbctO+YKBo+Z7LuA@mail.gmail.com>
 <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov>
 <CAKKNfu+y7auDDruCRp7Z7syAqULqfHwTFtGMQaF5Ksv0gkfWsQ@mail.gmail.com>
 <CAKKNfuKHmLTkcM3q6UVLEGnRTxjA+T__bkg8=HR_ROT9cnvjtA@mail.gmail.com>
 <ED101CB0-C3C4-410F-9A00-80890F201CC5@mail.nih.gov>
 <CAKKNfuLOaoJ6RG6-BexkJutf9CikQOcrYR=-DJox-BbKNqHdwA@mail.gmail.com>
 <CAKKNfuLwkB-VVg0KOkVWqjWwZ-2+p-iNm6txnCH5qi4wM_3TMA@mail.gmail.com>
 <CAKKNfuL1PQjYe9PEhbEsqeMP_XoVoxawLMHypzXiT5mnWzmtHA@mail.gmail.com>
 <CALzTN-Tn7mHJZfTOE2Gg7hu-mi1e=aokxKxqJ97sKbFf3ffaBw@mail.gmail.com>
 <CAKKNfuJJPA6gwa4fNMegkXH8T=t+D4XnFw-nk49dTrHPg5N-3Q@mail.gmail.com>
 <CAKKNfuKsZDV8faNbZ-Fd==ShTbd+1UyL3VY0ks2485H9sV6HFg@mail.gmail.com>
Message-ID: <CAKKNfuJh0Lj9P5pxED4=cEFhtxGrMfrmD4qtxGNnLq7wqgSWrQ@mail.gmail.com>

I figured how to rotate a DICOM Series in a directory, here's my code,
however, I get white images as a result, I'm not sure what I'm missing?

#include "itkImage.h"
#include "itkResampleImageFilter.h"
#include "itkAffineTransform.h"
#include "itkGDCMImageIO.h"

//Para las series
#include "itkGDCMSeriesFileNames.h"
#include "itkImageSeriesReader.h"
#include "itkImageSeriesWriter.h"
#include "itkGDCMSeriesFileNames.h"
#include "itkNumericSeriesFileNames.h"

int main( int argc, char * argv[] )
{
if( argc < 4 )
{
std::cerr << "Usage: " << std::endl;
std::cerr << argv[0] << " Directorio_Entrada Directorio_Salida
Grados_Rotacion" << std::endl;
return EXIT_FAILURE;
}

const unsigned int InputDimension = 3;
const unsigned int OutputDimension = 2;
typedef signed short PixelType;
typedef itk::Image< PixelType, InputDimension >    InputImageType;
typedef itk::Image< PixelType, OutputDimension >    OutputImageType;
typedef itk::ImageSeriesReader< InputImageType >    ReaderType;
typedef itk::GDCMImageIO    ImageIOType;
typedef itk::GDCMSeriesFileNames    InputNamesGeneratorType;
typedef itk::NumericSeriesFileNames    OutputNamesGeneratorType;
typedef itk::ImageSeriesWriter< InputImageType, OutputImageType >
 SeriesWriterType;
typedef itk::ResampleImageFilter< InputImageType, InputImageType >
ResampleFilterType;
typedef itk::LinearInterpolateImageFunction<InputImageType, double >
InterpolatorType;

ImageIOType::Pointer gdcmIO = ImageIOType::New();
InputNamesGeneratorType::Pointer inputNames =
InputNamesGeneratorType::New();
inputNames->SetInputDirectory( argv[1] );
const ReaderType::FileNamesContainer & filenames =
inputNames->GetInputFileNames();

ReaderType::Pointer reader = ReaderType::New();

reader->SetImageIO( gdcmIO );
reader->SetFileNames( filenames );
try
{
reader->Update();
}
catch (itk::ExceptionObject &excp)
{
std::cerr << "Exception thrown while reading the series" << std::endl;
std::cerr << excp << std::endl;
return EXIT_FAILURE;
}


const double angleInDegrees = atof( argv[3] );

typedef itk::AffineTransform< double, InputDimension > TransformType;
//usado para mapear el espacio de entrada con el espacio de salida
TransformType::Pointer transform = TransformType::New();
InterpolatorType::Pointer interpolator = InterpolatorType::New();


const InputImageType::PointType & origin = reader->GetOutput()->GetOrigin();
const InputImageType::SpacingType& inputSpacing =
reader->GetOutput()->GetSpacing();
const InputImageType::RegionType& inputRegion =
reader->GetOutput()->GetLargestPossibleRegion();
const InputImageType::SizeType& inputSize =
inputRegion.GetSize();

std::cout << "The input series in directory " << argv[1]
<< " has " << filenames.size() << " files with spacing "
<< inputSpacing
<< std::endl;

transform->SetIdentity();

ResampleFilterType::Pointer filter = ResampleFilterType::New();
filter->SetInput( reader->GetOutput() );
filter->SetInterpolator( interpolator );
filter->SetOutputOrigin( reader->GetOutput()->GetOrigin() );
filter->SetOutputSpacing( inputSpacing );
filter->SetOutputDirection( reader->GetOutput()->GetDirection() );
filter->SetSize( inputSize );
filter->SetDefaultPixelValue(100); //Pixel por defecto de lo que queda
fuera de la imagen cuando se rota
//filter->Update();

TransformType::OutputVectorType translation1;
const double imageCenterX = origin[0] + inputSpacing[0] * inputSize[0] /
2.0;
const double imageCenterY = origin[1] + inputSpacing[1] * inputSize[1] /
2.0;
translation1[0] = -imageCenterX;
translation1[1] = -imageCenterY;
transform->Translate( translation1 );
// Software Guide : EndCodeSnippet
std::cout << "imageCenterX = " << imageCenterX << std::endl;
std::cout << "imageCenterY = " << imageCenterY << std::endl;

const double degreesToRadians = std::atan(1.0) / 45.0;
const double angle = angleInDegrees * degreesToRadians;
transform->Rotate2D( -angle, false );

TransformType::OutputVectorType translation2;
translation2[0] = imageCenterX;
translation2[1] = imageCenterY;
transform->Translate( translation2, false );
filter->SetTransform( transform );
filter->Update();


// Generate the file names
itksys::SystemTools::MakeDirectory( argv[2] );
OutputNamesGeneratorType::Pointer outputNames =
OutputNamesGeneratorType::New();
std::string seriesFormat(argv[2]);
seriesFormat = seriesFormat + "/" + "IM%d.dcm";
outputNames->SetSeriesFormat (seriesFormat.c_str());
outputNames->SetStartIndex (1);
outputNames->SetEndIndex (230); //Rectificar

SeriesWriterType::Pointer seriesWriter = SeriesWriterType::New();
seriesWriter->SetInput( filter->GetOutput() );
seriesWriter->SetImageIO( gdcmIO );
seriesWriter->SetFileNames( outputNames->GetFileNames() );
//seriesWriter->SetMetaDataDictionaryArray( &outputArray );
try
{
seriesWriter->Update();
}
catch( itk::ExceptionObject & excp )
{
std::cerr << "Exception thrown while writing the series " << std::endl;
std::cerr << excp << std::endl;
return EXIT_FAILURE;
}
}

On Fri, Nov 14, 2014 at 10:28 AM, Matias Montroull <matimontg at gmail.com>
wrote:

> I'm having hard times following the code in the example. RIght now I have
> been able to rotate a dcm file one at a time, now I would like to input a
> directory and output another directory with  the rotated images, I would
> need some guidance for this task.
> Can I just set the input as directory instead of a file for example?
>
> On Thu, Nov 13, 2014 at 3:26 PM, Matias Montroull <matimontg at gmail.com>
> wrote:
>
>> Thanks Matt, I'll give it a try
>>
>> On Thu, Nov 13, 2014 at 2:37 PM, Matt McCormick <
>> matt.mccormick at kitware.com> wrote:
>>
>>> Hi Matias,
>>>
>>> This example may have a hint on how to write a series [1].
>>>
>>> HTH,
>>> Matt
>>>
>>> [1]
>>> http://itk.org/Doxygen/html/IO_2ImageReadDicomSeriesWrite_8cxx-example.html
>>>
>>> On Thu, Nov 13, 2014 at 12:18 PM, Matias Montroull <matimontg at gmail.com>
>>> wrote:
>>> > Now I have another question. This example is just for one file, is
>>> there a
>>> > way to do it for a directory containing a set of DICOM files?
>>> >
>>> > On Thu, Nov 13, 2014 at 2:16 PM, Matias Montroull <matimontg at gmail.com
>>> >
>>> > wrote:
>>> >>
>>> >> never mind, it was my bad. The InputPixelType was unsigned char and
>>> should
>>> >> have been unsigned short
>>> >>
>>> >> On Thu, Nov 13, 2014 at 2:14 PM, Matias Montroull <
>>> matimontg at gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Bradley, as soon as I enter this line of code:
>>> >>>
>>> >>> typedef itk::GDCMImageIO ImageIOType;
>>> >>> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
>>> >>> writer->SetImageIO(gdcmImageIO);
>>> >>>
>>> >>> I get a bad image as result.. any ideas what could it be?
>>> >>>
>>> >>> On Thu, Nov 13, 2014 at 11:36 AM, Bradley Lowekamp
>>> >>> <blowekamp at mail.nih.gov> wrote:
>>> >>>>
>>> >>>> Hello again,
>>> >>>>
>>> >>>> This is a non-trivial task where caution in needed to determine
>>> which
>>> >>>> tags should be copied. But here is a basic example here:
>>> >>>> http://itk.org/Wiki/ITK/Examples/DICOM/ResampleDICOM
>>> >>>>
>>> >>>> Brad
>>> >>>>
>>> >>>> On Nov 13, 2014, at 9:30 AM, Matias Montroull <matimontg at gmail.com>
>>> >>>> wrote:
>>> >>>>
>>> >>>> I have one more question, it seems the writer method removes lot of
>>> tags
>>> >>>> from the image, is there an option to keep the original tags such
>>> as patient
>>> >>>> name, model, manufacture etc?
>>> >>>>
>>> >>>> On Thu, Nov 13, 2014 at 11:27 AM, Matias Montroull <
>>> matimontg at gmail.com>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Bradley, I must say you're the man! that did the trick, thanks a
>>> lot!
>>> >>>>>
>>> >>>>> On Thu, Nov 13, 2014 at 10:59 AM, Bradley Lowekamp
>>> >>>>> <blowekamp at mail.nih.gov> wrote:
>>> >>>>>>
>>> >>>>>> Hello,
>>> >>>>>>
>>> >>>>>> Check out the ImageToImageFilter::SetDefaultPixelValue method [1].
>>> >>>>>>
>>> >>>>>> Brad
>>> >>>>>>
>>> >>>>>> [1]
>>> >>>>>>
>>> http://www.itk.org/Doxygen/html/classitk_1_1ResampleImageFilter.html#a227397f3786a0ec4d3107cb73033b4be
>>> >>>>>>
>>> >>>>>> On Nov 13, 2014, at 8:56 AM, Matias Montroull <
>>> matimontg at gmail.com>
>>> >>>>>> wrote:
>>> >>>>>>
>>> >>>>>> Hi,
>>> >>>>>>
>>> >>>>>> I'm running this example:
>>> >>>>>>
>>> >>>>>>
>>> http://www.itk.org/Doxygen/html/Filtering_2ResampleImageFilter3_8cxx-example.html
>>> >>>>>>
>>> >>>>>> and I'm getting this result which is fine but I need the white
>>> >>>>>> sections left due to the rotation to be black. how can I achieve
>>> this?
>>> >>>>>>
>>> >>>>>> <Capture.JPG>
>>> >>>>>>
>>> >>>>>> _____________________________________
>>> >>>>>> 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.php
>>> >>>>>>
>>> >>>>>> 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://public.kitware.com/mailman/listinfo/insight-users
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>> >
>>> > _____________________________________
>>> > 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.php
>>> >
>>> > 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://public.kitware.com/mailman/listinfo/insight-users
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141114/08d245aa/attachment.html>

From blowekamp at mail.nih.gov  Fri Nov 14 11:06:57 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 14 Nov 2014 11:06:57 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
 <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
 <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
Message-ID: <C64961EA-03EE-4E61-90C4-0C2F3E33B33E@mail.nih.gov>

Actually further reading the TIFFReadScanline documentation says that should not work for tiled images. So I guess it must be using the RGBA read method, but I am not sure how that is happening either. 

Are you used the tiled tiff images from the VTK tests?

Brad


On Nov 14, 2014, at 10:46 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:

> Meant to say:
> Wow. The new itk tiff reader read my tiled images.
> 
> 
> On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Wow. The new itk tiff reader sad my tiled images.
>> 
>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>> There is a TIFFReadTile call in lib tiff. I some tiled images I will
>>> try with the updated itk reader. I'll be really syprised if it works
>>> since reading tiled images is tricky and took quite a bit of code.
>>> 
>>> I'll keep you posted.
>>> 
>>> Bill
>>> 
>>> On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
>>> <blowekamp at mail.nih.gov> wrote:
>>>> Bill,
>>>> 
>>>> There was a tile block of code before, but that was not covered, looked unreachable and was removed.
>>>> 
>>>> Currently there are two ways that a tiff page can be read with the TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method from libtiff is fairly robust but reads the image into an RGBA buffer so is not memory efficient. Our custom method uses the scanline method [1], which should work with both stripped and tiled pages.
>>>> 
>>>> But please test, and add a test? I'm not 100% if there is a test image for tiled images.
>>>> 
>>>> Where the difference between stripped and tiled images would really matter is streaming, but that is not there...yet.
>>>> 
>>>> Brad
>>>> 
>>>> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>>>> 
>>>> 
>>>> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>> 
>>>>> Brad,
>>>>> 
>>>>> I recently added tiled image reading to VTK's tiff reader. Do you
>>>>> think that would be useful in IUTK. I don't know how often tiled tiff
>>>>> images are encountered.
>>>>> 
>>>>> BTW I do not mean tiled pyramid tiff images.
>>>>> 
>>>>> Bill
>>>>> 
>>>>> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>> Greetings,
>>>>>> 
>>>>>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>>>>>> of dead code, and improve performance up to 3-5X. A number of bug related to
>>>>>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>>>>>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>>>>>> such as OME-XML tags ( Originally contributed by Richard Beare
>>>>>> http://www.insight-journal.org/browse/publication/728 ).
>>>>>> 
>>>>>> Significant performance improvements were made to both scalar images and
>>>>>> palette images. Handling of certain orientations are now "better" handled,
>>>>>> while not changing how the default TOPLEFT orientation is loaded or written.
>>>>>> There were a number of cases which appear unreachable and illogical such as
>>>>>> support from Zeiss two-componet types, and support for some type of SGI
>>>>>> tiled tiff as a 3D image. These were removed.
>>>>>> 
>>>>>> If you are an active user of TIFF images with ITK, please checkout the
>>>>>> latest ITK master and test the refactored TIFFImageIO.
>>>>>> 
>>>>>> Thanks,
>>>>>> Brad
>>>>>> 
>>>>>> p.s. Here is the git log for the recent changes.
>>>>>> 
>>>>>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>>>>>> 
>>>>>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Fri Oct 31 14:25:13 2014 -0400
>>>>>> 
>>>>>>   ENH: adding TIFFImageIO test for RGB palette images
>>>>>> 
>>>>>>   Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>>>>>> 
>>>>>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Fri Oct 24 13:42:02 2014 -0400
>>>>>> 
>>>>>>   BUG: Adding missing parentheses around boolean expression
>>>>>> 
>>>>>>   Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>>>>>> 
>>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Wed Oct 22 15:05:39 2014 -0400
>>>>>> 
>>>>>>   PERF: Refactor color table lookup
>>>>>> 
>>>>>>   Change to use a index lookup for the color and gray scale
>>>>>>   palettes. The remove excessive exception checking done on a per pixel
>>>>>>   basis with the GetColor method. Additionally the InitializeColor
>>>>>>   method was change do initialize the color palette variables.
>>>>>> 
>>>>>>   An exception no longer occurs when an index exceeds the number of
>>>>>>   entries in a palette. Instead a module operator is used to prevent
>>>>>>   out of bounds memory access.
>>>>>> 
>>>>>>   Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>>>>>> 
>>>>>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Fri Oct 3 09:01:28 2014 -0400
>>>>>> 
>>>>>>   ENH: Refactor per pixel conversion function to per scan-line method
>>>>>> 
>>>>>>   This patch changes the implementation of conversion from the TIFF
>>>>>>   scanline buffer from a function call on each pixel to a function call
>>>>>>   per scanline. The enable efficient copying of similar scanline and
>>>>>>   better reuse of variables for palette look ups.
>>>>>> 
>>>>>>   This can increase the performance of reading grayscale images by up to
>>>>>>   3X for cached files.
>>>>>> 
>>>>>>   Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>>>>>> 
>>>>>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Tue Sep 30 08:56:58 2014 -0400
>>>>>> 
>>>>>>   ENH: RGBA read images should stay unchanged.
>>>>>> 
>>>>>>   The image that are read with the TIFFReadRGBAImage should not have
>>>>>>   their pixel types converted. This libtiff method always read images
>>>>>>   into an ABGR uint8 format. When the tiff file is read by this method
>>>>>>   it should report that uint8 and RGBA is the component an pixel type
>>>>>>   for the image. This allows the standard ITK buffer conversion to be
>>>>>>   performed.
>>>>>> 
>>>>>>   This change remove extra cases and template instantiations.
>>>>>> 
>>>>>>   Additionally the RGBAImageToBuffer method was flipping the image along
>>>>>>   the y-axis, this has been more explicitly done with the call to
>>>>>>   TIFFReadRGBAImageOriented.
>>>>>> 
>>>>>>   Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>>>>>> 
>>>>>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Fri Sep 26 14:04:09 2014 -0400
>>>>>> 
>>>>>>   ENH: Remove support for TIFF tile as 3D and dead code
>>>>>> 
>>>>>>   This TIFF file format is a file which contains a list of directories,
>>>>>>   if there are no directories in the file it's not a valid tiff. Code
>>>>>>   which supported 3D tiles was conditioned on a file with no directories
>>>>>>   and no data. Additional code was removed related to a private SGI tag
>>>>>>   TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>>>>>>   invalid case.
>>>>>> 
>>>>>>   Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>>>>>> 
>>>>>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Mon Oct 6 10:01:50 2014 -0400
>>>>>> 
>>>>>>   BUG: Address Coverity warning about null pointer dereferences
>>>>>> 
>>>>>>   The patch addressed the following Coverity warnings:
>>>>>> 
>>>>>>   ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>>>>>>   itkTIFFImageIO.cxx:
>>>>>>   1192 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>> 
>>>>>>   ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>>>>>>   itkTIFFImageIO.cxx:
>>>>>>   1096 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>> 
>>>>>>   ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>>>>>>   itkTIFFImageIO.cxx:
>>>>>>   1100 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>>   Last login: Fri Oct  3 19:47:29 on ttys004
>>>>>> 
>>>>>>   Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>>>>>> 
>>>>>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Fri Sep 26 11:04:38 2014 -0400
>>>>>> 
>>>>>>   ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>>>>>> 
>>>>>>   Refactoring of the pixelOffset to include the number of components
>>>>>>   remove the need for a separate block for RGB multi-component files.
>>>>>> 
>>>>>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Wed Sep 24 15:00:54 2014 -0400
>>>>>> 
>>>>>>   ENH: add arbitrary TIFF TAGs to meta-data dictionary
>>>>>> 
>>>>>>   A more general approach to adding custom tiff tags to the meta-data
>>>>>>   dictionary has been used based on the implementation of libtiff's
>>>>>>   PrintDirectory method and the libtiff "Defining New TIFF Tags"
>>>>>>   documentation.
>>>>>> 
>>>>>>   Additionally a new test image was added generated in Photoshop, which
>>>>>>   has a novel pixel layout, and also contains additional tag types such
>>>>>>   as byte, and size specified ascii.
>>>>>> 
>>>>>>   Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>>>>>> 
>>>>>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Mon Sep 22 15:08:36 2014 -0400
>>>>>> 
>>>>>>   BUG: Use array delete operator for array new allocations
>>>>>> 
>>>>>>   Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>>>>>> 
>>>>>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Tue Sep 23 11:14:15 2014 -0400
>>>>>> 
>>>>>>   STYLE: Fix minor kwstyle defects in test and test results
>>>>>> 
>>>>>>   Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>>>>>> 
>>>>>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>>>>>> Author: Richard Beare <Richard.Beare at ieee.org>
>>>>>> Date:   Tue Sep 23 11:11:34 2014 -0400
>>>>>> 
>>>>>>   ENH: Include TIFF tags in the MetaDataDictionary
>>>>>> 
>>>>>>   Add contribution from the Insight Journal:
>>>>>>   http://hdl.handle.net/10380/3170
>>>>>> 
>>>>>>   Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>>>>>> 
>>>>>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Mon Sep 22 14:46:44 2014 -0400
>>>>>> 
>>>>>>   BUG: Remove dead separated plannar code, add test
>>>>>> 
>>>>>>   The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>>>>>>   preceded by a unreachable due to a conditional and exception
>>>>>>   check. Support for this configuration remains in the TIFFReadRGBAImage
>>>>>>   method. A test for the configuration has been added.
>>>>>> 
>>>>>>   A new input image is added from the from the libTiff test images:
>>>>>> 
>>>>>>   PlanarConfiguration = 2 (separated samples)
>>>>>>   -------------------------------------------
>>>>>>   oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>>>>>> 
>>>>>>   Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>>>>>> 
>>>>>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Mon Sep 22 13:32:23 2014 -0400
>>>>>> 
>>>>>>   BUG: Fix right oriented tiff images
>>>>>> 
>>>>>>   The TIFFImageIO::ReadGenericImage method correctly handled top-left
>>>>>>   oriented images, and bottom-right image, however images oriented with
>>>>>>   right were non-correctly handled. These cases are now handled
>>>>>>   correctly by the TIFFRGBAImage generic path.
>>>>>> 
>>>>>>   New test images of the cthead1 image were added which have been
>>>>>>   flipped the to the different orientation, and the matching orientation
>>>>>>   tag specified so that they should all be read as equivalent
>>>>>>   images. These have been added as a test case.
>>>>>> 
>>>>>>   Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>>>>>> 
>>>>>> commit 6263f4389026f1bd770054e86c428b56629d705b
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Thu Sep 18 16:20:41 2014 -0400
>>>>>> 
>>>>>>   ENH: Refactor duplicated code to read a page
>>>>>> 
>>>>>>   Created a method to read a single page or sub-image in a tiff
>>>>>>   file. Simular code was both in the ReadVolume method for 3-d and the
>>>>>>   Read method for 2-d. The code block from ReadVolume was used because
>>>>>>   it contained more typed cases. There for this patch does improve the
>>>>>>   2d reading capabilities for tiffio, so that they are consistent with
>>>>>>   the 3d.
>>>>>> 
>>>>>>   Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>>>>>> 
>>>>>> commit 233571f1e626917bce872e450907bc8e8521e371
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Thu Sep 18 14:59:58 2014 -0400
>>>>>> 
>>>>>>   ENH: Refactor method to convert RGBA image to output buffer
>>>>>> 
>>>>>>   BUG: Address overflow issue when computing page offset with
>>>>>>   TIFFReadRGBAImage method.
>>>>>> 
>>>>>>   Extract repeated code to convert from ReadRGBAImage to output image
>>>>>>   type.
>>>>>> 
>>>>>>   Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>>>>>> 
>>>>>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Thu Sep 18 11:30:41 2014 -0400
>>>>>> 
>>>>>>   BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>>>>>> )
>>>>>> 
>>>>>>   There are no tests for this branch of code. It only works in 3D under
>>>>>>   certain cases. There are apparent bugs in the code such as not setting
>>>>>>   all of the input image, and logically dead branches. Some downloaded
>>>>>>   test images for similar described format do not load. This may effect
>>>>>>   files with the extensions tif, tiff, or lsm.
>>>>>> 
>>>>>>   Removal of this code will enable expansion of the current code to more
>>>>>>   generically support multi-sample per pixel images.
>>>>>> 
>>>>>>   For more robust reading of this type of image the SCIFIO remote
>>>>>>   module should be used.
>>>>>> 
>>>>>>   Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>>>>>> 
>>>>>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Tue Sep 16 15:31:52 2014 -0400
>>>>>> 
>>>>>>   ENH: Refactor GenericReadImage into template function
>>>>>> 
>>>>>>   Reduce code duplication by using template method.
>>>>>> 
>>>>>>   Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>>>>>> 
>>>>>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Tue Sep 16 12:09:59 2014 -0400
>>>>>> 
>>>>>>   ENH: Refactor ReadTwoSamplePerPixelImage into template function
>>>>>> 
>>>>>>   Reduce code duplication by using template method.
>>>>>> 
>>>>>>   Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>>>>>> 
>>>>>> commit 0b573136d636613217df9683ea846db8039f9312
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Tue Sep 16 11:12:45 2014 -0400
>>>>>> 
>>>>>>   ENH: Extract TiffReaderInternal to separate file
>>>>>> 
>>>>>>   Refactored private class to be in separate private header.
>>>>>> 
>>>>>>   Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>>>>>> 
>>>>>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>> Date:   Mon Sep 15 16:46:26 2014 -0400
>>>>>> 
>>>>>>   BUG: Fix overflows computing size of read tiff image
>>>>>> 
>>>>>>   When multiplying the height and width of an tiff image (32-bits),
>>>>>>   at least one element should be converted to size_t to help prevent
>>>>>>   numeric overflow.
>>>>>> 
>>>>>>   This change enables reading of larger RGB and large 2D image, that
>>>>>>   were previously truncated when reading. This does not address
>>>>>>   potential buffer overflow or resource limits which could occur.
>>>>>> 
>>>>>>   Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>>>>>> 
>>>>>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>>>>>> Author: Matt McCormick <matt.mccormick at kitware.com>
>>>>>> Date:   Mon Aug 25 00:35:48 2014 -0400
>>>>>> 
>>>>>>   COMP: Do not use _stat64 with MinGW-32.
>>>>>> 
>>>>>>   Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>>>>>>   including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>>>>>> with
>>>>>>   MinGW-32.
>>>>>> 
>>>>>>   Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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://kitware.com/products/protraining.php
>>>>>> 
>>>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Unpaid intern in BillsBasement at noware dot com
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
> 
> 
> 
> -- 
> Unpaid intern in BillsBasement at noware dot com


From bill.lorensen at gmail.com  Fri Nov 14 11:09:46 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 14 Nov 2014 11:09:46 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <C64961EA-03EE-4E61-90C4-0C2F3E33B33E@mail.nih.gov>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
 <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
 <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
 <C64961EA-03EE-4E61-90C4-0C2F3E33B33E@mail.nih.gov>
Message-ID: <CADZJ4hOCHgq-kE8qLrmUpvAiFFPuJwFUX6GzDm1Tx_Ovow1A9w@mail.gmail.com>

Yes, from the vtk tests. I created them with imagemagik


On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Actually further reading the TIFFReadScanline documentation says that should not work for tiled images. So I guess it must be using the RGBA read method, but I am not sure how that is happening either.
>
> Are you used the tiled tiff images from the VTK tests?
>
> Brad
>
>
> On Nov 14, 2014, at 10:46 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
>> Meant to say:
>> Wow. The new itk tiff reader read my tiled images.
>>
>>
>> On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>> Wow. The new itk tiff reader sad my tiled images.
>>>
>>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>> There is a TIFFReadTile call in lib tiff. I some tiled images I will
>>>> try with the updated itk reader. I'll be really syprised if it works
>>>> since reading tiled images is tricky and took quite a bit of code.
>>>>
>>>> I'll keep you posted.
>>>>
>>>> Bill
>>>>
>>>> On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
>>>> <blowekamp at mail.nih.gov> wrote:
>>>>> Bill,
>>>>>
>>>>> There was a tile block of code before, but that was not covered, looked unreachable and was removed.
>>>>>
>>>>> Currently there are two ways that a tiff page can be read with the TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method from libtiff is fairly robust but reads the image into an RGBA buffer so is not memory efficient. Our custom method uses the scanline method [1], which should work with both stripped and tiled pages.
>>>>>
>>>>> But please test, and add a test? I'm not 100% if there is a test image for tiled images.
>>>>>
>>>>> Where the difference between stripped and tiled images would really matter is streaming, but that is not there...yet.
>>>>>
>>>>> Brad
>>>>>
>>>>> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>>>>>
>>>>>
>>>>> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>>>
>>>>>> Brad,
>>>>>>
>>>>>> I recently added tiled image reading to VTK's tiff reader. Do you
>>>>>> think that would be useful in IUTK. I don't know how often tiled tiff
>>>>>> images are encountered.
>>>>>>
>>>>>> BTW I do not mean tiled pyramid tiff images.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
>>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>>> Greetings,
>>>>>>>
>>>>>>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>>>>>>> of dead code, and improve performance up to 3-5X. A number of bug related to
>>>>>>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>>>>>>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>>>>>>> such as OME-XML tags ( Originally contributed by Richard Beare
>>>>>>> http://www.insight-journal.org/browse/publication/728 ).
>>>>>>>
>>>>>>> Significant performance improvements were made to both scalar images and
>>>>>>> palette images. Handling of certain orientations are now "better" handled,
>>>>>>> while not changing how the default TOPLEFT orientation is loaded or written.
>>>>>>> There were a number of cases which appear unreachable and illogical such as
>>>>>>> support from Zeiss two-componet types, and support for some type of SGI
>>>>>>> tiled tiff as a 3D image. These were removed.
>>>>>>>
>>>>>>> If you are an active user of TIFF images with ITK, please checkout the
>>>>>>> latest ITK master and test the refactored TIFFImageIO.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Brad
>>>>>>>
>>>>>>> p.s. Here is the git log for the recent changes.
>>>>>>>
>>>>>>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>>>>>>>
>>>>>>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Fri Oct 31 14:25:13 2014 -0400
>>>>>>>
>>>>>>>   ENH: adding TIFFImageIO test for RGB palette images
>>>>>>>
>>>>>>>   Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>>>>>>>
>>>>>>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Fri Oct 24 13:42:02 2014 -0400
>>>>>>>
>>>>>>>   BUG: Adding missing parentheses around boolean expression
>>>>>>>
>>>>>>>   Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>>>>>>>
>>>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Wed Oct 22 15:05:39 2014 -0400
>>>>>>>
>>>>>>>   PERF: Refactor color table lookup
>>>>>>>
>>>>>>>   Change to use a index lookup for the color and gray scale
>>>>>>>   palettes. The remove excessive exception checking done on a per pixel
>>>>>>>   basis with the GetColor method. Additionally the InitializeColor
>>>>>>>   method was change do initialize the color palette variables.
>>>>>>>
>>>>>>>   An exception no longer occurs when an index exceeds the number of
>>>>>>>   entries in a palette. Instead a module operator is used to prevent
>>>>>>>   out of bounds memory access.
>>>>>>>
>>>>>>>   Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>>>>>>>
>>>>>>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Fri Oct 3 09:01:28 2014 -0400
>>>>>>>
>>>>>>>   ENH: Refactor per pixel conversion function to per scan-line method
>>>>>>>
>>>>>>>   This patch changes the implementation of conversion from the TIFF
>>>>>>>   scanline buffer from a function call on each pixel to a function call
>>>>>>>   per scanline. The enable efficient copying of similar scanline and
>>>>>>>   better reuse of variables for palette look ups.
>>>>>>>
>>>>>>>   This can increase the performance of reading grayscale images by up to
>>>>>>>   3X for cached files.
>>>>>>>
>>>>>>>   Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>>>>>>>
>>>>>>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Tue Sep 30 08:56:58 2014 -0400
>>>>>>>
>>>>>>>   ENH: RGBA read images should stay unchanged.
>>>>>>>
>>>>>>>   The image that are read with the TIFFReadRGBAImage should not have
>>>>>>>   their pixel types converted. This libtiff method always read images
>>>>>>>   into an ABGR uint8 format. When the tiff file is read by this method
>>>>>>>   it should report that uint8 and RGBA is the component an pixel type
>>>>>>>   for the image. This allows the standard ITK buffer conversion to be
>>>>>>>   performed.
>>>>>>>
>>>>>>>   This change remove extra cases and template instantiations.
>>>>>>>
>>>>>>>   Additionally the RGBAImageToBuffer method was flipping the image along
>>>>>>>   the y-axis, this has been more explicitly done with the call to
>>>>>>>   TIFFReadRGBAImageOriented.
>>>>>>>
>>>>>>>   Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>>>>>>>
>>>>>>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Fri Sep 26 14:04:09 2014 -0400
>>>>>>>
>>>>>>>   ENH: Remove support for TIFF tile as 3D and dead code
>>>>>>>
>>>>>>>   This TIFF file format is a file which contains a list of directories,
>>>>>>>   if there are no directories in the file it's not a valid tiff. Code
>>>>>>>   which supported 3D tiles was conditioned on a file with no directories
>>>>>>>   and no data. Additional code was removed related to a private SGI tag
>>>>>>>   TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>>>>>>>   invalid case.
>>>>>>>
>>>>>>>   Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>>>>>>>
>>>>>>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Mon Oct 6 10:01:50 2014 -0400
>>>>>>>
>>>>>>>   BUG: Address Coverity warning about null pointer dereferences
>>>>>>>
>>>>>>>   The patch addressed the following Coverity warnings:
>>>>>>>
>>>>>>>   ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>>>>>>>   itkTIFFImageIO.cxx:
>>>>>>>   1192 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>>>
>>>>>>>   ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>>>>>>>   itkTIFFImageIO.cxx:
>>>>>>>   1096 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>>>
>>>>>>>   ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>>>>>>>   itkTIFFImageIO.cxx:
>>>>>>>   1100 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>>>   Last login: Fri Oct  3 19:47:29 on ttys004
>>>>>>>
>>>>>>>   Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>>>>>>>
>>>>>>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Fri Sep 26 11:04:38 2014 -0400
>>>>>>>
>>>>>>>   ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>>>>>>>
>>>>>>>   Refactoring of the pixelOffset to include the number of components
>>>>>>>   remove the need for a separate block for RGB multi-component files.
>>>>>>>
>>>>>>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Wed Sep 24 15:00:54 2014 -0400
>>>>>>>
>>>>>>>   ENH: add arbitrary TIFF TAGs to meta-data dictionary
>>>>>>>
>>>>>>>   A more general approach to adding custom tiff tags to the meta-data
>>>>>>>   dictionary has been used based on the implementation of libtiff's
>>>>>>>   PrintDirectory method and the libtiff "Defining New TIFF Tags"
>>>>>>>   documentation.
>>>>>>>
>>>>>>>   Additionally a new test image was added generated in Photoshop, which
>>>>>>>   has a novel pixel layout, and also contains additional tag types such
>>>>>>>   as byte, and size specified ascii.
>>>>>>>
>>>>>>>   Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>>>>>>>
>>>>>>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Mon Sep 22 15:08:36 2014 -0400
>>>>>>>
>>>>>>>   BUG: Use array delete operator for array new allocations
>>>>>>>
>>>>>>>   Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>>>>>>>
>>>>>>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Tue Sep 23 11:14:15 2014 -0400
>>>>>>>
>>>>>>>   STYLE: Fix minor kwstyle defects in test and test results
>>>>>>>
>>>>>>>   Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>>>>>>>
>>>>>>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>>>>>>> Author: Richard Beare <Richard.Beare at ieee.org>
>>>>>>> Date:   Tue Sep 23 11:11:34 2014 -0400
>>>>>>>
>>>>>>>   ENH: Include TIFF tags in the MetaDataDictionary
>>>>>>>
>>>>>>>   Add contribution from the Insight Journal:
>>>>>>>   http://hdl.handle.net/10380/3170
>>>>>>>
>>>>>>>   Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>>>>>>>
>>>>>>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Mon Sep 22 14:46:44 2014 -0400
>>>>>>>
>>>>>>>   BUG: Remove dead separated plannar code, add test
>>>>>>>
>>>>>>>   The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>>>>>>>   preceded by a unreachable due to a conditional and exception
>>>>>>>   check. Support for this configuration remains in the TIFFReadRGBAImage
>>>>>>>   method. A test for the configuration has been added.
>>>>>>>
>>>>>>>   A new input image is added from the from the libTiff test images:
>>>>>>>
>>>>>>>   PlanarConfiguration = 2 (separated samples)
>>>>>>>   -------------------------------------------
>>>>>>>   oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>>>>>>>
>>>>>>>   Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>>>>>>>
>>>>>>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Mon Sep 22 13:32:23 2014 -0400
>>>>>>>
>>>>>>>   BUG: Fix right oriented tiff images
>>>>>>>
>>>>>>>   The TIFFImageIO::ReadGenericImage method correctly handled top-left
>>>>>>>   oriented images, and bottom-right image, however images oriented with
>>>>>>>   right were non-correctly handled. These cases are now handled
>>>>>>>   correctly by the TIFFRGBAImage generic path.
>>>>>>>
>>>>>>>   New test images of the cthead1 image were added which have been
>>>>>>>   flipped the to the different orientation, and the matching orientation
>>>>>>>   tag specified so that they should all be read as equivalent
>>>>>>>   images. These have been added as a test case.
>>>>>>>
>>>>>>>   Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>>>>>>>
>>>>>>> commit 6263f4389026f1bd770054e86c428b56629d705b
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Thu Sep 18 16:20:41 2014 -0400
>>>>>>>
>>>>>>>   ENH: Refactor duplicated code to read a page
>>>>>>>
>>>>>>>   Created a method to read a single page or sub-image in a tiff
>>>>>>>   file. Simular code was both in the ReadVolume method for 3-d and the
>>>>>>>   Read method for 2-d. The code block from ReadVolume was used because
>>>>>>>   it contained more typed cases. There for this patch does improve the
>>>>>>>   2d reading capabilities for tiffio, so that they are consistent with
>>>>>>>   the 3d.
>>>>>>>
>>>>>>>   Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>>>>>>>
>>>>>>> commit 233571f1e626917bce872e450907bc8e8521e371
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Thu Sep 18 14:59:58 2014 -0400
>>>>>>>
>>>>>>>   ENH: Refactor method to convert RGBA image to output buffer
>>>>>>>
>>>>>>>   BUG: Address overflow issue when computing page offset with
>>>>>>>   TIFFReadRGBAImage method.
>>>>>>>
>>>>>>>   Extract repeated code to convert from ReadRGBAImage to output image
>>>>>>>   type.
>>>>>>>
>>>>>>>   Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>>>>>>>
>>>>>>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Thu Sep 18 11:30:41 2014 -0400
>>>>>>>
>>>>>>>   BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>>>>>>> )
>>>>>>>
>>>>>>>   There are no tests for this branch of code. It only works in 3D under
>>>>>>>   certain cases. There are apparent bugs in the code such as not setting
>>>>>>>   all of the input image, and logically dead branches. Some downloaded
>>>>>>>   test images for similar described format do not load. This may effect
>>>>>>>   files with the extensions tif, tiff, or lsm.
>>>>>>>
>>>>>>>   Removal of this code will enable expansion of the current code to more
>>>>>>>   generically support multi-sample per pixel images.
>>>>>>>
>>>>>>>   For more robust reading of this type of image the SCIFIO remote
>>>>>>>   module should be used.
>>>>>>>
>>>>>>>   Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>>>>>>>
>>>>>>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Tue Sep 16 15:31:52 2014 -0400
>>>>>>>
>>>>>>>   ENH: Refactor GenericReadImage into template function
>>>>>>>
>>>>>>>   Reduce code duplication by using template method.
>>>>>>>
>>>>>>>   Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>>>>>>>
>>>>>>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Tue Sep 16 12:09:59 2014 -0400
>>>>>>>
>>>>>>>   ENH: Refactor ReadTwoSamplePerPixelImage into template function
>>>>>>>
>>>>>>>   Reduce code duplication by using template method.
>>>>>>>
>>>>>>>   Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>>>>>>>
>>>>>>> commit 0b573136d636613217df9683ea846db8039f9312
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Tue Sep 16 11:12:45 2014 -0400
>>>>>>>
>>>>>>>   ENH: Extract TiffReaderInternal to separate file
>>>>>>>
>>>>>>>   Refactored private class to be in separate private header.
>>>>>>>
>>>>>>>   Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>>>>>>>
>>>>>>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>> Date:   Mon Sep 15 16:46:26 2014 -0400
>>>>>>>
>>>>>>>   BUG: Fix overflows computing size of read tiff image
>>>>>>>
>>>>>>>   When multiplying the height and width of an tiff image (32-bits),
>>>>>>>   at least one element should be converted to size_t to help prevent
>>>>>>>   numeric overflow.
>>>>>>>
>>>>>>>   This change enables reading of larger RGB and large 2D image, that
>>>>>>>   were previously truncated when reading. This does not address
>>>>>>>   potential buffer overflow or resource limits which could occur.
>>>>>>>
>>>>>>>   Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>>>>>>>
>>>>>>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>>>>>>> Author: Matt McCormick <matt.mccormick at kitware.com>
>>>>>>> Date:   Mon Aug 25 00:35:48 2014 -0400
>>>>>>>
>>>>>>>   COMP: Do not use _stat64 with MinGW-32.
>>>>>>>
>>>>>>>   Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>>>>>>>   including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>>>>>>> with
>>>>>>>   MinGW-32.
>>>>>>>
>>>>>>>   Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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://kitware.com/products/protraining.php
>>>>>>>
>>>>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>



-- 
Unpaid intern in BillsBasement at noware dot com

From blowekamp at mail.nih.gov  Fri Nov 14 12:08:08 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 14 Nov 2014 12:08:08 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CADZJ4hOCHgq-kE8qLrmUpvAiFFPuJwFUX6GzDm1Tx_Ovow1A9w@mail.gmail.com>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
 <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
 <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
 <C64961EA-03EE-4E61-90C4-0C2F3E33B33E@mail.nih.gov>
 <CADZJ4hOCHgq-kE8qLrmUpvAiFFPuJwFUX6GzDm1Tx_Ovow1A9w@mail.gmail.com>
Message-ID: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov>

Bill,

Your images have an odd compression:

$ tiffinfo /scratch/blowekamp/build/VTK/ExternalData/Testing/Data/libtiff/tiled_64x64_tiff_example.tif 
TIFF Directory at offset 0x81f6 (33270)
  Image Width: 256 Image Length: 256
  Tile Width: 64 Tile Length: 64
  Bits/Sample: 8
  Compression Scheme: AdobeDeflate
  Photometric Interpretation: min-is-black
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 256
  Planar Configuration: single image plane
  Page Number: 0-1
  DocumentName: foo.tif
  White Point: 0.3127-0.329
  PrimaryChromaticities: 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000
  Predictor: horizontal differencing 2 (0x2)

This "AdobeDeflate" is not supported by the itk::TIFFImageIOInternal::CanRead method. This is what is causing the usage of TIFFRGBARead and not the fact that it's a tiled image.

How is VTK handling this odd compression?

Brad 

On Nov 14, 2014, at 11:09 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:

> Yes, from the vtk tests. I created them with imagemagik
> 
> 
> On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Actually further reading the TIFFReadScanline documentation says that should not work for tiled images. So I guess it must be using the RGBA read method, but I am not sure how that is happening either.
>> 
>> Are you used the tiled tiff images from the VTK tests?
>> 
>> Brad
>> 
>> 
>> On Nov 14, 2014, at 10:46 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> 
>>> Meant to say:
>>> Wow. The new itk tiff reader read my tiled images.
>>> 
>>> 
>>> On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>> Wow. The new itk tiff reader sad my tiled images.
>>>> 
>>>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>>> There is a TIFFReadTile call in lib tiff. I some tiled images I will
>>>>> try with the updated itk reader. I'll be really syprised if it works
>>>>> since reading tiled images is tricky and took quite a bit of code.
>>>>> 
>>>>> I'll keep you posted.
>>>>> 
>>>>> Bill
>>>>> 
>>>>> On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>> Bill,
>>>>>> 
>>>>>> There was a tile block of code before, but that was not covered, looked unreachable and was removed.
>>>>>> 
>>>>>> Currently there are two ways that a tiff page can be read with the TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method from libtiff is fairly robust but reads the image into an RGBA buffer so is not memory efficient. Our custom method uses the scanline method [1], which should work with both stripped and tiled pages.
>>>>>> 
>>>>>> But please test, and add a test? I'm not 100% if there is a test image for tiled images.
>>>>>> 
>>>>>> Where the difference between stripped and tiled images would really matter is streaming, but that is not there...yet.
>>>>>> 
>>>>>> Brad
>>>>>> 
>>>>>> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>>>>>> 
>>>>>> 
>>>>>> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>>>> 
>>>>>>> Brad,
>>>>>>> 
>>>>>>> I recently added tiled image reading to VTK's tiff reader. Do you
>>>>>>> think that would be useful in IUTK. I don't know how often tiled tiff
>>>>>>> images are encountered.
>>>>>>> 
>>>>>>> BTW I do not mean tiled pyramid tiff images.
>>>>>>> 
>>>>>>> Bill
>>>>>>> 
>>>>>>> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
>>>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>>>> Greetings,
>>>>>>>> 
>>>>>>>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>>>>>>>> of dead code, and improve performance up to 3-5X. A number of bug related to
>>>>>>>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>>>>>>>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>>>>>>>> such as OME-XML tags ( Originally contributed by Richard Beare
>>>>>>>> http://www.insight-journal.org/browse/publication/728 ).
>>>>>>>> 
>>>>>>>> Significant performance improvements were made to both scalar images and
>>>>>>>> palette images. Handling of certain orientations are now "better" handled,
>>>>>>>> while not changing how the default TOPLEFT orientation is loaded or written.
>>>>>>>> There were a number of cases which appear unreachable and illogical such as
>>>>>>>> support from Zeiss two-componet types, and support for some type of SGI
>>>>>>>> tiled tiff as a 3D image. These were removed.
>>>>>>>> 
>>>>>>>> If you are an active user of TIFF images with ITK, please checkout the
>>>>>>>> latest ITK master and test the refactored TIFFImageIO.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Brad
>>>>>>>> 
>>>>>>>> p.s. Here is the git log for the recent changes.
>>>>>>>> 
>>>>>>>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>>>>>>>> 
>>>>>>>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Fri Oct 31 14:25:13 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: adding TIFFImageIO test for RGB palette images
>>>>>>>> 
>>>>>>>>  Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>>>>>>>> 
>>>>>>>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Fri Oct 24 13:42:02 2014 -0400
>>>>>>>> 
>>>>>>>>  BUG: Adding missing parentheses around boolean expression
>>>>>>>> 
>>>>>>>>  Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>>>>>>>> 
>>>>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Wed Oct 22 15:05:39 2014 -0400
>>>>>>>> 
>>>>>>>>  PERF: Refactor color table lookup
>>>>>>>> 
>>>>>>>>  Change to use a index lookup for the color and gray scale
>>>>>>>>  palettes. The remove excessive exception checking done on a per pixel
>>>>>>>>  basis with the GetColor method. Additionally the InitializeColor
>>>>>>>>  method was change do initialize the color palette variables.
>>>>>>>> 
>>>>>>>>  An exception no longer occurs when an index exceeds the number of
>>>>>>>>  entries in a palette. Instead a module operator is used to prevent
>>>>>>>>  out of bounds memory access.
>>>>>>>> 
>>>>>>>>  Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>>>>>>>> 
>>>>>>>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Fri Oct 3 09:01:28 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Refactor per pixel conversion function to per scan-line method
>>>>>>>> 
>>>>>>>>  This patch changes the implementation of conversion from the TIFF
>>>>>>>>  scanline buffer from a function call on each pixel to a function call
>>>>>>>>  per scanline. The enable efficient copying of similar scanline and
>>>>>>>>  better reuse of variables for palette look ups.
>>>>>>>> 
>>>>>>>>  This can increase the performance of reading grayscale images by up to
>>>>>>>>  3X for cached files.
>>>>>>>> 
>>>>>>>>  Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>>>>>>>> 
>>>>>>>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Tue Sep 30 08:56:58 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: RGBA read images should stay unchanged.
>>>>>>>> 
>>>>>>>>  The image that are read with the TIFFReadRGBAImage should not have
>>>>>>>>  their pixel types converted. This libtiff method always read images
>>>>>>>>  into an ABGR uint8 format. When the tiff file is read by this method
>>>>>>>>  it should report that uint8 and RGBA is the component an pixel type
>>>>>>>>  for the image. This allows the standard ITK buffer conversion to be
>>>>>>>>  performed.
>>>>>>>> 
>>>>>>>>  This change remove extra cases and template instantiations.
>>>>>>>> 
>>>>>>>>  Additionally the RGBAImageToBuffer method was flipping the image along
>>>>>>>>  the y-axis, this has been more explicitly done with the call to
>>>>>>>>  TIFFReadRGBAImageOriented.
>>>>>>>> 
>>>>>>>>  Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>>>>>>>> 
>>>>>>>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Fri Sep 26 14:04:09 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Remove support for TIFF tile as 3D and dead code
>>>>>>>> 
>>>>>>>>  This TIFF file format is a file which contains a list of directories,
>>>>>>>>  if there are no directories in the file it's not a valid tiff. Code
>>>>>>>>  which supported 3D tiles was conditioned on a file with no directories
>>>>>>>>  and no data. Additional code was removed related to a private SGI tag
>>>>>>>>  TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>>>>>>>>  invalid case.
>>>>>>>> 
>>>>>>>>  Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>>>>>>>> 
>>>>>>>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Mon Oct 6 10:01:50 2014 -0400
>>>>>>>> 
>>>>>>>>  BUG: Address Coverity warning about null pointer dereferences
>>>>>>>> 
>>>>>>>>  The patch addressed the following Coverity warnings:
>>>>>>>> 
>>>>>>>>  ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>>>>>>>>  itkTIFFImageIO.cxx:
>>>>>>>>  1192 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>>>> 
>>>>>>>>  ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>>>>>>>>  itkTIFFImageIO.cxx:
>>>>>>>>  1096 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>>>> 
>>>>>>>>  ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>>>>>>>>  itkTIFFImageIO.cxx:
>>>>>>>>  1100 in itk::TIFFImageIO::ReadTIFFTags()()
>>>>>>>>  Last login: Fri Oct  3 19:47:29 on ttys004
>>>>>>>> 
>>>>>>>>  Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>>>>>>>> 
>>>>>>>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Fri Sep 26 11:04:38 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>>>>>>>> 
>>>>>>>>  Refactoring of the pixelOffset to include the number of components
>>>>>>>>  remove the need for a separate block for RGB multi-component files.
>>>>>>>> 
>>>>>>>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Wed Sep 24 15:00:54 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: add arbitrary TIFF TAGs to meta-data dictionary
>>>>>>>> 
>>>>>>>>  A more general approach to adding custom tiff tags to the meta-data
>>>>>>>>  dictionary has been used based on the implementation of libtiff's
>>>>>>>>  PrintDirectory method and the libtiff "Defining New TIFF Tags"
>>>>>>>>  documentation.
>>>>>>>> 
>>>>>>>>  Additionally a new test image was added generated in Photoshop, which
>>>>>>>>  has a novel pixel layout, and also contains additional tag types such
>>>>>>>>  as byte, and size specified ascii.
>>>>>>>> 
>>>>>>>>  Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>>>>>>>> 
>>>>>>>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Mon Sep 22 15:08:36 2014 -0400
>>>>>>>> 
>>>>>>>>  BUG: Use array delete operator for array new allocations
>>>>>>>> 
>>>>>>>>  Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>>>>>>>> 
>>>>>>>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Tue Sep 23 11:14:15 2014 -0400
>>>>>>>> 
>>>>>>>>  STYLE: Fix minor kwstyle defects in test and test results
>>>>>>>> 
>>>>>>>>  Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>>>>>>>> 
>>>>>>>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>>>>>>>> Author: Richard Beare <Richard.Beare at ieee.org>
>>>>>>>> Date:   Tue Sep 23 11:11:34 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Include TIFF tags in the MetaDataDictionary
>>>>>>>> 
>>>>>>>>  Add contribution from the Insight Journal:
>>>>>>>>  http://hdl.handle.net/10380/3170
>>>>>>>> 
>>>>>>>>  Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>>>>>>>> 
>>>>>>>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Mon Sep 22 14:46:44 2014 -0400
>>>>>>>> 
>>>>>>>>  BUG: Remove dead separated plannar code, add test
>>>>>>>> 
>>>>>>>>  The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>>>>>>>>  preceded by a unreachable due to a conditional and exception
>>>>>>>>  check. Support for this configuration remains in the TIFFReadRGBAImage
>>>>>>>>  method. A test for the configuration has been added.
>>>>>>>> 
>>>>>>>>  A new input image is added from the from the libTiff test images:
>>>>>>>> 
>>>>>>>>  PlanarConfiguration = 2 (separated samples)
>>>>>>>>  -------------------------------------------
>>>>>>>>  oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>>>>>>>> 
>>>>>>>>  Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>>>>>>>> 
>>>>>>>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Mon Sep 22 13:32:23 2014 -0400
>>>>>>>> 
>>>>>>>>  BUG: Fix right oriented tiff images
>>>>>>>> 
>>>>>>>>  The TIFFImageIO::ReadGenericImage method correctly handled top-left
>>>>>>>>  oriented images, and bottom-right image, however images oriented with
>>>>>>>>  right were non-correctly handled. These cases are now handled
>>>>>>>>  correctly by the TIFFRGBAImage generic path.
>>>>>>>> 
>>>>>>>>  New test images of the cthead1 image were added which have been
>>>>>>>>  flipped the to the different orientation, and the matching orientation
>>>>>>>>  tag specified so that they should all be read as equivalent
>>>>>>>>  images. These have been added as a test case.
>>>>>>>> 
>>>>>>>>  Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>>>>>>>> 
>>>>>>>> commit 6263f4389026f1bd770054e86c428b56629d705b
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Thu Sep 18 16:20:41 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Refactor duplicated code to read a page
>>>>>>>> 
>>>>>>>>  Created a method to read a single page or sub-image in a tiff
>>>>>>>>  file. Simular code was both in the ReadVolume method for 3-d and the
>>>>>>>>  Read method for 2-d. The code block from ReadVolume was used because
>>>>>>>>  it contained more typed cases. There for this patch does improve the
>>>>>>>>  2d reading capabilities for tiffio, so that they are consistent with
>>>>>>>>  the 3d.
>>>>>>>> 
>>>>>>>>  Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>>>>>>>> 
>>>>>>>> commit 233571f1e626917bce872e450907bc8e8521e371
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Thu Sep 18 14:59:58 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Refactor method to convert RGBA image to output buffer
>>>>>>>> 
>>>>>>>>  BUG: Address overflow issue when computing page offset with
>>>>>>>>  TIFFReadRGBAImage method.
>>>>>>>> 
>>>>>>>>  Extract repeated code to convert from ReadRGBAImage to output image
>>>>>>>>  type.
>>>>>>>> 
>>>>>>>>  Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>>>>>>>> 
>>>>>>>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Thu Sep 18 11:30:41 2014 -0400
>>>>>>>> 
>>>>>>>>  BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>>>>>>>> )
>>>>>>>> 
>>>>>>>>  There are no tests for this branch of code. It only works in 3D under
>>>>>>>>  certain cases. There are apparent bugs in the code such as not setting
>>>>>>>>  all of the input image, and logically dead branches. Some downloaded
>>>>>>>>  test images for similar described format do not load. This may effect
>>>>>>>>  files with the extensions tif, tiff, or lsm.
>>>>>>>> 
>>>>>>>>  Removal of this code will enable expansion of the current code to more
>>>>>>>>  generically support multi-sample per pixel images.
>>>>>>>> 
>>>>>>>>  For more robust reading of this type of image the SCIFIO remote
>>>>>>>>  module should be used.
>>>>>>>> 
>>>>>>>>  Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>>>>>>>> 
>>>>>>>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Tue Sep 16 15:31:52 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Refactor GenericReadImage into template function
>>>>>>>> 
>>>>>>>>  Reduce code duplication by using template method.
>>>>>>>> 
>>>>>>>>  Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>>>>>>>> 
>>>>>>>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Tue Sep 16 12:09:59 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Refactor ReadTwoSamplePerPixelImage into template function
>>>>>>>> 
>>>>>>>>  Reduce code duplication by using template method.
>>>>>>>> 
>>>>>>>>  Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>>>>>>>> 
>>>>>>>> commit 0b573136d636613217df9683ea846db8039f9312
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Tue Sep 16 11:12:45 2014 -0400
>>>>>>>> 
>>>>>>>>  ENH: Extract TiffReaderInternal to separate file
>>>>>>>> 
>>>>>>>>  Refactored private class to be in separate private header.
>>>>>>>> 
>>>>>>>>  Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>>>>>>>> 
>>>>>>>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>>>>>>>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>>>>>>> Date:   Mon Sep 15 16:46:26 2014 -0400
>>>>>>>> 
>>>>>>>>  BUG: Fix overflows computing size of read tiff image
>>>>>>>> 
>>>>>>>>  When multiplying the height and width of an tiff image (32-bits),
>>>>>>>>  at least one element should be converted to size_t to help prevent
>>>>>>>>  numeric overflow.
>>>>>>>> 
>>>>>>>>  This change enables reading of larger RGB and large 2D image, that
>>>>>>>>  were previously truncated when reading. This does not address
>>>>>>>>  potential buffer overflow or resource limits which could occur.
>>>>>>>> 
>>>>>>>>  Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>>>>>>>> 
>>>>>>>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>>>>>>>> Author: Matt McCormick <matt.mccormick at kitware.com>
>>>>>>>> Date:   Mon Aug 25 00:35:48 2014 -0400
>>>>>>>> 
>>>>>>>>  COMP: Do not use _stat64 with MinGW-32.
>>>>>>>> 
>>>>>>>>  Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>>>>>>>>  including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>>>>>>>> with
>>>>>>>>  MinGW-32.
>>>>>>>> 
>>>>>>>>  Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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://kitware.com/products/protraining.php
>>>>>>>> 
>>>>>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Unpaid intern in BillsBasement at noware dot com
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>> 
>>> 
>>> 
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>> 
> 
> 
> 
> -- 
> Unpaid intern in BillsBasement at noware dot com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141114/c760595c/attachment-0001.html>

From bill.lorensen at gmail.com  Fri Nov 14 12:44:14 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 14 Nov 2014 12:44:14 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
 <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
 <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
 <C64961EA-03EE-4E61-90C4-0C2F3E33B33E@mail.nih.gov>
 <CADZJ4hOCHgq-kE8qLrmUpvAiFFPuJwFUX6GzDm1Tx_Ovow1A9w@mail.gmail.com>
 <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov>
Message-ID: <CADZJ4hMXUFhiNAWprb6oBwOzfpkF3szz1MGr8RHAPwZs5N3BFQ@mail.gmail.com>

I added that compression option to the possibilities


On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Bill,
>
> Your images have an odd compression:
>
> $ tiffinfo
> /scratch/blowekamp/build/VTK/ExternalData/Testing/Data/libtiff/tiled_64x64_tiff_example.tif
> TIFF Directory at offset 0x81f6 (33270)
>   Image Width: 256 Image Length: 256
>   Tile Width: 64 Tile Length: 64
>   Bits/Sample: 8
>   Compression Scheme: AdobeDeflate
>   Photometric Interpretation: min-is-black
>   FillOrder: msb-to-lsb
>   Orientation: row 0 top, col 0 lhs
>   Samples/Pixel: 1
>   Rows/Strip: 256
>   Planar Configuration: single image plane
>   Page Number: 0-1
>   DocumentName: foo.tif
>   White Point: 0.3127-0.329
>   PrimaryChromaticities:
> 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000
>   Predictor: horizontal differencing 2 (0x2)
>
> This "AdobeDeflate" is not supported by the
> itk::TIFFImageIOInternal::CanRead method. This is what is causing the usage
> of TIFFRGBARead and not the fact that it's a tiled image.
>
> How is VTK handling this odd compression?
>
> Brad
>
> On Nov 14, 2014, at 11:09 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> Yes, from the vtk tests. I created them with imagemagik
>
>
> On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>
> Actually further reading the TIFFReadScanline documentation says that should
> not work for tiled images. So I guess it must be using the RGBA read method,
> but I am not sure how that is happening either.
>
> Are you used the tiled tiff images from the VTK tests?
>
> Brad
>
>
> On Nov 14, 2014, at 10:46 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> Meant to say:
> Wow. The new itk tiff reader read my tiled images.
>
>
> On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
> Wow. The new itk tiff reader sad my tiled images.
>
> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>
> There is a TIFFReadTile call in lib tiff. I some tiled images I will
> try with the updated itk reader. I'll be really syprised if it works
> since reading tiled images is tricky and took quite a bit of code.
>
> I'll keep you posted.
>
> Bill
>
> On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>
> Bill,
>
> There was a tile block of code before, but that was not covered, looked
> unreachable and was removed.
>
> Currently there are two ways that a tiff page can be read with the
> TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method
> from libtiff is fairly robust but reads the image into an RGBA buffer so is
> not memory efficient. Our custom method uses the scanline method [1], which
> should work with both stripped and tiled pages.
>
> But please test, and add a test? I'm not 100% if there is a test image for
> tiled images.
>
> Where the difference between stripped and tiled images would really matter
> is streaming, but that is not there...yet.
>
> Brad
>
> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>
>
> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> Brad,
>
> I recently added tiled image reading to VTK's tiff reader. Do you
> think that would be useful in IUTK. I don't know how often tiled tiff
> images are encountered.
>
> BTW I do not mean tiled pyramid tiff images.
>
> Bill
>
> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>
> Greetings,
>
> I have recently refactored ITK's TIFFImageIO to remove a significant amount
> of dead code, and improve performance up to 3-5X. A number of bug related to
> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
> place into the Meta-DataDictionary to allow access to additional TIFF fields
> such as OME-XML tags ( Originally contributed by Richard Beare
> http://www.insight-journal.org/browse/publication/728 ).
>
> Significant performance improvements were made to both scalar images and
> palette images. Handling of certain orientations are now "better" handled,
> while not changing how the default TOPLEFT orientation is loaded or written.
> There were a number of cases which appear unreachable and illogical such as
> support from Zeiss two-componet types, and support for some type of SGI
> tiled tiff as a 3D image. These were removed.
>
> If you are an active user of TIFF images with ITK, please checkout the
> latest ITK master and test the refactored TIFFImageIO.
>
> Thanks,
> Brad
>
> p.s. Here is the git log for the recent changes.
>
> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>
> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Oct 31 14:25:13 2014 -0400
>
>  ENH: adding TIFFImageIO test for RGB palette images
>
>  Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>
> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Oct 24 13:42:02 2014 -0400
>
>  BUG: Adding missing parentheses around boolean expression
>
>  Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>
> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Wed Oct 22 15:05:39 2014 -0400
>
>  PERF: Refactor color table lookup
>
>  Change to use a index lookup for the color and gray scale
>  palettes. The remove excessive exception checking done on a per pixel
>  basis with the GetColor method. Additionally the InitializeColor
>  method was change do initialize the color palette variables.
>
>  An exception no longer occurs when an index exceeds the number of
>  entries in a palette. Instead a module operator is used to prevent
>  out of bounds memory access.
>
>  Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>
> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Oct 3 09:01:28 2014 -0400
>
>  ENH: Refactor per pixel conversion function to per scan-line method
>
>  This patch changes the implementation of conversion from the TIFF
>  scanline buffer from a function call on each pixel to a function call
>  per scanline. The enable efficient copying of similar scanline and
>  better reuse of variables for palette look ups.
>
>  This can increase the performance of reading grayscale images by up to
>  3X for cached files.
>
>  Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>
> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 30 08:56:58 2014 -0400
>
>  ENH: RGBA read images should stay unchanged.
>
>  The image that are read with the TIFFReadRGBAImage should not have
>  their pixel types converted. This libtiff method always read images
>  into an ABGR uint8 format. When the tiff file is read by this method
>  it should report that uint8 and RGBA is the component an pixel type
>  for the image. This allows the standard ITK buffer conversion to be
>  performed.
>
>  This change remove extra cases and template instantiations.
>
>  Additionally the RGBAImageToBuffer method was flipping the image along
>  the y-axis, this has been more explicitly done with the call to
>  TIFFReadRGBAImageOriented.
>
>  Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>
> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Sep 26 14:04:09 2014 -0400
>
>  ENH: Remove support for TIFF tile as 3D and dead code
>
>  This TIFF file format is a file which contains a list of directories,
>  if there are no directories in the file it's not a valid tiff. Code
>  which supported 3D tiles was conditioned on a file with no directories
>  and no data. Additional code was removed related to a private SGI tag
>  TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>  invalid case.
>
>  Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>
> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Oct 6 10:01:50 2014 -0400
>
>  BUG: Address Coverity warning about null pointer dereferences
>
>  The patch addressed the following Coverity warnings:
>
>  ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>  itkTIFFImageIO.cxx:
>  1192 in itk::TIFFImageIO::ReadTIFFTags()()
>
>  ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>  itkTIFFImageIO.cxx:
>  1096 in itk::TIFFImageIO::ReadTIFFTags()()
>
>  ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>  itkTIFFImageIO.cxx:
>  1100 in itk::TIFFImageIO::ReadTIFFTags()()
>  Last login: Fri Oct  3 19:47:29 on ttys004
>
>  Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>
> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Fri Sep 26 11:04:38 2014 -0400
>
>  ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>
>  Refactoring of the pixelOffset to include the number of components
>  remove the need for a separate block for RGB multi-component files.
>
> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Wed Sep 24 15:00:54 2014 -0400
>
>  ENH: add arbitrary TIFF TAGs to meta-data dictionary
>
>  A more general approach to adding custom tiff tags to the meta-data
>  dictionary has been used based on the implementation of libtiff's
>  PrintDirectory method and the libtiff "Defining New TIFF Tags"
>  documentation.
>
>  Additionally a new test image was added generated in Photoshop, which
>  has a novel pixel layout, and also contains additional tag types such
>  as byte, and size specified ascii.
>
>  Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>
> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Sep 22 15:08:36 2014 -0400
>
>  BUG: Use array delete operator for array new allocations
>
>  Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>
> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 23 11:14:15 2014 -0400
>
>  STYLE: Fix minor kwstyle defects in test and test results
>
>  Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>
> commit 869f3275120646829b27d5cd75c23800d9df01cd
> Author: Richard Beare <Richard.Beare at ieee.org>
> Date:   Tue Sep 23 11:11:34 2014 -0400
>
>  ENH: Include TIFF tags in the MetaDataDictionary
>
>  Add contribution from the Insight Journal:
>  http://hdl.handle.net/10380/3170
>
>  Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>
> commit c7a76c9acb319862647a651a2060dd3fb16560d7
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Sep 22 14:46:44 2014 -0400
>
>  BUG: Remove dead separated plannar code, add test
>
>  The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>  preceded by a unreachable due to a conditional and exception
>  check. Support for this configuration remains in the TIFFReadRGBAImage
>  method. A test for the configuration has been added.
>
>  A new input image is added from the from the libTiff test images:
>
>  PlanarConfiguration = 2 (separated samples)
>  -------------------------------------------
>  oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>
>  Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>
> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Sep 22 13:32:23 2014 -0400
>
>  BUG: Fix right oriented tiff images
>
>  The TIFFImageIO::ReadGenericImage method correctly handled top-left
>  oriented images, and bottom-right image, however images oriented with
>  right were non-correctly handled. These cases are now handled
>  correctly by the TIFFRGBAImage generic path.
>
>  New test images of the cthead1 image were added which have been
>  flipped the to the different orientation, and the matching orientation
>  tag specified so that they should all be read as equivalent
>  images. These have been added as a test case.
>
>  Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>
> commit 6263f4389026f1bd770054e86c428b56629d705b
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Thu Sep 18 16:20:41 2014 -0400
>
>  ENH: Refactor duplicated code to read a page
>
>  Created a method to read a single page or sub-image in a tiff
>  file. Simular code was both in the ReadVolume method for 3-d and the
>  Read method for 2-d. The code block from ReadVolume was used because
>  it contained more typed cases. There for this patch does improve the
>  2d reading capabilities for tiffio, so that they are consistent with
>  the 3d.
>
>  Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>
> commit 233571f1e626917bce872e450907bc8e8521e371
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Thu Sep 18 14:59:58 2014 -0400
>
>  ENH: Refactor method to convert RGBA image to output buffer
>
>  BUG: Address overflow issue when computing page offset with
>  TIFFReadRGBAImage method.
>
>  Extract repeated code to convert from ReadRGBAImage to output image
>  type.
>
>  Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>
> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Thu Sep 18 11:30:41 2014 -0400
>
>  BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
> )
>
>  There are no tests for this branch of code. It only works in 3D under
>  certain cases. There are apparent bugs in the code such as not setting
>  all of the input image, and logically dead branches. Some downloaded
>  test images for similar described format do not load. This may effect
>  files with the extensions tif, tiff, or lsm.
>
>  Removal of this code will enable expansion of the current code to more
>  generically support multi-sample per pixel images.
>
>  For more robust reading of this type of image the SCIFIO remote
>  module should be used.
>
>  Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>
> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 16 15:31:52 2014 -0400
>
>  ENH: Refactor GenericReadImage into template function
>
>  Reduce code duplication by using template method.
>
>  Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>
> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 16 12:09:59 2014 -0400
>
>  ENH: Refactor ReadTwoSamplePerPixelImage into template function
>
>  Reduce code duplication by using template method.
>
>  Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>
> commit 0b573136d636613217df9683ea846db8039f9312
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Tue Sep 16 11:12:45 2014 -0400
>
>  ENH: Extract TiffReaderInternal to separate file
>
>  Refactored private class to be in separate private header.
>
>  Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>
> commit 6791b4a3613aade07e3f11f765f1316faf03b113
> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date:   Mon Sep 15 16:46:26 2014 -0400
>
>  BUG: Fix overflows computing size of read tiff image
>
>  When multiplying the height and width of an tiff image (32-bits),
>  at least one element should be converted to size_t to help prevent
>  numeric overflow.
>
>  This change enables reading of larger RGB and large 2D image, that
>  were previously truncated when reading. This does not address
>  potential buffer overflow or resource limits which could occur.
>
>  Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>
> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
> Author: Matt McCormick <matt.mccormick at kitware.com>
> Date:   Mon Aug 25 00:35:48 2014 -0400
>
>  COMP: Do not use _stat64 with MinGW-32.
>
>  Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>  including _stat64.  Do not use use _stat64 in TIFFImageIO when building
> with
>  MinGW-32.
>
>  Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>
>
>
>
> _______________________________________________
> 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://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
>



-- 
Unpaid intern in BillsBasement at noware dot com

From blowekamp at mail.nih.gov  Fri Nov 14 13:44:25 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 14 Nov 2014 13:44:25 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CADZJ4hMXUFhiNAWprb6oBwOzfpkF3szz1MGr8RHAPwZs5N3BFQ@mail.gmail.com>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
 <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
 <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
 <C64961EA-03EE-4E61-90C4-0C2F3E33B33E@mail.nih.gov>
 <CADZJ4hOCHgq-kE8qLrmUpvAiFFPuJwFUX6GzDm1Tx_Ovow1A9w@mail.gmail.com>
 <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov>
 <CADZJ4hMXUFhiNAWprb6oBwOzfpkF3szz1MGr8RHAPwZs5N3BFQ@mail.gmail.com>
Message-ID: <255B4B3C-4386-4DD4-83C1-964BD236CE0F@mail.nih.gov>

Bill,

Sorry for finding my answer so quickly after my prior e-mail. This method looks right:

int TIFFIsCODECConfigured(uint16 scheme);

http://www.remotesensing.org/libtiff/man/TIFFcodec.3tiff.html

Updating ITK...

Brad


On Nov 14, 2014, at 12:44 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:

> I added that compression option to the possibilities
> 
> 
> On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Bill,
>> 
>> Your images have an odd compression:
>> 
>> $ tiffinfo
>> /scratch/blowekamp/build/VTK/ExternalData/Testing/Data/libtiff/tiled_64x64_tiff_example.tif
>> TIFF Directory at offset 0x81f6 (33270)
>>  Image Width: 256 Image Length: 256
>>  Tile Width: 64 Tile Length: 64
>>  Bits/Sample: 8
>>  Compression Scheme: AdobeDeflate
>>  Photometric Interpretation: min-is-black
>>  FillOrder: msb-to-lsb
>>  Orientation: row 0 top, col 0 lhs
>>  Samples/Pixel: 1
>>  Rows/Strip: 256
>>  Planar Configuration: single image plane
>>  Page Number: 0-1
>>  DocumentName: foo.tif
>>  White Point: 0.3127-0.329
>>  PrimaryChromaticities:
>> 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000
>>  Predictor: horizontal differencing 2 (0x2)
>> 
>> This "AdobeDeflate" is not supported by the
>> itk::TIFFImageIOInternal::CanRead method. This is what is causing the usage
>> of TIFFRGBARead and not the fact that it's a tiled image.
>> 
>> How is VTK handling this odd compression?
>> 
>> Brad
>> 
>> On Nov 14, 2014, at 11:09 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> 
>> Yes, from the vtk tests. I created them with imagemagik
>> 
>> 
>> On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>> 
>> Actually further reading the TIFFReadScanline documentation says that should
>> not work for tiled images. So I guess it must be using the RGBA read method,
>> but I am not sure how that is happening either.
>> 
>> Are you used the tiled tiff images from the VTK tests?
>> 
>> Brad
>> 
>> 
>> On Nov 14, 2014, at 10:46 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> 
>> Meant to say:
>> Wow. The new itk tiff reader read my tiled images.
>> 
>> 
>> On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>> 
>> Wow. The new itk tiff reader sad my tiled images.
>> 
>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>> 
>> There is a TIFFReadTile call in lib tiff. I some tiled images I will
>> try with the updated itk reader. I'll be really syprised if it works
>> since reading tiled images is tricky and took quite a bit of code.
>> 
>> I'll keep you posted.
>> 
>> Bill
>> 
>> On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>> 
>> Bill,
>> 
>> There was a tile block of code before, but that was not covered, looked
>> unreachable and was removed.
>> 
>> Currently there are two ways that a tiff page can be read with the
>> TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method
>> from libtiff is fairly robust but reads the image into an RGBA buffer so is
>> not memory efficient. Our custom method uses the scanline method [1], which
>> should work with both stripped and tiled pages.
>> 
>> But please test, and add a test? I'm not 100% if there is a test image for
>> tiled images.
>> 
>> Where the difference between stripped and tiled images would really matter
>> is streaming, but that is not there...yet.
>> 
>> Brad
>> 
>> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>> 
>> 
>> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> 
>> Brad,
>> 
>> I recently added tiled image reading to VTK's tiff reader. Do you
>> think that would be useful in IUTK. I don't know how often tiled tiff
>> images are encountered.
>> 
>> BTW I do not mean tiled pyramid tiff images.
>> 
>> Bill
>> 
>> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>> 
>> Greetings,
>> 
>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>> of dead code, and improve performance up to 3-5X. A number of bug related to
>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>> such as OME-XML tags ( Originally contributed by Richard Beare
>> http://www.insight-journal.org/browse/publication/728 ).
>> 
>> Significant performance improvements were made to both scalar images and
>> palette images. Handling of certain orientations are now "better" handled,
>> while not changing how the default TOPLEFT orientation is loaded or written.
>> There were a number of cases which appear unreachable and illogical such as
>> support from Zeiss two-componet types, and support for some type of SGI
>> tiled tiff as a 3D image. These were removed.
>> 
>> If you are an active user of TIFF images with ITK, please checkout the
>> latest ITK master and test the refactored TIFFImageIO.
>> 
>> Thanks,
>> Brad
>> 
>> p.s. Here is the git log for the recent changes.
>> 
>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>> 
>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 31 14:25:13 2014 -0400
>> 
>> ENH: adding TIFFImageIO test for RGB palette images
>> 
>> Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>> 
>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 24 13:42:02 2014 -0400
>> 
>> BUG: Adding missing parentheses around boolean expression
>> 
>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>> 
>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Wed Oct 22 15:05:39 2014 -0400
>> 
>> PERF: Refactor color table lookup
>> 
>> Change to use a index lookup for the color and gray scale
>> palettes. The remove excessive exception checking done on a per pixel
>> basis with the GetColor method. Additionally the InitializeColor
>> method was change do initialize the color palette variables.
>> 
>> An exception no longer occurs when an index exceeds the number of
>> entries in a palette. Instead a module operator is used to prevent
>> out of bounds memory access.
>> 
>> Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>> 
>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 3 09:01:28 2014 -0400
>> 
>> ENH: Refactor per pixel conversion function to per scan-line method
>> 
>> This patch changes the implementation of conversion from the TIFF
>> scanline buffer from a function call on each pixel to a function call
>> per scanline. The enable efficient copying of similar scanline and
>> better reuse of variables for palette look ups.
>> 
>> This can increase the performance of reading grayscale images by up to
>> 3X for cached files.
>> 
>> Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>> 
>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 30 08:56:58 2014 -0400
>> 
>> ENH: RGBA read images should stay unchanged.
>> 
>> The image that are read with the TIFFReadRGBAImage should not have
>> their pixel types converted. This libtiff method always read images
>> into an ABGR uint8 format. When the tiff file is read by this method
>> it should report that uint8 and RGBA is the component an pixel type
>> for the image. This allows the standard ITK buffer conversion to be
>> performed.
>> 
>> This change remove extra cases and template instantiations.
>> 
>> Additionally the RGBAImageToBuffer method was flipping the image along
>> the y-axis, this has been more explicitly done with the call to
>> TIFFReadRGBAImageOriented.
>> 
>> Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>> 
>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Sep 26 14:04:09 2014 -0400
>> 
>> ENH: Remove support for TIFF tile as 3D and dead code
>> 
>> This TIFF file format is a file which contains a list of directories,
>> if there are no directories in the file it's not a valid tiff. Code
>> which supported 3D tiles was conditioned on a file with no directories
>> and no data. Additional code was removed related to a private SGI tag
>> TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>> invalid case.
>> 
>> Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>> 
>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Oct 6 10:01:50 2014 -0400
>> 
>> BUG: Address Coverity warning about null pointer dereferences
>> 
>> The patch addressed the following Coverity warnings:
>> 
>> ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>> itkTIFFImageIO.cxx:
>> 1192 in itk::TIFFImageIO::ReadTIFFTags()()
>> 
>> ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>> itkTIFFImageIO.cxx:
>> 1096 in itk::TIFFImageIO::ReadTIFFTags()()
>> 
>> ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>> itkTIFFImageIO.cxx:
>> 1100 in itk::TIFFImageIO::ReadTIFFTags()()
>> Last login: Fri Oct  3 19:47:29 on ttys004
>> 
>> Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>> 
>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Sep 26 11:04:38 2014 -0400
>> 
>> ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>> 
>> Refactoring of the pixelOffset to include the number of components
>> remove the need for a separate block for RGB multi-component files.
>> 
>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Wed Sep 24 15:00:54 2014 -0400
>> 
>> ENH: add arbitrary TIFF TAGs to meta-data dictionary
>> 
>> A more general approach to adding custom tiff tags to the meta-data
>> dictionary has been used based on the implementation of libtiff's
>> PrintDirectory method and the libtiff "Defining New TIFF Tags"
>> documentation.
>> 
>> Additionally a new test image was added generated in Photoshop, which
>> has a novel pixel layout, and also contains additional tag types such
>> as byte, and size specified ascii.
>> 
>> Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>> 
>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 15:08:36 2014 -0400
>> 
>> BUG: Use array delete operator for array new allocations
>> 
>> Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>> 
>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 23 11:14:15 2014 -0400
>> 
>> STYLE: Fix minor kwstyle defects in test and test results
>> 
>> Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>> 
>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>> Author: Richard Beare <Richard.Beare at ieee.org>
>> Date:   Tue Sep 23 11:11:34 2014 -0400
>> 
>> ENH: Include TIFF tags in the MetaDataDictionary
>> 
>> Add contribution from the Insight Journal:
>> http://hdl.handle.net/10380/3170
>> 
>> Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>> 
>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 14:46:44 2014 -0400
>> 
>> BUG: Remove dead separated plannar code, add test
>> 
>> The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>> preceded by a unreachable due to a conditional and exception
>> check. Support for this configuration remains in the TIFFReadRGBAImage
>> method. A test for the configuration has been added.
>> 
>> A new input image is added from the from the libTiff test images:
>> 
>> PlanarConfiguration = 2 (separated samples)
>> -------------------------------------------
>> oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>> 
>> Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>> 
>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 13:32:23 2014 -0400
>> 
>> BUG: Fix right oriented tiff images
>> 
>> The TIFFImageIO::ReadGenericImage method correctly handled top-left
>> oriented images, and bottom-right image, however images oriented with
>> right were non-correctly handled. These cases are now handled
>> correctly by the TIFFRGBAImage generic path.
>> 
>> New test images of the cthead1 image were added which have been
>> flipped the to the different orientation, and the matching orientation
>> tag specified so that they should all be read as equivalent
>> images. These have been added as a test case.
>> 
>> Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>> 
>> commit 6263f4389026f1bd770054e86c428b56629d705b
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 16:20:41 2014 -0400
>> 
>> ENH: Refactor duplicated code to read a page
>> 
>> Created a method to read a single page or sub-image in a tiff
>> file. Simular code was both in the ReadVolume method for 3-d and the
>> Read method for 2-d. The code block from ReadVolume was used because
>> it contained more typed cases. There for this patch does improve the
>> 2d reading capabilities for tiffio, so that they are consistent with
>> the 3d.
>> 
>> Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>> 
>> commit 233571f1e626917bce872e450907bc8e8521e371
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 14:59:58 2014 -0400
>> 
>> ENH: Refactor method to convert RGBA image to output buffer
>> 
>> BUG: Address overflow issue when computing page offset with
>> TIFFReadRGBAImage method.
>> 
>> Extract repeated code to convert from ReadRGBAImage to output image
>> type.
>> 
>> Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>> 
>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 11:30:41 2014 -0400
>> 
>> BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>> )
>> 
>> There are no tests for this branch of code. It only works in 3D under
>> certain cases. There are apparent bugs in the code such as not setting
>> all of the input image, and logically dead branches. Some downloaded
>> test images for similar described format do not load. This may effect
>> files with the extensions tif, tiff, or lsm.
>> 
>> Removal of this code will enable expansion of the current code to more
>> generically support multi-sample per pixel images.
>> 
>> For more robust reading of this type of image the SCIFIO remote
>> module should be used.
>> 
>> Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>> 
>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 15:31:52 2014 -0400
>> 
>> ENH: Refactor GenericReadImage into template function
>> 
>> Reduce code duplication by using template method.
>> 
>> Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>> 
>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 12:09:59 2014 -0400
>> 
>> ENH: Refactor ReadTwoSamplePerPixelImage into template function
>> 
>> Reduce code duplication by using template method.
>> 
>> Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>> 
>> commit 0b573136d636613217df9683ea846db8039f9312
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 11:12:45 2014 -0400
>> 
>> ENH: Extract TiffReaderInternal to separate file
>> 
>> Refactored private class to be in separate private header.
>> 
>> Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>> 
>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 15 16:46:26 2014 -0400
>> 
>> BUG: Fix overflows computing size of read tiff image
>> 
>> When multiplying the height and width of an tiff image (32-bits),
>> at least one element should be converted to size_t to help prevent
>> numeric overflow.
>> 
>> This change enables reading of larger RGB and large 2D image, that
>> were previously truncated when reading. This does not address
>> potential buffer overflow or resource limits which could occur.
>> 
>> Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>> 
>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>> Author: Matt McCormick <matt.mccormick at kitware.com>
>> Date:   Mon Aug 25 00:35:48 2014 -0400
>> 
>> COMP: Do not use _stat64 with MinGW-32.
>> 
>> Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>> including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>> with
>> MinGW-32.
>> 
>> Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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://kitware.com/products/protraining.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-developers
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
> 
> 
> 
> -- 
> Unpaid intern in BillsBasement at noware dot com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141114/e66d63b7/attachment.html>

From blowekamp at mail.nih.gov  Fri Nov 14 13:41:48 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 14 Nov 2014 13:41:48 -0500
Subject: [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CADZJ4hMXUFhiNAWprb6oBwOzfpkF3szz1MGr8RHAPwZs5N3BFQ@mail.gmail.com>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
 <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
 <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
 <C64961EA-03EE-4E61-90C4-0C2F3E33B33E@mail.nih.gov>
 <CADZJ4hOCHgq-kE8qLrmUpvAiFFPuJwFUX6GzDm1Tx_Ovow1A9w@mail.gmail.com>
 <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov>
 <CADZJ4hMXUFhiNAWprb6oBwOzfpkF3szz1MGr8RHAPwZs5N3BFQ@mail.gmail.com>
Message-ID: <C2B48E8D-210C-4C7E-B993-C83372874C1C@mail.nih.gov>

Bill,

There are quite a number of possible compression types which can be used in a tiff file[1]. Some of these are enabled/disable at compilation time based in what external libraries are used. These are defined with preprocessor directives in the tiff configuration file[2]. Ideally CanRead should some how query libtiff about support for this... I am looking for some type of documentation now...


Brad


[1] http://www.awaresystems.be/imaging/tiff/tifftags/compression.html
[2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/TIFF/src/itktiff/tif_config.h.in#L218

On Nov 14, 2014, at 12:44 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:

> I added that compression option to the possibilities
> 
> 
> On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Bill,
>> 
>> Your images have an odd compression:
>> 
>> $ tiffinfo
>> /scratch/blowekamp/build/VTK/ExternalData/Testing/Data/libtiff/tiled_64x64_tiff_example.tif
>> TIFF Directory at offset 0x81f6 (33270)
>>  Image Width: 256 Image Length: 256
>>  Tile Width: 64 Tile Length: 64
>>  Bits/Sample: 8
>>  Compression Scheme: AdobeDeflate
>>  Photometric Interpretation: min-is-black
>>  FillOrder: msb-to-lsb
>>  Orientation: row 0 top, col 0 lhs
>>  Samples/Pixel: 1
>>  Rows/Strip: 256
>>  Planar Configuration: single image plane
>>  Page Number: 0-1
>>  DocumentName: foo.tif
>>  White Point: 0.3127-0.329
>>  PrimaryChromaticities:
>> 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000
>>  Predictor: horizontal differencing 2 (0x2)
>> 
>> This "AdobeDeflate" is not supported by the
>> itk::TIFFImageIOInternal::CanRead method. This is what is causing the usage
>> of TIFFRGBARead and not the fact that it's a tiled image.
>> 
>> How is VTK handling this odd compression?
>> 
>> Brad
>> 
>> On Nov 14, 2014, at 11:09 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> 
>> Yes, from the vtk tests. I created them with imagemagik
>> 
>> 
>> On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>> 
>> Actually further reading the TIFFReadScanline documentation says that should
>> not work for tiled images. So I guess it must be using the RGBA read method,
>> but I am not sure how that is happening either.
>> 
>> Are you used the tiled tiff images from the VTK tests?
>> 
>> Brad
>> 
>> 
>> On Nov 14, 2014, at 10:46 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> 
>> Meant to say:
>> Wow. The new itk tiff reader read my tiled images.
>> 
>> 
>> On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>> 
>> Wow. The new itk tiff reader sad my tiled images.
>> 
>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>> 
>> There is a TIFFReadTile call in lib tiff. I some tiled images I will
>> try with the updated itk reader. I'll be really syprised if it works
>> since reading tiled images is tricky and took quite a bit of code.
>> 
>> I'll keep you posted.
>> 
>> Bill
>> 
>> On Fri, Nov 14, 2014 at 10:19 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>> 
>> Bill,
>> 
>> There was a tile block of code before, but that was not covered, looked
>> unreachable and was removed.
>> 
>> Currently there are two ways that a tiff page can be read with the
>> TIFFReadRGBAImageOriented, and with the TIFFReadScanline. The RGBA method
>> from libtiff is fairly robust but reads the image into an RGBA buffer so is
>> not memory efficient. Our custom method uses the scanline method [1], which
>> should work with both stripped and tiled pages.
>> 
>> But please test, and add a test? I'm not 100% if there is a test image for
>> tiled images.
>> 
>> Where the difference between stripped and tiled images would really matter
>> is streaming, but that is not there...yet.
>> 
>> Brad
>> 
>> [1] http://www.remotesensing.org/libtiff/libtiff.html#scanlines
>> 
>> 
>> On Nov 14, 2014, at 10:04 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> 
>> Brad,
>> 
>> I recently added tiled image reading to VTK's tiff reader. Do you
>> think that would be useful in IUTK. I don't know how often tiled tiff
>> images are encountered.
>> 
>> BTW I do not mean tiled pyramid tiff images.
>> 
>> Bill
>> 
>> On Fri, Nov 14, 2014 at 9:53 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>> 
>> Greetings,
>> 
>> I have recently refactored ITK's TIFFImageIO to remove a significant amount
>> of dead code, and improve performance up to 3-5X. A number of bug related to
>> reading BigTIFF files have been addressed. Additionally, Tiff tags are now
>> place into the Meta-DataDictionary to allow access to additional TIFF fields
>> such as OME-XML tags ( Originally contributed by Richard Beare
>> http://www.insight-journal.org/browse/publication/728 ).
>> 
>> Significant performance improvements were made to both scalar images and
>> palette images. Handling of certain orientations are now "better" handled,
>> while not changing how the default TOPLEFT orientation is loaded or written.
>> There were a number of cases which appear unreachable and illogical such as
>> support from Zeiss two-componet types, and support for some type of SGI
>> tiled tiff as a 3D image. These were removed.
>> 
>> If you are an active user of TIFF images with ITK, please checkout the
>> latest ITK master and test the refactored TIFFImageIO.
>> 
>> Thanks,
>> Brad
>> 
>> p.s. Here is the git log for the recent changes.
>> 
>> $git log --no-merges 6791b4a3613aade07e3f11f765f1316faf03b113..
>> 
>> commit 46f4125df47aeff9c42c9f2b3699c06e67ffaca9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 31 14:25:13 2014 -0400
>> 
>> ENH: adding TIFFImageIO test for RGB palette images
>> 
>> Change-Id: I320acc8beac8225616451d11b291b1d7e12a17d0
>> 
>> commit 9adc54c7f53b4da84a41f500d561ae494cb85158
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 24 13:42:02 2014 -0400
>> 
>> BUG: Adding missing parentheses around boolean expression
>> 
>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79
>> 
>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Wed Oct 22 15:05:39 2014 -0400
>> 
>> PERF: Refactor color table lookup
>> 
>> Change to use a index lookup for the color and gray scale
>> palettes. The remove excessive exception checking done on a per pixel
>> basis with the GetColor method. Additionally the InitializeColor
>> method was change do initialize the color palette variables.
>> 
>> An exception no longer occurs when an index exceeds the number of
>> entries in a palette. Instead a module operator is used to prevent
>> out of bounds memory access.
>> 
>> Change-Id: Ia62c65cd8b1be0d66c488540709a8fb961190cc9
>> 
>> commit d98cbeb7206f6007f7d0c25fd4a4becad8973053
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Oct 3 09:01:28 2014 -0400
>> 
>> ENH: Refactor per pixel conversion function to per scan-line method
>> 
>> This patch changes the implementation of conversion from the TIFF
>> scanline buffer from a function call on each pixel to a function call
>> per scanline. The enable efficient copying of similar scanline and
>> better reuse of variables for palette look ups.
>> 
>> This can increase the performance of reading grayscale images by up to
>> 3X for cached files.
>> 
>> Change-Id: I24bb744fda35629f1c1ed7154e26e5708e912059
>> 
>> commit 8e488f40e8cb7defa046700798b77e3944ac33c9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 30 08:56:58 2014 -0400
>> 
>> ENH: RGBA read images should stay unchanged.
>> 
>> The image that are read with the TIFFReadRGBAImage should not have
>> their pixel types converted. This libtiff method always read images
>> into an ABGR uint8 format. When the tiff file is read by this method
>> it should report that uint8 and RGBA is the component an pixel type
>> for the image. This allows the standard ITK buffer conversion to be
>> performed.
>> 
>> This change remove extra cases and template instantiations.
>> 
>> Additionally the RGBAImageToBuffer method was flipping the image along
>> the y-axis, this has been more explicitly done with the call to
>> TIFFReadRGBAImageOriented.
>> 
>> Change-Id: I022b12921d406edb09730f905213b0db811f1bd4
>> 
>> commit e5834d5b00e4e3fab3255d88e7d8fd917ee722e9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Sep 26 14:04:09 2014 -0400
>> 
>> ENH: Remove support for TIFF tile as 3D and dead code
>> 
>> This TIFF file format is a file which contains a list of directories,
>> if there are no directories in the file it's not a valid tiff. Code
>> which supported 3D tiles was conditioned on a file with no directories
>> and no data. Additional code was removed related to a private SGI tag
>> TIFFTAG_TILEDEPTH, ImageJ specific tag also pre-conditioned on this
>> invalid case.
>> 
>> Change-Id: Id4ef171c5dbe0c797be206e0059c7488719ef6e6
>> 
>> commit 3ac19a9ffd94e02254900dd0e5e2661c329e3183
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Oct 6 10:01:50 2014 -0400
>> 
>> BUG: Address Coverity warning about null pointer dereferences
>> 
>> The patch addressed the following Coverity warnings:
>> 
>> ** CID 1243373:  Explicit null dereferenced  (FORWARD_NULL)
>> itkTIFFImageIO.cxx:
>> 1192 in itk::TIFFImageIO::ReadTIFFTags()()
>> 
>> ** CID 1243372:  Dereference null return value  (NULL_RETURNS)
>> itkTIFFImageIO.cxx:
>> 1096 in itk::TIFFImageIO::ReadTIFFTags()()
>> 
>> ** CID 1243371:  Dereference before null check  (REVERSE_INULL)
>> itkTIFFImageIO.cxx:
>> 1100 in itk::TIFFImageIO::ReadTIFFTags()()
>> Last login: Fri Oct  3 19:47:29 on ttys004
>> 
>> Change-Id: I02c8435628c860ff03889b9b57e9dd1543bf82da
>> 
>> commit 52ce992f3a57ef9f187f9c4b4ebd7ce20db365bd
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Fri Sep 26 11:04:38 2014 -0400
>> 
>> ENH: Reduce code duplicate in TIFFImageIO::ReadCurrentPage
>> 
>> Refactoring of the pixelOffset to include the number of components
>> remove the need for a separate block for RGB multi-component files.
>> 
>> commit 97b33787ec17b76a61fdb43b5f1e1ea708bbac2c
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Wed Sep 24 15:00:54 2014 -0400
>> 
>> ENH: add arbitrary TIFF TAGs to meta-data dictionary
>> 
>> A more general approach to adding custom tiff tags to the meta-data
>> dictionary has been used based on the implementation of libtiff's
>> PrintDirectory method and the libtiff "Defining New TIFF Tags"
>> documentation.
>> 
>> Additionally a new test image was added generated in Photoshop, which
>> has a novel pixel layout, and also contains additional tag types such
>> as byte, and size specified ascii.
>> 
>> Change-Id: Idb2e669e540cfbe27a932444011f4b9896ca403d
>> 
>> commit 795c71abb8b5c3a09d461ec7b34eefbfdcb460e9
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 15:08:36 2014 -0400
>> 
>> BUG: Use array delete operator for array new allocations
>> 
>> Change-Id: Ic9bc3c3792083a1a1b3fd842486a7436a4086150
>> 
>> commit 83e8b6e699b3d9e2da8533dd1ea36dc0692bc9eb
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 23 11:14:15 2014 -0400
>> 
>> STYLE: Fix minor kwstyle defects in test and test results
>> 
>> Change-Id: I4b2641d31acb5c764de4041bb7d21c08b3c99846
>> 
>> commit 869f3275120646829b27d5cd75c23800d9df01cd
>> Author: Richard Beare <Richard.Beare at ieee.org>
>> Date:   Tue Sep 23 11:11:34 2014 -0400
>> 
>> ENH: Include TIFF tags in the MetaDataDictionary
>> 
>> Add contribution from the Insight Journal:
>> http://hdl.handle.net/10380/3170
>> 
>> Change-Id: I20b02394d92c421bad75c5d0af496a6e80089ac0
>> 
>> commit c7a76c9acb319862647a651a2060dd3fb16560d7
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 14:46:44 2014 -0400
>> 
>> BUG: Remove dead separated plannar code, add test
>> 
>> The PLANARCONFIG_SEPARATE block in TIFFImageIO::ReadGenericImage, was
>> preceded by a unreachable due to a conditional and exception
>> check. Support for this configuration remains in the TIFFReadRGBAImage
>> method. A test for the configuration has been added.
>> 
>> A new input image is added from the from the libTiff test images:
>> 
>> PlanarConfiguration = 2 (separated samples)
>> -------------------------------------------
>> oxford.tif      601x81 8-bit RGB (lzw) screendump off oxford
>> 
>> Change-Id: Ibb874f80809b70b1aee7a2c9ff1fc8544ed56c04
>> 
>> commit 1b57d75964496dd2cc9e050a4a4425f1163d4b22
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 22 13:32:23 2014 -0400
>> 
>> BUG: Fix right oriented tiff images
>> 
>> The TIFFImageIO::ReadGenericImage method correctly handled top-left
>> oriented images, and bottom-right image, however images oriented with
>> right were non-correctly handled. These cases are now handled
>> correctly by the TIFFRGBAImage generic path.
>> 
>> New test images of the cthead1 image were added which have been
>> flipped the to the different orientation, and the matching orientation
>> tag specified so that they should all be read as equivalent
>> images. These have been added as a test case.
>> 
>> Change-Id: I058382d6d2e18341ab87edd165490be2187c1d15
>> 
>> commit 6263f4389026f1bd770054e86c428b56629d705b
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 16:20:41 2014 -0400
>> 
>> ENH: Refactor duplicated code to read a page
>> 
>> Created a method to read a single page or sub-image in a tiff
>> file. Simular code was both in the ReadVolume method for 3-d and the
>> Read method for 2-d. The code block from ReadVolume was used because
>> it contained more typed cases. There for this patch does improve the
>> 2d reading capabilities for tiffio, so that they are consistent with
>> the 3d.
>> 
>> Change-Id: I0fbfb19f04435a703bb3fa09ea4e79179592e443
>> 
>> commit 233571f1e626917bce872e450907bc8e8521e371
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 14:59:58 2014 -0400
>> 
>> ENH: Refactor method to convert RGBA image to output buffer
>> 
>> BUG: Address overflow issue when computing page offset with
>> TIFFReadRGBAImage method.
>> 
>> Extract repeated code to convert from ReadRGBAImage to output image
>> type.
>> 
>> Change-Id: Ia90b5e104f22c77493b8a4cd5bf640fd793b8b4b
>> 
>> commit 1cd59825fa65f1123726a32f67c1a443015b40ec
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Thu Sep 18 11:30:41 2014 -0400
>> 
>> BUG: Remove Zeiss 2-channel support code in TIFFImageIO ( and LSMImageIO
>> )
>> 
>> There are no tests for this branch of code. It only works in 3D under
>> certain cases. There are apparent bugs in the code such as not setting
>> all of the input image, and logically dead branches. Some downloaded
>> test images for similar described format do not load. This may effect
>> files with the extensions tif, tiff, or lsm.
>> 
>> Removal of this code will enable expansion of the current code to more
>> generically support multi-sample per pixel images.
>> 
>> For more robust reading of this type of image the SCIFIO remote
>> module should be used.
>> 
>> Change-Id: Idb98d69538db3bc8520881ea4a5e22476238c41e
>> 
>> commit 690cfdc89343fcc8c7d3cc266d652cfb14de9d41
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 15:31:52 2014 -0400
>> 
>> ENH: Refactor GenericReadImage into template function
>> 
>> Reduce code duplication by using template method.
>> 
>> Change-Id: I79411ad6595258d54cbfa5a4152cc55994acd8e0
>> 
>> commit 5f73f24bfb668fa9f33804218c0db05cf5cadb3f
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 12:09:59 2014 -0400
>> 
>> ENH: Refactor ReadTwoSamplePerPixelImage into template function
>> 
>> Reduce code duplication by using template method.
>> 
>> Change-Id: I45f417486e60a4d3e67ff31fa967dac069b3ce3e
>> 
>> commit 0b573136d636613217df9683ea846db8039f9312
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Tue Sep 16 11:12:45 2014 -0400
>> 
>> ENH: Extract TiffReaderInternal to separate file
>> 
>> Refactored private class to be in separate private header.
>> 
>> Change-Id: Icb4008c1605a3a0b62c563350cf2e3bbe948ec6d
>> 
>> commit 6791b4a3613aade07e3f11f765f1316faf03b113
>> Author: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date:   Mon Sep 15 16:46:26 2014 -0400
>> 
>> BUG: Fix overflows computing size of read tiff image
>> 
>> When multiplying the height and width of an tiff image (32-bits),
>> at least one element should be converted to size_t to help prevent
>> numeric overflow.
>> 
>> This change enables reading of larger RGB and large 2D image, that
>> were previously truncated when reading. This does not address
>> potential buffer overflow or resource limits which could occur.
>> 
>> Change-Id: I192370606677c8dc1a903c67c2a0701026256d5a
>> 
>> commit b6fabfeb2a5b8d339b2d459edd3e3c50232b55ff
>> Author: Matt McCormick <matt.mccormick at kitware.com>
>> Date:   Mon Aug 25 00:35:48 2014 -0400
>> 
>> COMP: Do not use _stat64 with MinGW-32.
>> 
>> Unlike MinGW-w64, MinGW-32 aka MinGW, does not define as much of the API
>> including _stat64.  Do not use use _stat64 in TIFFImageIO when building
>> with
>> MinGW-32.
>> 
>> Change-Id: I8f13a4500cdadf4f4adae7b5cf8893fe8b8cad55
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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://kitware.com/products/protraining.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-developers
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
>> 
>> 
>> 
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> 
>> 
> 
> 
> 
> -- 
> Unpaid intern in BillsBasement at noware dot com


From j.plumat at auckland.ac.nz  Sun Nov 16 23:10:52 2014
From: j.plumat at auckland.ac.nz (Jerome Plumat)
Date: Mon, 17 Nov 2014 17:10:52 +1300
Subject: [ITK-users] Images and Array
Message-ID: <5469754C.7010902@auckland.ac.nz>

Hi everyone,
I'm facing to a problem and I would like your opinions. I would like to 
create and to save a 4D image with dynamic voxel sizes.

My current solution involves itk::Array

typedef float ArrayValType;
typedef itk::Array< ArrayValType > ArrayType;
typedef itk::Image< ArrayType, Dimension > ImageArrayType;

That solves the unknown length of the voxels (while itk::Vector needs to 
know it before compiling).

When I create and save this volume, no error is displayed but the file 
is "empty" (the header is present but no data).
The corresponding code is, in a dedicated object:

typedef unsigned short   OutputPixelType;
typedef itk::Array< OutputPixelType > ArrayType;
typedef typename itk::Image<ArrayType, Dimension> OutputImageType;
typedef itk::ImageFileWriter< OutputImageType > MetaWriterType;

typedef itk::CastImageFilter< InputImageType, OutputImageType 
 >CastFilterType;
typename CastFilterType::Pointer cast = CastFilterType::New();
cast->SetInput( m_vol );

typename MetaWriterType::Pointer writer = MetaWriterType::New();
writer->SetFileName( m_path );
writer->SetInput( cast->GetOutput() );
writer->Update();

where InputImageType = ImageArrayType

Does this strategy should work?
Do I need to implement my own writer? Do you know some other solutions?

Thanks in advance.

-- 

Jerome Plumat
-------
School of Medical Sciences
University of Auckland

If I am not for myself, who will be for me? And if I am only for myself, then what an I? And if not now when? ? Hillel HaZaken


From millerjv at gmail.com  Mon Nov 17 06:57:54 2014
From: millerjv at gmail.com (Jim Miller)
Date: Mon, 17 Nov 2014 06:57:54 -0500
Subject: [ITK-users] Images and Array
In-Reply-To: <5469754C.7010902@auckland.ac.nz>
References: <5469754C.7010902@auckland.ac.nz>
Message-ID: <8DA50100-B017-4870-9CE0-4D43FAC9FA56@gmail.com>

It sounds like you want to use the VectorImage type. VectorImage allows the lengths of the vectors to be specified at runtime. 

Formats like MetaIO and NRRD  will support this format. 

Jim

> On Nov 16, 2014, at 11:10 PM, Jerome Plumat <j.plumat at auckland.ac.nz> wrote:
> 
> Hi everyone,
> I'm facing to a problem and I would like your opinions. I would like to create and to save a 4D image with dynamic voxel sizes.
> 
> My current solution involves itk::Array
> 
> typedef float ArrayValType;
> typedef itk::Array< ArrayValType > ArrayType;
> typedef itk::Image< ArrayType, Dimension > ImageArrayType;
> 
> That solves the unknown length of the voxels (while itk::Vector needs to know it before compiling).
> 
> When I create and save this volume, no error is displayed but the file is "empty" (the header is present but no data).
> The corresponding code is, in a dedicated object:
> 
> typedef unsigned short   OutputPixelType;
> typedef itk::Array< OutputPixelType > ArrayType;
> typedef typename itk::Image<ArrayType, Dimension> OutputImageType;
> typedef itk::ImageFileWriter< OutputImageType > MetaWriterType;
> 
> typedef itk::CastImageFilter< InputImageType, OutputImageType >CastFilterType;
> typename CastFilterType::Pointer cast = CastFilterType::New();
> cast->SetInput( m_vol );
> 
> typename MetaWriterType::Pointer writer = MetaWriterType::New();
> writer->SetFileName( m_path );
> writer->SetInput( cast->GetOutput() );
> writer->Update();
> 
> where InputImageType = ImageArrayType
> 
> Does this strategy should work?
> Do I need to implement my own writer? Do you know some other solutions?
> 
> Thanks in advance.
> 
> -- 
> 
> Jerome Plumat
> -------
> School of Medical Sciences
> University of Auckland
> 
> If I am not for myself, who will be for me? And if I am only for myself, then what an I? And if not now when? ? Hillel HaZaken
> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

From j.plumat at auckland.ac.nz  Mon Nov 17 16:47:07 2014
From: j.plumat at auckland.ac.nz (Jerome Plumat)
Date: Tue, 18 Nov 2014 10:47:07 +1300
Subject: [ITK-users] Images and Array
In-Reply-To: <8DA50100-B017-4870-9CE0-4D43FAC9FA56@gmail.com>
References: <5469754C.7010902@auckland.ac.nz>
 <8DA50100-B017-4870-9CE0-4D43FAC9FA56@gmail.com>
Message-ID: <546A6CDB.9030301@auckland.ac.nz>

Hi Jim,
Thanks for the advice. This is exactly what I'm looking for. Everything 
works as expected now.

Jerome
-------
School of Medical Sciences
University of Auckland

On 18/11/14 00:57, Jim Miller wrote:
> It sounds like you want to use the VectorImage type. VectorImage allows the lengths of the vectors to be specified at runtime.
>
> Formats like MetaIO and NRRD  will support this format.
>
> Jim
>
>> On Nov 16, 2014, at 11:10 PM, Jerome Plumat <j.plumat at auckland.ac.nz> wrote:
>>
>> Hi everyone,
>> I'm facing to a problem and I would like your opinions. I would like to create and to save a 4D image with dynamic voxel sizes.
>>
>> My current solution involves itk::Array
>>
>> typedef float ArrayValType;
>> typedef itk::Array< ArrayValType > ArrayType;
>> typedef itk::Image< ArrayType, Dimension > ImageArrayType;
>>
>> That solves the unknown length of the voxels (while itk::Vector needs to know it before compiling).
>>
>> When I create and save this volume, no error is displayed but the file is "empty" (the header is present but no data).
>> The corresponding code is, in a dedicated object:
>>
>> typedef unsigned short   OutputPixelType;
>> typedef itk::Array< OutputPixelType > ArrayType;
>> typedef typename itk::Image<ArrayType, Dimension> OutputImageType;
>> typedef itk::ImageFileWriter< OutputImageType > MetaWriterType;
>>
>> typedef itk::CastImageFilter< InputImageType, OutputImageType >CastFilterType;
>> typename CastFilterType::Pointer cast = CastFilterType::New();
>> cast->SetInput( m_vol );
>>
>> typename MetaWriterType::Pointer writer = MetaWriterType::New();
>> writer->SetFileName( m_path );
>> writer->SetInput( cast->GetOutput() );
>> writer->Update();
>>
>> where InputImageType = ImageArrayType
>>
>> Does this strategy should work?
>> Do I need to implement my own writer? Do you know some other solutions?
>>
>> Thanks in advance.
>>
>> -- 
>>
>> Jerome Plumat
>> -------
>> School of Medical Sciences
>> University of Auckland
>>
>> If I am not for myself, who will be for me? And if I am only for myself, then what an I? And if not now when? ? Hillel HaZaken
>>
>> _____________________________________
>> 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.php
>>
>> 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://public.kitware.com/mailman/listinfo/insight-users


From jmerkow at gmail.com  Mon Nov 17 18:20:10 2014
From: jmerkow at gmail.com (jmerkow)
Date: Mon, 17 Nov 2014 16:20:10 -0700 (MST)
Subject: [ITK-users] SimpleITK Downsampling results in blank image
Message-ID: <1416266410055-34923.post@n7.nabble.com>

I have a strange issue when using the Resample procedural interface in
SimpleITK.
I have tried all the call signatures, but I can't seem to get meaningful
output.
I wrote a small illustrative example, where I read an image, attempt to
downsample by 2, and get nothing out.  This is written in python, using
SimpleITK 0.8.0.

Code:

import SimpleITK as sitk
image = sitk.ReadImage('/path/to/img/cabg11-1.mha')
image = sitk.Cast(sitk.RescaleIntensity(image), sitk.sitkFloat32)
scale = 2.0
iscale = 1/scale;
sz1,sp1,origin = image.GetSize(),image.GetSpacing(), image.GetOrigin()
direction = image.GetDirection()
sz2,sp2 = [int(n/scale) for n in sz1],[n*scale for n in sp1]
print "Orig Size ", sz1, "\nNew Size ", sz2
print "Orig Sp ", sp1, "\nNew Sp ", sp2
print origin
t = sitk.Transform(3, sitk.sitkScale)
t.SetParameters((scale, scale, scale))
simage =
sitk.Resample(image,sz2,t,sitk.sitkLinear,origin,sp2,direction,0.0,sitk.sitkFloat32)
print "New Image size:", simage.GetSize()
mmap = sitk.Statistics(simage)
for n in mmap.items():
    print n
print "\n",sitk.Version()

Output:
Orig Size  (170, 170, 130) 
New Size  [85, 85, 65]
Orig Sp  (0.03867189958691597, 0.03867189958691597, 0.0625) 
New Sp  [0.07734379917383194, 0.07734379917383194, 0.125]
(-13.1871, 6.57422, -16.3125)
New Image size: (85, 85, 65)
('Maximum', 0.0)
('Mean', 0.0)
('Minimum', 0.0)
('Sigma', 0.0)
('Sum', 0.0)
('Variance', 0.0)

SimpleITK Version: 0.8.0
Compiled: Mar 14 2014 02:43:02



Am I missing a step here?

-Jameson




--
View this message in context: http://itk-users.7.n7.nabble.com/SimpleITK-Downsampling-results-in-blank-image-tp34923.html
Sent from the ITK - Users mailing list archive at Nabble.com.

From jmerkow at gmail.com  Mon Nov 17 18:21:41 2014
From: jmerkow at gmail.com (jmerkow)
Date: Mon, 17 Nov 2014 16:21:41 -0700 (MST)
Subject: [ITK-users] SimpleITK Downsampling results in blank image
In-Reply-To: <1416266410055-34923.post@n7.nabble.com>
References: <1416266410055-34923.post@n7.nabble.com>
Message-ID: <1416266501929-34924.post@n7.nabble.com>

It looks like this may be related to another post on Nov 5?

http://itk-users.7.n7.nabble.com/Simple-Resampling-delivers-empty-image-td34867.html


-Jameson



--
View this message in context: http://itk-users.7.n7.nabble.com/SimpleITK-Downsampling-results-in-blank-image-tp34923p34924.html
Sent from the ITK - Users mailing list archive at Nabble.com.

From zeinsalah at gmail.com  Tue Nov 18 06:33:28 2014
From: zeinsalah at gmail.com (Zein Salah)
Date: Tue, 18 Nov 2014 12:33:28 +0100
Subject: [ITK-users] 2D/3D registration
Message-ID: <CADiSopMwr0trK7x_v05BWw7LeA8iJ7jWNBhZFw+_BaY5U1gJmA@mail.gmail.com>

Hello,

I need to register x-ray images with CT data. Does ITK actually provide
2D/3D registration mechanism?

Much thanks,
Zei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141118/bfb679aa/attachment.html>

From blowekamp at mail.nih.gov  Tue Nov 18 08:39:26 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 18 Nov 2014 08:39:26 -0500
Subject: [ITK-users] SimpleITK Downsampling results in blank image
In-Reply-To: <1416266410055-34923.post@n7.nabble.com>
References: <1416266410055-34923.post@n7.nabble.com>
Message-ID: <0789AC1A-931B-450C-A323-434318BB9253@mail.nih.gov>

I have a couple comments on you example below, but over all it looks OK.

On Nov 17, 2014, at 6:20 PM, jmerkow <jmerkow at gmail.com> wrote:

> I have a strange issue when using the Resample procedural interface in
> SimpleITK.
> I have tried all the call signatures, but I can't seem to get meaningful
> output.
> I wrote a small illustrative example, where I read an image, attempt to
> downsample by 2, and get nothing out.  This is written in python, using
> SimpleITK 0.8.0.
> 
> Code:
> 
> import SimpleITK as sitk
> image = sitk.ReadImage('/path/to/img/cabg11-1.mha')
> image = sitk.Cast(sitk.RescaleIntensity(image), sitk.sitkFloat32)

You likely should convert to float before rescaling, and it would be best to explicitly specify the min and max. This will help preserve maximum fidelity of the intensity.

> scale = 2.0
> iscale = 1/scale;
> sz1,sp1,origin = image.GetSize(),image.GetSpacing(), image.GetOrigin()
> direction = image.GetDirection()
> sz2,sp2 = [int(n/scale) for n in sz1],[n*scale for n in sp1]
> print "Orig Size ", sz1, "\nNew Size ", sz2
> print "Orig Sp ", sp1, "\nNew Sp ", sp2
> print origin

BUG: you should also scale the origin.

> t = sitk.Transform(3, sitk.sitkScale)
> t.SetParameters((scale, scale, scale))
> simage =
> sitk.Resample(image,sz2,t,sitk.sitkLinear,origin,sp2,direction,0.0,sitk.sitkFloat32)

Python keyword arguments unfortunetly don't work with the overloaded Resample methods. I'd recommend using the object oriented interface here something like:

resampler = sitk.ResampleImageFilter()
resampler.SetDefaultPixelValue(0)
resampler.SetOutputSize(sz1)
resampler.SetTransform(t)
...
resampler.DebugOn()
resampler.Execute(image)

Turning Debug on will print the ITK filter before execution which may be helpful for debugging.

> print "New Image size:", simage.GetSize()
> mmap = sitk.Statistics(simage)
> for n in mmap.items():
>    print n
> print "\n",sitk.Version()
> 
> Output:
> Orig Size  (170, 170, 130) 
> New Size  [85, 85, 65]
> Orig Sp  (0.03867189958691597, 0.03867189958691597, 0.0625) 
> New Sp  [0.07734379917383194, 0.07734379917383194, 0.125]
> (-13.1871, 6.57422, -16.3125)
> New Image size: (85, 85, 65)
> ('Maximum', 0.0)
> ('Mean', 0.0)
> ('Minimum', 0.0)
> ('Sigma', 0.0)
> ('Sum', 0.0)
> ('Variance', 0.0)
> 
> SimpleITK Version: 0.8.0
> Compiled: Mar 14 2014 02:43:02
> 
> 
> 
> Am I missing a step here?

First try getting it to work with an scale = 1 so it will be an identity transform. Then increase it by just a little to see how the output image is effected. I hope it was just the origin not being correctly computed was the issue.

Brad

> 
> -Jameson
> 
> 
> 
> 
> --
> View this message in context: http://itk-users.7.n7.nabble.com/SimpleITK-Downsampling-results-in-blank-image-tp34923.html
> Sent from the ITK - Users mailing list archive at Nabble.com.
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users


From blowekamp at mail.nih.gov  Tue Nov 18 09:13:57 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 18 Nov 2014 09:13:57 -0500
Subject: [ITK-users] 2D/3D registration
In-Reply-To: <CADiSopMwr0trK7x_v05BWw7LeA8iJ7jWNBhZFw+_BaY5U1gJmA@mail.gmail.com>
References: <CADiSopMwr0trK7x_v05BWw7LeA8iJ7jWNBhZFw+_BaY5U1gJmA@mail.gmail.com>
Message-ID: <AAC9493B-7A10-465B-B4FD-27379F76BAFF@mail.nih.gov>

Hello,

I don't know anything first hand and don't see any handy ITK examples for this. I hope some one with more experience with the issue will chime in. I did find these interesting links via a quick google:

http://www.insight-journal.org/browse/publication/800
https://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html
http://www.itk.org/pipermail/insight-users/2010-November/038801.html

Hope that helps,
Brad

On Nov 18, 2014, at 6:33 AM, Zein Salah <zeinsalah at gmail.com> wrote:

> Hello,
> 
> I need to register x-ray images with CT data. Does ITK actually provide 2D/3D registration mechanism?
> 
> Much thanks,
> Zei
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users


From millerjv at gmail.com  Tue Nov 18 09:43:36 2014
From: millerjv at gmail.com (Jim Miller)
Date: Tue, 18 Nov 2014 09:43:36 -0500
Subject: [ITK-users] 2D/3D registration
In-Reply-To: <AAC9493B-7A10-465B-B4FD-27379F76BAFF@mail.nih.gov>
References: <CADiSopMwr0trK7x_v05BWw7LeA8iJ7jWNBhZFw+_BaY5U1gJmA@mail.gmail.com>
 <AAC9493B-7A10-465B-B4FD-27379F76BAFF@mail.nih.gov>
Message-ID: <8F680DDF-47E4-4707-AA58-F30B2A6360DD@gmail.com>

There a special interpolator we use for 3D to 2D registration - RayCastInterpolateImageFunction. This can be used in the registration framework. 

Jim

> On Nov 18, 2014, at 9:13 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
> Hello,
> 
> I don't know anything first hand and don't see any handy ITK examples for this. I hope some one with more experience with the issue will chime in. I did find these interesting links via a quick google:
> 
> http://www.insight-journal.org/browse/publication/800
> https://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html
> http://www.itk.org/pipermail/insight-users/2010-November/038801.html
> 
> Hope that helps,
> Brad
> 
>> On Nov 18, 2014, at 6:33 AM, Zein Salah <zeinsalah at gmail.com> wrote:
>> 
>> Hello,
>> 
>> I need to register x-ray images with CT data. Does ITK actually provide 2D/3D registration mechanism?
>> 
>> Much thanks,
>> Zei
>> _____________________________________
>> 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.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-users
> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

From blowekamp at mail.nih.gov  Tue Nov 18 10:47:26 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 18 Nov 2014 10:47:26 -0500
Subject: [ITK-users] 2D/3D registration
In-Reply-To: <8F680DDF-47E4-4707-AA58-F30B2A6360DD@gmail.com>
References: <CADiSopMwr0trK7x_v05BWw7LeA8iJ7jWNBhZFw+_BaY5U1gJmA@mail.gmail.com>
 <AAC9493B-7A10-465B-B4FD-27379F76BAFF@mail.nih.gov>
 <8F680DDF-47E4-4707-AA58-F30B2A6360DD@gmail.com>
Message-ID: <01DE37C4-44C8-42A8-9037-3D0B766902E7@mail.nih.gov>

Jim,

I have heard that the ray cast interpolator can be used this way too, but I don't know of any examples or tests that do anything like that. I hope that it still works with the older registration framework. Who know if it works with the ITKV4 registration framework.

Adding this as an example or test would be an excellent contribution.

Brad

On Nov 18, 2014, at 9:43 AM, Jim Miller <millerjv at gmail.com> wrote:

> There a special interpolator we use for 3D to 2D registration - RayCastInterpolateImageFunction. This can be used in the registration framework. 
> 
> Jim
> 
>> On Nov 18, 2014, at 9:13 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>> 
>> Hello,
>> 
>> I don't know anything first hand and don't see any handy ITK examples for this. I hope some one with more experience with the issue will chime in. I did find these interesting links via a quick google:
>> 
>> http://www.insight-journal.org/browse/publication/800
>> https://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html
>> http://www.itk.org/pipermail/insight-users/2010-November/038801.html
>> 
>> Hope that helps,
>> Brad
>> 
>>> On Nov 18, 2014, at 6:33 AM, Zein Salah <zeinsalah at gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>> I need to register x-ray images with CT data. Does ITK actually provide 2D/3D registration mechanism?
>>> 
>>> Much thanks,
>>> Zei
>>> _____________________________________
>>> 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.php
>>> 
>>> 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://public.kitware.com/mailman/listinfo/insight-users
>> 
>> _____________________________________
>> 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.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-users


From jmerkow at gmail.com  Tue Nov 18 14:52:05 2014
From: jmerkow at gmail.com (Jameson Merkow)
Date: Tue, 18 Nov 2014 11:52:05 -0800
Subject: [ITK-users] SimpleITK Downsampling results in blank image
In-Reply-To: <0789AC1A-931B-450C-A323-434318BB9253@mail.nih.gov>
References: <1416266410055-34923.post@n7.nabble.com>
 <0789AC1A-931B-450C-A323-434318BB9253@mail.nih.gov>
Message-ID: <CAHWMK+i9vFv=BCmUcBJpmyXRaQ6oCML+nK8Koowv2WzG3dDdmQ@mail.gmail.com>

>
>
> BUG: you should also scale the origin.
>

I guess this is whats confusing. The origin should be the same (or very
close due to spacing changes).  I am resampling and updating the spacing to
be the inverse of the scale. The new image should have the same physical
dimensions, but sampled at a different scale (fewer or greater number of
voxels).

Its possible that I am using ResampleImageFilter wrong. Think the
ShrinkImageFilter or ExpandImageFilter with non-integer values.
If I do the equivalent operation with Shrink/Expand, the origin, spacing
and size end up the same as what I calculate for the resample image filter,
but the image comes out blank.


-Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141118/2c176917/attachment.html>

From blowekamp at mail.nih.gov  Tue Nov 18 16:42:41 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 18 Nov 2014 16:42:41 -0500
Subject: [ITK-users] SimpleITK Downsampling results in blank image
In-Reply-To: <CAHWMK+i9vFv=BCmUcBJpmyXRaQ6oCML+nK8Koowv2WzG3dDdmQ@mail.gmail.com>
References: <1416266410055-34923.post@n7.nabble.com>
 <0789AC1A-931B-450C-A323-434318BB9253@mail.nih.gov>
 <CAHWMK+i9vFv=BCmUcBJpmyXRaQ6oCML+nK8Koowv2WzG3dDdmQ@mail.gmail.com>
Message-ID: <37035E93-B7C0-45B9-A231-94281E935335@mail.nih.gov>

Hello again,

On Nov 18, 2014, at 2:52 PM, Jameson Merkow <jmerkow at gmail.com> wrote:

> 
> BUG: you should also scale the origin.
> 
> I guess this is whats confusing. The origin should be the same (or very close due to spacing changes).  I am resampling and updating the spacing to be the inverse of the scale. The new image should have the same physical dimensions, but sampled at a different scale (fewer or greater number of voxels).

No, they are different. When you are doing resampling  you are applying a transform mapping the input image's physical space to the output image's by the transform. In your case it's a scale. So if you have applying a scale of 0.1, and you origin was [100,100], it would be transform to [10,10].

> 
> Its possible that I am using ResampleImageFilter wrong. Think the ShrinkImageFilter or ExpandImageFilter with non-integer values.
> If I do the equivalent operation with Shrink/Expand, the origin, spacing and size end up the same as what I calculate for the resample image filter, but the image comes out blank.

These filters are a little different they are not applying a transform of the physical space. The input image an output image occupy approximately the same physical space, just the resolution has changed.

If you want to do a similar thing with the resample image filter you set the transform to the identity transform, then change change the Size. If you use the ResampleImageFilter as a class you may find the SetReferenceImage useful [1].

Brad

[1] http://www.itk.org/SimpleITKDoxygen/html/classitk_1_1simple_1_1ResampleImageFilter.html#a850affc7fc3ce420c04f754d5d7773a5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141118/42b34a18/attachment.html>

From emily-hammond at uiowa.edu  Wed Nov 19 11:56:00 2014
From: emily-hammond at uiowa.edu (Hammond, Emily M)
Date: Wed, 19 Nov 2014 16:56:00 +0000
Subject: [ITK-users] minimize skewing
Message-ID: <2609C492EC89AB4CAAD3647B8D1A43CC2F14FEDC@ITSNT437.iowa.uiowa.edu>

Hello all,

I am looking perform registration allowing for translation, rotation and anisotropic scaling. Is there a way to use the affine transform but limit the skewing performed? Or is there an alternative method to do this.

Thanks!
Emily Hammond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141119/a7714ba1/attachment.html>

From blowekamp at mail.nih.gov  Wed Nov 19 13:52:35 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 19 Nov 2014 13:52:35 -0500
Subject: [ITK-users] minimize skewing
In-Reply-To: <2609C492EC89AB4CAAD3647B8D1A43CC2F14FEDC@ITSNT437.iowa.uiowa.edu>
References: <2609C492EC89AB4CAAD3647B8D1A43CC2F14FEDC@ITSNT437.iowa.uiowa.edu>
Message-ID: <6A33BD14-4CC4-4565-A2FB-BBA7BB371646@mail.nih.gov>

Hello,

For 3D you might want to look into the ScaleVersor3DTransform or the ScaleSkewVersor3DTransform. These may parameterize the transform as you wish.

Brad

On Nov 19, 2014, at 11:56 AM, Hammond, Emily M <emily-hammond at uiowa.edu> wrote:

> Hello all,
> 
> I am looking perform registration allowing for translation, rotation and anisotropic scaling. Is there a way to use the affine transform but limit the skewing performed? Or is there an alternative method to do this.
> 
> Thanks!
> Emily Hammond
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141119/a4058dff/attachment.html>

From pwang_xjtu at hotmail.com  Wed Nov 19 16:44:47 2014
From: pwang_xjtu at hotmail.com (WangPing)
Date: Thu, 20 Nov 2014 05:44:47 +0800
Subject: [ITK-users] read imageJ ROI to matlab
Message-ID: <BAY176-W24A76777EAD4FC946558C1EC890@phx.gbl>

Dear list,
 
I am sorry I am not sure if I could ask a different question:
does anyone know how to read an ROI from ImageJ to matlab?  Or how to save the ImageJ ROI to a file (such as nifti format)?
 
Best Regards,
ping
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141120/4b0f8fa2/attachment.html>

From g.lemaitre58 at gmail.com  Wed Nov 19 17:05:42 2014
From: g.lemaitre58 at gmail.com (=?UTF-8?Q?Guillaume_Lema=C3=AEtre?=)
Date: Wed, 19 Nov 2014 23:05:42 +0100
Subject: [ITK-users] read imageJ ROI to matlab
In-Reply-To: <BAY176-W24A76777EAD4FC946558C1EC890@phx.gbl>
References: <BAY176-W24A76777EAD4FC946558C1EC890@phx.gbl>
Message-ID: <CACDxx9i-C35Q3k69AjiF8HkQDUs2ChH+5Ap3jkLcEiQ1H_36Vw@mail.gmail.com>

Hi,

Check this contribution:
http://www.mathworks.com/matlabcentral/fileexchange/32479-load---import-imagej-roi-files

Cheers,

On 19 November 2014 22:44, WangPing <pwang_xjtu at hotmail.com> wrote:

> Dear list,
>
> I am sorry I am not sure if I could ask a different question:
> does anyone know how to read an ROI from ImageJ to matlab?  Or how to save
> the ImageJ ROI to a file (such as nifti format)?
>
> Best Regards,
> ping
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>
>


-- 




*LEMA?TRE GuillaumePhD CandiateMSc Erasmus Mundus ViBOT (Vision-roBOTic)MSc
Business Innovation and Technology Management*
g.lemaitre58 at gmail.com

*ViCOROB - Computer Vision and Robotic Team*
Universitat de Girona, Campus Montilivi, Edifici P-IV 17071 Girona
Tel. +34 972 41 98 12 - Fax. +34 972 41 82 59
http://vicorob.udg.es/

*LE2I - Le Creusot*IUT Le Creusot, Laboratoire LE2I, 12 rue de la Fonderie,
71200 Le Creusot
Tel. +33 3 85 73 10 90 - Fax. +33 3 85 73 10 97
http://le2i.cnrs.fr

https://sites.google.com/site/glemaitre58/
Vice - Chairman of A.S.C. Fours UFOLEP
Chairman of A.S.C. Fours FFC
Webmaster of http://ascfours.free.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141119/2c7b0821/attachment.html>

From j.plumat at auckland.ac.nz  Wed Nov 19 23:01:14 2014
From: j.plumat at auckland.ac.nz (Jerome Plumat)
Date: Thu, 20 Nov 2014 17:01:14 +1300
Subject: [ITK-users] read imageJ ROI to matlab
In-Reply-To: <BAY176-W24A76777EAD4FC946558C1EC890@phx.gbl>
References: <BAY176-W24A76777EAD4FC946558C1EC890@phx.gbl>
Message-ID: <546D678A.2060408@auckland.ac.nz>

An other solution would be to use 3D-Slicer. You can export ROIs as VTK 
mesh or binary mask with a large list of formats (Tif, mha, ... ).

Jerome Plumat
-------
School of Medical Sciences
University of Auckland

If I am not for myself, who will be for me? And if I am only for myself, then what an I? And if not now when? ? Hillel HaZaken

On 20/11/14 10:44, WangPing wrote:
> Dear list,
>
> I am sorry I am not sure if I could ask a different question:
> does anyone know how to read an ROI from ImageJ to matlab?  Or how to 
> save the ImageJ ROI to a file (such as nifti format)?
>
> Best Regards,
> ping
>
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141120/277ba2dc/attachment.html>

From kondo at den.t.u-tokyo.ac.jp  Thu Nov 20 09:50:06 2014
From: kondo at den.t.u-tokyo.ac.jp (suguru KONDO)
Date: Thu, 20 Nov 2014 23:50:06 +0900
Subject: [ITK-users] How to implement VersorRigid3DTransform ?
Message-ID: <1416495006824541.525624613@ums001.ecc.u-tokyo.ac.jp>

Hello everyone.

I have a couple of questions about VersorRigid3DTransform.
I will sequentially consider registration process using VersorRigid3DTransform. 
If, my concept is wrong, please point it.

1.Transform moving image to fixed image

I think the formulation of VersorRigid3DTransform is below
and then all input points in moving image are transformed by this formulation.

[x']   [q1^2 - q2^2 - q3^2 + q4^2, 2(q1q2 - q3q4), 2(q1q3 + q2q4)]  [x - xc]   [tx]
[y'] = [2(q1q2 + q3q4), -q1^2 + q2^2 - q3^2 + q4^2, 2(q2q3 - q1q4)] [y - yc] + [ty]
[z']   [2(q1q3 - q2q4), 2(q2q3 + q1q4), -q1^2 - q2^2 + q3^2 + q4^2] [z - zc]   [tz]

P' = R * (P - C) + T

Versor : Q = q1 * i + q2 * j + q3 * k + q4 (q1^2 + q2^2 + q3^2 + q4^2 = 1)
Input point : P = (x, y, z)
Output point : P' = (x', y', z')
Center of rotation : C = (xc, yc, zc)
Translation vector : T = (tx, ty, tz) 
Rotation matrix : R 
Optimization parameter : {q1, q2, q3, tx, ty, tz}

2.Compute metric (cost function) and its derivative
For simplicity, I assumed that interpolation completed and metric is mean squares metric.  

In this case, I think metric is formulated by this formula.

MS(f(X), Tm(X)) = 1/N * ?(i=1...N)(f(X)_i  - Tm(X)_i )^2

All points in fixed image region : X
Metric : MS(f(X), Tm(X))
Fixed image : f(X)
Transformed moving image : Tm(X)
the i-th pixel of Image f(X) : f(X)_i 
the i-th pixel of Image Tm(X) : Tm(X)_i
the number of pixels considered : N = the number of pixels in fixed image (when calculation region is GetLargestPossibleRegion())

I think Tm(X)_i is represented by using optimization parameters {q1, q2, q3, tx, ty, tz}.
So, I think its jacobian matrix can be represented like this.

    [?Tm(X)_1/?q1, ?Tm(X)_1/?q2, ?Tm(X)_1/?q3, ?Tm(X)_1/?tx, ?Tm(X)_1/?ty, ?Tm(X)_1/?tz]
    [?Tm(X)_2/?q1, ?Tm(X)_2/?q2, ?Tm(X)_2/?q3, ?Tm(X)_2/?tx, ?Tm(X)_2/?ty, ?Tm(X)_2/?tz]
    [        .               .               .               .               .               .     ]
 J =[        .               .               .               .               .               .     ]
    [        .               .               .               .               .               .     ]
    [?Tm(X)_N/?q1, ?Tm(X)_N/?q2, ?Tm(X)_N/?q3, ?Tm(X)_N/?tx, ?Tm(X)_N/?ty, ?Tm(X)_N/?tz]

Here, I have a couple of questions.

q1, q2, q3 are versor components in versor space but I deal them same as tx, ty, tz.
Is my operation correct?   

Then, if this jacobian matrix is correct, we need to compute metric derivative by using this
because we need to decide search direction in optimization parameter space. 
But, I don't know how to compute metric derivative using jacobian matrix.
So, is there any publication outlining the exact calculations leading 
to the metric derivative implemented in the VersorRigid3DTransform?

I hope that somebody finds the time to answer.

Thanks

Suguru Kondo

From franciscolopezdelafranca at gmail.com  Sat Nov 22 02:51:56 2014
From: franciscolopezdelafranca at gmail.com (Francisco Lopez de la Franca)
Date: Sat, 22 Nov 2014 08:51:56 +0100
Subject: [ITK-users] Texture features/descriptors for 3D objects
Message-ID: <CAJqi3EJSeWqa_-VrE2VugUPUg8Z=L5nwK6GKTYaW4YVdqfOuJA@mail.gmail.com>

Hi,

Recently, I have been reading some documentation talking on the texture
features extraction subject. I am very interested on it, and I would like
to do some tests.

Does anyone know any framework, tool or library (ITK, VTK or Matlab)
providing with a class of function to extract the textures features or
descriptors for a tridimensional object?

In that documents, the authors talk about the co-occurrence matrices. If
anyone has some experience on this, I would appreciate a lot if it is
shared.

Thank you very much in advance.
Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141122/6c02d3c0/attachment.html>

From matimontg at gmail.com  Sat Nov 22 07:31:09 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Sat, 22 Nov 2014 09:31:09 -0300
Subject: [ITK-users] Encapsulate a ITK function into a DLL to be used with C#
Message-ID: <CAKKNfuKQo+m4KYiB_eC80yxx7p4H-9HpZKh5A27HOHTJBftpEg@mail.gmail.com>

Hi,

I have the following code that I would like to use in C#. Since it is ITK,
it's coded in C++ so I was wondering if I could create a DLL that can be
used in C# and then call the function as it was a class, pass parameters
and use the method?

All I need is to pass 3 parameters to the function (which is a function to
rotate images)

here's the code:

#include "itkImage.h"
#include "itkImageFileReader.h"
#include "itkImageFileWriter.h"
#include "itkResampleImageFilter.h"
#include "itkAffineTransform.h"
#include "itkGDCMImageIO.h"

int main( int argc, char * argv[] )
{
if( argc < 4 )
{
std::cerr << "Usage: " << std::endl;
std::cerr << argv[0] << " inputImageFile outputImageFile degrees" <<
std::endl;
return EXIT_FAILURE;
}

const unsigned int Dimension = 2; //imagen 2D
typedef signed short InputPixelType;
typedef signed short OutputPixelType;
typedef itk::Image< InputPixelType, Dimension > InputImageType;
typedef itk::Image< OutputPixelType, Dimension > OutputImageType;
typedef itk::ImageFileReader< InputImageType > ReaderType;
typedef itk::ImageFileWriter< OutputImageType > WriterType;
ReaderType::Pointer reader = ReaderType::New(); //lo que lee
WriterType::Pointer writer = WriterType::New(); //lo que escribe
reader->SetFileName( argv[1] ); //primer argumento
writer->SetFileName( argv[2] ); //segundo argumento

typedef itk::GDCMImageIO ImageIOType;
ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
reader->SetImageIO( gdcmImageIO );


const double angleInDegrees = atof( argv[3] ); //angulo de rotaci?n

typedef itk::ResampleImageFilter<InputImageType, OutputImageType >
FilterType; //Filtro
FilterType::Pointer filter = FilterType::New();

typedef itk::AffineTransform< double, Dimension > TransformType; //usado
para mapear el espacio de entrada con el espacio de salida
TransformType::Pointer transform = TransformType::New();

typedef itk::LinearInterpolateImageFunction<InputImageType, double >
InterpolatorType;
InterpolatorType::Pointer interpolator = InterpolatorType::New();
filter->SetInterpolator( interpolator );
filter->SetDefaultPixelValue(0); //Pixel por defecto de lo que queda fuera
de la imagen cuando se rota

reader->Update();

const InputImageType * inputImage = reader->GetOutput();
const InputImageType::SpacingType & spacing = inputImage->GetSpacing();
const InputImageType::PointType & origin = inputImage->GetOrigin();
InputImageType::SizeType size =
inputImage->GetLargestPossibleRegion().GetSize();
filter->SetOutputOrigin( origin );
filter->SetOutputSpacing( spacing );
filter->SetOutputDirection( inputImage->GetDirection() );
filter->SetSize( size );

filter->SetInput( reader->GetOutput() );
writer->SetInput( filter->GetOutput() );
writer->UseInputMetaDataDictionaryOff();
writer->SetImageIO(gdcmImageIO);
 TransformType::OutputVectorType translation1;
const double imageCenterX = origin[0] + spacing[0] * size[0] / 2.0;
const double imageCenterY = origin[1] + spacing[1] * size[1] / 2.0;
translation1[0] = -imageCenterX;
translation1[1] = -imageCenterY;
transform->Translate( translation1 );
// Software Guide : EndCodeSnippet
std::cout << "imageCenterX = " << imageCenterX << std::endl;
std::cout << "imageCenterY = " << imageCenterY << std::endl;

const double degreesToRadians = std::atan(1.0) / 45.0;
const double angle = angleInDegrees * degreesToRadians;
transform->Rotate2D( -angle, false );

TransformType::OutputVectorType translation2;
translation2[0] = imageCenterX;
translation2[1] = imageCenterY;
transform->Translate( translation2, false );
filter->SetTransform( transform );

try
{
writer->Update();
}
catch( itk::ExceptionObject & excep )
{
std::cerr << "Exception caught !" << std::endl;
std::cerr << excep << std::endl;
}
// Software Guide : EndCodeSnippet
return EXIT_SUCCESS;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141122/a33c7c86/attachment.html>

From brad at lowekamp.net  Sat Nov 22 12:06:09 2014
From: brad at lowekamp.net (Bradley Lowekamp)
Date: Sat, 22 Nov 2014 12:06:09 -0500
Subject: [ITK-users] Encapsulate a ITK function into a DLL to be used
	with C#
In-Reply-To: <CAKKNfuKQo+m4KYiB_eC80yxx7p4H-9HpZKh5A27HOHTJBftpEg@mail.gmail.com>
References: <CAKKNfuKQo+m4KYiB_eC80yxx7p4H-9HpZKh5A27HOHTJBftpEg@mail.gmail.com>
Message-ID: <BFEF1C2C-0CB0-42B5-9901-A38526AC5291@mail.nih.gov>

Hello

Have you looked into SimpleITK's C Sharp bindings?


> On Nov 22, 2014, at 7:31 AM, Matias Montroull <matimontg at gmail.com> wrote:
> 
> Hi,
> 
> I have the following code that I would like to use in C#. Since it is ITK, it's coded in C++ so I was wondering if I could create a DLL that can be used in C# and then call the function as it was a class, pass parameters and use the method?
> 
> All I need is to pass 3 parameters to the function (which is a function to rotate images)
> 
> here's the code:
> 
> #include "itkImage.h"
> #include "itkImageFileReader.h"
> #include "itkImageFileWriter.h"
> #include "itkResampleImageFilter.h"
> #include "itkAffineTransform.h"
> #include "itkGDCMImageIO.h"
> 
> int main( int argc, char * argv[] )
> {
> if( argc < 4 )
> {
> std::cerr << "Usage: " << std::endl;
> std::cerr << argv[0] << " inputImageFile outputImageFile degrees" << std::endl;
> return EXIT_FAILURE;
> }
> 
> const unsigned int Dimension = 2; //imagen 2D
> typedef signed short InputPixelType;
> typedef signed short OutputPixelType;
> typedef itk::Image< InputPixelType, Dimension > InputImageType;
> typedef itk::Image< OutputPixelType, Dimension > OutputImageType;
> typedef itk::ImageFileReader< InputImageType > ReaderType;
> typedef itk::ImageFileWriter< OutputImageType > WriterType;
> ReaderType::Pointer reader = ReaderType::New(); //lo que lee
> WriterType::Pointer writer = WriterType::New(); //lo que escribe
> reader->SetFileName( argv[1] ); //primer argumento
> writer->SetFileName( argv[2] ); //segundo argumento
> 
> typedef itk::GDCMImageIO ImageIOType;
> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
> reader->SetImageIO( gdcmImageIO );
> 
> 
> const double angleInDegrees = atof( argv[3] ); //angulo de rotaci?n
> 
> typedef itk::ResampleImageFilter<InputImageType, OutputImageType > FilterType; //Filtro
> FilterType::Pointer filter = FilterType::New();
> 
> typedef itk::AffineTransform< double, Dimension > TransformType; //usado para mapear el espacio de entrada con el espacio de salida
> TransformType::Pointer transform = TransformType::New();
> 
> typedef itk::LinearInterpolateImageFunction<InputImageType, double > InterpolatorType;
> InterpolatorType::Pointer interpolator = InterpolatorType::New();
> filter->SetInterpolator( interpolator );
> filter->SetDefaultPixelValue(0); //Pixel por defecto de lo que queda fuera de la imagen cuando se rota
> 
> reader->Update();
> 
> const InputImageType * inputImage = reader->GetOutput();
> const InputImageType::SpacingType & spacing = inputImage->GetSpacing();
> const InputImageType::PointType & origin = inputImage->GetOrigin();
> InputImageType::SizeType size =
> inputImage->GetLargestPossibleRegion().GetSize();
> filter->SetOutputOrigin( origin );
> filter->SetOutputSpacing( spacing );
> filter->SetOutputDirection( inputImage->GetDirection() );
> filter->SetSize( size );
> 
> filter->SetInput( reader->GetOutput() );
> writer->SetInput( filter->GetOutput() );
> writer->UseInputMetaDataDictionaryOff();
> writer->SetImageIO(gdcmImageIO);
>  TransformType::OutputVectorType translation1;
> const double imageCenterX = origin[0] + spacing[0] * size[0] / 2.0;
> const double imageCenterY = origin[1] + spacing[1] * size[1] / 2.0;
> translation1[0] = -imageCenterX;
> translation1[1] = -imageCenterY;
> transform->Translate( translation1 );
> // Software Guide : EndCodeSnippet
> std::cout << "imageCenterX = " << imageCenterX << std::endl;
> std::cout << "imageCenterY = " << imageCenterY << std::endl;
> 
> const double degreesToRadians = std::atan(1.0) / 45.0;
> const double angle = angleInDegrees * degreesToRadians;
> transform->Rotate2D( -angle, false );
> 
> TransformType::OutputVectorType translation2;
> translation2[0] = imageCenterX;
> translation2[1] = imageCenterY;
> transform->Translate( translation2, false );
> filter->SetTransform( transform );
> 
> try
> {
> writer->Update();
> }
> catch( itk::ExceptionObject & excep )
> {
> std::cerr << "Exception caught !" << std::endl;
> std::cerr << excep << std::endl;
> }
> // Software Guide : EndCodeSnippet
> return EXIT_SUCCESS;
> }
> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

From matt.mccormick at kitware.com  Sat Nov 22 12:25:34 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Sat, 22 Nov 2014 12:25:34 -0500
Subject: [ITK-users] Encapsulate a ITK function into a DLL to be used
	with C#
In-Reply-To: <CAKKNfuKQo+m4KYiB_eC80yxx7p4H-9HpZKh5A27HOHTJBftpEg@mail.gmail.com>
References: <CAKKNfuKQo+m4KYiB_eC80yxx7p4H-9HpZKh5A27HOHTJBftpEg@mail.gmail.com>
Message-ID: <CALzTN-TAUK0_Vp7VjmgC2k3wmP7swmPb2SJsy_euCtaRba1efw@mail.gmail.com>

Hi Matias,

C# has a feature call C++/CLI that can be used to call C++ code from C# [1]

HTH,
Matt

[1] http://www.codeproject.com/Articles/19354/Quick-C-CLI-Learn-C-CLI-in-less-than-minutes

On Sat, Nov 22, 2014 at 7:31 AM, Matias Montroull <matimontg at gmail.com> wrote:
> Hi,
>
> I have the following code that I would like to use in C#. Since it is ITK,
> it's coded in C++ so I was wondering if I could create a DLL that can be
> used in C# and then call the function as it was a class, pass parameters and
> use the method?
>
> All I need is to pass 3 parameters to the function (which is a function to
> rotate images)
>
> here's the code:
>
> #include "itkImage.h"
> #include "itkImageFileReader.h"
> #include "itkImageFileWriter.h"
> #include "itkResampleImageFilter.h"
> #include "itkAffineTransform.h"
> #include "itkGDCMImageIO.h"
>
> int main( int argc, char * argv[] )
> {
> if( argc < 4 )
> {
> std::cerr << "Usage: " << std::endl;
> std::cerr << argv[0] << " inputImageFile outputImageFile degrees" <<
> std::endl;
> return EXIT_FAILURE;
> }
>
> const unsigned int Dimension = 2; //imagen 2D
> typedef signed short InputPixelType;
> typedef signed short OutputPixelType;
> typedef itk::Image< InputPixelType, Dimension > InputImageType;
> typedef itk::Image< OutputPixelType, Dimension > OutputImageType;
> typedef itk::ImageFileReader< InputImageType > ReaderType;
> typedef itk::ImageFileWriter< OutputImageType > WriterType;
> ReaderType::Pointer reader = ReaderType::New(); //lo que lee
> WriterType::Pointer writer = WriterType::New(); //lo que escribe
> reader->SetFileName( argv[1] ); //primer argumento
> writer->SetFileName( argv[2] ); //segundo argumento
>
> typedef itk::GDCMImageIO ImageIOType;
> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
> reader->SetImageIO( gdcmImageIO );
>
>
> const double angleInDegrees = atof( argv[3] ); //angulo de rotaci?n
>
> typedef itk::ResampleImageFilter<InputImageType, OutputImageType >
> FilterType; //Filtro
> FilterType::Pointer filter = FilterType::New();
>
> typedef itk::AffineTransform< double, Dimension > TransformType; //usado
> para mapear el espacio de entrada con el espacio de salida
> TransformType::Pointer transform = TransformType::New();
>
> typedef itk::LinearInterpolateImageFunction<InputImageType, double >
> InterpolatorType;
> InterpolatorType::Pointer interpolator = InterpolatorType::New();
> filter->SetInterpolator( interpolator );
> filter->SetDefaultPixelValue(0); //Pixel por defecto de lo que queda fuera
> de la imagen cuando se rota
>
> reader->Update();
>
> const InputImageType * inputImage = reader->GetOutput();
> const InputImageType::SpacingType & spacing = inputImage->GetSpacing();
> const InputImageType::PointType & origin = inputImage->GetOrigin();
> InputImageType::SizeType size =
> inputImage->GetLargestPossibleRegion().GetSize();
> filter->SetOutputOrigin( origin );
> filter->SetOutputSpacing( spacing );
> filter->SetOutputDirection( inputImage->GetDirection() );
> filter->SetSize( size );
>
> filter->SetInput( reader->GetOutput() );
> writer->SetInput( filter->GetOutput() );
> writer->UseInputMetaDataDictionaryOff();
> writer->SetImageIO(gdcmImageIO);
>  TransformType::OutputVectorType translation1;
> const double imageCenterX = origin[0] + spacing[0] * size[0] / 2.0;
> const double imageCenterY = origin[1] + spacing[1] * size[1] / 2.0;
> translation1[0] = -imageCenterX;
> translation1[1] = -imageCenterY;
> transform->Translate( translation1 );
> // Software Guide : EndCodeSnippet
> std::cout << "imageCenterX = " << imageCenterX << std::endl;
> std::cout << "imageCenterY = " << imageCenterY << std::endl;
>
> const double degreesToRadians = std::atan(1.0) / 45.0;
> const double angle = angleInDegrees * degreesToRadians;
> transform->Rotate2D( -angle, false );
>
> TransformType::OutputVectorType translation2;
> translation2[0] = imageCenterX;
> translation2[1] = imageCenterY;
> transform->Translate( translation2, false );
> filter->SetTransform( transform );
>
> try
> {
> writer->Update();
> }
> catch( itk::ExceptionObject & excep )
> {
> std::cerr << "Exception caught !" << std::endl;
> std::cerr << excep << std::endl;
> }
> // Software Guide : EndCodeSnippet
> return EXIT_SUCCESS;
> }
>
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>

From matt.mccormick at kitware.com  Sat Nov 22 12:32:49 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Sat, 22 Nov 2014 12:32:49 -0500
Subject: [ITK-users] Texture features/descriptors for 3D objects
In-Reply-To: <CAJqi3EJSeWqa_-VrE2VugUPUg8Z=L5nwK6GKTYaW4YVdqfOuJA@mail.gmail.com>
References: <CAJqi3EJSeWqa_-VrE2VugUPUg8Z=L5nwK6GKTYaW4YVdqfOuJA@mail.gmail.com>
Message-ID: <CALzTN-RDXL4T6eP1GF8coWdAOosW-BXATczF=L7dLAADVdBdmQ@mail.gmail.com>

Hi Francisco,

The following classes can be useful for computing the co-occurence matrices:

  http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1ScalarImageToTextureFeaturesFilter.html

  http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1ScalarImageToCooccurrenceMatrixFilter.html

  http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1HistogramToTextureFeaturesFilter.html

HTH,
Matt

On Sat, Nov 22, 2014 at 2:51 AM, Francisco Lopez de la Franca
<franciscolopezdelafranca at gmail.com> wrote:
> Hi,
>
> Recently, I have been reading some documentation talking on the texture
> features extraction subject. I am very interested on it, and I would like to
> do some tests.
>
> Does anyone know any framework, tool or library (ITK, VTK or Matlab)
> providing with a class of function to extract the textures features or
> descriptors for a tridimensional object?
>
> In that documents, the authors talk about the co-occurrence matrices. If
> anyone has some experience on this, I would appreciate a lot if it is
> shared.
>
> Thank you very much in advance.
> Regards.
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>

From ntustison at gmail.com  Sat Nov 22 15:40:36 2014
From: ntustison at gmail.com (Nicholas Tustison)
Date: Sat, 22 Nov 2014 12:40:36 -0800
Subject: [ITK-users] Texture features/descriptors for 3D objects
In-Reply-To: <CALzTN-RDXL4T6eP1GF8coWdAOosW-BXATczF=L7dLAADVdBdmQ@mail.gmail.com>
References: <CAJqi3EJSeWqa_-VrE2VugUPUg8Z=L5nwK6GKTYaW4YVdqfOuJA@mail.gmail.com>
 <CALzTN-RDXL4T6eP1GF8coWdAOosW-BXATczF=L7dLAADVdBdmQ@mail.gmail.com>
Message-ID: <F42333CD-4F04-44D5-A73F-06A256D0F082@gmail.com>

Here?s a couple others:

http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1ScalarImageToRunLengthFeaturesFilter.html

http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1ScalarImageToRunLengthMatrixFilter.html <http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1ScalarImageToRunLengthMatrixFilter.html>

http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1HistogramToRunLengthFeaturesFilter.html <http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1HistogramToRunLengthFeaturesFilter.html>

http://www.itk.org/Doxygen/html/classitk_1_1StochasticFractalDimensionImageFilter.html <http://www.itk.org/Doxygen/html/classitk_1_1StochasticFractalDimensionImageFilter.html>

Nick



> On Nov 22, 2014, at 9:32 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
> Hi Francisco,
> 
> The following classes can be useful for computing the co-occurence matrices:
> 
>  http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1ScalarImageToTextureFeaturesFilter.html
> 
>  http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1ScalarImageToCooccurrenceMatrixFilter.html
> 
>  http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1HistogramToTextureFeaturesFilter.html
> 
> HTH,
> Matt
> 
> On Sat, Nov 22, 2014 at 2:51 AM, Francisco Lopez de la Franca
> <franciscolopezdelafranca at gmail.com> wrote:
>> Hi,
>> 
>> Recently, I have been reading some documentation talking on the texture
>> features extraction subject. I am very interested on it, and I would like to
>> do some tests.
>> 
>> Does anyone know any framework, tool or library (ITK, VTK or Matlab)
>> providing with a class of function to extract the textures features or
>> descriptors for a tridimensional object?
>> 
>> In that documents, the authors talk about the co-occurrence matrices. If
>> anyone has some experience on this, I would appreciate a lot if it is
>> shared.
>> 
>> Thank you very much in advance.
>> Regards.
>> 
>> _____________________________________
>> 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.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-users
>> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141122/5d615211/attachment-0001.html>

From tejas.rox at gmail.com  Sat Nov 22 20:04:31 2014
From: tejas.rox at gmail.com (Tejas)
Date: Sat, 22 Nov 2014 18:04:31 -0700 (MST)
Subject: [ITK-users] ITK and VNL - SVD decomposition of image - Seg fault
Message-ID: <1416704671980-7586604.post@n2.nabble.com>

Hi, 

I am trying to decompose my affine-registered input ITK image using the SVD
routine in VNL. I have followed prior source code available from the
following links: 

http://www.itk.org/pipermail/insight-users/2014-July/050694.html
http://public.kitware.com/vxl/doc/development/books/core/book_6.html
http://public.kitware.com/pipermail/insight-users/2007-February/020883.html

A part of my code, which is the root cause of the two problems below, is
pasted after a short explanation of what I am facing: 

There are two problems that occur:

Problem 1: 
While using the standard VNL SVD routine (vnl_svd) to decompose my input
image into the singular matrix (W) and two orthogonal matrices (U and V), I
witness segmentation faults when running my code from the command prompt.
This is similar to what one user had posted in the first link above.
Elaborating further:

My code seg faults when I use this line: vnl_svd<double> svd(VNLMatrix);
Yet, it runs fine when I use this line instead: vnl_svd<double>
svdTranspose(VNLMatrix.transpose());

Is there an inherent issue with the vnl_svd routine that has not been fixed
yet? If so, what are the other possible ways to run svd on a single 200x200
image? 

Problem 2: 
Recomposing the U,W,and V component matrices yields an abnormal result. The
recomposition of the matrices is returned as a vnl_matrix of a specific data
type; in my case, a double valued matrix. When visualizing the resulting
.MHA file in ITK-SNAP, the image appears all white. At first, I thought I
was seeing a scaled intensity of the image. So, I divided the image by it's
maximum value, and the result was pretty much the same, so scaling wasn't
the issue here. I believe that problem 2 is connected to problem 1, and I am
not sure about how to solve problem 1 itself. Does anybody have thoughts on
why this is the case? 


Code: 
        
        typedef itk::VariableSizeMatrix< double > MatrixType;        

	// create a matrix structure in ITK  
	MatrixType matrix;
        matrix.SetSize(rows, cols);		// set the size of the ITK matrix

	// create an image iterator
        // dAlignedIm is a double data-type, ITK affine-registered image
passed to vnl_svd, via an ITK VariableSizeMatrix and vnl_matrix. 

	IterType inputIter( dAlignedIm, dAlignedIm->GetLargestPossibleRegion() );
        inputIter.GoToBegin();

	while(!inputIter.IsAtEnd()) {

		// copy the input image intensity value into the corresponding matrix
		unsigned int c = inputIter.GetIndex()[0];
		unsigned int r = inputIter.GetIndex()[1];
		matrix(r, c) = inputIter.Get();
		++inputIter;
	}

	

	// create a vnl matrix 
	vnl_matrix< double > VNLMatrix = matrix.GetVnlMatrix();

	//// perform SVD decomposition
	vnl_svd<double> svdTranspose(VNLMatrix.transpose());

	//svdTranspose.recompose();
	//svdTranspose.W(0,0) = 0; 	 


	typedef itk::ImportImageFilter< double, Dimension >   ImportFilterType;

	ImportFilterType::Pointer importFilter = ImportFilterType::New();

	ImportFilterType::SizeType  size;
	size[0]  = cols;  // size along X
	size[1]  = rows;  // size along Y	

	ImportFilterType::IndexType start;
	start.Fill( 0 );

	ImportFilterType::RegionType region;
	region.SetIndex( start );
	region.SetSize(  size  );

	importFilter->SetRegion( region );

	double origin[ Dimension ];
	origin[0] = 0.0;    // X coordinate
	origin[1] = 0.0;    // Y coordinate

	importFilter->SetOrigin( origin );

	double spacing[ Dimension ];
	spacing[0] = 1.0;    // along X direction
	spacing[1] = 1.0;    // along Y direction

	importFilter->SetSpacing( spacing );
	
	const bool importImageFilterWillOwnTheBuffer = false;

	vnl_matrix <double> reconstruct = (svdTranspose.recompose());
	//reconstruct = reconstruct.transpose();
	
	importFilter->SetImportPointer( reconstruct.data_block(), rows*cols,
importImageFilterWillOwnTheBuffer );
	

	typedef itk::ImageFileWriter< doubleImageType >  WriterType2;
	//typedef itk::CastImageFilter<	doubleImageType,	ImageType >
CastFilterType3;

	WriterType2::Pointer writernew = WriterType2::New();
	//CastFilterType3::Pointer casternew = CastFilterType3::New();
	writernew->SetFileName( "reconstruct.mha" );
		
	//casternew->SetInput( importFilter->GetOutput() );
	writernew->SetInput(  importFilter->GetOutput()  );
	


	try
	{
		writernew->Update();
	}
		catch( itk::ExceptionObject & exp )
	{
		std::cerr << "Exception caught !" << std::endl;
		std::cerr << exp << std::endl;
	}



--
View this message in context: http://itk-insight-users.2283740.n2.nabble.com/ITK-and-VNL-SVD-decomposition-of-image-Seg-fault-tp7586604.html
Sent from the ITK Insight Users mailing list archive at Nabble.com.

From dan.muel at gmail.com  Sun Nov 23 02:09:44 2014
From: dan.muel at gmail.com (Dan Mueller)
Date: Sun, 23 Nov 2014 17:39:44 +1030
Subject: [ITK-users] Encapsulate a ITK function into a DLL to be used
	with C#
In-Reply-To: <CAKKNfuKQo+m4KYiB_eC80yxx7p4H-9HpZKh5A27HOHTJBftpEg@mail.gmail.com>
References: <CAKKNfuKQo+m4KYiB_eC80yxx7p4H-9HpZKh5A27HOHTJBftpEg@mail.gmail.com>
Message-ID: <CAPNvZ5a=RbPR8UZCYX7Ci7pmQNjACkh07ZgbaA3F7-VFGfqTgw@mail.gmail.com>

Hi Matias,

I would highly recommend SimpleITK. Given your requirements, it appears
SimpleITK wraps all the features you need.

Secondly I would recommend SWIG. Some years ago I created a wiki page to
explain how this works:
http://www.itk.org/Wiki/ITK/Using_ITK_from_.NET

Hope this helps.

Cheers, Dan
On 22 Nov 2014 23:01, "Matias Montroull" <matimontg at gmail.com> wrote:

> Hi,
>
> I have the following code that I would like to use in C#. Since it is ITK,
> it's coded in C++ so I was wondering if I could create a DLL that can be
> used in C# and then call the function as it was a class, pass parameters
> and use the method?
>
> All I need is to pass 3 parameters to the function (which is a function to
> rotate images)
>
> here's the code:
>
> #include "itkImage.h"
> #include "itkImageFileReader.h"
> #include "itkImageFileWriter.h"
> #include "itkResampleImageFilter.h"
> #include "itkAffineTransform.h"
> #include "itkGDCMImageIO.h"
>
> int main( int argc, char * argv[] )
> {
> if( argc < 4 )
> {
> std::cerr << "Usage: " << std::endl;
> std::cerr << argv[0] << " inputImageFile outputImageFile degrees" <<
> std::endl;
> return EXIT_FAILURE;
> }
>
> const unsigned int Dimension = 2; //imagen 2D
> typedef signed short InputPixelType;
> typedef signed short OutputPixelType;
> typedef itk::Image< InputPixelType, Dimension > InputImageType;
> typedef itk::Image< OutputPixelType, Dimension > OutputImageType;
> typedef itk::ImageFileReader< InputImageType > ReaderType;
> typedef itk::ImageFileWriter< OutputImageType > WriterType;
> ReaderType::Pointer reader = ReaderType::New(); //lo que lee
> WriterType::Pointer writer = WriterType::New(); //lo que escribe
> reader->SetFileName( argv[1] ); //primer argumento
> writer->SetFileName( argv[2] ); //segundo argumento
>
> typedef itk::GDCMImageIO ImageIOType;
> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
> reader->SetImageIO( gdcmImageIO );
>
>
> const double angleInDegrees = atof( argv[3] ); //angulo de rotaci?n
>
> typedef itk::ResampleImageFilter<InputImageType, OutputImageType >
> FilterType; //Filtro
> FilterType::Pointer filter = FilterType::New();
>
> typedef itk::AffineTransform< double, Dimension > TransformType; //usado
> para mapear el espacio de entrada con el espacio de salida
> TransformType::Pointer transform = TransformType::New();
>
> typedef itk::LinearInterpolateImageFunction<InputImageType, double >
> InterpolatorType;
> InterpolatorType::Pointer interpolator = InterpolatorType::New();
> filter->SetInterpolator( interpolator );
> filter->SetDefaultPixelValue(0); //Pixel por defecto de lo que queda fuera
> de la imagen cuando se rota
>
> reader->Update();
>
> const InputImageType * inputImage = reader->GetOutput();
> const InputImageType::SpacingType & spacing = inputImage->GetSpacing();
> const InputImageType::PointType & origin = inputImage->GetOrigin();
> InputImageType::SizeType size =
> inputImage->GetLargestPossibleRegion().GetSize();
> filter->SetOutputOrigin( origin );
> filter->SetOutputSpacing( spacing );
> filter->SetOutputDirection( inputImage->GetDirection() );
> filter->SetSize( size );
>
> filter->SetInput( reader->GetOutput() );
> writer->SetInput( filter->GetOutput() );
> writer->UseInputMetaDataDictionaryOff();
> writer->SetImageIO(gdcmImageIO);
>  TransformType::OutputVectorType translation1;
> const double imageCenterX = origin[0] + spacing[0] * size[0] / 2.0;
> const double imageCenterY = origin[1] + spacing[1] * size[1] / 2.0;
> translation1[0] = -imageCenterX;
> translation1[1] = -imageCenterY;
> transform->Translate( translation1 );
> // Software Guide : EndCodeSnippet
> std::cout << "imageCenterX = " << imageCenterX << std::endl;
> std::cout << "imageCenterY = " << imageCenterY << std::endl;
>
> const double degreesToRadians = std::atan(1.0) / 45.0;
> const double angle = angleInDegrees * degreesToRadians;
> transform->Rotate2D( -angle, false );
>
> TransformType::OutputVectorType translation2;
> translation2[0] = imageCenterX;
> translation2[1] = imageCenterY;
> transform->Translate( translation2, false );
> filter->SetTransform( transform );
>
> try
> {
> writer->Update();
> }
> catch( itk::ExceptionObject & excep )
> {
> std::cerr << "Exception caught !" << std::endl;
> std::cerr << excep << std::endl;
> }
> // Software Guide : EndCodeSnippet
> return EXIT_SUCCESS;
> }
>
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141123/d5249f84/attachment.html>

From fdrakopo at gmail.com  Sun Nov 23 16:51:07 2014
From: fdrakopo at gmail.com (Fotis Drakopoulos)
Date: Sun, 23 Nov 2014 16:51:07 -0500
Subject: [ITK-users] Problem reading a big nifti volume.
Message-ID: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>

Hi all,

For the last couple of days I have been trying reading (unsuccessfully)  a
big nifti volume labeled image from my disk.

The pixel type is unsigned char and the rest specs of the image are:
Size : [1001, 1001, 8345]  (in voxels)
Spacing : [0.012, 0.012, 0.012]  (in mm)
Origin : [0, 0, 0]
Direction :
1 0 0
0 1 0
0 0 1

First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea how
it looks like. Indeed the object in the volume looks as it was expected. So
far no problems. The specs of the image on Slicer are the same as above
(except the direction which has flipped signs for the first two diagonal
entries, as we know ).

Then I tried to load the image in the memory using the
itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After loading
the image I noticed that there are pixels with zero values instead of
non-zero by comparing the same indexes with the loaded image on Slicer.

Then I decided to write the loaded image on the disk using the
itk::ImageFileWriter.

After opening the (written from ITK) image on Slicer I checked the specks
and were the same with the original image as above. However I noticed that
a big portion of the image is completely empty (black)!

My workstation has enough memory to load the image (768 GB 1600MHz DDR3L)
and is using Red Hat Enterprise Linux Server 6.5.
The size of the original nifti volume is :

   - 25.7 MB (.nii.gz)
   - 8.36 GB (.nii)

Has anybody experienced similar difficulties trying to load so big volume
data?

Best,
Fotis Drakopoulos
CRTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141123/a627f94f/attachment.html>

From j.plumat at auckland.ac.nz  Sun Nov 23 17:15:07 2014
From: j.plumat at auckland.ac.nz (Jerome Plumat)
Date: Mon, 24 Nov 2014 11:15:07 +1300
Subject: [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
Message-ID: <54725C6B.7020001@auckland.ac.nz>

Hi,
Have you correctly specified the pixel type? I had similar problem and 
mine was due to pixels specifications.
Hope it helps.

Jerome Plumat
-------
School of Medical Sciences
University of Auckland

If I am not for myself, who will be for me? And if I am only for myself, then what an I? And if not now when? ? Hillel HaZaken

On 24/11/14 10:51, Fotis Drakopoulos wrote:
> Hi all,
>
> For the last couple of days I have been trying reading 
> (unsuccessfully)  a big nifti volume labeled image from my disk.
>
> The pixel type is unsigned char and the rest specs of the image are:
> Size : [1001, 1001, 8345]  (in voxels)
> Spacing : [0.012, 0.012, 0.012]  (in mm)
> Origin : [0, 0, 0]
> Direction :
> 1 0 0
> 0 1 0
> 0 0 1
>
> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an 
> idea how it looks like. Indeed the object in the volume looks as it 
> was expected. So far no problems. The specs of the image on Slicer are 
> the same as above (except the direction which has flipped signs for 
> the first two diagonal entries, as we know ).
>
> Then I tried to load the image in the memory using the 
> itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After 
> loading the image I noticed that there are pixels with zero values 
> instead of non-zero by comparing the same indexes with the loaded 
> image on Slicer.
>
> Then I decided to write the loaded image on the disk using the 
> itk::ImageFileWriter.
>
> After opening the (written from ITK) image on Slicer I checked the 
> specks and were the same with the original image as above. However I 
> noticed that a big portion of the image is completely empty (black)!
>
> My workstation has enough memory to load the image (768 GB 1600MHz 
> DDR3L) and is using Red Hat Enterprise Linux Server 6.5.
> The size of the original nifti volume is :
>
>   * 25.7 MB (.nii.gz)
>   * 8.36 GB (.nii)
>
> Has anybody experienced similar difficulties trying to load so big 
> volume data?
>
> Best,
> Fotis Drakopoulos
> CRTC
>
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141124/65e08f85/attachment.html>

From fdrakopo at gmail.com  Sun Nov 23 17:19:21 2014
From: fdrakopo at gmail.com (Fotis Drakopoulos)
Date: Sun, 23 Nov 2014 17:19:21 -0500
Subject: [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <54725C6B.7020001@auckland.ac.nz>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <54725C6B.7020001@auckland.ac.nz>
Message-ID: <CAG6AjRNGRNhYbzVegbeKULKLKmHkVxkgiCK3Rxir29dOq395iA@mail.gmail.com>

Hi  Jerome,

Yes, I correctly specified the pixel type to unsigned char.

On Sun, Nov 23, 2014 at 5:15 PM, Jerome Plumat <j.plumat at auckland.ac.nz>
wrote:

>  Hi,
> Have you correctly specified the pixel type? I had similar problem and
> mine was due to pixels specifications.
> Hope it helps.
>
> Jerome Plumat
> -------
> School of Medical Sciences
> University of Auckland
>
> If I am not for myself, who will be for me? And if I am only for myself, then what an I? And if not now when? ? Hillel HaZaken
>
> On 24/11/14 10:51, Fotis Drakopoulos wrote:
>
> Hi all,
>
>  For the last couple of days I have been trying reading (unsuccessfully)
>  a big nifti volume labeled image from my disk.
>
>  The pixel type is unsigned char and the rest specs of the image are:
> Size : [1001, 1001, 8345]  (in voxels)
>  Spacing : [0.012, 0.012, 0.012]  (in mm)
> Origin : [0, 0, 0]
> Direction :
> 1 0 0
> 0 1 0
> 0 0 1
>
>  First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea
> how it looks like. Indeed the object in the volume looks as it was
> expected. So far no problems. The specs of the image on Slicer are the same
> as above (except the direction which has flipped signs for the first two
> diagonal entries, as we know ).
>
>  Then I tried to load the image in the memory using the
> itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After loading
> the image I noticed that there are pixels with zero values instead of
> non-zero by comparing the same indexes with the loaded image on Slicer.
>
>  Then I decided to write the loaded image on the disk using the
> itk::ImageFileWriter.
>
>  After opening the (written from ITK) image on Slicer I checked the
> specks and were the same with the original image as above. However I
> noticed that a big portion of the image is completely empty (black)!
>
>  My workstation has enough memory to load the image (768 GB 1600MHz DDR3L)
> and is using Red Hat Enterprise Linux Server 6.5.
> The size of the original nifti volume is :
>
>    - 25.7 MB (.nii.gz)
>     - 8.36 GB (.nii)
>
>  Has anybody experienced similar difficulties trying to load so big
> volume data?
>
>  Best,
> Fotis Drakopoulos
> CRTC
>
>
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects athttp://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:http://www.kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>
>
>  ------------------------------
>
> Spam
> <https://www.spamtrap.odu.edu/canit/b.php?i=01Njag6QE&m=e24f9d3be5a0&t=20141123&c=s>
> Not spam
> <https://www.spamtrap.odu.edu/canit/b.php?i=01Njag6QE&m=e24f9d3be5a0&t=20141123&c=n>
> Forget previous vote
> <https://www.spamtrap.odu.edu/canit/b.php?i=01Njag6QE&m=e24f9d3be5a0&t=20141123&c=f>
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141123/3fcee160/attachment.html>

From g.bogle at auckland.ac.nz  Sun Nov 23 17:40:58 2014
From: g.bogle at auckland.ac.nz (Gib Bogle)
Date: Sun, 23 Nov 2014 22:40:58 +0000
Subject: [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
Message-ID: <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>

This is reminiscent of the previous problem with big TIFF images, now fixed.

Gib
________________________________
From: Insight-users [insight-users-bounces at itk.org] on behalf of Fotis Drakopoulos [fdrakopo at gmail.com]
Sent: Monday, 24 November 2014 10:51 a.m.
To: insight-users at itk.org; insight-developers at itk.org
Subject: [ITK-users] Problem reading a big nifti volume.

Hi all,

For the last couple of days I have been trying reading (unsuccessfully)  a big nifti volume labeled image from my disk.

The pixel type is unsigned char and the rest specs of the image are:
Size : [1001, 1001, 8345]  (in voxels)
Spacing : [0.012, 0.012, 0.012]  (in mm)
Origin : [0, 0, 0]
Direction :
1 0 0
0 1 0
0 0 1

First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea how it looks like. Indeed the object in the volume looks as it was expected. So far no problems. The specs of the image on Slicer are the same as above (except the direction which has flipped signs for the first two diagonal entries, as we know ).

Then I tried to load the image in the memory using the itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After loading the image I noticed that there are pixels with zero values instead of non-zero by comparing the same indexes with the loaded image on Slicer.

Then I decided to write the loaded image on the disk using the itk::ImageFileWriter.

After opening the (written from ITK) image on Slicer I checked the specks and were the same with the original image as above. However I noticed that a big portion of the image is completely empty (black)!

My workstation has enough memory to load the image (768 GB 1600MHz DDR3L) and is using Red Hat Enterprise Linux Server 6.5.
The size of the original nifti volume is :

  *   25.7 MB (.nii.gz)
  *   8.36 GB (.nii)

Has anybody experienced similar difficulties trying to load so big volume data?

Best,
Fotis Drakopoulos
CRTC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141123/dd4d47ee/attachment.html>

From brad at lowekamp.net  Sun Nov 23 18:04:52 2014
From: brad at lowekamp.net (Bradley Lowekamp)
Date: Sun, 23 Nov 2014 18:04:52 -0500
Subject: [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
Message-ID: <BD94B701-14F9-475B-BBE9-EE67A4EF659F@mail.nih.gov>

Shareable test data greatly helps determine the cause and fix these types of issues.

Got data?

Brad


> On Nov 23, 2014, at 5:40 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
> 
> This is reminiscent of the previous problem with big TIFF images, now fixed.
> 
> Gib
> From: Insight-users [insight-users-bounces at itk.org] on behalf of Fotis Drakopoulos [fdrakopo at gmail.com]
> Sent: Monday, 24 November 2014 10:51 a.m.
> To: insight-users at itk.org; insight-developers at itk.org
> Subject: [ITK-users] Problem reading a big nifti volume.
> 
> Hi all,
> 
> For the last couple of days I have been trying reading (unsuccessfully)  a big nifti volume labeled image from my disk.
> 
> The pixel type is unsigned char and the rest specs of the image are:
> Size : [1001, 1001, 8345]  (in voxels)
> Spacing : [0.012, 0.012, 0.012]  (in mm)
> Origin : [0, 0, 0]
> Direction : 
> 1 0 0
> 0 1 0
> 0 0 1
> 
> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea how it looks like. Indeed the object in the volume looks as it was expected. So far no problems. The specs of the image on Slicer are the same as above (except the direction which has flipped signs for the first two diagonal entries, as we know ).
> 
> Then I tried to load the image in the memory using the itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After loading the image I noticed that there are pixels with zero values instead of non-zero by comparing the same indexes with the loaded image on Slicer.
> 
> Then I decided to write the loaded image on the disk using the itk::ImageFileWriter. 
> 
> After opening the (written from ITK) image on Slicer I checked the specks and were the same with the original image as above. However I noticed that a big portion of the image is completely empty (black)!
> 
> My workstation has enough memory to load the image (768 GB 1600MHz DDR3L) and is using Red Hat Enterprise Linux Server 6.5. 
> The size of the original nifti volume is :
> 25.7 MB (.nii.gz)
> 8.36 GB (.nii)
> Has anybody experienced similar difficulties trying to load so big volume data?
> 
> Best,
> Fotis Drakopoulos
> CRTC
>      
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141123/2d0df3bc/attachment.html>

From blowekamp at mail.nih.gov  Mon Nov 24 10:13:20 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 24 Nov 2014 10:13:20 -0500
Subject: [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
Message-ID: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>

Shareable test data greatly helps determine the cause and fix these types of issues.

Got data?

Brad
On Nov 23, 2014, at 5:40 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:

> This is reminiscent of the previous problem with big TIFF images, now fixed.
> 
> Gib
> From: Insight-users [insight-users-bounces at itk.org] on behalf of Fotis Drakopoulos [fdrakopo at gmail.com]
> Sent: Monday, 24 November 2014 10:51 a.m.
> To: insight-users at itk.org; insight-developers at itk.org
> Subject: [ITK-users] Problem reading a big nifti volume.
> 
> Hi all,
> 
> For the last couple of days I have been trying reading (unsuccessfully)  a big nifti volume labeled image from my disk.
> 
> The pixel type is unsigned char and the rest specs of the image are:
> Size : [1001, 1001, 8345]  (in voxels)
> Spacing : [0.012, 0.012, 0.012]  (in mm)
> Origin : [0, 0, 0]
> Direction : 
> 1 0 0
> 0 1 0
> 0 0 1
> 
> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea how it looks like. Indeed the object in the volume looks as it was expected. So far no problems. The specs of the image on Slicer are the same as above (except the direction which has flipped signs for the first two diagonal entries, as we know ).
> 
> Then I tried to load the image in the memory using the itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After loading the image I noticed that there are pixels with zero values instead of non-zero by comparing the same indexes with the loaded image on Slicer.
> 
> Then I decided to write the loaded image on the disk using the itk::ImageFileWriter. 
> 
> After opening the (written from ITK) image on Slicer I checked the specks and were the same with the original image as above. However I noticed that a big portion of the image is completely empty (black)!
> 
> My workstation has enough memory to load the image (768 GB 1600MHz DDR3L) and is using Red Hat Enterprise Linux Server 6.5. 
> The size of the original nifti volume is :
> 25.7 MB (.nii.gz)
> 8.36 GB (.nii)
> Has anybody experienced similar difficulties trying to load so big volume data?
> 
> Best,
> Fotis Drakopoulos
> CRTC
>      
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141124/71cfa80e/attachment.html>

From emily-hammond at uiowa.edu  Mon Nov 24 13:41:08 2014
From: emily-hammond at uiowa.edu (Hammond, Emily M)
Date: Mon, 24 Nov 2014 18:41:08 +0000
Subject: [ITK-users] minimize skewing
In-Reply-To: <6A33BD14-4CC4-4565-A2FB-BBA7BB371646@mail.nih.gov>
References: <2609C492EC89AB4CAAD3647B8D1A43CC2F14FEDC@ITSNT437.iowa.uiowa.edu>,
 <6A33BD14-4CC4-4565-A2FB-BBA7BB371646@mail.nih.gov>
Message-ID: <2609C492EC89AB4CAAD3647B8D1A43CC2F159444@ITSNT437.iowa.uiowa.edu>

Thank you for your suggestion. It has been helpful!

I have implemented the ScaleVersor3DTransform and have received results. However, every time the rotation is much larger causing terrible results. Here is an example of a final transform received.

scaleVersorTransform information:
   Rotation: [ -0.606402, 0.792956, 0.0591457, 1.41421e-005 ]
   Translation: [9.16674, -1.28393, -17.1493]
   Scale: [4.08189, 1.52688, 2.35832]

I haven't had much experience with versors, but I went through the calculations from a previous mailing list email (http://public.kitware.com/pipermail/insight-users/2009-March/029584.html) and got a very very large rotation that is occurring (as is seen in the resulting image). Is there any reason that I may be getting such a large, unrealistic rotation?

Here is how I've set up my optimizer:

typedef itk::RegularStepGradientDescentOptimizer GDOptimizerType;
GDOptimizerType::Pointer gdOptimizer = GDOptimizerType::New();

// set up optimizer
gdOptimizer->SetNumberOfIterations( 200 );
gdOptimizer->SetRelaxationFactor( 0.9 );
gdOptimizer->SetMinimumStepLength( 0.001 );
gdOptimizer->SetMaximumStepLength( 5.0 );
gdOptimizer->SetGradientMagnitudeTolerance( 0.001 );

// initialize optimizer scales
typedef GDOptimizerType::ScalesType OptimizerScalesType;
OptimizerScalesType optimizerScales( scaleVersorTransform->GetNumberOfParameters() );
// rotation
const double rotationScale = 1.0/10000.0;
optimizerScales[0] = rotationScale;
optimizerScales[1] = rotationScale;
optimizerScales[2] = rotationScale;
// translation
const double translationScale = 1.0/1000.0;
optimizerScales[3] = translationScale;
optimizerScales[4] = translationScale;
optimizerScales[5] = translationScale;
// scaling
const double scalingScale = 1.0/100.0;
optimizerScales[6] = scalingScale;
optimizerScales[7] = scalingScale;
optimizerScales[8] = scalingScale;
// set scales
gdOptimizer->SetScales( optimizerScales );

Any advice would be great!
Thanks!

Emily Hammond

________________________________
From: Bradley Lowekamp [blowekamp at mail.nih.gov]
Sent: Wednesday, November 19, 2014 12:52 PM
To: Hammond, Emily M
Cc: insight users
Subject: Re: [ITK-users] minimize skewing

Hello,

For 3D you might want to look into the ScaleVersor3DTransform or the ScaleSkewVersor3DTransform. These may parameterize the transform as you wish.

Brad

On Nov 19, 2014, at 11:56 AM, Hammond, Emily M <emily-hammond at uiowa.edu<mailto:emily-hammond at uiowa.edu>> wrote:

Hello all,

I am looking perform registration allowing for translation, rotation and anisotropic scaling. Is there a way to use the affine transform but limit the skewing performed? Or is there an alternative method to do this.

Thanks!
Emily Hammond
_____________________________________
Powered by www.kitware.com<http://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.php

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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141124/edb6a507/attachment.html>

From matimontg at gmail.com  Mon Nov 24 19:28:57 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Mon, 24 Nov 2014 21:28:57 -0300
Subject: [ITK-users] Encapsulate a ITK function into a DLL to be used
	with C#
In-Reply-To: <CAPNvZ5a=RbPR8UZCYX7Ci7pmQNjACkh07ZgbaA3F7-VFGfqTgw@mail.gmail.com>
References: <CAKKNfuKQo+m4KYiB_eC80yxx7p4H-9HpZKh5A27HOHTJBftpEg@mail.gmail.com>
 <CAPNvZ5a=RbPR8UZCYX7Ci7pmQNjACkh07ZgbaA3F7-VFGfqTgw@mail.gmail.com>
Message-ID: <CAKKNfuJKqxxQ9RHKKxB4iN-PbK-7pTZji8ZypVF2-6NBfa8iKw@mail.gmail.com>

Thank you all for your answers, I'll give it a try!

On Sun, Nov 23, 2014 at 4:09 AM, Dan Mueller <dan.muel at gmail.com> wrote:

> Hi Matias,
>
> I would highly recommend SimpleITK. Given your requirements, it appears
> SimpleITK wraps all the features you need.
>
> Secondly I would recommend SWIG. Some years ago I created a wiki page to
> explain how this works:
> http://www.itk.org/Wiki/ITK/Using_ITK_from_.NET
>
> Hope this helps.
>
> Cheers, Dan
> On 22 Nov 2014 23:01, "Matias Montroull" <matimontg at gmail.com> wrote:
>
>> Hi,
>>
>> I have the following code that I would like to use in C#. Since it is
>> ITK, it's coded in C++ so I was wondering if I could create a DLL that can
>> be used in C# and then call the function as it was a class, pass parameters
>> and use the method?
>>
>> All I need is to pass 3 parameters to the function (which is a function
>> to rotate images)
>>
>> here's the code:
>>
>> #include "itkImage.h"
>> #include "itkImageFileReader.h"
>> #include "itkImageFileWriter.h"
>> #include "itkResampleImageFilter.h"
>> #include "itkAffineTransform.h"
>> #include "itkGDCMImageIO.h"
>>
>> int main( int argc, char * argv[] )
>> {
>> if( argc < 4 )
>> {
>> std::cerr << "Usage: " << std::endl;
>> std::cerr << argv[0] << " inputImageFile outputImageFile degrees" <<
>> std::endl;
>> return EXIT_FAILURE;
>> }
>>
>> const unsigned int Dimension = 2; //imagen 2D
>> typedef signed short InputPixelType;
>> typedef signed short OutputPixelType;
>> typedef itk::Image< InputPixelType, Dimension > InputImageType;
>> typedef itk::Image< OutputPixelType, Dimension > OutputImageType;
>> typedef itk::ImageFileReader< InputImageType > ReaderType;
>> typedef itk::ImageFileWriter< OutputImageType > WriterType;
>> ReaderType::Pointer reader = ReaderType::New(); //lo que lee
>> WriterType::Pointer writer = WriterType::New(); //lo que escribe
>> reader->SetFileName( argv[1] ); //primer argumento
>> writer->SetFileName( argv[2] ); //segundo argumento
>>
>> typedef itk::GDCMImageIO ImageIOType;
>> ImageIOType::Pointer gdcmImageIO = ImageIOType::New();
>> reader->SetImageIO( gdcmImageIO );
>>
>>
>> const double angleInDegrees = atof( argv[3] ); //angulo de rotaci?n
>>
>> typedef itk::ResampleImageFilter<InputImageType, OutputImageType >
>> FilterType; //Filtro
>> FilterType::Pointer filter = FilterType::New();
>>
>> typedef itk::AffineTransform< double, Dimension > TransformType; //usado
>> para mapear el espacio de entrada con el espacio de salida
>> TransformType::Pointer transform = TransformType::New();
>>
>> typedef itk::LinearInterpolateImageFunction<InputImageType, double >
>> InterpolatorType;
>> InterpolatorType::Pointer interpolator = InterpolatorType::New();
>> filter->SetInterpolator( interpolator );
>> filter->SetDefaultPixelValue(0); //Pixel por defecto de lo que queda
>> fuera de la imagen cuando se rota
>>
>> reader->Update();
>>
>> const InputImageType * inputImage = reader->GetOutput();
>> const InputImageType::SpacingType & spacing = inputImage->GetSpacing();
>> const InputImageType::PointType & origin = inputImage->GetOrigin();
>> InputImageType::SizeType size =
>> inputImage->GetLargestPossibleRegion().GetSize();
>> filter->SetOutputOrigin( origin );
>> filter->SetOutputSpacing( spacing );
>> filter->SetOutputDirection( inputImage->GetDirection() );
>> filter->SetSize( size );
>>
>> filter->SetInput( reader->GetOutput() );
>> writer->SetInput( filter->GetOutput() );
>> writer->UseInputMetaDataDictionaryOff();
>> writer->SetImageIO(gdcmImageIO);
>>  TransformType::OutputVectorType translation1;
>> const double imageCenterX = origin[0] + spacing[0] * size[0] / 2.0;
>> const double imageCenterY = origin[1] + spacing[1] * size[1] / 2.0;
>> translation1[0] = -imageCenterX;
>> translation1[1] = -imageCenterY;
>> transform->Translate( translation1 );
>> // Software Guide : EndCodeSnippet
>> std::cout << "imageCenterX = " << imageCenterX << std::endl;
>> std::cout << "imageCenterY = " << imageCenterY << std::endl;
>>
>> const double degreesToRadians = std::atan(1.0) / 45.0;
>> const double angle = angleInDegrees * degreesToRadians;
>> transform->Rotate2D( -angle, false );
>>
>> TransformType::OutputVectorType translation2;
>> translation2[0] = imageCenterX;
>> translation2[1] = imageCenterY;
>> transform->Translate( translation2, false );
>> filter->SetTransform( transform );
>>
>> try
>> {
>> writer->Update();
>> }
>> catch( itk::ExceptionObject & excep )
>> {
>> std::cerr << "Exception caught !" << std::endl;
>> std::cerr << excep << std::endl;
>> }
>> // Software Guide : EndCodeSnippet
>> return EXIT_SUCCESS;
>> }
>>
>>
>> _____________________________________
>> 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.php
>>
>> 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://public.kitware.com/mailman/listinfo/insight-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141124/f2166bfd/attachment-0001.html>

From matimontg at gmail.com  Mon Nov 24 19:31:33 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Mon, 24 Nov 2014 21:31:33 -0300
Subject: [ITK-users] Get RescaleIntercept
Message-ID: <CAKKNfuKsDdhr292znccRZSrSv6SkVPnfEA9xeZfE58HDWeURqg@mail.gmail.com>

Hi,

I'm struggling with code I did to get the RescaleIntercept of an image.

It's simple as this:

typedef itk::GDCMImageIO ImageIOTypeGDCM;
ImageIOTypeGDCM::Pointer gdcmImageIO = ImageIOTypeGDCM::New();
reader->SetImageIO( gdcmImageIO );

double intercept = gdcmImageIO->GetRescaleIntercept();
std::cout << "Rescale Intercept value: " << intercept << std::endl;

Now, the last line returns "0" and actually the tag (0028|1052) reads
"-1000"

Is there any issues with the code or something I missed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141124/332699d8/attachment.html>

From matt.mccormick at kitware.com  Mon Nov 24 20:47:31 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Mon, 24 Nov 2014 20:47:31 -0500
Subject: [ITK-users] Get RescaleIntercept
In-Reply-To: <CAKKNfuKsDdhr292znccRZSrSv6SkVPnfEA9xeZfE58HDWeURqg@mail.gmail.com>
References: <CAKKNfuKsDdhr292znccRZSrSv6SkVPnfEA9xeZfE58HDWeURqg@mail.gmail.com>
Message-ID: <CALzTN-SCdMkawebyjn6K3fWg2AXVq6hYbMkMSdZ83VqBUVGr=g@mail.gmail.com>

Hi Matias,

  reader->UpdateOutputInformation();

must be called for gdcmImageIO to parse the tags.

HTH,
Matt


On Mon, Nov 24, 2014 at 7:31 PM, Matias Montroull <matimontg at gmail.com> wrote:
> Hi,
>
> I'm struggling with code I did to get the RescaleIntercept of an image.
>
> It's simple as this:
>
> typedef itk::GDCMImageIO ImageIOTypeGDCM;
> ImageIOTypeGDCM::Pointer gdcmImageIO = ImageIOTypeGDCM::New();
> reader->SetImageIO( gdcmImageIO );
>
> double intercept = gdcmImageIO->GetRescaleIntercept();
> std::cout << "Rescale Intercept value: " << intercept << std::endl;
>
> Now, the last line returns "0" and actually the tag (0028|1052) reads
> "-1000"
>
> Is there any issues with the code or something I missed?
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>

From zeinsalah at gmail.com  Tue Nov 25 04:37:00 2014
From: zeinsalah at gmail.com (Zein Salah)
Date: Tue, 25 Nov 2014 10:37:00 +0100
Subject: [ITK-users] [ITK] Otsu Filter for object/background separation
In-Reply-To: <CAA+VR6isWQDHzOj--n0f2iPiceg+1EbBjBPXc+p7us+ZWStejQ@mail.gmail.com>
References: <CADiSopNLpxu4V+W+fbMz_+Wfet3qv_GvekS+9nK46TLMd8GiAA@mail.gmail.com>
 <CAA+VR6isWQDHzOj--n0f2iPiceg+1EbBjBPXc+p7us+ZWStejQ@mail.gmail.com>
Message-ID: <CADiSopNjfyS9VY1=TqWzes6oG_47KmBRWZr_uV3j8uVF38i=7w@mail.gmail.com>

well. is there a ready-made filter /function to automatically check if
the image has a bi-modal histogram?

On Wed, Nov 12, 2014 at 2:14 PM, Girish Mallya Udupi
<indianzeppelin at gmail.com> wrote:
> Hi Zein,
>
> As you might know, Otsu's method assumes that the histogram of the image is
> bi-modal. i.e., there are two classes of pixels forming two peaks separated
> by a valley.
> All the method (and the corresponding ITK filter) does is calculate the
> threshold which maximizes the inter-class variance and apply it on the
> image.
>
>
> On Wed, Nov 12, 2014 at 12:43 PM, Zein Salah <zeinsalah at gmail.com> wrote:
>>
>> Hello,
>>
>> I have been using the otsu filter for doing object-from-background
>> separation. However, I noticed that the filter always comes out with an
>> separation threshold, even if the image does NOT actually have a
>> "reasonable" background, see the attached image, e.g..
>>
>> My question is: is it possible to control the filter in such a way that it
>> only generate a threshold if there is really a background?
>>
>> Practically, I could, in a post-processing step,  do a decision weather
>> the separation is feasible or not, e.g. computing the comparing the
>> statistics of the two separated areas (average intensity, variance, etc.).
>> But I thought the otsu filter already does such things internally, right? Is
>> it possible to inquire such data from the filter?
>>
>> Any ideas would be welcome!!
>>
>> Much thanks,
>>
>> Zein
>>
>>
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/mailman/listinfo/community
>>
>
>
>
> --
> Regards,
> Girish

From fdrakopo at gmail.com  Tue Nov 25 15:14:38 2014
From: fdrakopo at gmail.com (Fotis Drakopoulos)
Date: Tue, 25 Nov 2014 15:14:38 -0500
Subject: [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
Message-ID: <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>

Hi all,

I created a test nifti image that reproduces the problem I mentioned before.
How can I share this image with the ITK community?

Best,
Fotis Drakopoulos


On Mon, Nov 24, 2014 at 10:13 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Shareable test data greatly helps determine the cause and fix these types
> of issues.
>
> Got data?
>
> Brad
> On Nov 23, 2014, at 5:40 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
>
> This is reminiscent of the previous problem with big TIFF images, now
> fixed.
>
> Gib
> ------------------------------
> *From:* Insight-users [insight-users-bounces at itk.org] on behalf of Fotis
> Drakopoulos [fdrakopo at gmail.com]
> *Sent:* Monday, 24 November 2014 10:51 a.m.
> *To:* insight-users at itk.org; insight-developers at itk.org
> *Subject:* [ITK-users] Problem reading a big nifti volume.
>
> Hi all,
>
> For the last couple of days I have been trying reading (unsuccessfully)  a
> big nifti volume labeled image from my disk.
>
> The pixel type is unsigned char and the rest specs of the image are:
> Size : [1001, 1001, 8345]  (in voxels)
> Spacing : [0.012, 0.012, 0.012]  (in mm)
> Origin : [0, 0, 0]
> Direction :
> 1 0 0
> 0 1 0
> 0 0 1
>
> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea
> how it looks like. Indeed the object in the volume looks as it was
> expected. So far no problems. The specs of the image on Slicer are the same
> as above (except the direction which has flipped signs for the first two
> diagonal entries, as we know ).
>
> Then I tried to load the image in the memory using the
> itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After loading
> the image I noticed that there are pixels with zero values instead of
> non-zero by comparing the same indexes with the loaded image on Slicer.
>
> Then I decided to write the loaded image on the disk using the
> itk::ImageFileWriter.
>
> After opening the (written from ITK) image on Slicer I checked the specks
> and were the same with the original image as above. However I noticed that
> a big portion of the image is completely empty (black)!
>
> My workstation has enough memory to load the image (768 GB 1600MHz DDR3L)
> and is using Red Hat Enterprise Linux Server 6.5.
> The size of the original nifti volume is :
>
>    - 25.7 MB (.nii.gz)
>    - 8.36 GB (.nii)
>
> Has anybody experienced similar difficulties trying to load so big volume
> data?
>
> Best,
> Fotis Drakopoulos
> CRTC
>
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users
>
>
>  ------------------------------
>
> Spam
> <https://www.spamtrap.odu.edu/canit/b.php?i=01NjreqIw&m=3de3085bbaec&t=20141124&c=s>
> Not spam
> <https://www.spamtrap.odu.edu/canit/b.php?i=01NjreqIw&m=3de3085bbaec&t=20141124&c=n>
> Forget previous vote
> <https://www.spamtrap.odu.edu/canit/b.php?i=01NjreqIw&m=3de3085bbaec&t=20141124&c=f>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141125/6480b0fc/attachment.html>

From yxp233 at postech.ac.kr  Tue Nov 25 17:51:38 2014
From: yxp233 at postech.ac.kr (Xiaopeng Yang)
Date: Wed, 26 Nov 2014 07:51:38 +0900
Subject: [ITK-users] Compiling ITK with GPU ON
In-Reply-To: <1416946491553778.030297.ptmail03@ptmail03>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
 <1416946491553778.030297.ptmail03@ptmail03>
Message-ID: <033801d00902$5f3afbb0$1db0f310$@ac.kr>

Hi,

 

I am trying to compile ITK 4.6.1 with GPU ON, but I failed. Is there any tutorial or document about compiling ITK with GPU ON? I got warning messages as follows. And I ignored them and tried to build ITK but got error ?cannot find CL/opencl.h?.

 

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

 

Here is how I set up directories of OpenCL:

OPENCL_INCLUDE_DIRS  C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/include

OPENCL_LIBRARIES          C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib

 

Any help is appreciated!

 

Best regards,

Xiaopeng Yang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141126/b2b11ad5/attachment.html>

From michkapopoff at gmail.com  Tue Nov 25 18:14:52 2014
From: michkapopoff at gmail.com (michkapopoff at gmail.com)
Date: Wed, 26 Nov 2014 00:14:52 +0100
Subject: [ITK-users] Compiling ITK with GPU ON
In-Reply-To: <033801d00902$5f3afbb0$1db0f310$@ac.kr>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
 <1416946491553778.030297.ptmail03@ptmail03>
 <033801d00902$5f3afbb0$1db0f310$@ac.kr>
Message-ID: <9D9EF19C-229E-4898-A99F-70E051AFBA72@gmail.com>

Hi

I think OPENCL_LIBRARIES needs to be set to OpenCL.dll, which should be somewhere in this lib folder (/lib/x64/OpenCL.dll ?)
Could you try this ?

Michka

> On 25 Nov 2014, at 23:51, Xiaopeng Yang <yxp233 at postech.ac.kr> wrote:
> 
> Hi,
>  
> I am trying to compile ITK 4.6.1 with GPU ON, but I failed. Is there any tutorial or document about compiling ITK with GPU ON? I got warning messages as follows. And I ignored them and tried to build ITK but got error ?cannot find CL/opencl.h?.
>  
> WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.
> WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.
> WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.
> WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.
> WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.
>  
> Here is how I set up directories of OpenCL:
> OPENCL_INCLUDE_DIRS  C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/include
> OPENCL_LIBRARIES          C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib
>  
> Any help is appreciated!
>  
> Best regards,
> Xiaopeng Yang
> _____________________________________
> Powered by www.kitware.com <http://www.kitware.com/>
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.php <http://www.kitware.com/products/protraining.php>
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ <http://www.itk.org/Wiki/ITK_FAQ>
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-users <http://public.kitware.com/mailman/listinfo/insight-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141126/f01523cb/attachment.html>

From yxp233 at postech.ac.kr  Tue Nov 25 18:19:34 2014
From: yxp233 at postech.ac.kr (Xiaopeng Yang)
Date: Wed, 26 Nov 2014 08:19:34 +0900
Subject: [ITK-users] Compiling ITK with GPU ON
In-Reply-To: <1416957299141961.09157.ptmail03@ptmail03>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
 <1416946491553778.030297.ptmail03@ptmail03>
 <033801d00902$5f3afbb0$1db0f310$@ac.kr>
 <1416957299141961.09157.ptmail03@ptmail03>
Message-ID: <034601d00906$4626b520$d2741f60$@ac.kr>

Hi

 

Thank you very much. I will try it.

 

Best regards,

Xiaopeng

 

From: michkapopoff at gmail.com [mailto:michkapopoff at gmail.com] 
Sent: Wednesday, November 26, 2014 8:15 AM
To: Xiaopeng Yang
Cc: insight-users at itk.org
Subject: Re: [ITK-users] Compiling ITK with GPU ON

 

Hi

 

I think OPENCL_LIBRARIES needs to be set to OpenCL.dll, which should be somewhere in this lib folder (/lib/x64/OpenCL.dll ?)

Could you try this ?

 

Michka

 

On 25 Nov 2014, at 23:51, Xiaopeng Yang <yxp233 at postech.ac.kr> wrote:

 

Hi,

 

I am trying to compile ITK 4.6.1 with GPU ON, but I failed. Is there any tutorial or document about compiling ITK with GPU ON? I got warning messages as follows. And I ignored them and tried to build ITK but got error ?cannot find CL/opencl.h?.

 

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

WARNING: Target "ITKGPUCommon" requests linking to directory "C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib". Targets may link only to libraries. CMake is dropping the item.

 

Here is how I set up directories of OpenCL:

OPENCL_INCLUDE_DIRS  C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/include

OPENCL_LIBRARIES          C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v6.5/lib

 

Any help is appreciated!

 

Best regards,

Xiaopeng Yang

_____________________________________
Powered by  <http://www.kitware.com/> www.kitware.com

Visit other Kitware open-source projects at
 <http://www.kitware.com/opensource/opensource.html> http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
 <http://www.kitware.com/products/protraining.php> http://www.kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
 <http://www.itk.org/Wiki/ITK_FAQ> http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
 <http://public.kitware.com/mailman/listinfo/insight-users> http://public.kitware.com/mailman/listinfo/insight-users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141126/48f2586c/attachment.html>

From tonimuusimaki at gmail.com  Tue Nov 25 18:29:59 2014
From: tonimuusimaki at gmail.com (barbababa)
Date: Tue, 25 Nov 2014 16:29:59 -0700 (MST)
Subject: [ITK-users] pointer to the problem
Message-ID: <1416958199946-7586621.post@n2.nabble.com>



hi,

i am making a dynamic library to external program and previously with itk
3.2 this following code worked.
Now with itk 4.6 if i put 

		typedef itk::Image<float, 2> ImageType;
		typedef itk::DiscreteGaussianImageFilter<ImageType, ImageType > 
FilterType;

the external program starts fine and loads the dll. If I only add this line 

		FilterType::Pointer filter = FilterType::New();

Then the program says Specified module could not be found.

Any ideas? 

Thanks!

i am using now itk 4.6 with visual studio 2008 x64 release c++



--
View this message in context: http://itk-insight-users.2283740.n2.nabble.com/pointer-to-the-problem-tp7586621.html
Sent from the ITK Insight Users mailing list archive at Nabble.com.

From tejas.rox at gmail.com  Tue Nov 25 20:09:27 2014
From: tejas.rox at gmail.com (Tejas)
Date: Tue, 25 Nov 2014 18:09:27 -0700 (MST)
Subject: [ITK-users] ITK and VNL - SVD decomposition of image - Seg fault
In-Reply-To: <1416704671980-7586604.post@n2.nabble.com>
References: <1416704671980-7586604.post@n2.nabble.com>
Message-ID: <1416964167024-7586622.post@n2.nabble.com>

I have created a temporary solution to my problem by using the SVD routine
available in OpenCV. 
I did not have the OpenCV bridge module in ITK built, so I had to
incorporate the relevant header files (core.hpp, imgproc.hpp, gpu.hpp,
highgui.hpp etc.) into my project, and link to the appropriate
configuration-specific OpenCV libraries as well. After completing my image
analysis operation, I used the ITK import image filter to import my OpenCV
data back into ITK. 

My hope is that this fix will help someone in the future whenever they
stumble across the same problem I had faced while using vnl_svd. 

The code is as follows: 

        typedef itk::VariableSizeMatrix< double > MatrixType;         

        // create a matrix structure in ITK   
        MatrixType matrix; 
        matrix.SetSize(rows, cols);	// set the size of the ITK matrix 

	// create an image iterator
	IterType inputIter( dAlignedIm, dAlignedIm->GetLargestPossibleRegion() );
        inputIter.GoToBegin();

	// copy the BRATS image to openCV
	while(!inputIter.IsAtEnd()) {

		// copy the input image intensity value into the corresponding matrix
		matrix(inputIter.GetIndex()[1], inputIter.GetIndex()[0]) =
inputIter.Get();
		
		cv_brats.at<double>(inputIter.GetIndex()[1], inputIter.GetIndex()[0]) =
matrix(inputIter.GetIndex()[1], inputIter.GetIndex()[0]); 
		++inputIter;
	}

	Mat U, S, Vt; 
	
	// compute svd of Brats image 
	SVD::compute(cv_brats, S, U, Vt); 

        // .............
        // Do whatever you want with the singular values and orthonormal
matrices.
        // I used it for reconstruction, so I will get back an OpenCV mat
structure called 'reconstruct'. 

        // IMPORT OpenCV MAT INTO ITK 	

	ImportFilterType::Pointer importFilter = ImportFilterType::New();

	// set size of the image
	ImportFilterType::SizeType  size;
	size[0]  = reconstruct.cols;  // size along X
	size[1]  = reconstruct.rows;  // size along Y

	// set starting index of image - top left
	ImportFilterType::IndexType start;
	start.Fill( 0 );

	// set region of the image
	ImportFilterType::RegionType region;
	region.SetIndex( start );
	region.SetSize(  size  );
	
	importFilter->SetRegion( region );

	// set spacing of image
	double spacing[ Dimension ];
	spacing[0] = 1.0;    // along X direction
	spacing[1] = 1.0;    // along Y direction
	
	importFilter->SetSpacing( spacing );

	// set origin of output image
	double origin[ Dimension ];
	origin[0] = 0.0;    // X coordinate
	origin[1] = 0.0;    // Y coordinate

	importFilter->SetOrigin( origin );

	// allocate CPU image buffer after specifying size of image
	const unsigned int numberOfPixels =  size[0] * size[1];
	double * localBuffer = new double[ numberOfPixels ];

	// reconstruct.data is an (unsigned char*) type
	// reinterpret cast it into the (double*) type, which is used by the local
buffer
	localBuffer = reinterpret_cast<double *> (reconstruct.data);

	// now, import the local image data
	const bool importImageFilterWillOwnTheBuffer = false;
	importFilter->SetImportPointer( localBuffer, numberOfPixels,
importImageFilterWillOwnTheBuffer );

	// pass data from the imported image to the new ITK image
	doubleImageType::Pointer newIm = importFilter->GetOutput();      





--
View this message in context: http://itk-insight-users.2283740.n2.nabble.com/ITK-and-VNL-SVD-decomposition-of-image-Seg-fault-tp7586604p7586622.html
Sent from the ITK Insight Users mailing list archive at Nabble.com.

From yxp233 at postech.ac.kr  Tue Nov 25 22:03:49 2014
From: yxp233 at postech.ac.kr (Xiaopeng Yang)
Date: Wed, 26 Nov 2014 12:03:49 +0900
Subject: [ITK-users] GPU Implementation
In-Reply-To: <1405533203306221.02118.ptmail04@ptmail04>
References: <1405441657014-7585907.post@n2.nabble.com>
 <4C3F118B-E049-4168-9542-FC8D288FC38E@mail.nih.gov>
 <1405533203306221.02118.ptmail04@ptmail04>
Message-ID: <035401d00925$9a422350$cec669f0$@ac.kr>

Hi Michael,

I also had the same errors while building my GPU registration program. Have
you solved the problems? I guess the error was caused by improper setting in
CMakeLists.txt file, but I could not find any CMakeLists.txt sample
regarding GPU implementation in ITK. I doubt whether there are users using
this GPU module or not.

Best regards,
Xiaopeng Yang


This is the question you raised:

I am trying to implement the GPU demons registration algorithm, but I have
been having difficulty getting the program to compile.  I believe the errors
are because it cannot find the OpenCL library correctly, but I'm not sure
how to fix it. 

I am using a NVIDIA Quadro FX 570 and am currently using OpenCL through the
CUDA Computing Toolkit 4.2.  My cmake file is attached, but I have had to
manually enter in the directory locations to CMake because I have not been
able to find a FindOpenCL.cmake file that works correctly.  My operating
system is Windows 7 x64. 

I am able to compile ITK after generating it in CMake with manually linked
directories and Itk_Use_Gpu checked, but I have not been able to compile my
program without getting errors, which are listed at the bottom. 

Does anyone have suggestions as to how to fix this? 

Best regards, 
Michael Pinkert 

2>registrationFunctions.obj : error LNK2019: unresolved external symbol
"public: static char const * __cdecl
itk::GPUPDEDeformableRegistrationFilterKernel::GetOpenCLSource(void)"
(?GetOpenCLSource at GPUPDEDeformableRegistrationFilterKernel@itk@@SAPEBDXZ)
referenced in function "public: static char const * __cdecl
itk::GPUPDEDeformableRegistrationFilter<class itk::GPUImage<float,3>,class
itk::GPUImage<float,3>,class itk::GPUImage<class
itk::Vector<float,3>,3>,class itk::DemonsRegistrationFilter<class
itk::GPUImage<float,3>,class itk::GPUImage<float,3>,class
itk::GPUImage<class itk::Vector<float,3>,3> > >::GetOpenCLSource(void)"
(?GetOpenCLSource@?$GPUPDEDeformableRegistrationFilter at V?$GPUImage at M$02 at itk@
@V12 at V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@V?$DemonsRegistrationFilter at V?$GP
UImage at M$02 at itk@@V12 at V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@@2@@itk@@SAPEBDXZ
) 

2>registrationFunctions.obj : error LNK2019: unresolved external symbol
"public: static char const * __cdecl
itk::GPUDemonsRegistrationFunctionKernel::GetOpenCLSource(void)"
(?GetOpenCLSource at GPUDemonsRegistrationFunctionKernel@itk@@SAPEBDXZ)
referenced in function "public: static char const * __cdecl
itk::GPUDemonsRegistrationFunction<class itk::GPUImage<float,3>,class
itk::GPUImage<float,3>,classitk::GPUImage<class itk::Vector<float,3>,3>
>::GetOpenCLSource(void)"
(?GetOpenCLSource@?$GPUDemonsRegistrationFunction at V?$GPUImage at M$02 at itk@@V12@
V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@@itk@@SAPEBDXZ)





From matt.mccormick at kitware.com  Tue Nov 25 22:44:18 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 25 Nov 2014 22:44:18 -0500
Subject: [ITK-users] [ITK-dev]  Problem reading a big nifti volume.
In-Reply-To: <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
 <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>
Message-ID: <CALzTN-RPtGjgVY=NPgQOE0tVj5hvP9EQRWFkwdJzBvo64_vyKA@mail.gmail.com>

Hi Fotis,

Thanks for helping to improve large nifti file support.

The file can be uploaded on midas3.kitware.com.  Sign up for the ITK
community [1], let the list know the name of your account, and myself
or one of the other administrators will add upload priviledges to the
account.

The file could then be added to ITK/Public/ITK/Modules/IO/NIFTI/test/Input.

Thanks,
Matt

[1] http://midas3.kitware.com/midas/community/12

On Tue, Nov 25, 2014 at 3:14 PM, Fotis Drakopoulos <fdrakopo at gmail.com> wrote:
> Hi all,
>
> I created a test nifti image that reproduces the problem I mentioned before.
> How can I share this image with the ITK community?
>
> Best,
> Fotis Drakopoulos
>
>
> On Mon, Nov 24, 2014 at 10:13 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
> wrote:
>>
>> Shareable test data greatly helps determine the cause and fix these types
>> of issues.
>>
>> Got data?
>>
>> Brad
>> On Nov 23, 2014, at 5:40 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
>>
>> This is reminiscent of the previous problem with big TIFF images, now
>> fixed.
>>
>> Gib
>> ________________________________
>> From: Insight-users [insight-users-bounces at itk.org] on behalf of Fotis
>> Drakopoulos [fdrakopo at gmail.com]
>> Sent: Monday, 24 November 2014 10:51 a.m.
>> To: insight-users at itk.org; insight-developers at itk.org
>> Subject: [ITK-users] Problem reading a big nifti volume.
>>
>> Hi all,
>>
>> For the last couple of days I have been trying reading (unsuccessfully)  a
>> big nifti volume labeled image from my disk.
>>
>> The pixel type is unsigned char and the rest specs of the image are:
>> Size : [1001, 1001, 8345]  (in voxels)
>> Spacing : [0.012, 0.012, 0.012]  (in mm)
>> Origin : [0, 0, 0]
>> Direction :
>> 1 0 0
>> 0 1 0
>> 0 0 1
>>
>> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea
>> how it looks like. Indeed the object in the volume looks as it was expected.
>> So far no problems. The specs of the image on Slicer are the same as above
>> (except the direction which has flipped signs for the first two diagonal
>> entries, as we know ).
>>
>> Then I tried to load the image in the memory using the
>> itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After loading
>> the image I noticed that there are pixels with zero values instead of
>> non-zero by comparing the same indexes with the loaded image on Slicer.
>>
>> Then I decided to write the loaded image on the disk using the
>> itk::ImageFileWriter.
>>
>> After opening the (written from ITK) image on Slicer I checked the specks
>> and were the same with the original image as above. However I noticed that a
>> big portion of the image is completely empty (black)!
>>
>> My workstation has enough memory to load the image (768 GB 1600MHz DDR3L)
>> and is using Red Hat Enterprise Linux Server 6.5.
>> The size of the original nifti volume is :
>>
>> 25.7 MB (.nii.gz)
>> 8.36 GB (.nii)
>>
>> Has anybody experienced similar difficulties trying to load so big volume
>> data?
>>
>> Best,
>> Fotis Drakopoulos
>> CRTC
>>
>> _____________________________________
>> 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.php
>>
>> 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://public.kitware.com/mailman/listinfo/insight-users
>>
>>
>> ________________________________
>>
>> Spam
>> Not spam
>> Forget previous vote
>
>
>
> _______________________________________________
> 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://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>

From millerjv at gmail.com  Wed Nov 26 07:10:15 2014
From: millerjv at gmail.com (Jim Miller)
Date: Wed, 26 Nov 2014 07:10:15 -0500
Subject: [ITK-users] GPU Implementation
In-Reply-To: <035401d00925$9a422350$cec669f0$@ac.kr>
References: <1405441657014-7585907.post@n2.nabble.com>
 <4C3F118B-E049-4168-9542-FC8D288FC38E@mail.nih.gov>
 <1405533203306221.02118.ptmail04@ptmail04>
 <035401d00925$9a422350$cec669f0$@ac.kr>
Message-ID: <D5BA015B-321F-4B08-ACC5-5F11DEADD8FE@gmail.com>

This doesn't look like any issue with finding OpenCL. The link error is saying it cannot find the implementation of an ITK method. 

I think  GPUPDEDeformableRegistrationFilterKernel::GetOpenCLSource(void) is supposed to return the kernel's implementation (probably as a string containing the OpenCL code). 

Is there a txx file that is not being included? Does your program contain the same headers and test?

(I guess the error could occur if OpenCL was not found if the implementation of this method in  GPUPDEDeformableRegistrationFilterKernel is within #ifdef/#endif on OpenCL.)

Jim

> On Nov 25, 2014, at 10:03 PM, Xiaopeng Yang <yxp233 at postech.ac.kr> wrote:
> 
> Hi Michael,
> 
> I also had the same errors while building my GPU registration program. Have
> you solved the problems? I guess the error was caused by improper setting in
> CMakeLists.txt file, but I could not find any CMakeLists.txt sample
> regarding GPU implementation in ITK. I doubt whether there are users using
> this GPU module or not.
> 
> Best regards,
> Xiaopeng Yang
> 
> 
> This is the question you raised:
> 
> I am trying to implement the GPU demons registration algorithm, but I have
> been having difficulty getting the program to compile.  I believe the errors
> are because it cannot find the OpenCL library correctly, but I'm not sure
> how to fix it. 
> 
> I am using a NVIDIA Quadro FX 570 and am currently using OpenCL through the
> CUDA Computing Toolkit 4.2.  My cmake file is attached, but I have had to
> manually enter in the directory locations to CMake because I have not been
> able to find a FindOpenCL.cmake file that works correctly.  My operating
> system is Windows 7 x64. 
> 
> I am able to compile ITK after generating it in CMake with manually linked
> directories and Itk_Use_Gpu checked, but I have not been able to compile my
> program without getting errors, which are listed at the bottom. 
> 
> Does anyone have suggestions as to how to fix this? 
> 
> Best regards, 
> Michael Pinkert 
> 
> 2>registrationFunctions.obj : error LNK2019: unresolved external symbol
> "public: static char const * __cdecl
> itk::GPUPDEDeformableRegistrationFilterKernel::GetOpenCLSource(void)"
> (?GetOpenCLSource at GPUPDEDeformableRegistrationFilterKernel@itk@@SAPEBDXZ)
> referenced in function "public: static char const * __cdecl
> itk::GPUPDEDeformableRegistrationFilter<class itk::GPUImage<float,3>,class
> itk::GPUImage<float,3>,class itk::GPUImage<class
> itk::Vector<float,3>,3>,class itk::DemonsRegistrationFilter<class
> itk::GPUImage<float,3>,class itk::GPUImage<float,3>,class
> itk::GPUImage<class itk::Vector<float,3>,3> > >::GetOpenCLSource(void)"
> (?GetOpenCLSource@?$GPUPDEDeformableRegistrationFilter at V?$GPUImage at M$02 at itk@
> @V12 at V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@V?$DemonsRegistrationFilter at V?$GP
> UImage at M$02 at itk@@V12 at V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@@2@@itk@@SAPEBDXZ
> ) 
> 
> 2>registrationFunctions.obj : error LNK2019: unresolved external symbol
> "public: static char const * __cdecl
> itk::GPUDemonsRegistrationFunctionKernel::GetOpenCLSource(void)"
> (?GetOpenCLSource at GPUDemonsRegistrationFunctionKernel@itk@@SAPEBDXZ)
> referenced in function "public: static char const * __cdecl
> itk::GPUDemonsRegistrationFunction<class itk::GPUImage<float,3>,class
> itk::GPUImage<float,3>,classitk::GPUImage<class itk::Vector<float,3>,3>
>> ::GetOpenCLSource(void)"
> (?GetOpenCLSource@?$GPUDemonsRegistrationFunction at V?$GPUImage at M$02 at itk@@V12@
> V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@@itk@@SAPEBDXZ)
> 
> 
> 
> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

From yxp233 at postech.ac.kr  Wed Nov 26 07:33:56 2014
From: yxp233 at postech.ac.kr (Xiaopeng Yang)
Date: Wed, 26 Nov 2014 21:33:56 +0900
Subject: [ITK-users] GPU Implementation
In-Reply-To: <1417003820802645.09215.ptmail03@ptmail03>
References: <1405441657014-7585907.post@n2.nabble.com>
 <4C3F118B-E049-4168-9542-FC8D288FC38E@mail.nih.gov>
 <1405533203306221.02118.ptmail04@ptmail04>
 <035401d00925$9a422350$cec669f0$@ac.kr>
 <1417003820802645.09215.ptmail03@ptmail03>
Message-ID: <039601d00975$3f03c660$bd0b5320$@ac.kr>

Hi,

I tried to compile the code from Modules\Registration\GPUPDEDeformable\test
folder. Enclosed please find the code and CMakeLists file. I am quite new to
GPU, sorry I could not understand your explanation. Could you point out what
I missed please?

Thanks,
Xiaopeng

-----Original Message-----
From: Jim Miller [mailto:millerjv at gmail.com] 
Sent: Wednesday, November 26, 2014 9:10 PM
To: Xiaopeng Yang
Cc: Michael Pinkert; insight-users at itk.org
Subject: Re: [ITK-users] GPU Implementation

This doesn't look like any issue with finding OpenCL. The link error is
saying it cannot find the implementation of an ITK method. 

I think  GPUPDEDeformableRegistrationFilterKernel::GetOpenCLSource(void) is
supposed to return the kernel's implementation (probably as a string
containing the OpenCL code). 

Is there a txx file that is not being included? Does your program contain
the same headers and test?

(I guess the error could occur if OpenCL was not found if the implementation
of this method in  GPUPDEDeformableRegistrationFilterKernel is within
#ifdef/#endif on OpenCL.)

Jim

> On Nov 25, 2014, at 10:03 PM, Xiaopeng Yang <yxp233 at postech.ac.kr> wrote:
> 
> Hi Michael,
> 
> I also had the same errors while building my GPU registration program. 
> Have you solved the problems? I guess the error was caused by improper 
> setting in CMakeLists.txt file, but I could not find any 
> CMakeLists.txt sample regarding GPU implementation in ITK. I doubt 
> whether there are users using this GPU module or not.
> 
> Best regards,
> Xiaopeng Yang
> 
> 
> This is the question you raised:
> 
> I am trying to implement the GPU demons registration algorithm, but I 
> have been having difficulty getting the program to compile.  I believe 
> the errors are because it cannot find the OpenCL library correctly, 
> but I'm not sure how to fix it.
> 
> I am using a NVIDIA Quadro FX 570 and am currently using OpenCL 
> through the CUDA Computing Toolkit 4.2.  My cmake file is attached, 
> but I have had to manually enter in the directory locations to CMake 
> because I have not been able to find a FindOpenCL.cmake file that 
> works correctly.  My operating system is Windows 7 x64.
> 
> I am able to compile ITK after generating it in CMake with manually 
> linked directories and Itk_Use_Gpu checked, but I have not been able 
> to compile my program without getting errors, which are listed at the
bottom.
> 
> Does anyone have suggestions as to how to fix this? 
> 
> Best regards,
> Michael Pinkert
> 
> 2>registrationFunctions.obj : error LNK2019: unresolved external 
> 2>symbol
> "public: static char const * __cdecl
> itk::GPUPDEDeformableRegistrationFilterKernel::GetOpenCLSource(void)"
> (?GetOpenCLSource at GPUPDEDeformableRegistrationFilterKernel@itk@@SAPEBD
> XZ) referenced in function "public: static char const * __cdecl 
> itk::GPUPDEDeformableRegistrationFilter<class 
> itk::GPUImage<float,3>,class itk::GPUImage<float,3>,class 
> itk::GPUImage<class itk::Vector<float,3>,3>,class 
> itk::DemonsRegistrationFilter<class
> itk::GPUImage<float,3>,class itk::GPUImage<float,3>,class 
> itk::GPUImage<class itk::Vector<float,3>,3> > >::GetOpenCLSource(void)"
> (?GetOpenCLSource@?$GPUPDEDeformableRegistrationFilter at V?$GPUImage at M$0
> 2 at itk@ 
> @V12 at V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@V?$DemonsRegistrationFilter
> @V?$GP 
> UImage at M$02 at itk@@V12 at V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@@2@@itk@@SA
> PEBDXZ
> )
> 
> 2>registrationFunctions.obj : error LNK2019: unresolved external 
> 2>symbol
> "public: static char const * __cdecl
> itk::GPUDemonsRegistrationFunctionKernel::GetOpenCLSource(void)"
> (?GetOpenCLSource at GPUDemonsRegistrationFunctionKernel@itk@@SAPEBDXZ)
> referenced in function "public: static char const * __cdecl 
> itk::GPUDemonsRegistrationFunction<class itk::GPUImage<float,3>,class 
> itk::GPUImage<float,3>,classitk::GPUImage<class 
> itk::Vector<float,3>,3>
>> ::GetOpenCLSource(void)"
> (?GetOpenCLSource@?$GPUDemonsRegistrationFunction at V?$GPUImage at M$02 at itk
> @@V12@
> V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@@itk@@SAPEBDXZ)
> 
> 
> 
> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141126/81872eb6/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: itkGPUDemonsRegistrationFilterTest.cxx
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141126/81872eb6/attachment-0001.ksh>

From fdrakopo at gmail.com  Wed Nov 26 09:21:32 2014
From: fdrakopo at gmail.com (Fotis Drakopoulos)
Date: Wed, 26 Nov 2014 09:21:32 -0500
Subject: [ITK-users] [ITK-dev]  Problem reading a big nifti volume.
In-Reply-To: <CALzTN-RPtGjgVY=NPgQOE0tVj5hvP9EQRWFkwdJzBvo64_vyKA@mail.gmail.com>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
 <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>
 <CALzTN-RPtGjgVY=NPgQOE0tVj5hvP9EQRWFkwdJzBvo64_vyKA@mail.gmail.com>
Message-ID: <CAG6AjRP9KTRsNgOgDifr33MKvQN7SuuR-XR1r3pWcnwSW_6rcw@mail.gmail.com>

Hi,
I signed up for the ITK community on midas.

Thanks,
Fotis Drakopoulos

On Tue, Nov 25, 2014 at 10:44 PM, Matt McCormick <matt.mccormick at kitware.com
> wrote:

> Hi Fotis,
>
> Thanks for helping to improve large nifti file support.
>
> The file can be uploaded on midas3.kitware.com.  Sign up for the ITK
> community [1], let the list know the name of your account, and myself
> or one of the other administrators will add upload priviledges to the
> account.
>
> The file could then be added to ITK/Public/ITK/Modules/IO/NIFTI/test/Input.
>
> Thanks,
> Matt
>
> [1] http://midas3.kitware.com/midas/community/12
>
> On Tue, Nov 25, 2014 at 3:14 PM, Fotis Drakopoulos <fdrakopo at gmail.com>
> wrote:
> > Hi all,
> >
> > I created a test nifti image that reproduces the problem I mentioned
> before.
> > How can I share this image with the ITK community?
> >
> > Best,
> > Fotis Drakopoulos
> >
> >
> > On Mon, Nov 24, 2014 at 10:13 AM, Bradley Lowekamp <
> blowekamp at mail.nih.gov>
> > wrote:
> >>
> >> Shareable test data greatly helps determine the cause and fix these
> types
> >> of issues.
> >>
> >> Got data?
> >>
> >> Brad
> >> On Nov 23, 2014, at 5:40 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
> >>
> >> This is reminiscent of the previous problem with big TIFF images, now
> >> fixed.
> >>
> >> Gib
> >> ________________________________
> >> From: Insight-users [insight-users-bounces at itk.org] on behalf of Fotis
> >> Drakopoulos [fdrakopo at gmail.com]
> >> Sent: Monday, 24 November 2014 10:51 a.m.
> >> To: insight-users at itk.org; insight-developers at itk.org
> >> Subject: [ITK-users] Problem reading a big nifti volume.
> >>
> >> Hi all,
> >>
> >> For the last couple of days I have been trying reading
> (unsuccessfully)  a
> >> big nifti volume labeled image from my disk.
> >>
> >> The pixel type is unsigned char and the rest specs of the image are:
> >> Size : [1001, 1001, 8345]  (in voxels)
> >> Spacing : [0.012, 0.012, 0.012]  (in mm)
> >> Origin : [0, 0, 0]
> >> Direction :
> >> 1 0 0
> >> 0 1 0
> >> 0 0 1
> >>
> >> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea
> >> how it looks like. Indeed the object in the volume looks as it was
> expected.
> >> So far no problems. The specs of the image on Slicer are the same as
> above
> >> (except the direction which has flipped signs for the first two diagonal
> >> entries, as we know ).
> >>
> >> Then I tried to load the image in the memory using the
> >> itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After
> loading
> >> the image I noticed that there are pixels with zero values instead of
> >> non-zero by comparing the same indexes with the loaded image on Slicer.
> >>
> >> Then I decided to write the loaded image on the disk using the
> >> itk::ImageFileWriter.
> >>
> >> After opening the (written from ITK) image on Slicer I checked the
> specks
> >> and were the same with the original image as above. However I noticed
> that a
> >> big portion of the image is completely empty (black)!
> >>
> >> My workstation has enough memory to load the image (768 GB 1600MHz
> DDR3L)
> >> and is using Red Hat Enterprise Linux Server 6.5.
> >> The size of the original nifti volume is :
> >>
> >> 25.7 MB (.nii.gz)
> >> 8.36 GB (.nii)
> >>
> >> Has anybody experienced similar difficulties trying to load so big
> volume
> >> data?
> >>
> >> Best,
> >> Fotis Drakopoulos
> >> CRTC
> >>
> >> _____________________________________
> >> 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.php
> >>
> >> 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://public.kitware.com/mailman/listinfo/insight-users
> >>
> >>
> >> ________________________________
> >>
> >> Spam
> >> Not spam
> >> Forget previous vote
> >
> >
> >
> > _______________________________________________
> > 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://kitware.com/products/protraining.php
> >
> > 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://public.kitware.com/mailman/listinfo/insight-developers
> >
>
>
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
>
> Teach CanIt if this mail (ID 03Nk3J6v4) is spam:
> Spam:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=s
> Not spam:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=n
> Forget vote:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=f
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141126/e4896ead/attachment.html>

From tonimuusimaki at gmail.com  Wed Nov 26 11:25:36 2014
From: tonimuusimaki at gmail.com (barbababa)
Date: Wed, 26 Nov 2014 09:25:36 -0700 (MST)
Subject: [ITK-users] pointer to the problem
In-Reply-To: <1416958199946-7586621.post@n2.nabble.com>
References: <1416958199946-7586621.post@n2.nabble.com>
Message-ID: <1417019136424-7586628.post@n2.nabble.com>


don?t know if it is related but i tried to build the
discretegaussianimagefilter-example, which built
nicely. However when running the .exe file a window
appears saying:

ITKIOHDF5-4.6.dll is missing

Did I miss something in the cmake step?

Cheers and thanks for any help!





--
View this message in context: http://itk-insight-users.2283740.n2.nabble.com/pointer-to-the-problem-tp7586621p7586628.html
Sent from the ITK Insight Users mailing list archive at Nabble.com.

From matimontg at gmail.com  Wed Nov 26 18:05:37 2014
From: matimontg at gmail.com (Matias Montroull)
Date: Wed, 26 Nov 2014 20:05:37 -0300
Subject: [ITK-users] Get RescaleIntercept
In-Reply-To: <CALzTN-SCdMkawebyjn6K3fWg2AXVq6hYbMkMSdZ83VqBUVGr=g@mail.gmail.com>
References: <CAKKNfuKsDdhr292znccRZSrSv6SkVPnfEA9xeZfE58HDWeURqg@mail.gmail.com>
 <CALzTN-SCdMkawebyjn6K3fWg2AXVq6hYbMkMSdZ83VqBUVGr=g@mail.gmail.com>
Message-ID: <CAKKNfuKynOEk_uAkqbQ7q7YOG=-OHCsdaD9OHKZRieqsnLTE+w@mail.gmail.com>

Thanks Matt, that worked!

On Mon, Nov 24, 2014 at 10:47 PM, Matt McCormick <matt.mccormick at kitware.com
> wrote:

> Hi Matias,
>
>   reader->UpdateOutputInformation();
>
> must be called for gdcmImageIO to parse the tags.
>
> HTH,
> Matt
>
>
> On Mon, Nov 24, 2014 at 7:31 PM, Matias Montroull <matimontg at gmail.com>
> wrote:
> > Hi,
> >
> > I'm struggling with code I did to get the RescaleIntercept of an image.
> >
> > It's simple as this:
> >
> > typedef itk::GDCMImageIO ImageIOTypeGDCM;
> > ImageIOTypeGDCM::Pointer gdcmImageIO = ImageIOTypeGDCM::New();
> > reader->SetImageIO( gdcmImageIO );
> >
> > double intercept = gdcmImageIO->GetRescaleIntercept();
> > std::cout << "Rescale Intercept value: " << intercept << std::endl;
> >
> > Now, the last line returns "0" and actually the tag (0028|1052) reads
> > "-1000"
> >
> > Is there any issues with the code or something I missed?
> >
> > _____________________________________
> > 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.php
> >
> > 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://public.kitware.com/mailman/listinfo/insight-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141126/2fc30a22/attachment.html>

From matt.mccormick at kitware.com  Wed Nov 26 20:41:39 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 26 Nov 2014 20:41:39 -0500
Subject: [ITK-users] [ITK-dev]  Problem reading a big nifti volume.
In-Reply-To: <CAG6AjRP9KTRsNgOgDifr33MKvQN7SuuR-XR1r3pWcnwSW_6rcw@mail.gmail.com>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
 <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>
 <CALzTN-RPtGjgVY=NPgQOE0tVj5hvP9EQRWFkwdJzBvo64_vyKA@mail.gmail.com>
 <CAG6AjRP9KTRsNgOgDifr33MKvQN7SuuR-XR1r3pWcnwSW_6rcw@mail.gmail.com>
Message-ID: <CALzTN-RNFaynep_vAhDu2NwNUsuo696SErYZYGn7bGOpaE3kVQ@mail.gmail.com>

Thanks! Added.

On Wed, Nov 26, 2014 at 9:21 AM, Fotis Drakopoulos <fdrakopo at gmail.com> wrote:
> Hi,
> I signed up for the ITK community on midas.
>
> Thanks,
> Fotis Drakopoulos
>
> On Tue, Nov 25, 2014 at 10:44 PM, Matt McCormick
> <matt.mccormick at kitware.com> wrote:
>>
>> Hi Fotis,
>>
>> Thanks for helping to improve large nifti file support.
>>
>> The file can be uploaded on midas3.kitware.com.  Sign up for the ITK
>> community [1], let the list know the name of your account, and myself
>> or one of the other administrators will add upload priviledges to the
>> account.
>>
>> The file could then be added to
>> ITK/Public/ITK/Modules/IO/NIFTI/test/Input.
>>
>> Thanks,
>> Matt
>>
>> [1] http://midas3.kitware.com/midas/community/12
>>
>> On Tue, Nov 25, 2014 at 3:14 PM, Fotis Drakopoulos <fdrakopo at gmail.com>
>> wrote:
>> > Hi all,
>> >
>> > I created a test nifti image that reproduces the problem I mentioned
>> > before.
>> > How can I share this image with the ITK community?
>> >
>> > Best,
>> > Fotis Drakopoulos
>> >
>> >
>> > On Mon, Nov 24, 2014 at 10:13 AM, Bradley Lowekamp
>> > <blowekamp at mail.nih.gov>
>> > wrote:
>> >>
>> >> Shareable test data greatly helps determine the cause and fix these
>> >> types
>> >> of issues.
>> >>
>> >> Got data?
>> >>
>> >> Brad
>> >> On Nov 23, 2014, at 5:40 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
>> >>
>> >> This is reminiscent of the previous problem with big TIFF images, now
>> >> fixed.
>> >>
>> >> Gib
>> >> ________________________________
>> >> From: Insight-users [insight-users-bounces at itk.org] on behalf of Fotis
>> >> Drakopoulos [fdrakopo at gmail.com]
>> >> Sent: Monday, 24 November 2014 10:51 a.m.
>> >> To: insight-users at itk.org; insight-developers at itk.org
>> >> Subject: [ITK-users] Problem reading a big nifti volume.
>> >>
>> >> Hi all,
>> >>
>> >> For the last couple of days I have been trying reading (unsuccessfully)
>> >> a
>> >> big nifti volume labeled image from my disk.
>> >>
>> >> The pixel type is unsigned char and the rest specs of the image are:
>> >> Size : [1001, 1001, 8345]  (in voxels)
>> >> Spacing : [0.012, 0.012, 0.012]  (in mm)
>> >> Origin : [0, 0, 0]
>> >> Direction :
>> >> 1 0 0
>> >> 0 1 0
>> >> 0 0 1
>> >>
>> >> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea
>> >> how it looks like. Indeed the object in the volume looks as it was
>> >> expected.
>> >> So far no problems. The specs of the image on Slicer are the same as
>> >> above
>> >> (except the direction which has flipped signs for the first two
>> >> diagonal
>> >> entries, as we know ).
>> >>
>> >> Then I tried to load the image in the memory using the
>> >> itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After
>> >> loading
>> >> the image I noticed that there are pixels with zero values instead of
>> >> non-zero by comparing the same indexes with the loaded image on Slicer.
>> >>
>> >> Then I decided to write the loaded image on the disk using the
>> >> itk::ImageFileWriter.
>> >>
>> >> After opening the (written from ITK) image on Slicer I checked the
>> >> specks
>> >> and were the same with the original image as above. However I noticed
>> >> that a
>> >> big portion of the image is completely empty (black)!
>> >>
>> >> My workstation has enough memory to load the image (768 GB 1600MHz
>> >> DDR3L)
>> >> and is using Red Hat Enterprise Linux Server 6.5.
>> >> The size of the original nifti volume is :
>> >>
>> >> 25.7 MB (.nii.gz)
>> >> 8.36 GB (.nii)
>> >>
>> >> Has anybody experienced similar difficulties trying to load so big
>> >> volume
>> >> data?
>> >>
>> >> Best,
>> >> Fotis Drakopoulos
>> >> CRTC
>> >>
>> >> _____________________________________
>> >> 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.php
>> >>
>> >> 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://public.kitware.com/mailman/listinfo/insight-users
>> >>
>> >>
>> >> ________________________________
>> >>
>> >> Spam
>> >> Not spam
>> >> Forget previous vote
>> >
>> >
>> >
>> > _______________________________________________
>> > 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://kitware.com/products/protraining.php
>> >
>> > 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://public.kitware.com/mailman/listinfo/insight-developers
>> >
>>
>>
>> --
>> BEGIN-ANTISPAM-VOTING-LINKS
>> ------------------------------------------------------
>>
>> Teach CanIt if this mail (ID 03Nk3J6v4) is spam:
>> Spam:
>> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=s
>> Not spam:
>> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=n
>> Forget vote:
>> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=f
>> ------------------------------------------------------
>> END-ANTISPAM-VOTING-LINKS
>>
>

From matt.mccormick at kitware.com  Wed Nov 26 20:43:42 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 26 Nov 2014 20:43:42 -0500
Subject: [ITK-users] pointer to the problem
In-Reply-To: <1417019136424-7586628.post@n2.nabble.com>
References: <1416958199946-7586621.post@n2.nabble.com>
 <1417019136424-7586628.post@n2.nabble.com>
Message-ID: <CALzTN-ScrFUUMHLTWpmT8QXSbaoAKapSWdO6d_G6n3ehjWy_tw@mail.gmail.com>

Hi,

It is best to run your application from the command line to see any errors.

If it says that ITKIOHDF5-4.6.dll is missing, was it verified that
this file is available?

HTH,
Matt

On Wed, Nov 26, 2014 at 11:25 AM, barbababa <tonimuusimaki at gmail.com> wrote:
>
> don?t know if it is related but i tried to build the
> discretegaussianimagefilter-example, which built
> nicely. However when running the .exe file a window
> appears saying:
>
> ITKIOHDF5-4.6.dll is missing
>
> Did I miss something in the cmake step?
>
> Cheers and thanks for any help!
>
>
>
>
>
> --
> View this message in context: http://itk-insight-users.2283740.n2.nabble.com/pointer-to-the-problem-tp7586621p7586628.html
> Sent from the ITK Insight Users mailing list archive at Nabble.com.
> _____________________________________
> 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.php
>
> 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://public.kitware.com/mailman/listinfo/insight-users

From indianzeppelin at gmail.com  Thu Nov 27 06:24:16 2014
From: indianzeppelin at gmail.com (Girish Mallya Udupi)
Date: Thu, 27 Nov 2014 11:24:16 +0000
Subject: [ITK-users] [ITK] Otsu Filter for object/background separation
In-Reply-To: <CADiSopNjfyS9VY1=TqWzes6oG_47KmBRWZr_uV3j8uVF38i=7w@mail.gmail.com>
References: <CADiSopNLpxu4V+W+fbMz_+Wfet3qv_GvekS+9nK46TLMd8GiAA@mail.gmail.com>
 <CAA+VR6isWQDHzOj--n0f2iPiceg+1EbBjBPXc+p7us+ZWStejQ@mail.gmail.com>
 <CADiSopNjfyS9VY1=TqWzes6oG_47KmBRWZr_uV3j8uVF38i=7w@mail.gmail.com>
Message-ID: <CAA+VR6h0stH=Ut=QEJsq7VR29G_E7Jpd+hznDq9nBrEnSqi+ag@mail.gmail.com>

Not that I'm aware of, but experienced users could direct you to it if
there is one.

You could check the number of local maxima in the histogram, and run OTSU
only if there are two. To find the local maxima, try the following steps.

a) Get the histogram of the image [1].
b) Convert the histogram to a 1D-image [2].
c) Find the local maxima [3] and perform the check.

However, in practice, the histogram might be really noisy and might require
some smoothing before you find the local maxima (before step (c)). See [4].

A better way might be to find the maxima of the kernel density estimate of
the histogram, but I am not sure how to do this in ITK.

[1]
http://www.itk.org/Doxygen/html/classitk_1_1Statistics_1_1ImageToHistogramFilter.html
[2] http://www.itk.org/Doxygen/html/classitk_1_1HistogramToImageFilter.html
[3]
http://www.itk.org/Doxygen/html/classitk_1_1RegionalMaximaImageFilter.html
[4] http://public.kitware.com/pipermail/insight-users/2009-July/031433.html


On Tue, Nov 25, 2014 at 9:37 AM, Zein Salah <zeinsalah at gmail.com> wrote:

> well. is there a ready-made filter /function to automatically check if
> the image has a bi-modal histogram?
>
> On Wed, Nov 12, 2014 at 2:14 PM, Girish Mallya Udupi
> <indianzeppelin at gmail.com> wrote:
> > Hi Zein,
> >
> > As you might know, Otsu's method assumes that the histogram of the image
> is
> > bi-modal. i.e., there are two classes of pixels forming two peaks
> separated
> > by a valley.
> > All the method (and the corresponding ITK filter) does is calculate the
> > threshold which maximizes the inter-class variance and apply it on the
> > image.
> >
> >
> > On Wed, Nov 12, 2014 at 12:43 PM, Zein Salah <zeinsalah at gmail.com>
> wrote:
> >>
> >> Hello,
> >>
> >> I have been using the otsu filter for doing object-from-background
> >> separation. However, I noticed that the filter always comes out with an
> >> separation threshold, even if the image does NOT actually have a
> >> "reasonable" background, see the attached image, e.g..
> >>
> >> My question is: is it possible to control the filter in such a way that
> it
> >> only generate a threshold if there is really a background?
> >>
> >> Practically, I could, in a post-processing step,  do a decision weather
> >> the separation is feasible or not, e.g. computing the comparing the
> >> statistics of the two separated areas (average intensity, variance,
> etc.).
> >> But I thought the otsu filter already does such things internally,
> right? Is
> >> it possible to inquire such data from the filter?
> >>
> >> Any ideas would be welcome!!
> >>
> >> Much thanks,
> >>
> >> Zein
> >>
> >>
> >> _______________________________________________
> >> Community mailing list
> >> Community at itk.org
> >> http://public.kitware.com/mailman/listinfo/community
> >>
> >
> >
> >
> > --
> > Regards,
> > Girish
>



-- 
Regards,
Girish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141127/53e333f1/attachment.html>

From yxp233 at postech.ac.kr  Thu Nov 27 07:34:27 2014
From: yxp233 at postech.ac.kr (Xiaopeng Yang)
Date: Thu, 27 Nov 2014 21:34:27 +0900
Subject: [ITK-users] GPU Implementation
References: <1405441657014-7585907.post@n2.nabble.com>
 <4C3F118B-E049-4168-9542-FC8D288FC38E@mail.nih.gov>
 <1405533203306221.02118.ptmail04@ptmail04>
 <035401d00925$9a422350$cec669f0$@ac.kr>
 <1417003820802645.09215.ptmail03@ptmail03> 
Message-ID: <042401d00a3e$7bea7f00$73bf7d00$@ac.kr>

Hi Jim,

I am sorry but could you please build the code enclosed to check whether you
also have that kind of errors or not?

Thank you very much.

Best,
Xiaopeng

-----Original Message-----
From: Xiaopeng Yang [mailto:yxp233 at postech.ac.kr] 
Sent: Wednesday, November 26, 2014 9:34 PM
To: 'Jim Miller'
Cc: 'Michael Pinkert'; 'insight-users at itk.org'
Subject: RE: [ITK-users] GPU Implementation

Hi,

I tried to compile the code from Modules\Registration\GPUPDEDeformable\test
folder. Enclosed please find the code and CMakeLists file. I am quite new to
GPU, sorry I could not understand your explanation. Could you point out what
I missed please?

Thanks,
Xiaopeng

-----Original Message-----
From: Jim Miller [mailto:millerjv at gmail.com]
Sent: Wednesday, November 26, 2014 9:10 PM
To: Xiaopeng Yang
Cc: Michael Pinkert; insight-users at itk.org
Subject: Re: [ITK-users] GPU Implementation

This doesn't look like any issue with finding OpenCL. The link error is
saying it cannot find the implementation of an ITK method. 

I think  GPUPDEDeformableRegistrationFilterKernel::GetOpenCLSource(void) is
supposed to return the kernel's implementation (probably as a string
containing the OpenCL code). 

Is there a txx file that is not being included? Does your program contain
the same headers and test?

(I guess the error could occur if OpenCL was not found if the implementation
of this method in  GPUPDEDeformableRegistrationFilterKernel is within
#ifdef/#endif on OpenCL.)

Jim

> On Nov 25, 2014, at 10:03 PM, Xiaopeng Yang <yxp233 at postech.ac.kr> wrote:
> 
> Hi Michael,
> 
> I also had the same errors while building my GPU registration program. 
> Have you solved the problems? I guess the error was caused by improper 
> setting in CMakeLists.txt file, but I could not find any 
> CMakeLists.txt sample regarding GPU implementation in ITK. I doubt 
> whether there are users using this GPU module or not.
> 
> Best regards,
> Xiaopeng Yang
> 
> 
> This is the question you raised:
> 
> I am trying to implement the GPU demons registration algorithm, but I 
> have been having difficulty getting the program to compile.  I believe 
> the errors are because it cannot find the OpenCL library correctly, 
> but I'm not sure how to fix it.
> 
> I am using a NVIDIA Quadro FX 570 and am currently using OpenCL 
> through the CUDA Computing Toolkit 4.2.  My cmake file is attached, 
> but I have had to manually enter in the directory locations to CMake 
> because I have not been able to find a FindOpenCL.cmake file that 
> works correctly.  My operating system is Windows 7 x64.
> 
> I am able to compile ITK after generating it in CMake with manually 
> linked directories and Itk_Use_Gpu checked, but I have not been able 
> to compile my program without getting errors, which are listed at the
bottom.
> 
> Does anyone have suggestions as to how to fix this? 
> 
> Best regards,
> Michael Pinkert
> 
> 2>registrationFunctions.obj : error LNK2019: unresolved external 
> 2>symbol
> "public: static char const * __cdecl
> itk::GPUPDEDeformableRegistrationFilterKernel::GetOpenCLSource(void)"
> (?GetOpenCLSource at GPUPDEDeformableRegistrationFilterKernel@itk@@SAPEBD
> XZ) referenced in function "public: static char const * __cdecl 
> itk::GPUPDEDeformableRegistrationFilter<class
> itk::GPUImage<float,3>,class itk::GPUImage<float,3>,class 
> itk::GPUImage<class itk::Vector<float,3>,3>,class 
> itk::DemonsRegistrationFilter<class
> itk::GPUImage<float,3>,class itk::GPUImage<float,3>,class 
> itk::GPUImage<class itk::Vector<float,3>,3> > >::GetOpenCLSource(void)"
> (?GetOpenCLSource@?$GPUPDEDeformableRegistrationFilter at V?$GPUImage at M$0
> 2 at itk@
> @V12 at V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@V?$DemonsRegistrationFilter
> @V?$GP
> UImage at M$02 at itk@@V12 at V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@@2@@itk@@SA
> PEBDXZ
> )
> 
> 2>registrationFunctions.obj : error LNK2019: unresolved external 
> 2>symbol
> "public: static char const * __cdecl
> itk::GPUDemonsRegistrationFunctionKernel::GetOpenCLSource(void)"
> (?GetOpenCLSource at GPUDemonsRegistrationFunctionKernel@itk@@SAPEBDXZ)
> referenced in function "public: static char const * __cdecl 
> itk::GPUDemonsRegistrationFunction<class itk::GPUImage<float,3>,class 
> itk::GPUImage<float,3>,classitk::GPUImage<class
> itk::Vector<float,3>,3>
>> ::GetOpenCLSource(void)"
> (?GetOpenCLSource@?$GPUDemonsRegistrationFunction at V?$GPUImage at M$02 at itk
> @@V12@
> V?$GPUImage at V?$Vector at M$02 at itk@@$02 at 2@@itk@@SAPEBDXZ)
> 
> 
> 
> 
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141127/8dd3f433/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: itkGPUDemonsRegistrationFilterTest.cxx
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141127/8dd3f433/attachment.ksh>

From lassi.paavolainen at jyu.fi  Thu Nov 27 08:08:33 2014
From: lassi.paavolainen at jyu.fi (Paavolainen Lassi)
Date: Thu, 27 Nov 2014 13:08:33 +0000
Subject: [ITK-users] Future of WrapITK
Message-ID: <BB43A6B0CAEAFC439640CD9D13607DC24D6A284B@mbs2.ad.jyu.fi>

Hi,

I'm developing software that uses ITK through Python wrapping. After some period of slower development progress we are now moving from ITK 3.20 to ITK 4.x. The software is developed and packages are released for 64-bit Windows, Linux and OS X. The problem is that ITK 4.6.1 with Python wrappings can be built only for Linux. It seems that there is no way around the issues with GCCXML and new Visual Studio in Win or Clang in OS X 10.9.

The issue has been raised before in: http://www.itk.org/pipermail/insight-users/2014-July/050562.html

To follow up that question, has there been any progress related to GCCXML replacement or development of GCCXML to support new Visual Studio and Clang? Are there still plans for this or will wrapITK be deprecated and replaced by SimpleITK? Is there anything I can help with?

I noticed the Wiki page (http://www.itk.org/Wiki/ITK/Wrapping) where it is said that ITK 4.7 will include support for Python 3 but will it also fix the problem with Clang or new Visual Studios?

I have to admit that I haven't tried SimpleITK so I don't know whether it could provide the same flexibility as wrapITK and how much of ITK related code would need to be rewritten.

Cheers,
Lassi

From michkapopoff at gmail.com  Thu Nov 27 10:39:33 2014
From: michkapopoff at gmail.com (michkapopoff at gmail.com)
Date: Thu, 27 Nov 2014 16:39:33 +0100
Subject: [ITK-users] Future of WrapITK
In-Reply-To: <BB43A6B0CAEAFC439640CD9D13607DC24D6A284B@mbs2.ad.jyu.fi>
References: <BB43A6B0CAEAFC439640CD9D13607DC24D6A284B@mbs2.ad.jyu.fi>
Message-ID: <189A597A-010D-4BEC-8A76-29A5046E32DD@gmail.com>

Hi

we have been working on Wrapping so the development is going on. 
Some small improvements were made for ITK 4.7.

I ported most of the code to Python3, but we have still an error which we have been working on, but is tricky to tackle.
I hope to get this done for ITK 4.8, and it will need some testing.

Fixing the problem for Clang is also under way, I don?t know how much resources we can put in it but I am hoping also for ITK 4.8, though I can not
promise anything here.

If you really need ITK wrappings on OS X, you can try my ITK binaries for homebrew: https://github.com/iMichka/homebrew-MacVTKITKPythonBottles <https://github.com/iMichka/homebrew-MacVTKITKPythonBottles>
(Please open a ticket on the github page if you have any trouble with these binaries).

If you would like to help, there are a lot of things to do on the wrapping code.
(Writing examples for the ITK examples website is a good way to start with).

For SimpleITK vs Wrapping, it all depends on what image types you want to analyse, and what filters you want to use.

Michka

> On 27 Nov 2014, at 14:08, Paavolainen Lassi <lassi.paavolainen at jyu.fi> wrote:
> 
> Hi,
> 
> I'm developing software that uses ITK through Python wrapping. After some period of slower development progress we are now moving from ITK 3.20 to ITK 4.x. The software is developed and packages are released for 64-bit Windows, Linux and OS X. The problem is that ITK 4.6.1 with Python wrappings can be built only for Linux. It seems that there is no way around the issues with GCCXML and new Visual Studio in Win or Clang in OS X 10.9.
> 
> The issue has been raised before in: http://www.itk.org/pipermail/insight-users/2014-July/050562.html
> 
> To follow up that question, has there been any progress related to GCCXML replacement or development of GCCXML to support new Visual Studio and Clang? Are there still plans for this or will wrapITK be deprecated and replaced by SimpleITK? Is there anything I can help with?
> 
> I noticed the Wiki page (http://www.itk.org/Wiki/ITK/Wrapping) where it is said that ITK 4.7 will include support for Python 3 but will it also fix the problem with Clang or new Visual Studios?
> 
> I have to admit that I haven't tried SimpleITK so I don't know whether it could provide the same flexibility as wrapITK and how much of ITK related code would need to be rewritten.
> 
> Cheers,
> Lassi
> _____________________________________
> 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.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141127/cda689c0/attachment.html>

From lassi.paavolainen at jyu.fi  Fri Nov 28 03:56:53 2014
From: lassi.paavolainen at jyu.fi (Paavolainen Lassi)
Date: Fri, 28 Nov 2014 08:56:53 +0000
Subject: [ITK-users] Future of WrapITK
In-Reply-To: <189A597A-010D-4BEC-8A76-29A5046E32DD@gmail.com>
References: <BB43A6B0CAEAFC439640CD9D13607DC24D6A284B@mbs2.ad.jyu.fi>,
 <189A597A-010D-4BEC-8A76-29A5046E32DD@gmail.com>
Message-ID: <BB43A6B0CAEAFC439640CD9D13607DC24D6A2A89@mbs2.ad.jyu.fi>

Thank you Michka for this information and for your work with wrapping as well.

We are developing with Python 2.7 so fixes for Python 3 is not important for us but I can help do some testing. Do you know if the developments in wrapping will effect the Visual Studio compilers? I might get my hands to Visual Studio 2008 but then I need to leave off some of our latest modules that are using C++11 specification. It probably gives some issues if ITK is built with Visual Studio 2008 and external filter with Visual Studio 2013.

I was aware of your OS X binaries but the issue is that we also have our own ITK classes that needs to be wrapped so we cannot use these.

We are using many image filters as well as the registration framework from the ITK. I think I read that the registration framework is not fully usable in SimpleITK.

I'll follow the developments for ITK 4.8 and will test and help in anyways possible. Thank you all for your efforts with ITK wrappings.

Cheers,
Lassi

________________________________
From: michkapopoff at gmail.com [michkapopoff at gmail.com]
Sent: Thursday, November 27, 2014 17:39
To: Paavolainen Lassi
Cc: insight-users at itk.org; community at itk.org
Subject: Re: [ITK-users] Future of WrapITK

Hi

we have been working on Wrapping so the development is going on.
Some small improvements were made for ITK 4.7.

I ported most of the code to Python3, but we have still an error which we have been working on, but is tricky to tackle.
I hope to get this done for ITK 4.8, and it will need some testing.

Fixing the problem for Clang is also under way, I don?t know how much resources we can put in it but I am hoping also for ITK 4.8, though I can not
promise anything here.

If you really need ITK wrappings on OS X, you can try my ITK binaries for homebrew: https://github.com/iMichka/homebrew-MacVTKITKPythonBottles
(Please open a ticket on the github page if you have any trouble with these binaries).

If you would like to help, there are a lot of things to do on the wrapping code.
(Writing examples for the ITK examples website is a good way to start with).

For SimpleITK vs Wrapping, it all depends on what image types you want to analyse, and what filters you want to use.

Michka

On 27 Nov 2014, at 14:08, Paavolainen Lassi <lassi.paavolainen at jyu.fi<mailto:lassi.paavolainen at jyu.fi>> wrote:

Hi,

I'm developing software that uses ITK through Python wrapping. After some period of slower development progress we are now moving from ITK 3.20 to ITK 4.x. The software is developed and packages are released for 64-bit Windows, Linux and OS X. The problem is that ITK 4.6.1 with Python wrappings can be built only for Linux. It seems that there is no way around the issues with GCCXML and new Visual Studio in Win or Clang in OS X 10.9.

The issue has been raised before in: http://www.itk.org/pipermail/insight-users/2014-July/050562.html

To follow up that question, has there been any progress related to GCCXML replacement or development of GCCXML to support new Visual Studio and Clang? Are there still plans for this or will wrapITK be deprecated and replaced by SimpleITK? Is there anything I can help with?

I noticed the Wiki page (http://www.itk.org/Wiki/ITK/Wrapping) where it is said that ITK 4.7 will include support for Python 3 but will it also fix the problem with Clang or new Visual Studios?

I have to admit that I haven't tried SimpleITK so I don't know whether it could provide the same flexibility as wrapITK and how much of ITK related code would need to be rewritten.

Cheers,
Lassi
_____________________________________
Powered by www.kitware.com<http://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.php

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://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20141128/021a2abf/attachment.html>