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] [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 _____________________________________ 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 bschaffer at superstem.org Mon Nov 3 03:51:11 2014 From: bschaffer at superstem.org (Dr Bernhard Schaffer) Date: Mon, 3 Nov 2014 09:51:11 +0100 Subject: [ITK] templating typdef question In-Reply-To: References: <000601cff3bb$da4da7f0$8ee8f7d0$@superstem.org> Message-ID: <002701cff743$51e73490$f5b59db0$@superstem.org> Hi Matt, I?m afraid I still don't quite get it. I think I've understood the concept of the template and the switch-cases from the example you've given [1], but that example code does not seem to 'return' the final image in any way, and that's where I'm stuck at the moment. Leaving different types aside and just looking into dimensionality, I now basically have the following working: The (dimension) template class wrapping around my own image object MyIMG and one of the functions I want to use the wrapper in: ( Methods are static methods of my class. My own stuff is marked in orange below. (Do emails in this list preserve formatting?) ) void MyITKWrapper::SomeCoolITKMethod( MyIMG img ) { switch ( img.GetDimensionality() ) { case( 2 ): MyITKWrapper::WrapScalarImage < 2 >( img ); break; case( 3 ): MyITKWrapper::WrapScalarImage < 3 >( img ); break; } } template< unsigned int VDimension > void MyITKWrapper::WrapScalarImage( MyIMG img ) { typedef itk::ImportImageFilter ImportFilterType; ImportFilterType::Pointer importFilter = ImportFilterType::New(); ImportFilterType::SizeType size; ImportFilterType::IndexType start; itk::SpacePrecisionType origin[VDimension]; itk::SpacePrecisionType spacing[VDimension]; long nPixels=1; for ( int dim = 0; dimSetRegion( region ); importFilter->SetOrigin( origin ); importFilter->SetSpacing( spacing ); float *localBuffer = (float *) img.GetArrayPointer(); const bool importImageFilterWillOwnTheBuffer = false; importFilter->SetImportPointer( localBuffer, nPixels, importImageFilterWillOwnTheBuffer ); return; } This compiles and is fine. The problem, of course, is, that I now want to use the ?importFilter? in my ?SomeCoolITKMethod? method, so that I can go on like: void MyITKWrapper::SomeCoolITKMethod( MyIMG img ) { switch ( img.GetDimensionality() ) { case( 2 ): importFilter = MyITKWrapper::WrapDMScalarImage < 2 >( img ); break; case( 3 ): importFilter = MyITKWrapper::WrapDMScalarImage < 3 >( img ); break; } otherCoolITKFilter->SetInput( importFilter->GetOutput() ); [?] a lot more stuff [?] } ?but I don?t know how I can ?define? importFilter generically in this method, and I also can?t make itk::ImportImageFilter the return-type of my templated wrapper method. Do I have to make ?SomeCoolITKMethod? a template function itself and have the switch-case in the method calling SomeCoolITKMethod ? Or is there a better way? Thanks, Bernhard [1] http://itk.org/ITKExamples/src/IO/ImageBase/ReadUnknownImageType/Documentation.html -----Original Message----- From: Matt McCormick [mailto:matt.mccormick at kitware.com] Sent: 29 October 2014 22:28 To: Dr Bernhard Schaffer Cc: community at itk.org Subject: Re: [ITK] templating typdef question Hi Bernhard, Welcome to ITK! The basic strategy is to put all the templated code in a template function or class. This prevents duplicated code (the root of almost all evil). Then, use a switch statement and call the appropriate templates. An example is here [1], which is long because it switches over both a number of pixel types and dimensions, but it demonstrates the idea. Inside the templated code, use for loops instead explicit assignment to set each dimension value. Also, use code like Image::SpacingType spacing; spacing.Fill( 1.0 ); instead of itk::SpacePrecisionType spacing[2]; spacing[0] = 1.0; spacing[1] = 1.0; Hope this helps, Matt [1] http://itk.org/ITKExamples/src/IO/ImageBase/ReadUnknownImageType/Documentation.html On Wed, Oct 29, 2014 at 5:03 PM, Dr Bernhard Schaffer < bschaffer at superstem.org> wrote: > Hi, > > This is my second email to this list. I?m still not so familiar with > typedefs in coding, and I?ve the current problem: > > > > I have my own ?image? objects which can be 2D or 3D and of different > number type. If I assume they are only 2D and float I can do something like this: > > (The cyan lines show methods of ?my? object.) > > > > > > const unsigned int DIMENSION = 2; > > > > typedef itk::ImportImageFilter > ImportFilterType; > > ImportFilterType::Pointer importFilter = ImportFilterType::New(); > > > > ImportFilterType::SizeType size; > > size[0] = MYIMAGE.GetXSIZE(); > > size[1] = MYIMAGE.GetYSIZE(); > > > > ImportFilterType::IndexType start; > > start.Fill( 0 ); > > > > ImportFilterType::RegionType region; > > region.SetIndex( start ); > > region.SetSize( size ); > > importFilter->SetRegion( region ); > > > > const itk::SpacePrecisionType origin[ DIMENSION ] = { 0.0, 0.0 }; > > importFilter->SetOrigin( origin ); > > > > const itk::SpacePrecisionType spacing[ DIMENSION ] = { > 1.0, 1.0 }; > > importFilter->SetSpacing( spacing ); > > > > const bool importImageFilterWillOwnTheBuffer = false; > > > > float *localBuffer = MYIMAGE.GETPOINTER(); > > importFilter->SetImportPointer( localBuffer, > size[0]*size[1], importImageFilterWillOwnTheBuffer ); > > > > typedef itk::Image< float,DIMENSION > InputImageType; > > typedef itk::Image< float,DIMENSION > OutputImageType; > > > > typedef itk::CurvatureFlowImageFilter< InputImageType, > OutputImageType > FilterType; > > FilterType::Pointer filter = FilterType::New(); > > > > filter->SetInput( importFilter->GetOutput() ); > > filter->SetTimeStep( timeStep ); > > filter->SetNumberOfIterations( iterations ); > > filter->Update(); > > typedef itk::ImageRegionIterator< OutputImageType > > IteratorType; > > OutputImageType::Pointer filtered = filter->GetOutput(); > > [?] > > > > If my image is 3D I can do accordingly: (Yellow is the difference to > above) > > > > const unsigned int DIMENSION = 3; > > > > typedef itk::ImportImageFilter > ImportFilterType; > > ImportFilterType::Pointer importFilter = ImportFilterType::New(); > > > > ImportFilterType::SizeType size; > > size[0] = MYIMAGE.GetXSIZE(); > > size[1] = MYIMAGE.GetYSIZE(); > > size[2] = MYIMAGE.GetZSIZE(); > > > > > > ImportFilterType::IndexType start; > > start.Fill( 0 ); > > > > ImportFilterType::RegionType region; > > region.SetIndex( start ); > > region.SetSize( size ); > > importFilter->SetRegion( region ); > > > > const itk::SpacePrecisionType origin[ DIMENSION ] = { 0.0, 0.0, 0.0 }; > > importFilter->SetOrigin( origin ); > > > > const itk::SpacePrecisionType spacing[ DIMENSION ] = { > 1.0, 1.0, > 1.0 }; > > importFilter->SetSpacing( spacing ); > > > > const bool importImageFilterWillOwnTheBuffer = false; > > float *localBuffer = MYIMAGE.GETPOINTER(); > > importFilter->SetImportPointer( localBuffer, > size[0]*size[1]*size[2], importImageFilterWillOwnTheBuffer ); > > > > typedef itk::Image< float,DIMENSION > InputImageType; > > typedef itk::Image< float,DIMENSION > OutputImageType; > > > > typedef itk::CurvatureFlowImageFilter< InputImageType, > OutputImageType > FilterType; > > FilterType::Pointer filter = FilterType::New(); > > > > filter->SetInput( importFilter->GetOutput() ); > > filter->SetTimeStep( timeStep ); > > filter->SetNumberOfIterations( iterations ); > > filter->Update(); > > typedef itk::ImageRegionIterator< OutputImageType > > IteratorType; > > OutputImageType::Pointer filtered = filter->GetOutput(); > > [?] > > > > The problem I have is the following. I can query my object about its > dimensionality, but I can?t do the following: > > > > const unsigned int DIMENSION = MYIMAGE.GETDIMENSIONALITY(); > > > > because the typedefs are evaluated on compilation not on runtime. So my > way around this is, to actually duplicate all the code and have both > my examples in a switch-case: > > > > switch(MYIMAGE.GETDIMENSIONALITY()) > > { > > case(2): > > { > > ? EXAMPLE 2D as above > > } > > break; > > case(3): > > { > > ? EXAMPLE 3D as above > > } > > break; > > } > > > > Which is rather obvious code duplication. Is there a better way to do this? > (there has to!) The problem branches out, if I also allow the type > float to be specified by my object as in > > switch(MYIMAGE.GETDATATYPE()) > > { > > case(1):?float?; > > case(2):?double?; > > case(3):? > > ? > > } > > > > > > I would very much appreciate a few lines of (pseudo-) code showing me > how I can do this better. > > > > Thank you very much, > > Best regards, > > Bernhard > > > > > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [ITK-users] Error compiling msvc2010 + ITK4.6 + Qt In-Reply-To: References: <5446873A.7070500@imnc.in2p3.fr> <930E7D31-ACFE-4ECF-8EAD-E8D3B6081B92@mail.nih.gov> <54475B84.5020906@imnc.in2p3.fr> <54492AB3.2030006@imnc.in2p3.fr> <544A073B.4080905@imnc.in2p3.fr> Message-ID: 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 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 >> 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 >> >> 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 >> >>>>> >> >>>>> 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: -------------- next part -------------- _____________________________________ 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 09:39:53 2014 From: Olivier.Commowick at inria.fr (Olivier Commowick) Date: Mon, 3 Nov 2014 15:39:53 +0100 Subject: [ITK] [ITK-users] VectorImage vs image of vectors Message-ID: 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 , 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 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] [ITK-users] VectorImage vs image of vectors In-Reply-To: References: 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 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 , 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 _____________________________________ 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] [ITK-users] VectorImage vs image of vectors In-Reply-To: <118DE5D3-1862-45B6-BEB1-37E2C8A90B82@mail.nih.gov> References: <118DE5D3-1862-45B6-BEB1-37E2C8A90B82@mail.nih.gov> Message-ID: 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 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 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 , 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/ _____________________________________ 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 Mon Nov 3 10:50:31 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 3 Nov 2014 10:50:31 -0500 Subject: [ITK] templating typdef question In-Reply-To: <002701cff743$51e73490$f5b59db0$@superstem.org> References: <000601cff3bb$da4da7f0$8ee8f7d0$@superstem.org> <002701cff743$51e73490$f5b59db0$@superstem.org> Message-ID: Hi Bernhard, > > The (dimension) template class wrapping around my own image object MyIMG and > one of the functions I want to use the wrapper in: > > ( Methods are static methods of my class. My own stuff is marked in orange > below. (Do emails in this list preserve formatting?) ) Yes, looks very readable -- thank you. > > > > void MyITKWrapper::SomeCoolITKMethod( MyIMG img ) > > { > > switch ( img.GetDimensionality() ) > > { > > case( 2 ): MyITKWrapper::WrapScalarImage < 2 >( img ); > break; > > case( 3 ): MyITKWrapper::WrapScalarImage < 3 >( img ); > break; > > } > > } > > > > template< unsigned int VDimension > > > void MyITKWrapper::WrapScalarImage( MyIMG img ) > > { > > typedef itk::ImportImageFilter ImportFilterType; > > ImportFilterType::Pointer importFilter = ImportFilterType::New(); > > > > ImportFilterType::SizeType size; > > ImportFilterType::IndexType start; > > itk::SpacePrecisionType origin[VDimension]; > > itk::SpacePrecisionType spacing[VDimension]; > > long nPixels=1; > > for ( int dim = 0; dim > { > > size[dim] = img.GetSizeAlongDimension(dim); > > nPixels *= size[dim]; > > start[dim] = 0; > > origin[dim] = 0.0; > > spacing[dim] = 1.0; > > } > > > > ImportFilterType::RegionType region; > > region.SetIndex( start ); > > region.SetSize( size ); > > importFilter->SetRegion( region ); > > importFilter->SetOrigin( origin ); > > importFilter->SetSpacing( spacing ); > > > > float *localBuffer = (float *) img.GetArrayPointer(); > > const bool importImageFilterWillOwnTheBuffer = false; > > importFilter->SetImportPointer( localBuffer, nPixels, > importImageFilterWillOwnTheBuffer ); > > return; > > } > Very nice! > This compiles and is fine. The problem, of course, is, that I now want to > use the ?importFilter? in my ?SomeCoolITKMethod? method, so that I can go on > like: > > > > > > void MyITKWrapper::SomeCoolITKMethod( MyIMG img ) > > { > > switch ( img.GetDimensionality() ) > > { > > case( 2 ): importFilter = MyITKWrapper::WrapDMScalarImage < > 2 >( img ); break; > > case( 3 ): importFilter = MyITKWrapper::WrapDMScalarImage < > 3 >( img ); break; > > } > > > > otherCoolITKFilter->SetInput( importFilter->GetOutput() ); > > [?] > > a lot more stuff > > [?] > > } > > > > ?but I don?t know how I can ?define? importFilter generically in this > method, and I also can?t make > > > > itk::ImportImageFilter > > > > the return-type of my templated wrapper method. > > Do I have to make ?SomeCoolITKMethod? a template function itself and have > the switch-case in the method calling SomeCoolITKMethod ? Or is there a > better way? > It generally works best to put all templated code inside the template instead of moving in and out of templates. However, if this is neally not desired, itk::ImageBase< VImageDimension >::Pointer or itk::DataObject::Pointer can be returned, which are base classes that do not have the template parameters. They would then have to be downcast when you need to operate on the specific type. HTH, Matt 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] [ITK-users] VectorImage vs image of vectors In-Reply-To: References: Message-ID: 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, 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 void DoSomething() { typedef itk::Image< itk::Vector, NDim > ImageType; ... } int main(int,char *[]) { ... switch(vecLength) { case 3: DoSomething(); break; case 11: DoSomething(); ? } } 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" 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 , 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. ________________________________ _____________________________________ 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 stnava at gmail.com Mon Nov 3 11:40:19 2014 From: stnava at gmail.com (brian avants) Date: Mon, 3 Nov 2014 11:40:19 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check Message-ID: This email is motivated by this issue: https://github.com/stnava/ANTs/issues/74 but it is not isolated to ants. Worth a read for additional context. ITK currently enforces a relatively strict check that image and displacement fields "occupy the same physical space." However, for some unclear (to me) reasons, the direction matrices or origins of images can lose precision when passing through ITK pipelines ( especially through resampling or resolution-changing filters ). This results in filters aborting and this can occur at various different places in a complex series of ITK-based operations. My concern with this is that it can lead to a very severe loss of productivity when this somewhat unpredictable error occurs. For instance, a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, brainsfit, joint label fusion, etc). The user expects registration or segmentation filters to "work well" especially when the data is of a standard sort. Then, after some oft-substantial execution time, this mysterious error appears: itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy the same physical space! While I am all for correctness, when the impact on productivity exceeds a certain threshold, I think it is useful to bend the rules a bit. Perhaps one of these would improve the situation: 1) change: ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx and ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx changing direction tolerance and coordinate tolerance to 1.e-4 https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457 https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 and change the documentation too: https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.h#L76-L87 2) Change the exception to a warning. This would at least allow complex pipelines to execute while notifying the user of a possible issue. 3) Document all of the places that the user/developer should call: Set/GetCoordinateTolerance Set/GetDirectionTolerance . This last solution would require adding Set/GetCoordinate and Direction tolerance to: https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h as well, for consistency. Anyway, I raise this issue b/c of the many man and computer hours lost by this check. Not once has this check actually helped us, in any measurable way, avoid errors. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 ntustison at gmail.com Mon Nov 3 11:44:11 2014 From: ntustison at gmail.com (Nicholas Tustison) Date: Mon, 3 Nov 2014 08:44:11 -0800 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: Message-ID: <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com> Added to this list of suggestions, would it be possible to set a tolerance in the list of cmake options? Nick > On Nov 3, 2014, at 8:40 AM, brian avants wrote: > > This email is motivated by this issue: > > https://github.com/stnava/ANTs/issues/74 > > but it is not isolated to ants. Worth a read for additional context. > > ITK currently enforces a relatively strict check that image and displacement fields "occupy the same physical space." However, for some unclear (to me) reasons, the direction matrices or origins of images can lose precision when passing through ITK pipelines ( especially through resampling or resolution-changing filters ). This results in filters aborting and this can occur at various different places in a complex series of ITK-based operations. > > My concern with this is that it can lead to a very severe loss of productivity when this somewhat unpredictable error occurs. For instance, a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, brainsfit, joint label fusion, etc). The user expects registration or segmentation filters to "work well" especially when the data is of a standard sort. Then, after some oft-substantial execution time, this mysterious error appears: > > itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy the same physical space! > > While I am all for correctness, when the impact on productivity exceeds a certain threshold, I think it is useful to bend the rules a bit. Perhaps one of these would improve the situation: > > 1) change: > > ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx > > and > > ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx > > changing direction tolerance and coordinate tolerance to 1.e-4 > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457 > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 > and change the documentation too: > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.h#L76-L87 > 2) Change the exception to a warning. This would at least allow complex pipelines to execute while notifying the user of a possible issue. > > 3) Document all of the places that the user/developer should call: > > Set/GetCoordinateTolerance Set/GetDirectionTolerance . > > This last solution would require adding Set/GetCoordinate and Direction tolerance to: > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h > > as well, for consistency. > > Anyway, I raise this issue b/c of the many man and computer hours lost by this check. > > Not once has this check actually helped us, in any measurable way, avoid errors. > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 jocmail at gmail.com Mon Nov 3 11:47:10 2014 From: jocmail at gmail.com (Oswaldo Cavalcante) Date: Mon, 3 Nov 2014 13:47:10 -0300 Subject: [ITK] SimpleITK for Java in Ubuntu 32-bit Message-ID: Hello, I'm trying to learn and use SimpleITK wrapped for Java in my project, but I would like to code on Ubuntu. Unfortunately, there is no binaries for 32-bit on the SimpleITK downloads page. Could someone help me sending these binaries? Especially the native libraries for Java in 32-bit architecture, the file "libSimpleITKJava.so". Another question, is that i'm trying and searching about to cast or in some way use a Java BufferedImage in the SimpleITK Image. How can I do it? Thanks -- *Jos? Oswaldo Cavalcante da Silva Filho* Mestrando em Inform?tica pela Universidade Federal de Alagoas Professor da Faculdade de Tecnologia de Alagoas http://lattes.cnpq.br/0516674124789514 -- *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. Knuth] -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Mon Nov 3 11:59:15 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Mon, 3 Nov 2014 11:59:15 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com> References: <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com> Message-ID: <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov> Nick, Wouldn't a settable global default value be preferred? ie. Set/GetGlobalDefaultCoordinateTolerance. Adding yet another CMake variable is rarely preferred, IMHO. Also, you mention in the ANTs issue, that it may be related to specific filters such as the Shrink filter. Do you have more specifics or reproducible sequence for this? There are some complexities with how some of the multi-scale filters compute the changing origin, it would not surprise me if there is a minor bug some place for certain more complex images. Also related does the nifti file format store this information as doubles or floats? Brad On Nov 3, 2014, at 11:44 AM, Nicholas Tustison wrote: > Added to this list of suggestions, would it be possible to set a tolerance > in the list of cmake options? > > Nick > > > >> On Nov 3, 2014, at 8:40 AM, brian avants wrote: >> >> This email is motivated by this issue: >> >> https://github.com/stnava/ANTs/issues/74 >> >> but it is not isolated to ants. Worth a read for additional context. >> >> ITK currently enforces a relatively strict check that image and displacement fields "occupy the same physical space." However, for some unclear (to me) reasons, the direction matrices or origins of images can lose precision when passing through ITK pipelines ( especially through resampling or resolution-changing filters ). This results in filters aborting and this can occur at various different places in a complex series of ITK-based operations. >> >> My concern with this is that it can lead to a very severe loss of productivity when this somewhat unpredictable error occurs. For instance, a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, brainsfit, joint label fusion, etc). The user expects registration or segmentation filters to "work well" especially when the data is of a standard sort. Then, after some oft-substantial execution time, this mysterious error appears: >> >> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy the same physical space! >> >> While I am all for correctness, when the impact on productivity exceeds a certain threshold, I think it is useful to bend the rules a bit. Perhaps one of these would improve the situation: >> >> 1) change: >> >> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx >> >> and >> >> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >> >> changing direction tolerance and coordinate tolerance to 1.e-4 >> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457 >> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >> >> and change the documentation too: >> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.h#L76-L87 >> >> 2) Change the exception to a warning. This would at least allow complex pipelines to execute while notifying the user of a possible issue. >> >> 3) Document all of the places that the user/developer should call: >> >> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >> >> This last solution would require adding Set/GetCoordinate and Direction tolerance to: >> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >> >> as well, for consistency. >> >> Anyway, I raise this issue b/c of the many man and computer hours lost by this check. >> >> Not once has this check actually helped us, in any measurable way, avoid errors. >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 stnava at gmail.com Mon Nov 3 12:04:22 2014 From: stnava at gmail.com (brian avants) Date: Mon, 3 Nov 2014 12:04:22 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov> References: <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com> <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov> Message-ID: Brad, I think that you are right in suggesting that nifti is particularly susceptible to this. But I dont know the data type. Where would the global Set/GetGlobalDefaultCoordinateTolerance (and Set/ GetGlobalDefaultDirectionTolerance ) exist? I would be happy if they could be called once within a given code base ( like Nick's suggestion ) but it might be ok to call once for each executable. brian On Mon, Nov 3, 2014 at 11:59 AM, Bradley Lowekamp wrote: > Nick, > > > Wouldn't a settable global default value be preferred? ie. > Set/GetGlobalDefaultCoordinateTolerance. > > Adding yet another CMake variable is rarely preferred, IMHO. > > > Also, you mention in the ANTs issue, that it may be related to specific > filters such as the Shrink filter. Do you have more specifics or > reproducible sequence for this? There are some complexities with how some > of the multi-scale filters compute the changing origin, it would not > surprise me if there is a minor bug some place for certain more complex > images. > > Also related does the nifti file format store this information as doubles > or floats? > > Brad > > On Nov 3, 2014, at 11:44 AM, Nicholas Tustison > wrote: > > Added to this list of suggestions, would it be possible to set a tolerance > in the list of cmake options? > > Nick > > > > On Nov 3, 2014, at 8:40 AM, brian avants wrote: > > This email is motivated by this issue: > > https://github.com/stnava/ANTs/issues/74 > > but it is not isolated to ants. Worth a read for additional context. > > ITK currently enforces a relatively strict check that image and > displacement fields "occupy the same physical space." However, for some > unclear (to me) reasons, the direction matrices or origins of images can > lose precision when passing through ITK pipelines ( especially through > resampling or resolution-changing filters ). This results in filters > aborting and this can occur at various different places in a complex series > of ITK-based operations. > > My concern with this is that it can lead to a very severe loss of > productivity when this somewhat unpredictable error occurs. For instance, > a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, > brainsfit, joint label fusion, etc). The user expects registration or > segmentation filters to "work well" especially when the data is of a > standard sort. Then, after some oft-substantial execution time, this > mysterious error appears: > > itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy the > same physical space! > > While I am all for correctness, when the impact on productivity exceeds a > certain threshold, I think it is useful to bend the rules a bit. Perhaps > one of these would improve the situation: > > 1) change: > > > ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx > > and > > ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx > > changing direction tolerance and coordinate tolerance to 1.e-4 > > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457 > > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 > > and change the documentation too: > > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.h#L76-L87 > 2) Change the exception to a warning. This would at least allow complex > pipelines to execute while notifying the user of a possible issue. > > 3) Document all of the places that the user/developer should call: > > Set/GetCoordinateTolerance Set/GetDirectionTolerance . > > This last solution would require adding Set/GetCoordinate and Direction > tolerance to: > > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h > > as well, for consistency. > > Anyway, I raise this issue b/c of the many man and computer hours lost by > this check. > > Not once has this check actually helped us, in any measurable way, avoid > errors. > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 blowekamp at mail.nih.gov Mon Nov 3 12:15:22 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Mon, 3 Nov 2014 12:15:22 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com> <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov> Message-ID: <3FD91A2E-D5FF-4330-A198-913440E36561@mail.nih.gov> Brian, I was thinking that those methods should be added to the ImageToImageFilter. While the Displacement filter can certainly use those values. I would like to further consider that that is an issue with the way the displacement fields are created. I have discussed with Hans the correctness of preserving the center vs preserving the location before with the shrink image filters. I have a patch with an alternative approach (which I thought I had done as a optional flag) [1], I have a thought that the ShrinkFilter and adaptor used to scale the displacement fields aren't symmetric. This will need exploration.. but if this error is as common as is indicated, then I am suspicious. Brad [1] http://review.source.kitware.com/#/c/8179/1 On Nov 3, 2014, at 12:04 PM, brian avants wrote: > Brad, > > I think that you are right in suggesting that nifti is particularly susceptible to this. But I dont know the data type. > > Where would the global Set/GetGlobalDefaultCoordinateTolerance (and Set/GetGlobalDefaultDirectionTolerance ) exist? I would be happy if they could be called once within a given code base ( like Nick's suggestion ) but it might be ok to call once for each executable. > > > brian > > > > On Mon, Nov 3, 2014 at 11:59 AM, Bradley Lowekamp wrote: > Nick, > > > Wouldn't a settable global default value be preferred? ie. Set/GetGlobalDefaultCoordinateTolerance. > > Adding yet another CMake variable is rarely preferred, IMHO. > > > Also, you mention in the ANTs issue, that it may be related to specific filters such as the Shrink filter. Do you have more specifics or reproducible sequence for this? There are some complexities with how some of the multi-scale filters compute the changing origin, it would not surprise me if there is a minor bug some place for certain more complex images. > > Also related does the nifti file format store this information as doubles or floats? > > Brad > > On Nov 3, 2014, at 11:44 AM, Nicholas Tustison wrote: > >> Added to this list of suggestions, would it be possible to set a tolerance >> in the list of cmake options? >> >> Nick >> >> >> >>> On Nov 3, 2014, at 8:40 AM, brian avants wrote: >>> >>> This email is motivated by this issue: >>> >>> https://github.com/stnava/ANTs/issues/74 >>> >>> but it is not isolated to ants. Worth a read for additional context. >>> >>> ITK currently enforces a relatively strict check that image and displacement fields "occupy the same physical space." However, for some unclear (to me) reasons, the direction matrices or origins of images can lose precision when passing through ITK pipelines ( especially through resampling or resolution-changing filters ). This results in filters aborting and this can occur at various different places in a complex series of ITK-based operations. >>> >>> My concern with this is that it can lead to a very severe loss of productivity when this somewhat unpredictable error occurs. For instance, a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, brainsfit, joint label fusion, etc). The user expects registration or segmentation filters to "work well" especially when the data is of a standard sort. Then, after some oft-substantial execution time, this mysterious error appears: >>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy the same physical space! >>> >>> While I am all for correctness, when the impact on productivity exceeds a certain threshold, I think it is useful to bend the rules a bit. Perhaps one of these would improve the situation: >>> >>> 1) change: >>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx >>> >>> and >>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457 >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >>> >>> and change the documentation too: >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.h#L76-L87 >>> >>> 2) Change the exception to a warning. This would at least allow complex pipelines to execute while notifying the user of a possible issue. >>> >>> 3) Document all of the places that the user/developer should call: >>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>> >>> This last solution would require adding Set/GetCoordinate and Direction tolerance to: >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >>> >>> as well, for consistency. >>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost by this check. >>> >>> Not once has this check actually helped us, in any measurable way, avoid errors. >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 ntustison at wustl.edu Mon Nov 3 12:30:14 2014 From: ntustison at wustl.edu (Nick Tustison) Date: Mon, 3 Nov 2014 09:30:14 -0800 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: <3FD91A2E-D5FF-4330-A198-913440E36561@mail.nih.gov> References: <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com> <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov> <3FD91A2E-D5FF-4330-A198-913440E36561@mail.nih.gov> Message-ID: Hi Brad, I realize the problem associated with adding another cmake variable. Currently, most of my processing is done on the university cluster and this issue can pop up in the different programs we have for ANTs as well as with specific programs I've built outside of ANTs but which still depend on ITK. What I do currently is change the tolerance in both locations in ITK to something much larger. Given that use case, I'm hoping that a solution would be easy to manage and system-wide such as a global tolerance level (or an on/off flag). My initial thought was to add it as a cmake variable but I'm open to anything. By the way, I was just at LONI talking to one of the computer guys who has also run into this issue quite a bit on their cluster and this is the solution I recommended. It would be nice if there were something less kludgey. Nick On Mon, Nov 3, 2014 at 9:15 AM, Bradley Lowekamp wrote: > Brian, > > I was thinking that those methods should be added to the > ImageToImageFilter. > > While the Displacement filter can certainly use those values. I would like > to further consider that that is an issue with the way the displacement > fields are created. > > I have discussed with Hans the correctness of preserving the center vs > preserving the location before with the shrink image filters. I have a > patch with an alternative approach (which I thought I had done as a > optional flag) [1], > > I have a thought that the ShrinkFilter and adaptor used to scale the > displacement fields aren't symmetric. This will need exploration.. but if > this error is as common as is indicated, then I am suspicious. > > Brad > > > [1] http://review.source.kitware.com/#/c/8179/1 > > On Nov 3, 2014, at 12:04 PM, brian avants wrote: > > Brad, > > I think that you are right in suggesting that nifti is particularly > susceptible to this. But I dont know the data type. > > Where would the global Set/GetGlobalDefaultCoordinateTolerance (and Set/ > GetGlobalDefaultDirectionTolerance ) exist? I would be happy if they > could be called once within a given code base ( like Nick's suggestion ) > but it might be ok to call once for each executable. > > > brian > > > > On Mon, Nov 3, 2014 at 11:59 AM, Bradley Lowekamp > wrote: > >> Nick, >> >> >> Wouldn't a settable global default value be preferred? ie. >> Set/GetGlobalDefaultCoordinateTolerance. >> >> Adding yet another CMake variable is rarely preferred, IMHO. >> >> >> Also, you mention in the ANTs issue, that it may be related to specific >> filters such as the Shrink filter. Do you have more specifics or >> reproducible sequence for this? There are some complexities with how some >> of the multi-scale filters compute the changing origin, it would not >> surprise me if there is a minor bug some place for certain more complex >> images. >> >> Also related does the nifti file format store this information as doubles >> or floats? >> >> Brad >> >> On Nov 3, 2014, at 11:44 AM, Nicholas Tustison >> wrote: >> >> Added to this list of suggestions, would it be possible to set a tolerance >> in the list of cmake options? >> >> Nick >> >> >> >> On Nov 3, 2014, at 8:40 AM, brian avants wrote: >> >> This email is motivated by this issue: >> >> https://github.com/stnava/ANTs/issues/74 >> >> but it is not isolated to ants. Worth a read for additional context. >> >> ITK currently enforces a relatively strict check that image and >> displacement fields "occupy the same physical space." However, for some >> unclear (to me) reasons, the direction matrices or origins of images can >> lose precision when passing through ITK pipelines ( especially through >> resampling or resolution-changing filters ). This results in filters >> aborting and this can occur at various different places in a complex series >> of ITK-based operations. >> >> My concern with this is that it can lead to a very severe loss of >> productivity when this somewhat unpredictable error occurs. For instance, >> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >> brainsfit, joint label fusion, etc). The user expects registration or >> segmentation filters to "work well" especially when the data is of a >> standard sort. Then, after some oft-substantial execution time, this >> mysterious error appears: >> >> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy the >> same physical space! >> >> While I am all for correctness, when the impact on productivity exceeds a >> certain threshold, I think it is useful to bend the rules a bit. Perhaps >> one of these would improve the situation: >> >> 1) change: >> >> >> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx >> >> and >> >> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >> >> changing direction tolerance and coordinate tolerance to 1.e-4 >> >> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457 >> >> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >> >> and change the documentation too: >> >> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.h#L76-L87 >> 2) Change the exception to a warning. This would at least allow complex >> pipelines to execute while notifying the user of a possible issue. >> >> 3) Document all of the places that the user/developer should call: >> >> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >> >> This last solution would require adding Set/GetCoordinate and Direction >> tolerance to: >> >> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >> >> as well, for consistency. >> >> Anyway, I raise this issue b/c of the many man and computer hours lost by >> this check. >> >> Not once has this check actually helped us, in any measurable way, avoid >> errors. >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 matt.mccormick at kitware.com Mon Nov 3 12:38:51 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 3 Nov 2014 12:38:51 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: Message-ID: Hi Brian, Thanks for discussing this. I think a combination of fixing the underlying issue that is being brought up by the exception, relaxing the tolerance, and improving the documentation is a good approach. 2 cents, Matt On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: > This email is motivated by this issue: > > https://github.com/stnava/ANTs/issues/74 > > but it is not isolated to ants. Worth a read for additional context. > > ITK currently enforces a relatively strict check that image and displacement > fields "occupy the same physical space." However, for some unclear (to me) > reasons, the direction matrices or origins of images can lose precision when > passing through ITK pipelines ( especially through resampling or > resolution-changing filters ). This results in filters aborting and this > can occur at various different places in a complex series of ITK-based > operations. > > My concern with this is that it can lead to a very severe loss of > productivity when this somewhat unpredictable error occurs. For instance, > a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, > brainsfit, joint label fusion, etc). The user expects registration or > segmentation filters to "work well" especially when the data is of a > standard sort. Then, after some oft-substantial execution time, this > mysterious error appears: > > itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy the > same physical space! > > > While I am all for correctness, when the impact on productivity exceeds a > certain threshold, I think it is useful to bend the rules a bit. Perhaps > one of these would improve the situation: > > 1) change: > > ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx > > and > > ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx > > changing direction tolerance and coordinate tolerance to 1.e-4 > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457 > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 > > and change the documentation too: > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.h#L76-L87 > > 2) Change the exception to a warning. This would at least allow complex > pipelines to execute while notifying the user of a possible issue. > > 3) Document all of the places that the user/developer should call: > > Set/GetCoordinateTolerance Set/GetDirectionTolerance . > > This last solution would require adding Set/GetCoordinate and Direction > tolerance to: > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h > > as well, for consistency. > > Anyway, I raise this issue b/c of the many man and computer hours lost by > this check. > > Not once has this check actually helped us, in any measurable way, avoid > errors. > > > > _______________________________________________ > 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 > _______________________________________________ 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 michkapopoff at gmail.com Mon Nov 3 12:39:15 2014 From: michkapopoff at gmail.com (michkapopoff at gmail.com) Date: Mon, 3 Nov 2014 18:39:15 +0100 Subject: [ITK] SimpleITK for Java in Ubuntu 32-bit In-Reply-To: References: Message-ID: <342E2471-C535-4D8D-A7F3-A56FFF633494@gmail.com> Hi the thing is that we can not provide binaries for each platform / OS. Especially that there would be a lot of languages and combinations to support (python, java, 32 bit, 64 bit ?). You may have to build SimpleITK by yourself. You can find instructions for this here [1]. You will need cmake for this. Please look at the super build part. Michka [1] http://www.itk.org/Wiki/SimpleITK/GettingStarted > On 03 Nov 2014, at 17:47, Oswaldo Cavalcante wrote: > > Hello, > > I'm trying to learn and use SimpleITK wrapped for Java in my project, but I would like to code on Ubuntu. Unfortunately, there is no binaries for 32-bit on the SimpleITK downloads page. > > Could someone help me sending these binaries? Especially the native libraries for Java in 32-bit architecture, the file "libSimpleITKJava.so". > > Another question, is that i'm trying and searching about to cast or in some way use a Java BufferedImage in the SimpleITK Image. How can I do it? > > Thanks > > -- > Jos? Oswaldo Cavalcante da Silva Filho > > Mestrando em Inform?tica pela Universidade Federal de Alagoas > Professor da Faculdade de Tecnologia de Alagoas > http://lattes.cnpq.br/0516674124789514 > > -- > "Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por pessoas que n?o t?m essas maneiras estranhas de pensar" [Donald E. Knuth] > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschaffer at superstem.org Mon Nov 3 12:41:31 2014 From: bschaffer at superstem.org (Dr Bernhard Schaffer) Date: Mon, 3 Nov 2014 18:41:31 +0100 Subject: [ITK] templating typdef question In-Reply-To: References: <000601cff3bb$da4da7f0$8ee8f7d0$@superstem.org> <002701cff743$51e73490$f5b59db0$@superstem.org> Message-ID: <015701cff78d$69b7db20$3d279160$@superstem.org> Hi Matt, Sorry for being so persistent, but I really want to understand this, and then do it in the optimum way. >From your advice, I?ve restructured my code (and it works) as follows: The actual ITK method is templated and does not know anything about ?my? image object. Instead it just takes the data pointers to source & destination and an array which stores the dimension-sizes. The code now reads: MyIMG MyITKWrapper::CurvatureFlowImageFilter( MyIMG srcImage, long iterations, double timeStep ) { // Do stuff to get my pointers and array info octet *src = (octet *) srcImage.GetDataPointer(); octet *dst = (octet *) dstImage.GetDataPointer(); long srcDataType = srcImage.GetDataType(); ulong dims[5] = { 1, 1, 1, 1, 1 }; for ( long d=0; d ( iterations, timeStep, (float *) src , (float *) dst, dims );} break; case(FLOAT8DATA): { CurvatureFlowImageFilter <2> ( iterations, timeStep, (double *) src, (double *) dst, dims );} break; default: ThrowString("Data type not supported."); } break; case(3): switch(srcDataType) { case(FLOAT4DATA): { CurvatureFlowImageFilter <3> ( iterations, timeStep, (float *) src , (float *) dst, dims );} break; case(FLOAT8DATA): { CurvatureFlowImageFilter <3> ( iterations, timeStep, (double *) src, (double *) dst, dims );} break; default: ThrowString("Data type not supported."); } break; default: ThrowString("Dimensionality not supported."); } return resultImage; } template< unsigned int VDimension, typename tSrc, typename tDest > void MyITKWrapper::CurvatureFlowImageFilter( long iterations, double timeStep, typename tSrc *src, typename tDest *dst, ulong *dimSizes ) { // Wrap data for ITK typedef itk::ImportImageFilter ImportFilterType; ImportFilterType::Pointer importFilter = ImportFilterType::New(); ImportFilterType::SizeType size; ImportFilterType::IndexType start; itk::SpacePrecisionType origin[VDimension]; itk::SpacePrecisionType spacing[VDimension]; long nPixels=1; for ( int dim = 0; dimSetRegion( region ); importFilter->SetOrigin( origin ); importFilter->SetSpacing( spacing ); importFilter->SetImportPointer( src, nPixels, false ); // Perform ITK action typedef itk::Image InputImageType; typedef itk::Image OutputImageType; typedef itk::CurvatureFlowImageFilter< InputImageType, OutputImageType > FilterType; FilterType::Pointer filter = FilterType::New(); filter->SetInput( importFilter->GetOutput() ); filter->SetTimeStep( timeStep ); filter->SetNumberOfIterations( iterations ); filter->Update(); //Write back the data typedef itk::ImageRegionIterator< OutputImageType > IteratorType; OutputImageType::Pointer filtered = filter->GetOutput(); IteratorType iterator( filtered, filtered->GetRequestedRegion() ); for ( iterator.GoToBegin(); !iterator.IsAtEnd(); ++iterator ) { *dst = (tDest) iterator.Get(); dst++; } } Now, as said this works, but if you look into the CurvatureFlowImageFilter method, only the 8 lines in the ?Perform ITK action ? section are actually specific to this filter. As I want to wrap around a lot (ideally all) itk functionality: Is there really no better way to abstract the ?wrapping? ? Do I really have to copy&paste the ?Wrap data for ITK? and ?Write back the data? sections into each and every filter I want to wrap around? Thanks, Bernhard -----Original Message----- From: Matt McCormick [mailto:matt.mccormick at kitware.com] Sent: 03 November 2014 16:51 To: Dr Bernhard Schaffer Cc: community at itk.org Subject: Re: [ITK] templating typdef question Hi Bernhard, > > The (dimension) template class wrapping around my own image object > MyIMG and one of the functions I want to use the wrapper in: > > ( Methods are static methods of my class. My own stuff is marked in > orange below. (Do emails in this list preserve formatting?) ) Yes, looks very readable -- thank you. > > > > void MyITKWrapper::SomeCoolITKMethod( MyIMG img ) > > { > > switch ( img.GetDimensionality() ) > > { > > case( 2 ): MyITKWrapper::WrapScalarImage < 2 >( img ); > break; > > case( 3 ): MyITKWrapper::WrapScalarImage < 3 >( img ); > break; > > } > > } > > > > template< unsigned int VDimension > > > void MyITKWrapper::WrapScalarImage( MyIMG img ) > > { > > typedef itk::ImportImageFilter > ImportFilterType; > > ImportFilterType::Pointer importFilter = > ImportFilterType::New(); > > > > ImportFilterType::SizeType size; > > ImportFilterType::IndexType start; > > itk::SpacePrecisionType origin[VDimension]; > > itk::SpacePrecisionType spacing[VDimension]; > > long nPixels=1; > > for ( int dim = 0; dim > { > > size[dim] = img.GetSizeAlongDimension(dim); > > nPixels *= size[dim]; > > start[dim] = 0; > > origin[dim] = 0.0; > > spacing[dim] = 1.0; > > } > > > > ImportFilterType::RegionType region; > > region.SetIndex( start ); > > region.SetSize( size ); > > importFilter->SetRegion( region ); > > importFilter->SetOrigin( origin ); > > importFilter->SetSpacing( spacing ); > > > > float *localBuffer = (float *) img.GetArrayPointer(); > > const bool importImageFilterWillOwnTheBuffer = false; > > importFilter->SetImportPointer( localBuffer, nPixels, > importImageFilterWillOwnTheBuffer ); > > return; > > } > Very nice! > This compiles and is fine. The problem, of course, is, that I now want > to use the ?importFilter? in my ?SomeCoolITKMethod? method, so that I > can go on > like: > > > > > > void MyITKWrapper::SomeCoolITKMethod( MyIMG img ) > > { > > switch ( img.GetDimensionality() ) > > { > > case( 2 ): importFilter = MyITKWrapper::WrapDMScalarImage < > 2 >( img ); break; > > case( 3 ): importFilter = MyITKWrapper::WrapDMScalarImage < > 3 >( img ); break; > > } > > > > otherCoolITKFilter->SetInput( importFilter->GetOutput() ); > > [?] > > a lot more stuff > > [?] > > } > > > > ?but I don?t know how I can ?define? importFilter generically in this > method, and I also can?t make > > > > itk::ImportImageFilter > > > > the return-type of my templated wrapper method. > > Do I have to make ?SomeCoolITKMethod? a template function itself and > have the switch-case in the method calling SomeCoolITKMethod ? Or is > there a better way? > It generally works best to put all templated code inside the template instead of moving in and out of templates. However, if this is neally not desired, itk::ImageBase< VImageDimension >::Pointer or itk::DataObject::Pointer can be returned, which are base classes that do not have the template parameters. They would then have to be downcast when you need to operate on the specific type. HTH, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocmail at gmail.com Mon Nov 3 12:55:50 2014 From: jocmail at gmail.com (Oswaldo Cavalcante) Date: Mon, 3 Nov 2014 14:55:50 -0300 Subject: [ITK] SimpleITK for Java in Ubuntu 32-bit In-Reply-To: <342E2471-C535-4D8D-A7F3-A56FFF633494@gmail.com> References: <342E2471-C535-4D8D-A7F3-A56FFF633494@gmail.com> Message-ID: Thanks! In fact, I've tried to compile, but I got errors in two different machines. When the file libSimpleITKJava.so is being generated, the memory uses increases a lot (about further 4 Gb!!), so the process is stopped with a message like this: 'error: no enough memory'. I've tried several times, but I couldn't generate the native libs. Another doubt, is that i'm trying and searching about to cast or in some way use a Java BufferedImage in the SimpleITK. How can I do it? Thanks a lot! 2014-11-03 14:39 GMT-03:00 : > Hi > > the thing is that we can not provide binaries for each platform / OS. > Especially that there would be a lot of languages and combinations to > support (python, java, 32 bit, 64 bit ?). You may have to build SimpleITK > by yourself. You can find instructions for this here [1]. You will need > cmake for this. Please look at the super build part. > > Michka > > [1] http://www.itk.org/Wiki/SimpleITK/GettingStarted > > On 03 Nov 2014, at 17:47, Oswaldo Cavalcante wrote: > > Hello, > > I'm trying to learn and use SimpleITK wrapped for Java in my project, but > I would like to code on Ubuntu. Unfortunately, there is no binaries for > 32-bit on the SimpleITK downloads page. > > Could someone help me sending these binaries? Especially the native > libraries for Java in 32-bit architecture, the file "libSimpleITKJava.so". > > Another question, is that i'm trying and searching about to cast or in > some way use a Java BufferedImage in the SimpleITK Image. How can I do it? > > Thanks > > -- > *Jos? Oswaldo Cavalcante da Silva Filho* > > Mestrando em Inform?tica pela Universidade Federal de Alagoas > Professor da Faculdade de Tecnologia de Alagoas > http://lattes.cnpq.br/0516674124789514 > > -- > *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por > pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. Knuth] > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > > > -- *Jos? Oswaldo Cavalcante da Silva Filho* Mestrando em Inform?tica pela Universidade Federal de Alagoas Professor da Faculdade de Tecnologia de Alagoas http://lattes.cnpq.br/0516674124789514 -- *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. Knuth] -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Mon Nov 3 13:15:25 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 3 Nov 2014 13:15:25 -0500 Subject: [ITK] templating typdef question In-Reply-To: <015701cff78d$69b7db20$3d279160$@superstem.org> References: <000601cff3bb$da4da7f0$8ee8f7d0$@superstem.org> <002701cff743$51e73490$f5b59db0$@superstem.org> <015701cff78d$69b7db20$3d279160$@superstem.org> Message-ID: Hi Bernhard, Looks good. The "// Perform ITK action" section could be another templated function/class that is templated over InputImageType, OutputImageType, and FilterType. Template specialization can be provided for the different filter types, e.g. CurvatureFlowImageFilter. HTH, Matt On Mon, Nov 3, 2014 at 12:41 PM, Dr Bernhard Schaffer wrote: > Hi Matt, > > Sorry for being so persistent, but I really want to understand this, and > then do it in the optimum way. > > From your advice, I?ve restructured my code (and it works) as follows: > > > > The actual ITK method is templated and does not know anything about ?my? > image object. > > Instead it just takes the data pointers to source & destination and an array > which stores the dimension-sizes. The code now reads: > > > > MyIMG MyITKWrapper::CurvatureFlowImageFilter( MyIMG srcImage, long > iterations, double timeStep ) > > { > > // Do stuff to get my pointers and array info > > octet *src = (octet *) srcImage.GetDataPointer(); > > octet *dst = (octet *) dstImage.GetDataPointer(); > > long srcDataType = srcImage.GetDataType(); > > > > ulong dims[5] = { 1, 1, 1, 1, 1 }; > > for ( long d=0; d > dims[d] = srcImage.GetSizeAlongDimension(d); > > > > // Switch into templated code to branch depending on type & > dimensionality > > switch(nDims) > > { > > case(2): > > switch(srcDataType) > > { > > case(FLOAT4DATA): { CurvatureFlowImageFilter <2> ( > iterations, timeStep, (float *) src , (float *) dst, dims );} break; > > case(FLOAT8DATA): { CurvatureFlowImageFilter <2> ( > iterations, timeStep, (double *) src, (double *) dst, dims );} break; > > default: ThrowString("Data type not supported."); > > } > > break; > > case(3): > > switch(srcDataType) > > { > > case(FLOAT4DATA): { CurvatureFlowImageFilter <3> ( > iterations, timeStep, (float *) src , (float *) dst, dims );} break; > > case(FLOAT8DATA): { CurvatureFlowImageFilter <3> ( > iterations, timeStep, (double *) src, (double *) dst, dims );} break; > > default: ThrowString("Data type not supported."); > > } > > break; > > default: ThrowString("Dimensionality not supported."); > > } > > > > return resultImage; > > } > > > > > > template< unsigned int VDimension, typename tSrc, typename tDest > > > void MyITKWrapper::CurvatureFlowImageFilter( long iterations, double > timeStep, typename tSrc *src, typename tDest *dst, ulong *dimSizes ) > > { > > // Wrap data for ITK > > typedef itk::ImportImageFilter ImportFilterType; > > ImportFilterType::Pointer importFilter = ImportFilterType::New(); > > > > ImportFilterType::SizeType size; > > ImportFilterType::IndexType start; > > itk::SpacePrecisionType origin[VDimension]; > > itk::SpacePrecisionType spacing[VDimension]; > > long nPixels=1; > > for ( int dim = 0; dim > { > > size[dim] = dimSizes[dim]; start[dim] = 0; origin[dim] = > 0.0; spacing[dim] = 1.0; > > nPixels *= size[dim]; > > } > > ImportFilterType::RegionType region; > > region.SetIndex( start ); > > region.SetSize( size ); > > importFilter->SetRegion( region ); > > importFilter->SetOrigin( origin ); > > importFilter->SetSpacing( spacing ); > > importFilter->SetImportPointer( src, nPixels, false ); > > > > // Perform ITK action > > typedef itk::Image InputImageType; > > typedef itk::Image OutputImageType; > > typedef itk::CurvatureFlowImageFilter< InputImageType, > OutputImageType > FilterType; > > FilterType::Pointer filter = FilterType::New(); > > filter->SetInput( importFilter->GetOutput() ); > > filter->SetTimeStep( timeStep ); > > filter->SetNumberOfIterations( iterations ); > > filter->Update(); > > > > //Write back the data > > typedef itk::ImageRegionIterator< OutputImageType > > IteratorType; > > OutputImageType::Pointer filtered = filter->GetOutput(); > > IteratorType iterator( filtered, filtered->GetRequestedRegion() ); > > for ( iterator.GoToBegin(); !iterator.IsAtEnd(); ++iterator ) > > { > > *dst = (tDest) iterator.Get(); > > dst++; > > } > > } > > > > Now, as said this works, but if you look into the CurvatureFlowImageFilter > method, only the 8 lines in the ?Perform ITK action ? section are actually > specific to this filter. As I want to wrap around a lot (ideally all) itk > functionality: Is there really no better way to abstract the ?wrapping? ? > > > > Do I really have to copy&paste the ?Wrap data for ITK? and ?Write back the > data? sections into each and every filter I want to wrap around? > > > > Thanks, > > Bernhard > > > > > > -----Original Message----- > From: Matt McCormick [mailto:matt.mccormick at kitware.com] > Sent: 03 November 2014 16:51 > To: Dr Bernhard Schaffer > Cc: community at itk.org > Subject: Re: [ITK] templating typdef question > > > > Hi Bernhard, > > > >> > >> The (dimension) template class wrapping around my own image object > >> MyIMG and one of the functions I want to use the wrapper in: > >> > >> ( Methods are static methods of my class. My own stuff is marked in > >> orange below. (Do emails in this list preserve formatting?) ) > > > > Yes, looks very readable -- thank you. > > > >> > >> > >> > >> void MyITKWrapper::SomeCoolITKMethod( MyIMG img ) > >> > >> { > >> > >> switch ( img.GetDimensionality() ) > >> > >> { > >> > >> case( 2 ): MyITKWrapper::WrapScalarImage < 2 >( img ); > >> break; > >> > >> case( 3 ): MyITKWrapper::WrapScalarImage < 3 >( img ); > >> break; > >> > >> } > >> > >> } > >> > >> > >> > >> template< unsigned int VDimension > > >> > >> void MyITKWrapper::WrapScalarImage( MyIMG img ) > >> > >> { > >> > >> typedef itk::ImportImageFilter > >> ImportFilterType; > >> > >> ImportFilterType::Pointer importFilter = > >> ImportFilterType::New(); > >> > >> > >> > >> ImportFilterType::SizeType size; > >> > >> ImportFilterType::IndexType start; > >> > >> itk::SpacePrecisionType origin[VDimension]; > >> > >> itk::SpacePrecisionType spacing[VDimension]; > >> > >> long nPixels=1; > >> > >> for ( int dim = 0; dim >> > >> { > >> > >> size[dim] = img.GetSizeAlongDimension(dim); > >> > >> nPixels *= size[dim]; > >> > >> start[dim] = 0; > >> > >> origin[dim] = 0.0; > >> > >> spacing[dim] = 1.0; > >> > >> } > >> > >> > >> > >> ImportFilterType::RegionType region; > >> > >> region.SetIndex( start ); > >> > >> region.SetSize( size ); > >> > >> importFilter->SetRegion( region ); > >> > >> importFilter->SetOrigin( origin ); > >> > >> importFilter->SetSpacing( spacing ); > >> > >> > >> > >> float *localBuffer = (float *) img.GetArrayPointer(); > >> > >> const bool importImageFilterWillOwnTheBuffer = false; > >> > >> importFilter->SetImportPointer( localBuffer, nPixels, > >> importImageFilterWillOwnTheBuffer ); > >> > >> return; > >> > >> } > >> > > > > Very nice! > > > > > > > >> This compiles and is fine. The problem, of course, is, that I now want > >> to use the ?importFilter? in my ?SomeCoolITKMethod? method, so that I > >> can go on > >> like: > >> > >> > >> > >> > >> > >> void MyITKWrapper::SomeCoolITKMethod( MyIMG img ) > >> > >> { > >> > >> switch ( img.GetDimensionality() ) > >> > >> { > >> > >> case( 2 ): importFilter = MyITKWrapper::WrapDMScalarImage >> < > >> 2 >( img ); break; > >> > >> case( 3 ): importFilter = MyITKWrapper::WrapDMScalarImage >> < > >> 3 >( img ); break; > >> > >> } > >> > >> > >> > >> otherCoolITKFilter->SetInput( importFilter->GetOutput() ); > >> > >> [?] > >> > >> a lot more stuff > >> > >> [?] > >> > >> } > >> > >> > >> > >> ?but I don?t know how I can ?define? importFilter generically in this > >> method, and I also can?t make > >> > >> > >> > >> itk::ImportImageFilter > >> > >> > >> > >> the return-type of my templated wrapper method. > >> > >> Do I have to make ?SomeCoolITKMethod? a template function itself and > >> have the switch-case in the method calling SomeCoolITKMethod ? Or is > >> there a better way? > >> > > > > It generally works best to put all templated code inside the template > instead of moving in and out of templates. However, if this is neally not > desired, itk::ImageBase< VImageDimension >::Pointer or > itk::DataObject::Pointer can be returned, which are base classes that do not > have the template parameters. They would then have to be downcast when you > need to operate on the specific type. > > > > HTH, > > Matt From blowekamp at mail.nih.gov Mon Nov 3 13:22:01 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Mon, 3 Nov 2014 13:22:01 -0500 Subject: [ITK] SimpleITK for Java in Ubuntu 32-bit In-Reply-To: References: <342E2471-C535-4D8D-A7F3-A56FFF633494@gmail.com> Message-ID: <38E3FA32-153F-4934-8A30-83CA3E0C967E@mail.nih.gov> Hello, The default configuration build ITK and SimpleITK as static libraries, and then the SWIG layer generates a shared libraries with the other libraries statically linked. This produces a smaller and more efficient runtime library which in most cases is preferred during run time, and has a simpler installation. This is at the trade off of requiring more system resources when building/linking. I would recommend utilizing a system with the required resources when building. Alternatively, you can enable shared libraries in the CMake configuration. This will build ITK, and the SimpleITK core as shared libraries, are greatly reduce the requirements to link. While the SimpleITK/SWIG interface could provide a native buffer interface the way that it's done in Python and C#, no one has implemented it yet. Contributions are very much welcomed! Brad On Nov 3, 2014, at 12:55 PM, Oswaldo Cavalcante wrote: > Thanks! > > In fact, I've tried to compile, but I got errors in two different machines. When the file libSimpleITKJava.so is being generated, the memory uses increases a lot (about further 4 Gb!!), so the process is stopped with a message like this: 'error: no enough memory'. I've tried several times, but I couldn't generate the native libs. > > Another doubt, is that i'm trying and searching about to cast or in some way use a Java BufferedImage in the SimpleITK. How can I do it? > > Thanks a lot! > > 2014-11-03 14:39 GMT-03:00 : > Hi > > the thing is that we can not provide binaries for each platform / OS. Especially that there would be a lot of languages and combinations to support (python, java, 32 bit, 64 bit ?). You may have to build SimpleITK by yourself. You can find instructions for this here [1]. You will need cmake for this. Please look at the super build part. > > Michka > > [1] http://www.itk.org/Wiki/SimpleITK/GettingStarted > >> On 03 Nov 2014, at 17:47, Oswaldo Cavalcante wrote: >> >> Hello, >> >> I'm trying to learn and use SimpleITK wrapped for Java in my project, but I would like to code on Ubuntu. Unfortunately, there is no binaries for 32-bit on the SimpleITK downloads page. >> >> Could someone help me sending these binaries? Especially the native libraries for Java in 32-bit architecture, the file "libSimpleITKJava.so". >> >> Another question, is that i'm trying and searching about to cast or in some way use a Java BufferedImage in the SimpleITK Image. How can I do it? >> >> Thanks >> >> -- >> Jos? Oswaldo Cavalcante da Silva Filho >> >> Mestrando em Inform?tica pela Universidade Federal de Alagoas >> Professor da Faculdade de Tecnologia de Alagoas >> http://lattes.cnpq.br/0516674124789514 >> >> -- >> "Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por pessoas que n?o t?m essas maneiras estranhas de pensar" [Donald E. Knuth] >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community > > > > > -- > Jos? Oswaldo Cavalcante da Silva Filho > > Mestrando em Inform?tica pela Universidade Federal de Alagoas > Professor da Faculdade de Tecnologia de Alagoas > http://lattes.cnpq.br/0516674124789514 > > -- > "Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por pessoas que n?o t?m essas maneiras estranhas de pensar" [Donald E. Knuth] > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [ITK-users] Loading a specifing region of an image from disk Message-ID: 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] SimpleITK - Reading different DICOM serie In-Reply-To: References: 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 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Loading a specifing region of an image from disk In-Reply-To: References: 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? 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 _____________________________________ 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 Ryan.E.Young at Colorado.EDU Mon Nov 3 15:43:25 2014 From: Ryan.E.Young at Colorado.EDU (Ryan Edward Young) Date: Mon, 3 Nov 2014 12:43:25 -0800 Subject: [ITK] SimpleITK in R: Best way to read image Message-ID: Hello, A am trying to read several nifti files into R as follows. for(i in 1:n){ im=ReadImage(image.nii.gz) imArray=as.array(im) #compare image with other images, and add the similar part to an array } When I do this the memory usage just keeps growing. It appears that simpleITK is not doing any garbage collection when I open a new image into my im variable. Is there a command to close itk connection to a image or clear that part of the buffer? Any advice is appreciated. Thanks Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [ITK-users] SimpleITK - Reading different DICOM serie In-Reply-To: <26879E67-D42E-4A53-9309-7CD933EC3FD0@mail.nih.gov> References: <26879E67-D42E-4A53-9309-7CD933EC3FD0@mail.nih.gov> Message-ID: 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 wrote: > Hello, > > What version of ITK and SimpleITK are you using? > > Thanks, > Brad > > On Oct 31, 2014, at 7:03 PM, Guillaume Lema?tre > 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: -------------- next part -------------- _____________________________________ 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 Mon Nov 3 15:50:25 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Mon, 3 Nov 2014 15:50:25 -0500 Subject: [ITK] SimpleITK in R: Best way to read image In-Reply-To: References: Message-ID: <6B1D4F2F-F47F-4417-B3E8-C4D7FE30FE5E@mail.nih.gov> Hello, I haven't use the R interface much. I have two suggestions: 1) Did you try manually calling the R garbage collector? [1] 2) If you comment out the imArray conversion do you still get the "leak"? ( This is to narrow down the cause of 1 doesn't address the issue) Brad [1] http://stat.ethz.ch/R-manual/R-patched/library/base/html/gc.html On Nov 3, 2014, at 3:43 PM, Ryan Edward Young wrote: > Hello, > > A am trying to read several nifti files into R as follows. > > for(i in 1:n){ > im=ReadImage(image.nii.gz) > imArray=as.array(im) > #compare image with other images, and add the similar part to an array > } > > When I do this the memory usage just keeps growing. It appears that simpleITK is not doing any garbage collection when I open a new image into my im variable. Is there a command to close itk connection to a image or clear that part of the buffer? Any advice is appreciated. > > Thanks > Ryan > > > > > > > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community 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] [ITK-users] SimpleITK - Reading different DICOM serie References: Message-ID: 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 > Subject: [ITK-users] SimpleITK - Reading different DICOM serie > Date: October 31, 2014 at 7:03:36 PM EDT > To: "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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] SimpleITK - Reading different DICOM serie In-Reply-To: References: Message-ID: 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 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 > *Subject: **[ITK-users] SimpleITK - Reading different DICOM serie* > *Date: *October 31, 2014 at 7:03:36 PM EDT > *To: *"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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Loading a specifing region of an image from disk In-Reply-To: <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov> References: <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov> Message-ID: 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 : > 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? 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: -------------- next part -------------- _____________________________________ 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 M.Staring at lumc.nl Tue Nov 4 03:51:11 2014 From: M.Staring at lumc.nl (M.Staring at lumc.nl) Date: Tue, 4 Nov 2014 08:51:11 +0000 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: Message-ID: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Hi all, Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? Regards, Marius > -----Original Message----- > From: Insight-developers [mailto:insight-developers-bounces at itk.org] On > Behalf Of Matt McCormick > Sent: maandag 3 november 2014 18:39 > To: brian avants > Cc: Insight-developers at itk.org > Subject: Re: [ITK-dev] image and deformation field physical space check > > Hi Brian, > > Thanks for discussing this. > > I think a combination of fixing the underlying issue that is being brought up by > the exception, relaxing the tolerance, and improving the documentation is a > good approach. > > 2 cents, > Matt > > On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: > > This email is motivated by this issue: > > > > https://github.com/stnava/ANTs/issues/74 > > > > but it is not isolated to ants. Worth a read for additional context. > > > > ITK currently enforces a relatively strict check that image and > > displacement fields "occupy the same physical space." However, for > > some unclear (to me) reasons, the direction matrices or origins of > > images can lose precision when passing through ITK pipelines ( > > especially through resampling or resolution-changing filters ). This > > results in filters aborting and this can occur at various different > > places in a complex series of ITK-based operations. > > > > My concern with this is that it can lead to a very severe loss of > > productivity when this somewhat unpredictable error occurs. For instance, > > a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, > > brainsfit, joint label fusion, etc). The user expects registration or > > segmentation filters to "work well" especially when the data is of a > > standard sort. Then, after some oft-substantial execution time, this > > mysterious error appears: > > > > itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy > > the same physical space! > > > > > > While I am all for correctness, when the impact on productivity exceeds a > > certain threshold, I think it is useful to bend the rules a bit. Perhaps > > one of these would improve the situation: > > > > 1) change: > > > > ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField > > Transform.hxx > > > > and > > > > ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx > > > > changing direction tolerance and coordinate tolerance to 1.e-4 > > > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F > > iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L > > 454-L457 > > > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C > > ore/Common/include/itkImageToImageFilter.hxx#L40-L41 > > > > and change the documentation too: > > > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C > > ore/Common/include/itkImageToImageFilter.h#L76-L87 > > > > 2) Change the exception to a warning. This would at least allow > > complex pipelines to execute while notifying the user of a possible issue. > > > > 3) Document all of the places that the user/developer should call: > > > > Set/GetCoordinateTolerance Set/GetDirectionTolerance . > > > > This last solution would require adding Set/GetCoordinate and > > Direction tolerance to: > > > > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F > > iltering/DisplacementField/include/itkDisplacementFieldTransform.h > > > > as well, for consistency. > > > > Anyway, I raise this issue b/c of the many man and computer hours lost > > by this check. > > > > Not once has this check actually helped us, in any measurable way, > > avoid errors. > > > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 _______________________________________________ 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 jocmail at gmail.com Tue Nov 4 08:57:19 2014 From: jocmail at gmail.com (Oswaldo Cavalcante) Date: Tue, 4 Nov 2014 10:57:19 -0300 Subject: [ITK] SimpleITK for Java in Ubuntu 32-bit In-Reply-To: <38E3FA32-153F-4934-8A30-83CA3E0C967E@mail.nih.gov> References: <342E2471-C535-4D8D-A7F3-A56FFF633494@gmail.com> <38E3FA32-153F-4934-8A30-83CA3E0C967E@mail.nih.gov> Message-ID: Hello, Thanks! I've tried again and I finally got the right binaries and native libraries for Java. About the conversion from Java BufferedImage, there is any way to import a Java Image to SimpleITK? I'm working with binary images, so could I convert my images in a binary matrix or array, and so convert it into a SimpleITK Image, for example? I've seen that in Matlab exists a GetImageFromArray method, using a specific numpy array, but I didn't find something like this for Java. Thanks 2014-11-03 15:22 GMT-03:00 Bradley Lowekamp : > Hello, > > The default configuration build ITK and SimpleITK as static libraries, and > then the SWIG layer generates a shared libraries with the other libraries > statically linked. This produces a smaller and more efficient runtime > library which in most cases is preferred during run time, and has a simpler > installation. This is at the trade off of requiring more system resources > when building/linking. I would recommend utilizing a system with the > required resources when building. > > Alternatively, you can enable shared libraries in the CMake configuration. > This will build ITK, and the SimpleITK core as shared libraries, are > greatly reduce the requirements to link. > > While the SimpleITK/SWIG interface could provide a native buffer interface > the way that it's done in Python and C#, no one has implemented it yet. > Contributions are very much welcomed! > > Brad > > On Nov 3, 2014, at 12:55 PM, Oswaldo Cavalcante wrote: > > Thanks! > > In fact, I've tried to compile, but I got errors in two different > machines. When the file libSimpleITKJava.so is being generated, the memory > uses increases a lot (about further 4 Gb!!), so the process is stopped with > a message like this: 'error: no enough memory'. I've tried several times, > but I couldn't generate the native libs. > > Another doubt, is that i'm trying and searching about to cast or in some > way use a Java BufferedImage in the SimpleITK. How can I do it? > > Thanks a lot! > > 2014-11-03 14:39 GMT-03:00 : > >> Hi >> >> the thing is that we can not provide binaries for each platform / OS. >> Especially that there would be a lot of languages and combinations to >> support (python, java, 32 bit, 64 bit ?). You may have to build SimpleITK >> by yourself. You can find instructions for this here [1]. You will need >> cmake for this. Please look at the super build part. >> >> Michka >> >> [1] http://www.itk.org/Wiki/SimpleITK/GettingStarted >> >> On 03 Nov 2014, at 17:47, Oswaldo Cavalcante wrote: >> >> Hello, >> >> I'm trying to learn and use SimpleITK wrapped for Java in my project, but >> I would like to code on Ubuntu. Unfortunately, there is no binaries for >> 32-bit on the SimpleITK downloads page. >> >> Could someone help me sending these binaries? Especially the native >> libraries for Java in 32-bit architecture, the file "libSimpleITKJava.so". >> >> Another question, is that i'm trying and searching about to cast or in >> some way use a Java BufferedImage in the SimpleITK Image. How can I do it? >> >> Thanks >> >> -- >> *Jos? Oswaldo Cavalcante da Silva Filho* >> >> Mestrando em Inform?tica pela Universidade Federal de Alagoas >> Professor da Faculdade de Tecnologia de Alagoas >> http://lattes.cnpq.br/0516674124789514 >> >> -- >> *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m >> por pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. >> Knuth] >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community >> >> >> > > > -- > *Jos? Oswaldo Cavalcante da Silva Filho* > > Mestrando em Inform?tica pela Universidade Federal de Alagoas > Professor da Faculdade de Tecnologia de Alagoas > http://lattes.cnpq.br/0516674124789514 > > -- > *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por > pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. Knuth] > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > > > -- *Jos? Oswaldo Cavalcante da Silva Filho* Mestrando em Inform?tica pela Universidade Federal de Alagoas Professor da Faculdade de Tecnologia de Alagoas http://lattes.cnpq.br/0516674124789514 -- *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. Knuth] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocmail at gmail.com Tue Nov 4 09:04:51 2014 From: jocmail at gmail.com (Oswaldo Cavalcante) Date: Tue, 4 Nov 2014 11:04:51 -0300 Subject: [ITK] SimpleITK for Java in Ubuntu 32-bit In-Reply-To: <38E3FA32-153F-4934-8A30-83CA3E0C967E@mail.nih.gov> References: <342E2471-C535-4D8D-A7F3-A56FFF633494@gmail.com> <38E3FA32-153F-4934-8A30-83CA3E0C967E@mail.nih.gov> Message-ID: Hello, Thanks! I've tried again and I finally got the right binaries and native libraries for Java. About the conversion from Java BufferedImage, there is any way to import a Java Image to SimpleITK? I'm working with binary images, so could I convert my images in a binary matrix or array, and so convert it into a SimpleITK Image? I've seen that in Matlab exists a GetImageFromArray method, using a specific numpy array, but I didn't find something like this for Java. Thanks 2014-11-03 15:22 GMT-03:00 Bradley Lowekamp : > Hello, > > The default configuration build ITK and SimpleITK as static libraries, and > then the SWIG layer generates a shared libraries with the other libraries > statically linked. This produces a smaller and more efficient runtime > library which in most cases is preferred during run time, and has a simpler > installation. This is at the trade off of requiring more system resources > when building/linking. I would recommend utilizing a system with the > required resources when building. > > Alternatively, you can enable shared libraries in the CMake configuration. > This will build ITK, and the SimpleITK core as shared libraries, are > greatly reduce the requirements to link. > > While the SimpleITK/SWIG interface could provide a native buffer interface > the way that it's done in Python and C#, no one has implemented it yet. > Contributions are very much welcomed! > > Brad > > On Nov 3, 2014, at 12:55 PM, Oswaldo Cavalcante wrote: > > Thanks! > > In fact, I've tried to compile, but I got errors in two different > machines. When the file libSimpleITKJava.so is being generated, the memory > uses increases a lot (about further 4 Gb!!), so the process is stopped with > a message like this: 'error: no enough memory'. I've tried several times, > but I couldn't generate the native libs. > > Another doubt, is that i'm trying and searching about to cast or in some > way use a Java BufferedImage in the SimpleITK. How can I do it? > > Thanks a lot! > > 2014-11-03 14:39 GMT-03:00 : > >> Hi >> >> the thing is that we can not provide binaries for each platform / OS. >> Especially that there would be a lot of languages and combinations to >> support (python, java, 32 bit, 64 bit ?). You may have to build SimpleITK >> by yourself. You can find instructions for this here [1]. You will need >> cmake for this. Please look at the super build part. >> >> Michka >> >> [1] http://www.itk.org/Wiki/SimpleITK/GettingStarted >> >> On 03 Nov 2014, at 17:47, Oswaldo Cavalcante wrote: >> >> Hello, >> >> I'm trying to learn and use SimpleITK wrapped for Java in my project, but >> I would like to code on Ubuntu. Unfortunately, there is no binaries for >> 32-bit on the SimpleITK downloads page. >> >> Could someone help me sending these binaries? Especially the native >> libraries for Java in 32-bit architecture, the file "libSimpleITKJava.so". >> >> Another question, is that i'm trying and searching about to cast or in >> some way use a Java BufferedImage in the SimpleITK Image. How can I do it? >> >> Thanks >> >> -- >> *Jos? Oswaldo Cavalcante da Silva Filho* >> >> Mestrando em Inform?tica pela Universidade Federal de Alagoas >> Professor da Faculdade de Tecnologia de Alagoas >> http://lattes.cnpq.br/0516674124789514 >> >> -- >> *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m >> por pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. >> Knuth] >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community >> >> >> > > > -- > *Jos? Oswaldo Cavalcante da Silva Filho* > > Mestrando em Inform?tica pela Universidade Federal de Alagoas > Professor da Faculdade de Tecnologia de Alagoas > http://lattes.cnpq.br/0516674124789514 > > -- > *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por > pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. Knuth] > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > > > -- *Jos? Oswaldo Cavalcante da Silva Filho* Mestrando em Inform?tica pela Universidade Federal de Alagoas Professor da Faculdade de Tecnologia de Alagoas http://lattes.cnpq.br/0516674124789514 -- *"Deus deseja que a B?blia seja lida por homens de ci?ncia como tamb?m por pessoas que n?o t?m essas maneiras estranhas de pensar" *[Donald E. Knuth] -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Tue Nov 4 09:14:51 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 4 Nov 2014 09:14:51 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Message-ID: That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? Brad On Nov 4, 2014, at 3:51 AM, wrote: > Hi all, > > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? > > Regards, Marius > >> -----Original Message----- >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On >> Behalf Of Matt McCormick >> Sent: maandag 3 november 2014 18:39 >> To: brian avants >> Cc: Insight-developers at itk.org >> Subject: Re: [ITK-dev] image and deformation field physical space check >> >> Hi Brian, >> >> Thanks for discussing this. >> >> I think a combination of fixing the underlying issue that is being brought up by >> the exception, relaxing the tolerance, and improving the documentation is a >> good approach. >> >> 2 cents, >> Matt >> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: >>> This email is motivated by this issue: >>> >>> https://github.com/stnava/ANTs/issues/74 >>> >>> but it is not isolated to ants. Worth a read for additional context. >>> >>> ITK currently enforces a relatively strict check that image and >>> displacement fields "occupy the same physical space." However, for >>> some unclear (to me) reasons, the direction matrices or origins of >>> images can lose precision when passing through ITK pipelines ( >>> especially through resampling or resolution-changing filters ). This >>> results in filters aborting and this can occur at various different >>> places in a complex series of ITK-based operations. >>> >>> My concern with this is that it can lead to a very severe loss of >>> productivity when this somewhat unpredictable error occurs. For instance, >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>> brainsfit, joint label fusion, etc). The user expects registration or >>> segmentation filters to "work well" especially when the data is of a >>> standard sort. Then, after some oft-substantial execution time, this >>> mysterious error appears: >>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>> the same physical space! >>> >>> >>> While I am all for correctness, when the impact on productivity exceeds a >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps >>> one of these would improve the situation: >>> >>> 1) change: >>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>> Transform.hxx >>> >>> and >>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>> 454-L457 >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>> >>> and change the documentation too: >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>> >>> 2) Change the exception to a warning. This would at least allow >>> complex pipelines to execute while notifying the user of a possible issue. >>> >>> 3) Document all of the places that the user/developer should call: >>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>> >>> This last solution would require adding Set/GetCoordinate and >>> Direction tolerance to: >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>> >>> as well, for consistency. >>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >>> by this check. >>> >>> Not once has this check actually helped us, in any measurable way, >>> avoid errors. >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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 > _______________________________________________ > 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 _______________________________________________ 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 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] [ITK-users] Error compiling msvc2010 + ITK4.6 + Qt In-Reply-To: References: <5446873A.7070500@imnc.in2p3.fr> <930E7D31-ACFE-4ECF-8EAD-E8D3B6081B92@mail.nih.gov> <54475B84.5020906@imnc.in2p3.fr> <54492AB3.2030006@imnc.in2p3.fr> <544A073B.4080905@imnc.in2p3.fr> 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 > > 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 > > > 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 > > 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 > >> > 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 > >>>>> > > >>>>> 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 > > > -- 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: -------------- next part -------------- _____________________________________ 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 stnava at gmail.com Tue Nov 4 09:21:42 2014 From: stnava at gmail.com (brian avants) Date: Tue, 4 Nov 2014 09:21:42 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Message-ID: i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. brian On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp wrote: > That is a question: why is an exact copy not happening? Is is due to > runtime errors or accumulation of errors during IO? > > Brad > > > On Nov 4, 2014, at 3:51 AM, wrote: > > > Hi all, > > > > Would it be possible to fix this issue by passing the physical space by > reference, or by performing an exact copy? > > > > Regards, Marius > > > >> -----Original Message----- > >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On > >> Behalf Of Matt McCormick > >> Sent: maandag 3 november 2014 18:39 > >> To: brian avants > >> Cc: Insight-developers at itk.org > >> Subject: Re: [ITK-dev] image and deformation field physical space check > >> > >> Hi Brian, > >> > >> Thanks for discussing this. > >> > >> I think a combination of fixing the underlying issue that is being > brought up by > >> the exception, relaxing the tolerance, and improving the documentation > is a > >> good approach. > >> > >> 2 cents, > >> Matt > >> > >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: > >>> This email is motivated by this issue: > >>> > >>> https://github.com/stnava/ANTs/issues/74 > >>> > >>> but it is not isolated to ants. Worth a read for additional context. > >>> > >>> ITK currently enforces a relatively strict check that image and > >>> displacement fields "occupy the same physical space." However, for > >>> some unclear (to me) reasons, the direction matrices or origins of > >>> images can lose precision when passing through ITK pipelines ( > >>> especially through resampling or resolution-changing filters ). This > >>> results in filters aborting and this can occur at various different > >>> places in a complex series of ITK-based operations. > >>> > >>> My concern with this is that it can lead to a very severe loss of > >>> productivity when this somewhat unpredictable error occurs. For > instance, > >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, > >>> brainsfit, joint label fusion, etc). The user expects registration or > >>> segmentation filters to "work well" especially when the data is of a > >>> standard sort. Then, after some oft-substantial execution time, this > >>> mysterious error appears: > >>> > >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy > >>> the same physical space! > >>> > >>> > >>> While I am all for correctness, when the impact on productivity > exceeds a > >>> certain threshold, I think it is useful to bend the rules a bit. > Perhaps > >>> one of these would improve the situation: > >>> > >>> 1) change: > >>> > >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField > >>> Transform.hxx > >>> > >>> and > >>> > >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx > >>> > >>> changing direction tolerance and coordinate tolerance to 1.e-4 > >>> > >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F > >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L > >>> 454-L457 > >>> > >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C > >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 > >>> > >>> and change the documentation too: > >>> > >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C > >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 > >>> > >>> 2) Change the exception to a warning. This would at least allow > >>> complex pipelines to execute while notifying the user of a possible > issue. > >>> > >>> 3) Document all of the places that the user/developer should call: > >>> > >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . > >>> > >>> This last solution would require adding Set/GetCoordinate and > >>> Direction tolerance to: > >>> > >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F > >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h > >>> > >>> as well, for consistency. > >>> > >>> Anyway, I raise this issue b/c of the many man and computer hours lost > >>> by this check. > >>> > >>> Not once has this check actually helped us, in any measurable way, > >>> avoid errors. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >>> > >> _______________________________________________ > >> 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 > > _______________________________________________ > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 blowekamp at mail.nih.gov Tue Nov 4 09:26:06 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 4 Nov 2014 09:26:06 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Message-ID: I agree that would be good. The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one? Brad On Nov 4, 2014, at 9:21 AM, brian avants wrote: > i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. > > > brian > > > > On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp wrote: > That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? > > Brad > > > On Nov 4, 2014, at 3:51 AM, wrote: > > > Hi all, > > > > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? > > > > Regards, Marius > > > >> -----Original Message----- > >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On > >> Behalf Of Matt McCormick > >> Sent: maandag 3 november 2014 18:39 > >> To: brian avants > >> Cc: Insight-developers at itk.org > >> Subject: Re: [ITK-dev] image and deformation field physical space check > >> > >> Hi Brian, > >> > >> Thanks for discussing this. > >> > >> I think a combination of fixing the underlying issue that is being brought up by > >> the exception, relaxing the tolerance, and improving the documentation is a > >> good approach. > >> > >> 2 cents, > >> Matt > >> > >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: > >>> This email is motivated by this issue: > >>> > >>> https://github.com/stnava/ANTs/issues/74 > >>> > >>> but it is not isolated to ants. Worth a read for additional context. > >>> > >>> ITK currently enforces a relatively strict check that image and > >>> displacement fields "occupy the same physical space." However, for > >>> some unclear (to me) reasons, the direction matrices or origins of > >>> images can lose precision when passing through ITK pipelines ( > >>> especially through resampling or resolution-changing filters ). This > >>> results in filters aborting and this can occur at various different > >>> places in a complex series of ITK-based operations. > >>> > >>> My concern with this is that it can lead to a very severe loss of > >>> productivity when this somewhat unpredictable error occurs. For instance, > >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, > >>> brainsfit, joint label fusion, etc). The user expects registration or > >>> segmentation filters to "work well" especially when the data is of a > >>> standard sort. Then, after some oft-substantial execution time, this > >>> mysterious error appears: > >>> > >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy > >>> the same physical space! > >>> > >>> > >>> While I am all for correctness, when the impact on productivity exceeds a > >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps > >>> one of these would improve the situation: > >>> > >>> 1) change: > >>> > >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField > >>> Transform.hxx > >>> > >>> and > >>> > >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx > >>> > >>> changing direction tolerance and coordinate tolerance to 1.e-4 > >>> > >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F > >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L > >>> 454-L457 > >>> > >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C > >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 > >>> > >>> and change the documentation too: > >>> > >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C > >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 > >>> > >>> 2) Change the exception to a warning. This would at least allow > >>> complex pipelines to execute while notifying the user of a possible issue. > >>> > >>> 3) Document all of the places that the user/developer should call: > >>> > >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . > >>> > >>> This last solution would require adding Set/GetCoordinate and > >>> Direction tolerance to: > >>> > >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F > >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h > >>> > >>> as well, for consistency. > >>> > >>> Anyway, I raise this issue b/c of the many man and computer hours lost > >>> by this check. > >>> > >>> Not once has this check actually helped us, in any measurable way, > >>> avoid errors. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >>> > >> _______________________________________________ > >> 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 > > _______________________________________________ > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 stnava at gmail.com Tue Nov 4 09:28:48 2014 From: stnava at gmail.com (brian avants) Date: Tue, 4 Nov 2014 09:28:48 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Message-ID: so - just to be clear ... same thing needs to be done here: ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance Set/GetDirectionTolerance which already exists in the image to image filter (but not displacement field)? brian On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp wrote: > I agree that would be good. > > The other thing which can be done concurrently is add the > ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer > for that one? > > Brad > > On Nov 4, 2014, at 9:21 AM, brian avants wrote: > > i guess the next step is to dig up a couple of examples of this behavior > and post them somewhere. > > > brian > > > > On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp > wrote: > >> That is a question: why is an exact copy not happening? Is is due to >> runtime errors or accumulation of errors during IO? >> >> Brad >> >> >> On Nov 4, 2014, at 3:51 AM, >> wrote: >> >> > Hi all, >> > >> > Would it be possible to fix this issue by passing the physical space by >> reference, or by performing an exact copy? >> > >> > Regards, Marius >> > >> >> -----Original Message----- >> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] >> On >> >> Behalf Of Matt McCormick >> >> Sent: maandag 3 november 2014 18:39 >> >> To: brian avants >> >> Cc: Insight-developers at itk.org >> >> Subject: Re: [ITK-dev] image and deformation field physical space check >> >> >> >> Hi Brian, >> >> >> >> Thanks for discussing this. >> >> >> >> I think a combination of fixing the underlying issue that is being >> brought up by >> >> the exception, relaxing the tolerance, and improving the documentation >> is a >> >> good approach. >> >> >> >> 2 cents, >> >> Matt >> >> >> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants >> wrote: >> >>> This email is motivated by this issue: >> >>> >> >>> https://github.com/stnava/ANTs/issues/74 >> >>> >> >>> but it is not isolated to ants. Worth a read for additional context. >> >>> >> >>> ITK currently enforces a relatively strict check that image and >> >>> displacement fields "occupy the same physical space." However, for >> >>> some unclear (to me) reasons, the direction matrices or origins of >> >>> images can lose precision when passing through ITK pipelines ( >> >>> especially through resampling or resolution-changing filters ). This >> >>> results in filters aborting and this can occur at various different >> >>> places in a complex series of ITK-based operations. >> >>> >> >>> My concern with this is that it can lead to a very severe loss of >> >>> productivity when this somewhat unpredictable error occurs. For >> instance, >> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >> >>> brainsfit, joint label fusion, etc). The user expects registration >> or >> >>> segmentation filters to "work well" especially when the data is of a >> >>> standard sort. Then, after some oft-substantial execution time, this >> >>> mysterious error appears: >> >>> >> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >> >>> the same physical space! >> >>> >> >>> >> >>> While I am all for correctness, when the impact on productivity >> exceeds a >> >>> certain threshold, I think it is useful to bend the rules a bit. >> Perhaps >> >>> one of these would improve the situation: >> >>> >> >>> 1) change: >> >>> >> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >> >>> Transform.hxx >> >>> >> >>> and >> >>> >> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >> >>> >> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >> >>> >> >>> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >> >>> 454-L457 >> >>> >> >>> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >> >>> >> >>> and change the documentation too: >> >>> >> >>> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >> >>> >> >>> 2) Change the exception to a warning. This would at least allow >> >>> complex pipelines to execute while notifying the user of a possible >> issue. >> >>> >> >>> 3) Document all of the places that the user/developer should call: >> >>> >> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >> >>> >> >>> This last solution would require adding Set/GetCoordinate and >> >>> Direction tolerance to: >> >>> >> >>> >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >> >>> >> >>> as well, for consistency. >> >>> >> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >> >>> by this check. >> >>> >> >>> Not once has this check actually helped us, in any measurable way, >> >>> avoid errors. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >>> >> >> _______________________________________________ >> >> 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 >> > _______________________________________________ >> > 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 >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 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] [ITK-users] Loading a specifing region of an image from disk In-Reply-To: References: <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov> Message-ID: Discussion inline below: On Nov 3, 2014, at 5:58 PM, Pol Mons? Purt? 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: -------------- next part -------------- _____________________________________ 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 4 09:54:50 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 4 Nov 2014 09:54:50 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Message-ID: Was it just the DisplacementFieldTransform being the problem or was it other filters in general and randomly? The proposed new variable should be a static member variable of ImageToImageFilter, hence the term global. It would be used to set the value here, instead of a constant [1]. This is similar to the GlobalDefaultNumberOfThreaders, as it effects the initial value for all new filters. The complication is that this base class is templated, and this global need to transcend the templates. A similar things was done with the ImageSource class by adding a second private parent without templates [2], [3]. The complexity there with lazy initialization is not needed for this case, as we just have a simple float. Additionally I have developed a preference for private namespace local statics for this type of case, as it produces a cleaner symbol table for shared libraries. Clearly for the DisplacementField, the tolerance variables should be exposed similarly as done in the ImageToImageFilter. And it could pull the default from the variable from above, however getting the default for a transform from a filter may not make since. [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 On Nov 4, 2014, at 9:28 AM, brian avants wrote: > so - just to be clear ... same thing needs to be done here: > > ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h > > and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance Set/GetDirectionTolerance > > which already exists in the image to image filter (but not displacement field)? > > > > brian > > > > On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp wrote: > I agree that would be good. > > The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one? > > Brad > > On Nov 4, 2014, at 9:21 AM, brian avants wrote: > >> i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. >> >> >> brian >> >> >> >> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp wrote: >> That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? >> >> Brad >> >> >> On Nov 4, 2014, at 3:51 AM, wrote: >> >> > Hi all, >> > >> > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? >> > >> > Regards, Marius >> > >> >> -----Original Message----- >> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On >> >> Behalf Of Matt McCormick >> >> Sent: maandag 3 november 2014 18:39 >> >> To: brian avants >> >> Cc: Insight-developers at itk.org >> >> Subject: Re: [ITK-dev] image and deformation field physical space check >> >> >> >> Hi Brian, >> >> >> >> Thanks for discussing this. >> >> >> >> I think a combination of fixing the underlying issue that is being brought up by >> >> the exception, relaxing the tolerance, and improving the documentation is a >> >> good approach. >> >> >> >> 2 cents, >> >> Matt >> >> >> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: >> >>> This email is motivated by this issue: >> >>> >> >>> https://github.com/stnava/ANTs/issues/74 >> >>> >> >>> but it is not isolated to ants. Worth a read for additional context. >> >>> >> >>> ITK currently enforces a relatively strict check that image and >> >>> displacement fields "occupy the same physical space." However, for >> >>> some unclear (to me) reasons, the direction matrices or origins of >> >>> images can lose precision when passing through ITK pipelines ( >> >>> especially through resampling or resolution-changing filters ). This >> >>> results in filters aborting and this can occur at various different >> >>> places in a complex series of ITK-based operations. >> >>> >> >>> My concern with this is that it can lead to a very severe loss of >> >>> productivity when this somewhat unpredictable error occurs. For instance, >> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >> >>> brainsfit, joint label fusion, etc). The user expects registration or >> >>> segmentation filters to "work well" especially when the data is of a >> >>> standard sort. Then, after some oft-substantial execution time, this >> >>> mysterious error appears: >> >>> >> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >> >>> the same physical space! >> >>> >> >>> >> >>> While I am all for correctness, when the impact on productivity exceeds a >> >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps >> >>> one of these would improve the situation: >> >>> >> >>> 1) change: >> >>> >> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >> >>> Transform.hxx >> >>> >> >>> and >> >>> >> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >> >>> >> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >> >>> >> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >> >>> 454-L457 >> >>> >> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >> >>> >> >>> and change the documentation too: >> >>> >> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >> >>> >> >>> 2) Change the exception to a warning. This would at least allow >> >>> complex pipelines to execute while notifying the user of a possible issue. >> >>> >> >>> 3) Document all of the places that the user/developer should call: >> >>> >> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >> >>> >> >>> This last solution would require adding Set/GetCoordinate and >> >>> Direction tolerance to: >> >>> >> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >> >>> >> >>> as well, for consistency. >> >>> >> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >> >>> by this check. >> >>> >> >>> Not once has this check actually helped us, in any measurable way, >> >>> avoid errors. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >>> >> >> _______________________________________________ >> >> 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 >> > _______________________________________________ >> > 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 >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 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] [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/ . _____________________________________ 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 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] [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/ . -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Loading a specifing region of an image from disk In-Reply-To: References: <42A21489-BD3B-47A3-954F-CF6429EC6F13@mail.nih.gov> Message-ID: 2014-11-04 15:31 GMT+01:00 Bradley Lowekamp : > Discussion inline below: > > On Nov 3, 2014, at 5:58 PM, Pol Mons? Purt? 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 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 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: -------------- next part -------------- _____________________________________ 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 stnava at gmail.com Tue Nov 4 15:37:17 2014 From: stnava at gmail.com (brian avants) Date: Tue, 4 Nov 2014 15:37:17 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Message-ID: this example exhibits the problematic behavior (CentOS release 6.3 ) https://copy.com/6imJcj9ZuAGoQVtG reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST brian On Tue, Nov 4, 2014 at 9:54 AM, Bradley Lowekamp wrote: > > Was it just the DisplacementFieldTransform being the problem or was it > other filters in general and randomly? > > The proposed new variable should be a static member variable of > ImageToImageFilter, hence the term global. It would be used to set the > value here, instead of a constant [1]. This is similar to the > GlobalDefaultNumberOfThreaders, as it effects the initial value for all new > filters. The complication is that this base class is templated, and this > global need to transcend the templates. A similar things was done with the > ImageSource class by adding a second private parent without templates [2], > [3]. The complexity there with lazy initialization is not needed for this > case, as we just have a simple float. Additionally I have developed a > preference for private namespace local statics for this type of case, as it > produces a cleaner symbol table for shared libraries. > > Clearly for the DisplacementField, the tolerance variables should be > exposed similarly as done in the ImageToImageFilter. And it could pull the > default from the variable from above, however getting the default for a > transform from a filter may not make since. > > > > > [1] > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 > [2] > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 > [3] > https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 > > > > On Nov 4, 2014, at 9:28 AM, brian avants wrote: > > so - just to be clear ... same thing needs to be done here: > > > ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h > > and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance > Set/GetDirectionTolerance > > which already exists in the image to image filter (but not displacement > field)? > > > brian > > > > On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp > wrote: > >> I agree that would be good. >> >> The other thing which can be done concurrently is add the >> ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer >> for that one? >> >> Brad >> >> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >> >> i guess the next step is to dig up a couple of examples of this behavior >> and post them somewhere. >> >> >> brian >> >> >> >> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp >> wrote: >> >>> That is a question: why is an exact copy not happening? Is is due to >>> runtime errors or accumulation of errors during IO? >>> >>> Brad >>> >>> >>> On Nov 4, 2014, at 3:51 AM, >>> wrote: >>> >>> > Hi all, >>> > >>> > Would it be possible to fix this issue by passing the physical space >>> by reference, or by performing an exact copy? >>> > >>> > Regards, Marius >>> > >>> >> -----Original Message----- >>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] >>> On >>> >> Behalf Of Matt McCormick >>> >> Sent: maandag 3 november 2014 18:39 >>> >> To: brian avants >>> >> Cc: Insight-developers at itk.org >>> >> Subject: Re: [ITK-dev] image and deformation field physical space >>> check >>> >> >>> >> Hi Brian, >>> >> >>> >> Thanks for discussing this. >>> >> >>> >> I think a combination of fixing the underlying issue that is being >>> brought up by >>> >> the exception, relaxing the tolerance, and improving the >>> documentation is a >>> >> good approach. >>> >> >>> >> 2 cents, >>> >> Matt >>> >> >>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants >>> wrote: >>> >>> This email is motivated by this issue: >>> >>> >>> >>> https://github.com/stnava/ANTs/issues/74 >>> >>> >>> >>> but it is not isolated to ants. Worth a read for additional >>> context. >>> >>> >>> >>> ITK currently enforces a relatively strict check that image and >>> >>> displacement fields "occupy the same physical space." However, for >>> >>> some unclear (to me) reasons, the direction matrices or origins of >>> >>> images can lose precision when passing through ITK pipelines ( >>> >>> especially through resampling or resolution-changing filters ). This >>> >>> results in filters aborting and this can occur at various different >>> >>> places in a complex series of ITK-based operations. >>> >>> >>> >>> My concern with this is that it can lead to a very severe loss of >>> >>> productivity when this somewhat unpredictable error occurs. For >>> instance, >>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>> >>> brainsfit, joint label fusion, etc). The user expects registration >>> or >>> >>> segmentation filters to "work well" especially when the data is of a >>> >>> standard sort. Then, after some oft-substantial execution time, >>> this >>> >>> mysterious error appears: >>> >>> >>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>> >>> the same physical space! >>> >>> >>> >>> >>> >>> While I am all for correctness, when the impact on productivity >>> exceeds a >>> >>> certain threshold, I think it is useful to bend the rules a bit. >>> Perhaps >>> >>> one of these would improve the situation: >>> >>> >>> >>> 1) change: >>> >>> >>> >>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>> >>> Transform.hxx >>> >>> >>> >>> and >>> >>> >>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>> >>> >>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>> >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>> >>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>> >>> 454-L457 >>> >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>> >>> >>> >>> and change the documentation too: >>> >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>> >>> >>> >>> 2) Change the exception to a warning. This would at least allow >>> >>> complex pipelines to execute while notifying the user of a possible >>> issue. >>> >>> >>> >>> 3) Document all of the places that the user/developer should call: >>> >>> >>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>> >>> >>> >>> This last solution would require adding Set/GetCoordinate and >>> >>> Direction tolerance to: >>> >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>> >>> >>> >>> as well, for consistency. >>> >>> >>> >>> Anyway, I raise this issue b/c of the many man and computer hours >>> lost >>> >>> by this check. >>> >>> >>> >>> Not once has this check actually helped us, in any measurable way, >>> >>> avoid errors. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >>> >>> >> _______________________________________________ >>> >> 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 >>> > _______________________________________________ >>> > 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 >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 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] [ITK-users] SimpleITK - Reading different DICOM serie In-Reply-To: References: Message-ID: 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 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 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 >> *Subject: **[ITK-users] SimpleITK - Reading different DICOM serie* >> *Date: *October 31, 2014 at 7:03:36 PM EDT >> *To: *"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: -------------- next part -------------- _____________________________________ 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 ehrhardt at imi.uni-luebeck.de Wed Nov 5 05:29:58 2014 From: ehrhardt at imi.uni-luebeck.de (Jan Ehrhardt) Date: Wed, 5 Nov 2014 11:29:58 +0100 (CET) Subject: [ITK] Behaviour of KdTreeBasedKmeansEstimator Message-ID: <57157.84.140.35.3.1415183398.squirrel@mail.uni-luebeck.de> Hi folks, I want to implement k-means clustering of sample measurement vectors and started with the example codes provided in http://www.itk.org/Doxygen45/html/Statistics_2KdTreeBasedKMeansClustering_8cxx-example.html and http://www.itk.org/Wiki/ITK/Examples/Statistics/KdTreeBasedKmeansEstimator Both examples work, but small changes to the code results in unexpected behaviour. If the standard deviation in KdTreeBasedKMeansClustering.cxx is reduced (e.g. to 5), the algorithm is not able to find the correct clusters with centroid 100 and 200. Instead clusters with centroid 150 and 0 are found. Is this an intended behaviour? Reducing the standard deviation should provide a better separation of the two classes. The wiki example will crash if the number of samples increases (Exception: vectors are not the same size (3 and 0)). The same happens, if I replace the WeightedCentroidKdTreeGenerator with KdTreeGenerator in KdTreeBasedKMeansClustering.cxx. The crash seems to be related to the bucket size and number of samples. Is this a bug in KdTreeGenerator? I'm serching for a robust n-dimensional clustering algorithm. Do you have any suggestions for alternative algorithms or to stabilze the behaviour of the KdTreeBasedKmeansEstimator? Thanks, Jan 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] [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. _____________________________________ 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 Wed Nov 5 09:25:48 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Wed, 5 Nov 2014 09:25:48 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Message-ID: <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov> Brian, This does not look like a simplified test case to illustrate the problem. Also it didn't work for me: [blowekamp at malawi PhysicalSpaceError]$ ./reg_subject_deform.sh antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ , deformed.nii.gz ] -r [ , , 1] -t Rigid[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [200x100x50,1e-8,10] -f 6x4x2 -s 4x3x1vox -t Affine[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [100x100x50x10,1e-8,10] -f 4x4x2x1 -s 4x2x1x0vox -t SyN[0.2,3,0] -m CC[, , 1, 2] -c [40x50x30,1e-9,10] -f 4x2x1 -s 2x1x0vox All_Command_lines_OK Using single precision for computations. bad file name Exception Object caught: itk::ExceptionObject (0x7fcb90f1ca88) Location: "virtual void itk::CenteredTransformInitializer, itk::Image, itk::Image >::InitializeTransform() [TTransform = itk::Euler3DTransform, TFixedImage = itk::Image, TMovingImage = itk::Image]" File: /scratch/blowekamp/build/ANTS/ITKv4-install/include/ITK-4.7/itkCenteredTransformInitializer.hxx Line: 42 Description: itk::ERROR: CenteredTransformInitializer(0x7fcb90f1c4b0): Fixed Image has not been set Brad On Nov 4, 2014, at 3:37 PM, brian avants wrote: > this example exhibits the problematic behavior (CentOS release 6.3 ) > > https://copy.com/6imJcj9ZuAGoQVtG > > reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST > > > > > > brian > > > > On Tue, Nov 4, 2014 at 9:54 AM, Bradley Lowekamp wrote: > > Was it just the DisplacementFieldTransform being the problem or was it other filters in general and randomly? > > The proposed new variable should be a static member variable of ImageToImageFilter, hence the term global. It would be used to set the value here, instead of a constant [1]. This is similar to the GlobalDefaultNumberOfThreaders, as it effects the initial value for all new filters. The complication is that this base class is templated, and this global need to transcend the templates. A similar things was done with the ImageSource class by adding a second private parent without templates [2], [3]. The complexity there with lazy initialization is not needed for this case, as we just have a simple float. Additionally I have developed a preference for private namespace local statics for this type of case, as it produces a cleaner symbol table for shared libraries. > > Clearly for the DisplacementField, the tolerance variables should be exposed similarly as done in the ImageToImageFilter. And it could pull the default from the variable from above, however getting the default for a transform from a filter may not make since. > > > > > [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 > [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 > [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 > > > > On Nov 4, 2014, at 9:28 AM, brian avants wrote: > >> so - just to be clear ... same thing needs to be done here: >> >> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >> >> and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance Set/GetDirectionTolerance >> >> which already exists in the image to image filter (but not displacement field)? >> >> >> >> brian >> >> >> >> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp wrote: >> I agree that would be good. >> >> The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one? >> >> Brad >> >> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >> >>> i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. >>> >>> >>> brian >>> >>> >>> >>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp wrote: >>> That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? >>> >>> Brad >>> >>> >>> On Nov 4, 2014, at 3:51 AM, wrote: >>> >>> > Hi all, >>> > >>> > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? >>> > >>> > Regards, Marius >>> > >>> >> -----Original Message----- >>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On >>> >> Behalf Of Matt McCormick >>> >> Sent: maandag 3 november 2014 18:39 >>> >> To: brian avants >>> >> Cc: Insight-developers at itk.org >>> >> Subject: Re: [ITK-dev] image and deformation field physical space check >>> >> >>> >> Hi Brian, >>> >> >>> >> Thanks for discussing this. >>> >> >>> >> I think a combination of fixing the underlying issue that is being brought up by >>> >> the exception, relaxing the tolerance, and improving the documentation is a >>> >> good approach. >>> >> >>> >> 2 cents, >>> >> Matt >>> >> >>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: >>> >>> This email is motivated by this issue: >>> >>> >>> >>> https://github.com/stnava/ANTs/issues/74 >>> >>> >>> >>> but it is not isolated to ants. Worth a read for additional context. >>> >>> >>> >>> ITK currently enforces a relatively strict check that image and >>> >>> displacement fields "occupy the same physical space." However, for >>> >>> some unclear (to me) reasons, the direction matrices or origins of >>> >>> images can lose precision when passing through ITK pipelines ( >>> >>> especially through resampling or resolution-changing filters ). This >>> >>> results in filters aborting and this can occur at various different >>> >>> places in a complex series of ITK-based operations. >>> >>> >>> >>> My concern with this is that it can lead to a very severe loss of >>> >>> productivity when this somewhat unpredictable error occurs. For instance, >>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>> >>> brainsfit, joint label fusion, etc). The user expects registration or >>> >>> segmentation filters to "work well" especially when the data is of a >>> >>> standard sort. Then, after some oft-substantial execution time, this >>> >>> mysterious error appears: >>> >>> >>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>> >>> the same physical space! >>> >>> >>> >>> >>> >>> While I am all for correctness, when the impact on productivity exceeds a >>> >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps >>> >>> one of these would improve the situation: >>> >>> >>> >>> 1) change: >>> >>> >>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>> >>> Transform.hxx >>> >>> >>> >>> and >>> >>> >>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>> >>> >>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>> >>> 454-L457 >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>> >>> >>> >>> and change the documentation too: >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>> >>> >>> >>> 2) Change the exception to a warning. This would at least allow >>> >>> complex pipelines to execute while notifying the user of a possible issue. >>> >>> >>> >>> 3) Document all of the places that the user/developer should call: >>> >>> >>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>> >>> >>> >>> This last solution would require adding Set/GetCoordinate and >>> >>> Direction tolerance to: >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>> >>> >>> >>> as well, for consistency. >>> >>> >>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >>> >>> by this check. >>> >>> >>> >>> Not once has this check actually helped us, in any measurable way, >>> >>> avoid errors. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >>> >>> >> _______________________________________________ >>> >> 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 >>> > _______________________________________________ >>> > 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 >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 stnava at gmail.com Wed Nov 5 09:34:16 2014 From: stnava at gmail.com (brian avants) Date: Wed, 5 Nov 2014 09:34:16 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov> References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov> Message-ID: just to be clear: it should be called in this way reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST i could not find an itk test that covers the 3D case of multiple stages ... if someone knows of one, let me know. brian On Wed, Nov 5, 2014 at 9:25 AM, Bradley Lowekamp wrote: > Brian, > > This does not look like a simplified test case to illustrate the problem. > Also it didn't work for me: > > [blowekamp at malawi PhysicalSpaceError]$ ./reg_subject_deform.sh > antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ , > deformed.nii.gz ] -r [ , , 1] -t Rigid[0.1] -m MI[ , , 1, 32, Regular, > 0.25] -c [200x100x50,1e-8,10] -f 6x4x2 -s 4x3x1vox -t Affine[0.1] -m MI[ , > , 1, 32, Regular, 0.25] -c [100x100x50x10,1e-8,10] -f 4x4x2x1 -s 4x2x1x0vox > -t SyN[0.2,3,0] -m CC[, , 1, 2] -c [40x50x30,1e-9,10] -f 4x2x1 -s 2x1x0vox > All_Command_lines_OK > Using single precision for computations. > bad file name > Exception Object caught: > > itk::ExceptionObject (0x7fcb90f1ca88) > Location: "virtual void > itk::CenteredTransformInitializer, > itk::Image, itk::Image >::InitializeTransform() > [TTransform = itk::Euler3DTransform, TFixedImage = itk::Image 3>, TMovingImage = itk::Image]" > File: > /scratch/blowekamp/build/ANTS/ITKv4-install/include/ITK-4.7/itkCenteredTransformInitializer.hxx > Line: 42 > Description: itk::ERROR: CenteredTransformInitializer(0x7fcb90f1c4b0): > Fixed Image has not been set > > Brad > > On Nov 4, 2014, at 3:37 PM, brian avants wrote: > > this example exhibits the problematic behavior (CentOS release 6.3 ) > > https://copy.com/6imJcj9ZuAGoQVtG > > reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST > > > > > brian > > > > On Tue, Nov 4, 2014 at 9:54 AM, Bradley Lowekamp > wrote: > >> >> Was it just the DisplacementFieldTransform being the problem or was it >> other filters in general and randomly? >> >> The proposed new variable should be a static member variable of >> ImageToImageFilter, hence the term global. It would be used to set the >> value here, instead of a constant [1]. This is similar to the >> GlobalDefaultNumberOfThreaders, as it effects the initial value for all new >> filters. The complication is that this base class is templated, and this >> global need to transcend the templates. A similar things was done with the >> ImageSource class by adding a second private parent without templates [2], >> [3]. The complexity there with lazy initialization is not needed for this >> case, as we just have a simple float. Additionally I have developed a >> preference for private namespace local statics for this type of case, as it >> produces a cleaner symbol table for shared libraries. >> >> Clearly for the DisplacementField, the tolerance variables should be >> exposed similarly as done in the ImageToImageFilter. And it could pull the >> default from the variable from above, however getting the default for a >> transform from a filter may not make since. >> >> >> >> >> [1] >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >> [2] >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 >> [3] >> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 >> >> >> >> On Nov 4, 2014, at 9:28 AM, brian avants wrote: >> >> so - just to be clear ... same thing needs to be done here: >> >> >> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >> >> and how does Get/SetGlobalDefault differ from >> Set/GetCoordinateTolerance Set/GetDirectionTolerance >> >> which already exists in the image to image filter (but not displacement >> field)? >> >> >> brian >> >> >> >> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp >> wrote: >> >>> I agree that would be good. >>> >>> The other thing which can be done concurrently is add the >>> ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer >>> for that one? >>> >>> Brad >>> >>> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >>> >>> i guess the next step is to dig up a couple of examples of this behavior >>> and post them somewhere. >>> >>> >>> brian >>> >>> >>> >>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp >> > wrote: >>> >>>> That is a question: why is an exact copy not happening? Is is due to >>>> runtime errors or accumulation of errors during IO? >>>> >>>> Brad >>>> >>>> >>>> On Nov 4, 2014, at 3:51 AM, >>>> wrote: >>>> >>>> > Hi all, >>>> > >>>> > Would it be possible to fix this issue by passing the physical space >>>> by reference, or by performing an exact copy? >>>> > >>>> > Regards, Marius >>>> > >>>> >> -----Original Message----- >>>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] >>>> On >>>> >> Behalf Of Matt McCormick >>>> >> Sent: maandag 3 november 2014 18:39 >>>> >> To: brian avants >>>> >> Cc: Insight-developers at itk.org >>>> >> Subject: Re: [ITK-dev] image and deformation field physical space >>>> check >>>> >> >>>> >> Hi Brian, >>>> >> >>>> >> Thanks for discussing this. >>>> >> >>>> >> I think a combination of fixing the underlying issue that is being >>>> brought up by >>>> >> the exception, relaxing the tolerance, and improving the >>>> documentation is a >>>> >> good approach. >>>> >> >>>> >> 2 cents, >>>> >> Matt >>>> >> >>>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants >>>> wrote: >>>> >>> This email is motivated by this issue: >>>> >>> >>>> >>> https://github.com/stnava/ANTs/issues/74 >>>> >>> >>>> >>> but it is not isolated to ants. Worth a read for additional >>>> context. >>>> >>> >>>> >>> ITK currently enforces a relatively strict check that image and >>>> >>> displacement fields "occupy the same physical space." However, for >>>> >>> some unclear (to me) reasons, the direction matrices or origins of >>>> >>> images can lose precision when passing through ITK pipelines ( >>>> >>> especially through resampling or resolution-changing filters ). >>>> This >>>> >>> results in filters aborting and this can occur at various different >>>> >>> places in a complex series of ITK-based operations. >>>> >>> >>>> >>> My concern with this is that it can lead to a very severe loss of >>>> >>> productivity when this somewhat unpredictable error occurs. For >>>> instance, >>>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>>> >>> brainsfit, joint label fusion, etc). The user expects >>>> registration or >>>> >>> segmentation filters to "work well" especially when the data is of a >>>> >>> standard sort. Then, after some oft-substantial execution time, >>>> this >>>> >>> mysterious error appears: >>>> >>> >>>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>>> >>> the same physical space! >>>> >>> >>>> >>> >>>> >>> While I am all for correctness, when the impact on productivity >>>> exceeds a >>>> >>> certain threshold, I think it is useful to bend the rules a bit. >>>> Perhaps >>>> >>> one of these would improve the situation: >>>> >>> >>>> >>> 1) change: >>>> >>> >>>> >>> >>>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>>> >>> Transform.hxx >>>> >>> >>>> >>> and >>>> >>> >>>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>>> >>> >>>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>>> >>> >>>> >>> >>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>> >>> >>>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>>> >>> 454-L457 >>>> >>> >>>> >>> >>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>> >>> >>>> >>> and change the documentation too: >>>> >>> >>>> >>> >>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>>> >>> >>>> >>> 2) Change the exception to a warning. This would at least allow >>>> >>> complex pipelines to execute while notifying the user of a possible >>>> issue. >>>> >>> >>>> >>> 3) Document all of the places that the user/developer should call: >>>> >>> >>>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>>> >>> >>>> >>> This last solution would require adding Set/GetCoordinate and >>>> >>> Direction tolerance to: >>>> >>> >>>> >>> >>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>>> >>> >>>> >>> as well, for consistency. >>>> >>> >>>> >>> Anyway, I raise this issue b/c of the many man and computer hours >>>> lost >>>> >>> by this check. >>>> >>> >>>> >>> Not once has this check actually helped us, in any measurable way, >>>> >>> avoid errors. >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> 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 >>>> >>> >>>> >> _______________________________________________ >>>> >> 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 >>>> > _______________________________________________ >>>> > 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 >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 blowekamp at mail.nih.gov Wed Nov 5 10:07:06 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Wed, 5 Nov 2014 10:07:06 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov> Message-ID: Ahh yes, I see that in your original e-mail... I guess after downloading and building ANTs I forgot to go back to the original e-mail. This looks like a regular ANTs run not a minimal example to illustrate the problem. Can you please share what are the requirements to reproduce this problem and what you ruled out in the process of narrowing down the problem? I am hoping for something a little more isolated or easier to run than a long running registration process. Are all the iteration needed? Do the images need to be this big for the problem? I was thinking this was an issue with how the meta-data was propagate, computed or manage. Which would imply it some what independent of the size of the image. Thanks, Brad On Nov 5, 2014, at 9:34 AM, brian avants wrote: > just to be clear: it should be called in this way > > reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST > > i could not find an itk test that covers the 3D case of multiple stages ... if someone knows of one, let me know. > > > brian > > > > On Wed, Nov 5, 2014 at 9:25 AM, Bradley Lowekamp wrote: > Brian, > > This does not look like a simplified test case to illustrate the problem. Also it didn't work for me: > > [blowekamp at malawi PhysicalSpaceError]$ ./reg_subject_deform.sh > antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ , deformed.nii.gz ] -r [ , , 1] -t Rigid[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [200x100x50,1e-8,10] -f 6x4x2 -s 4x3x1vox -t Affine[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [100x100x50x10,1e-8,10] -f 4x4x2x1 -s 4x2x1x0vox -t SyN[0.2,3,0] -m CC[, , 1, 2] -c [40x50x30,1e-9,10] -f 4x2x1 -s 2x1x0vox > All_Command_lines_OK > Using single precision for computations. > bad file name > Exception Object caught: > > itk::ExceptionObject (0x7fcb90f1ca88) > Location: "virtual void itk::CenteredTransformInitializer, itk::Image, itk::Image >::InitializeTransform() [TTransform = itk::Euler3DTransform, TFixedImage = itk::Image, TMovingImage = itk::Image]" > File: /scratch/blowekamp/build/ANTS/ITKv4-install/include/ITK-4.7/itkCenteredTransformInitializer.hxx > Line: 42 > Description: itk::ERROR: CenteredTransformInitializer(0x7fcb90f1c4b0): Fixed Image has not been set > > Brad > > On Nov 4, 2014, at 3:37 PM, brian avants wrote: > >> this example exhibits the problematic behavior (CentOS release 6.3 ) >> >> https://copy.com/6imJcj9ZuAGoQVtG >> >> reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST >> >> >> >> >> >> brian >> >> >> >> On Tue, Nov 4, 2014 at 9:54 AM, Bradley Lowekamp wrote: >> >> Was it just the DisplacementFieldTransform being the problem or was it other filters in general and randomly? >> >> The proposed new variable should be a static member variable of ImageToImageFilter, hence the term global. It would be used to set the value here, instead of a constant [1]. This is similar to the GlobalDefaultNumberOfThreaders, as it effects the initial value for all new filters. The complication is that this base class is templated, and this global need to transcend the templates. A similar things was done with the ImageSource class by adding a second private parent without templates [2], [3]. The complexity there with lazy initialization is not needed for this case, as we just have a simple float. Additionally I have developed a preference for private namespace local statics for this type of case, as it produces a cleaner symbol table for shared libraries. >> >> Clearly for the DisplacementField, the tolerance variables should be exposed similarly as done in the ImageToImageFilter. And it could pull the default from the variable from above, however getting the default for a transform from a filter may not make since. >> >> >> >> >> [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 >> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 >> >> >> >> On Nov 4, 2014, at 9:28 AM, brian avants wrote: >> >>> so - just to be clear ... same thing needs to be done here: >>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >>> >>> and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance Set/GetDirectionTolerance >>> >>> which already exists in the image to image filter (but not displacement field)? >>> >>> >>> >>> brian >>> >>> >>> >>> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp wrote: >>> I agree that would be good. >>> >>> The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one? >>> >>> Brad >>> >>> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >>> >>>> i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. >>>> >>>> >>>> brian >>>> >>>> >>>> >>>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp wrote: >>>> That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? >>>> >>>> Brad >>>> >>>> >>>> On Nov 4, 2014, at 3:51 AM, wrote: >>>> >>>> > Hi all, >>>> > >>>> > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? >>>> > >>>> > Regards, Marius >>>> > >>>> >> -----Original Message----- >>>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On >>>> >> Behalf Of Matt McCormick >>>> >> Sent: maandag 3 november 2014 18:39 >>>> >> To: brian avants >>>> >> Cc: Insight-developers at itk.org >>>> >> Subject: Re: [ITK-dev] image and deformation field physical space check >>>> >> >>>> >> Hi Brian, >>>> >> >>>> >> Thanks for discussing this. >>>> >> >>>> >> I think a combination of fixing the underlying issue that is being brought up by >>>> >> the exception, relaxing the tolerance, and improving the documentation is a >>>> >> good approach. >>>> >> >>>> >> 2 cents, >>>> >> Matt >>>> >> >>>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: >>>> >>> This email is motivated by this issue: >>>> >>> >>>> >>> https://github.com/stnava/ANTs/issues/74 >>>> >>> >>>> >>> but it is not isolated to ants. Worth a read for additional context. >>>> >>> >>>> >>> ITK currently enforces a relatively strict check that image and >>>> >>> displacement fields "occupy the same physical space." However, for >>>> >>> some unclear (to me) reasons, the direction matrices or origins of >>>> >>> images can lose precision when passing through ITK pipelines ( >>>> >>> especially through resampling or resolution-changing filters ). This >>>> >>> results in filters aborting and this can occur at various different >>>> >>> places in a complex series of ITK-based operations. >>>> >>> >>>> >>> My concern with this is that it can lead to a very severe loss of >>>> >>> productivity when this somewhat unpredictable error occurs. For instance, >>>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>>> >>> brainsfit, joint label fusion, etc). The user expects registration or >>>> >>> segmentation filters to "work well" especially when the data is of a >>>> >>> standard sort. Then, after some oft-substantial execution time, this >>>> >>> mysterious error appears: >>>> >>> >>>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>>> >>> the same physical space! >>>> >>> >>>> >>> >>>> >>> While I am all for correctness, when the impact on productivity exceeds a >>>> >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps >>>> >>> one of these would improve the situation: >>>> >>> >>>> >>> 1) change: >>>> >>> >>>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>>> >>> Transform.hxx >>>> >>> >>>> >>> and >>>> >>> >>>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>>> >>> >>>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>>> >>> >>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>>> >>> 454-L457 >>>> >>> >>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>> >>> >>>> >>> and change the documentation too: >>>> >>> >>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>>> >>> >>>> >>> 2) Change the exception to a warning. This would at least allow >>>> >>> complex pipelines to execute while notifying the user of a possible issue. >>>> >>> >>>> >>> 3) Document all of the places that the user/developer should call: >>>> >>> >>>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>>> >>> >>>> >>> This last solution would require adding Set/GetCoordinate and >>>> >>> Direction tolerance to: >>>> >>> >>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>>> >>> >>>> >>> as well, for consistency. >>>> >>> >>>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >>>> >>> by this check. >>>> >>> >>>> >>> Not once has this check actually helped us, in any measurable way, >>>> >>> avoid errors. >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> 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 >>>> >>> >>>> >> _______________________________________________ >>>> >> 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 >>>> > _______________________________________________ >>>> > 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 >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 blowekamp at mail.nih.gov Wed Nov 5 11:55:09 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Wed, 5 Nov 2014 11:55:09 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov> Message-ID: <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov> Hello, I narrowed this example down alittle bit, and reduce the size so that is can be debugged. Here is the command line I came up with: cmd="antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ $OUTPUT_ROOT , ${OUTPUT_ROOT}deformed.nii.gz ] -r [ $FIXED, $MOVING, 1] -t Affine[0.1] -m MI[ $FIXED, $MOVING, 1, 32, Regular, 0.25] -c [100,1e-8,10] -f 4 -s 4vox -t SyN[0.2,3,0] -m CC[$FIXED, $MOVING, 1, 2] -c [1x1,1e-9,10] -f 4x2 -s 2x1vox " Having two stages in the SyN registration seems to be the critical parts. Brad On Nov 5, 2014, at 10:07 AM, Bradley Lowekamp wrote: > Ahh yes, I see that in your original e-mail... I guess after downloading and building ANTs I forgot to go back to the original e-mail. > > This looks like a regular ANTs run not a minimal example to illustrate the problem. Can you please share what are the requirements to reproduce this problem and what you ruled out in the process of narrowing down the problem? > > I am hoping for something a little more isolated or easier to run than a long running registration process. Are all the iteration needed? Do the images need to be this big for the problem? I was thinking this was an issue with how the meta-data was propagate, computed or manage. Which would imply it some what independent of the size of the image. > > Thanks, > Brad > > On Nov 5, 2014, at 9:34 AM, brian avants wrote: > >> just to be clear: it should be called in this way >> >> reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST >> >> i could not find an itk test that covers the 3D case of multiple stages ... if someone knows of one, let me know. >> >> >> brian >> >> >> >> On Wed, Nov 5, 2014 at 9:25 AM, Bradley Lowekamp wrote: >> Brian, >> >> This does not look like a simplified test case to illustrate the problem. Also it didn't work for me: >> >> [blowekamp at malawi PhysicalSpaceError]$ ./reg_subject_deform.sh >> antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ , deformed.nii.gz ] -r [ , , 1] -t Rigid[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [200x100x50,1e-8,10] -f 6x4x2 -s 4x3x1vox -t Affine[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [100x100x50x10,1e-8,10] -f 4x4x2x1 -s 4x2x1x0vox -t SyN[0.2,3,0] -m CC[, , 1, 2] -c [40x50x30,1e-9,10] -f 4x2x1 -s 2x1x0vox >> All_Command_lines_OK >> Using single precision for computations. >> bad file name >> Exception Object caught: >> >> itk::ExceptionObject (0x7fcb90f1ca88) >> Location: "virtual void itk::CenteredTransformInitializer, itk::Image, itk::Image >::InitializeTransform() [TTransform = itk::Euler3DTransform, TFixedImage = itk::Image, TMovingImage = itk::Image]" >> File: /scratch/blowekamp/build/ANTS/ITKv4-install/include/ITK-4.7/itkCenteredTransformInitializer.hxx >> Line: 42 >> Description: itk::ERROR: CenteredTransformInitializer(0x7fcb90f1c4b0): Fixed Image has not been set >> >> Brad >> >> On Nov 4, 2014, at 3:37 PM, brian avants wrote: >> >>> this example exhibits the problematic behavior (CentOS release 6.3 ) >>> >>> https://copy.com/6imJcj9ZuAGoQVtG >>> >>> reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST >>> >>> >>> >>> >>> >>> brian >>> >>> >>> >>> On Tue, Nov 4, 2014 at 9:54 AM, Bradley Lowekamp wrote: >>> >>> Was it just the DisplacementFieldTransform being the problem or was it other filters in general and randomly? >>> >>> The proposed new variable should be a static member variable of ImageToImageFilter, hence the term global. It would be used to set the value here, instead of a constant [1]. This is similar to the GlobalDefaultNumberOfThreaders, as it effects the initial value for all new filters. The complication is that this base class is templated, and this global need to transcend the templates. A similar things was done with the ImageSource class by adding a second private parent without templates [2], [3]. The complexity there with lazy initialization is not needed for this case, as we just have a simple float. Additionally I have developed a preference for private namespace local statics for this type of case, as it produces a cleaner symbol table for shared libraries. >>> >>> Clearly for the DisplacementField, the tolerance variables should be exposed similarly as done in the ImageToImageFilter. And it could pull the default from the variable from above, however getting the default for a transform from a filter may not make since. >>> >>> >>> >>> >>> [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >>> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 >>> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 >>> >>> >>> >>> On Nov 4, 2014, at 9:28 AM, brian avants wrote: >>> >>>> so - just to be clear ... same thing needs to be done here: >>>> >>>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >>>> >>>> and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance Set/GetDirectionTolerance >>>> >>>> which already exists in the image to image filter (but not displacement field)? >>>> >>>> >>>> >>>> brian >>>> >>>> >>>> >>>> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp wrote: >>>> I agree that would be good. >>>> >>>> The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one? >>>> >>>> Brad >>>> >>>> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >>>> >>>>> i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. >>>>> >>>>> >>>>> brian >>>>> >>>>> >>>>> >>>>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp wrote: >>>>> That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? >>>>> >>>>> Brad >>>>> >>>>> >>>>> On Nov 4, 2014, at 3:51 AM, wrote: >>>>> >>>>> > Hi all, >>>>> > >>>>> > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? >>>>> > >>>>> > Regards, Marius >>>>> > >>>>> >> -----Original Message----- >>>>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On >>>>> >> Behalf Of Matt McCormick >>>>> >> Sent: maandag 3 november 2014 18:39 >>>>> >> To: brian avants >>>>> >> Cc: Insight-developers at itk.org >>>>> >> Subject: Re: [ITK-dev] image and deformation field physical space check >>>>> >> >>>>> >> Hi Brian, >>>>> >> >>>>> >> Thanks for discussing this. >>>>> >> >>>>> >> I think a combination of fixing the underlying issue that is being brought up by >>>>> >> the exception, relaxing the tolerance, and improving the documentation is a >>>>> >> good approach. >>>>> >> >>>>> >> 2 cents, >>>>> >> Matt >>>>> >> >>>>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: >>>>> >>> This email is motivated by this issue: >>>>> >>> >>>>> >>> https://github.com/stnava/ANTs/issues/74 >>>>> >>> >>>>> >>> but it is not isolated to ants. Worth a read for additional context. >>>>> >>> >>>>> >>> ITK currently enforces a relatively strict check that image and >>>>> >>> displacement fields "occupy the same physical space." However, for >>>>> >>> some unclear (to me) reasons, the direction matrices or origins of >>>>> >>> images can lose precision when passing through ITK pipelines ( >>>>> >>> especially through resampling or resolution-changing filters ). This >>>>> >>> results in filters aborting and this can occur at various different >>>>> >>> places in a complex series of ITK-based operations. >>>>> >>> >>>>> >>> My concern with this is that it can lead to a very severe loss of >>>>> >>> productivity when this somewhat unpredictable error occurs. For instance, >>>>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>>>> >>> brainsfit, joint label fusion, etc). The user expects registration or >>>>> >>> segmentation filters to "work well" especially when the data is of a >>>>> >>> standard sort. Then, after some oft-substantial execution time, this >>>>> >>> mysterious error appears: >>>>> >>> >>>>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>>>> >>> the same physical space! >>>>> >>> >>>>> >>> >>>>> >>> While I am all for correctness, when the impact on productivity exceeds a >>>>> >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps >>>>> >>> one of these would improve the situation: >>>>> >>> >>>>> >>> 1) change: >>>>> >>> >>>>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>>>> >>> Transform.hxx >>>>> >>> >>>>> >>> and >>>>> >>> >>>>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>>>> >>> >>>>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>>>> >>> >>>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>>>> >>> 454-L457 >>>>> >>> >>>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>>> >>> >>>>> >>> and change the documentation too: >>>>> >>> >>>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>>>> >>> >>>>> >>> 2) Change the exception to a warning. This would at least allow >>>>> >>> complex pipelines to execute while notifying the user of a possible issue. >>>>> >>> >>>>> >>> 3) Document all of the places that the user/developer should call: >>>>> >>> >>>>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>>>> >>> >>>>> >>> This last solution would require adding Set/GetCoordinate and >>>>> >>> Direction tolerance to: >>>>> >>> >>>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>>>> >>> >>>>> >>> as well, for consistency. >>>>> >>> >>>>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >>>>> >>> by this check. >>>>> >>> >>>>> >>> Not once has this check actually helped us, in any measurable way, >>>>> >>> avoid errors. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> 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 >>>>> >>> >>>>> >> _______________________________________________ >>>>> >> 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 >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > _______________________________________________ > 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 > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 stnava at gmail.com Wed Nov 5 11:58:50 2014 From: stnava at gmail.com (brian avants) Date: Wed, 5 Nov 2014 11:58:50 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov> References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov> <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov> Message-ID: That's great - very helpful I also found ( not sure if you can reproduce ) that if I do: MultiplyImages 3 S10.nii.gz 1 S10b.nii.gz MultiplyImages 3 KKI2009-11-t1weighted.nii.gz 1 KKI2009-11-t1weightedb.nii.gz and then run ./reg_subject_deform.sh S10b.nii.gz KKI2009-11-t1weightedb.nii.gz TEST it seems to work ok ... this was originally suggested by phil cook. all multiplyimages does, as it suggests, is multiply by a scalar / convert to floating point type. not sure if this is illuminating, yet ... but a little more info. brian On Wed, Nov 5, 2014 at 11:55 AM, Bradley Lowekamp wrote: > Hello, > > I narrowed this example down alittle bit, and reduce the size so that is > can be debugged. Here is the command line I came up with: > > cmd="antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ > $OUTPUT_ROOT , ${OUTPUT_ROOT}deformed.nii.gz ] -r [ $FIXED, $MOVING, 1] -t > Affine[0.1] -m MI[ $FIXED, $MOVING, 1, 32, Regular, 0.25] -c [100,1e-8,10] > -f 4 -s 4vox -t SyN[0.2,3,0] -m CC[$FIXED, $MOVING, 1, 2] -c [1x1,1e-9,10] > -f 4x2 -s 2x1vox " > > > Having two stages in the SyN registration seems to be the critical parts. > > Brad > > > On Nov 5, 2014, at 10:07 AM, Bradley Lowekamp > wrote: > > Ahh yes, I see that in your original e-mail... I guess after downloading > and building ANTs I forgot to go back to the original e-mail. > > This looks like a regular ANTs run not a minimal example to illustrate the > problem. Can you please share what are the requirements to reproduce this > problem and what you ruled out in the process of narrowing down the problem? > > I am hoping for something a little more isolated or easier to run than a > long running registration process. Are all the iteration needed? Do the > images need to be this big for the problem? I was thinking this was an > issue with how the meta-data was propagate, computed or manage. Which would > imply it some what independent of the size of the image. > > Thanks, > Brad > > On Nov 5, 2014, at 9:34 AM, brian avants wrote: > > just to be clear: it should be called in this way > > reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST > > i could not find an itk test that covers the 3D case of multiple stages > ... if someone knows of one, let me know. > > > brian > > > > On Wed, Nov 5, 2014 at 9:25 AM, Bradley Lowekamp > wrote: > >> Brian, >> >> This does not look like a simplified test case to illustrate the problem. >> Also it didn't work for me: >> >> [blowekamp at malawi PhysicalSpaceError]$ ./reg_subject_deform.sh >> antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ , >> deformed.nii.gz ] -r [ , , 1] -t Rigid[0.1] -m MI[ , , 1, 32, Regular, >> 0.25] -c [200x100x50,1e-8,10] -f 6x4x2 -s 4x3x1vox -t Affine[0.1] -m MI[ , >> , 1, 32, Regular, 0.25] -c [100x100x50x10,1e-8,10] -f 4x4x2x1 -s 4x2x1x0vox >> -t SyN[0.2,3,0] -m CC[, , 1, 2] -c [40x50x30,1e-9,10] -f 4x2x1 -s 2x1x0vox >> All_Command_lines_OK >> Using single precision for computations. >> bad file name >> Exception Object caught: >> >> itk::ExceptionObject (0x7fcb90f1ca88) >> Location: "virtual void >> itk::CenteredTransformInitializer, >> itk::Image, itk::Image >::InitializeTransform() >> [TTransform = itk::Euler3DTransform, TFixedImage = itk::Image> 3>, TMovingImage = itk::Image]" >> File: >> /scratch/blowekamp/build/ANTS/ITKv4-install/include/ITK-4.7/itkCenteredTransformInitializer.hxx >> Line: 42 >> Description: itk::ERROR: CenteredTransformInitializer(0x7fcb90f1c4b0): >> Fixed Image has not been set >> >> Brad >> >> On Nov 4, 2014, at 3:37 PM, brian avants wrote: >> >> this example exhibits the problematic behavior (CentOS release 6.3 ) >> >> https://copy.com/6imJcj9ZuAGoQVtG >> >> reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST >> >> >> >> >> brian >> >> >> >> On Tue, Nov 4, 2014 at 9:54 AM, Bradley Lowekamp >> wrote: >> >>> >>> Was it just the DisplacementFieldTransform being the problem or was it >>> other filters in general and randomly? >>> >>> The proposed new variable should be a static member variable of >>> ImageToImageFilter, hence the term global. It would be used to set the >>> value here, instead of a constant [1]. This is similar to the >>> GlobalDefaultNumberOfThreaders, as it effects the initial value for all new >>> filters. The complication is that this base class is templated, and this >>> global need to transcend the templates. A similar things was done with the >>> ImageSource class by adding a second private parent without templates [2], >>> [3]. The complexity there with lazy initialization is not needed for this >>> case, as we just have a simple float. Additionally I have developed a >>> preference for private namespace local statics for this type of case, as it >>> produces a cleaner symbol table for shared libraries. >>> >>> Clearly for the DisplacementField, the tolerance variables should be >>> exposed similarly as done in the ImageToImageFilter. And it could pull the >>> default from the variable from above, however getting the default for a >>> transform from a filter may not make since. >>> >>> >>> >>> >>> [1] >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >>> [2] >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 >>> [3] >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 >>> >>> >>> >>> On Nov 4, 2014, at 9:28 AM, brian avants wrote: >>> >>> so - just to be clear ... same thing needs to be done here: >>> >>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >>> >>> and how does Get/SetGlobalDefault differ from >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance >>> >>> which already exists in the image to image filter (but not displacement >>> field)? >>> >>> >>> brian >>> >>> >>> >>> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp >> > wrote: >>> >>>> I agree that would be good. >>>> >>>> The other thing which can be done concurrently is add the >>>> ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer >>>> for that one? >>>> >>>> Brad >>>> >>>> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >>>> >>>> i guess the next step is to dig up a couple of examples of this >>>> behavior and post them somewhere. >>>> >>>> >>>> brian >>>> >>>> >>>> >>>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp < >>>> blowekamp at mail.nih.gov> wrote: >>>> >>>>> That is a question: why is an exact copy not happening? Is is due to >>>>> runtime errors or accumulation of errors during IO? >>>>> >>>>> Brad >>>>> >>>>> >>>>> On Nov 4, 2014, at 3:51 AM, >>>>> wrote: >>>>> >>>>> > Hi all, >>>>> > >>>>> > Would it be possible to fix this issue by passing the physical space >>>>> by reference, or by performing an exact copy? >>>>> > >>>>> > Regards, Marius >>>>> > >>>>> >> -----Original Message----- >>>>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] >>>>> On >>>>> >> Behalf Of Matt McCormick >>>>> >> Sent: maandag 3 november 2014 18:39 >>>>> >> To: brian avants >>>>> >> Cc: Insight-developers at itk.org >>>>> >> Subject: Re: [ITK-dev] image and deformation field physical space >>>>> check >>>>> >> >>>>> >> Hi Brian, >>>>> >> >>>>> >> Thanks for discussing this. >>>>> >> >>>>> >> I think a combination of fixing the underlying issue that is being >>>>> brought up by >>>>> >> the exception, relaxing the tolerance, and improving the >>>>> documentation is a >>>>> >> good approach. >>>>> >> >>>>> >> 2 cents, >>>>> >> Matt >>>>> >> >>>>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants >>>>> wrote: >>>>> >>> This email is motivated by this issue: >>>>> >>> >>>>> >>> https://github.com/stnava/ANTs/issues/74 >>>>> >>> >>>>> >>> but it is not isolated to ants. Worth a read for additional >>>>> context. >>>>> >>> >>>>> >>> ITK currently enforces a relatively strict check that image and >>>>> >>> displacement fields "occupy the same physical space." However, for >>>>> >>> some unclear (to me) reasons, the direction matrices or origins of >>>>> >>> images can lose precision when passing through ITK pipelines ( >>>>> >>> especially through resampling or resolution-changing filters ). >>>>> This >>>>> >>> results in filters aborting and this can occur at various different >>>>> >>> places in a complex series of ITK-based operations. >>>>> >>> >>>>> >>> My concern with this is that it can lead to a very severe loss of >>>>> >>> productivity when this somewhat unpredictable error occurs. For >>>>> instance, >>>>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>>>> >>> brainsfit, joint label fusion, etc). The user expects >>>>> registration or >>>>> >>> segmentation filters to "work well" especially when the data is of >>>>> a >>>>> >>> standard sort. Then, after some oft-substantial execution time, >>>>> this >>>>> >>> mysterious error appears: >>>>> >>> >>>>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not >>>>> occupy >>>>> >>> the same physical space! >>>>> >>> >>>>> >>> >>>>> >>> While I am all for correctness, when the impact on productivity >>>>> exceeds a >>>>> >>> certain threshold, I think it is useful to bend the rules a bit. >>>>> Perhaps >>>>> >>> one of these would improve the situation: >>>>> >>> >>>>> >>> 1) change: >>>>> >>> >>>>> >>> >>>>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>>>> >>> Transform.hxx >>>>> >>> >>>>> >>> and >>>>> >>> >>>>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>>>> >>> >>>>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>>>> >>> >>>>> >>> >>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>>> >>> >>>>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>>>> >>> 454-L457 >>>>> >>> >>>>> >>> >>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>>> >>> >>>>> >>> and change the documentation too: >>>>> >>> >>>>> >>> >>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>>>> >>> >>>>> >>> 2) Change the exception to a warning. This would at least allow >>>>> >>> complex pipelines to execute while notifying the user of a >>>>> possible issue. >>>>> >>> >>>>> >>> 3) Document all of the places that the user/developer should call: >>>>> >>> >>>>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>>>> >>> >>>>> >>> This last solution would require adding Set/GetCoordinate and >>>>> >>> Direction tolerance to: >>>>> >>> >>>>> >>> >>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>>>> >>> >>>>> >>> as well, for consistency. >>>>> >>> >>>>> >>> Anyway, I raise this issue b/c of the many man and computer hours >>>>> lost >>>>> >>> by this check. >>>>> >>> >>>>> >>> Not once has this check actually helped us, in any measurable way, >>>>> >>> avoid errors. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> 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 >>>>> >>> >>>>> >> _______________________________________________ >>>>> >> 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 >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > _______________________________________________ > 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 > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 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] [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/ . -------------- next part -------------- _____________________________________ 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 Wed Nov 5 13:55:43 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Wed, 5 Nov 2014 13:55:43 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov> <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov> Message-ID: <552F6BE4-DA37-4C73-89BC-947169CFEE6F@mail.nih.gov> Brian, The first think I see is that the failure is dependent on the usage of "-float", which I believe changes the parameter type to be float. This also makes the fixed parameters float. For the BSpline and Displacement field transform the origin, spacing, orientation are not stored as floats resulting in a loss of precision. The problem particularly occurs with the TransformAdaptors which sets these values. While this error is not egregious, it is minor flaw which should be addressed. The Adaptors should be setting this information with double precision and not float. Brad On Nov 5, 2014, at 11:58 AM, brian avants wrote: > That's great - very helpful > > I also found ( not sure if you can reproduce ) that if I do: > > MultiplyImages 3 S10.nii.gz 1 S10b.nii.gz > MultiplyImages 3 KKI2009-11-t1weighted.nii.gz 1 KKI2009-11-t1weightedb.nii.gz > > and then run > > > ./reg_subject_deform.sh S10b.nii.gz KKI2009-11-t1weightedb.nii.gz TEST > > it seems to work ok ... this was originally suggested by phil cook. > > all multiplyimages does, as it suggests, is multiply by a scalar / convert to floating point type. > > not sure if this is illuminating, yet ... but a little more info. > > > > > > brian > > > > On Wed, Nov 5, 2014 at 11:55 AM, Bradley Lowekamp wrote: > Hello, > > I narrowed this example down alittle bit, and reduce the size so that is can be debugged. Here is the command line I came up with: > > cmd="antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ $OUTPUT_ROOT , ${OUTPUT_ROOT}deformed.nii.gz ] -r [ $FIXED, $MOVING, 1] -t Affine[0.1] -m MI[ $FIXED, $MOVING, 1, 32, Regular, 0.25] -c [100,1e-8,10] -f 4 -s 4vox -t SyN[0.2,3,0] -m CC[$FIXED, $MOVING, 1, 2] -c [1x1,1e-9,10] -f 4x2 -s 2x1vox " > > > Having two stages in the SyN registration seems to be the critical parts. > > Brad > > > On Nov 5, 2014, at 10:07 AM, Bradley Lowekamp wrote: > >> Ahh yes, I see that in your original e-mail... I guess after downloading and building ANTs I forgot to go back to the original e-mail. >> >> This looks like a regular ANTs run not a minimal example to illustrate the problem. Can you please share what are the requirements to reproduce this problem and what you ruled out in the process of narrowing down the problem? >> >> I am hoping for something a little more isolated or easier to run than a long running registration process. Are all the iteration needed? Do the images need to be this big for the problem? I was thinking this was an issue with how the meta-data was propagate, computed or manage. Which would imply it some what independent of the size of the image. >> >> Thanks, >> Brad >> >> On Nov 5, 2014, at 9:34 AM, brian avants wrote: >> >>> just to be clear: it should be called in this way >>> >>> reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST >>> >>> i could not find an itk test that covers the 3D case of multiple stages ... if someone knows of one, let me know. >>> >>> >>> brian >>> >>> >>> >>> On Wed, Nov 5, 2014 at 9:25 AM, Bradley Lowekamp wrote: >>> Brian, >>> >>> This does not look like a simplified test case to illustrate the problem. Also it didn't work for me: >>> >>> [blowekamp at malawi PhysicalSpaceError]$ ./reg_subject_deform.sh >>> antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ , deformed.nii.gz ] -r [ , , 1] -t Rigid[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [200x100x50,1e-8,10] -f 6x4x2 -s 4x3x1vox -t Affine[0.1] -m MI[ , , 1, 32, Regular, 0.25] -c [100x100x50x10,1e-8,10] -f 4x4x2x1 -s 4x2x1x0vox -t SyN[0.2,3,0] -m CC[, , 1, 2] -c [40x50x30,1e-9,10] -f 4x2x1 -s 2x1x0vox >>> All_Command_lines_OK >>> Using single precision for computations. >>> bad file name >>> Exception Object caught: >>> >>> itk::ExceptionObject (0x7fcb90f1ca88) >>> Location: "virtual void itk::CenteredTransformInitializer, itk::Image, itk::Image >::InitializeTransform() [TTransform = itk::Euler3DTransform, TFixedImage = itk::Image, TMovingImage = itk::Image]" >>> File: /scratch/blowekamp/build/ANTS/ITKv4-install/include/ITK-4.7/itkCenteredTransformInitializer.hxx >>> Line: 42 >>> Description: itk::ERROR: CenteredTransformInitializer(0x7fcb90f1c4b0): Fixed Image has not been set >>> >>> Brad >>> >>> On Nov 4, 2014, at 3:37 PM, brian avants wrote: >>> >>>> this example exhibits the problematic behavior (CentOS release 6.3 ) >>>> >>>> https://copy.com/6imJcj9ZuAGoQVtG >>>> >>>> reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST >>>> >>>> >>>> >>>> >>>> >>>> brian >>>> >>>> >>>> >>>> On Tue, Nov 4, 2014 at 9:54 AM, Bradley Lowekamp wrote: >>>> >>>> Was it just the DisplacementFieldTransform being the problem or was it other filters in general and randomly? >>>> >>>> The proposed new variable should be a static member variable of ImageToImageFilter, hence the term global. It would be used to set the value here, instead of a constant [1]. This is similar to the GlobalDefaultNumberOfThreaders, as it effects the initial value for all new filters. The complication is that this base class is templated, and this global need to transcend the templates. A similar things was done with the ImageSource class by adding a second private parent without templates [2], [3]. The complexity there with lazy initialization is not needed for this case, as we just have a simple float. Additionally I have developed a preference for private namespace local statics for this type of case, as it produces a cleaner symbol table for shared libraries. >>>> >>>> Clearly for the DisplacementField, the tolerance variables should be exposed similarly as done in the ImageToImageFilter. And it could pull the default from the variable from above, however getting the default for a transform from a filter may not make since. >>>> >>>> >>>> >>>> >>>> [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 >>>> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 >>>> >>>> >>>> >>>> On Nov 4, 2014, at 9:28 AM, brian avants wrote: >>>> >>>>> so - just to be clear ... same thing needs to be done here: >>>>> >>>>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >>>>> >>>>> and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance Set/GetDirectionTolerance >>>>> >>>>> which already exists in the image to image filter (but not displacement field)? >>>>> >>>>> >>>>> >>>>> brian >>>>> >>>>> >>>>> >>>>> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp wrote: >>>>> I agree that would be good. >>>>> >>>>> The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one? >>>>> >>>>> Brad >>>>> >>>>> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >>>>> >>>>>> i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. >>>>>> >>>>>> >>>>>> brian >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp wrote: >>>>>> That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>>> On Nov 4, 2014, at 3:51 AM, wrote: >>>>>> >>>>>> > Hi all, >>>>>> > >>>>>> > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? >>>>>> > >>>>>> > Regards, Marius >>>>>> > >>>>>> >> -----Original Message----- >>>>>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On >>>>>> >> Behalf Of Matt McCormick >>>>>> >> Sent: maandag 3 november 2014 18:39 >>>>>> >> To: brian avants >>>>>> >> Cc: Insight-developers at itk.org >>>>>> >> Subject: Re: [ITK-dev] image and deformation field physical space check >>>>>> >> >>>>>> >> Hi Brian, >>>>>> >> >>>>>> >> Thanks for discussing this. >>>>>> >> >>>>>> >> I think a combination of fixing the underlying issue that is being brought up by >>>>>> >> the exception, relaxing the tolerance, and improving the documentation is a >>>>>> >> good approach. >>>>>> >> >>>>>> >> 2 cents, >>>>>> >> Matt >>>>>> >> >>>>>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: >>>>>> >>> This email is motivated by this issue: >>>>>> >>> >>>>>> >>> https://github.com/stnava/ANTs/issues/74 >>>>>> >>> >>>>>> >>> but it is not isolated to ants. Worth a read for additional context. >>>>>> >>> >>>>>> >>> ITK currently enforces a relatively strict check that image and >>>>>> >>> displacement fields "occupy the same physical space." However, for >>>>>> >>> some unclear (to me) reasons, the direction matrices or origins of >>>>>> >>> images can lose precision when passing through ITK pipelines ( >>>>>> >>> especially through resampling or resolution-changing filters ). This >>>>>> >>> results in filters aborting and this can occur at various different >>>>>> >>> places in a complex series of ITK-based operations. >>>>>> >>> >>>>>> >>> My concern with this is that it can lead to a very severe loss of >>>>>> >>> productivity when this somewhat unpredictable error occurs. For instance, >>>>>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>>>>> >>> brainsfit, joint label fusion, etc). The user expects registration or >>>>>> >>> segmentation filters to "work well" especially when the data is of a >>>>>> >>> standard sort. Then, after some oft-substantial execution time, this >>>>>> >>> mysterious error appears: >>>>>> >>> >>>>>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>>>>> >>> the same physical space! >>>>>> >>> >>>>>> >>> >>>>>> >>> While I am all for correctness, when the impact on productivity exceeds a >>>>>> >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps >>>>>> >>> one of these would improve the situation: >>>>>> >>> >>>>>> >>> 1) change: >>>>>> >>> >>>>>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>>>>> >>> Transform.hxx >>>>>> >>> >>>>>> >>> and >>>>>> >>> >>>>>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>>>>> >>> >>>>>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>>>>> >>> >>>>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>>>>> >>> 454-L457 >>>>>> >>> >>>>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>>>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>>>> >>> >>>>>> >>> and change the documentation too: >>>>>> >>> >>>>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>>>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>>>>> >>> >>>>>> >>> 2) Change the exception to a warning. This would at least allow >>>>>> >>> complex pipelines to execute while notifying the user of a possible issue. >>>>>> >>> >>>>>> >>> 3) Document all of the places that the user/developer should call: >>>>>> >>> >>>>>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>>>>> >>> >>>>>> >>> This last solution would require adding Set/GetCoordinate and >>>>>> >>> Direction tolerance to: >>>>>> >>> >>>>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>>>>> >>> >>>>>> >>> as well, for consistency. >>>>>> >>> >>>>>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >>>>>> >>> by this check. >>>>>> >>> >>>>>> >>> Not once has this check actually helped us, in any measurable way, >>>>>> >>> avoid errors. >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> 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 >>>>>> >>> >>>>>> >> _______________________________________________ >>>>>> >> 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 >>>>>> > _______________________________________________ >>>>>> > 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 >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> 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 >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 stnava at gmail.com Wed Nov 5 13:59:49 2014 From: stnava at gmail.com (brian avants) Date: Wed, 5 Nov 2014 13:59:49 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: <552F6BE4-DA37-4C73-89BC-947169CFEE6F@mail.nih.gov> References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov> <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov> <552F6BE4-DA37-4C73-89BC-947169CFEE6F@mail.nih.gov> Message-ID: brilliant, brad ... i think you've nailed one part of the problem. i will check and see if anyone has encountered this when using double precision. brian On Wed, Nov 5, 2014 at 1:55 PM, Bradley Lowekamp wrote: > Brian, > > The first think I see is that the failure is dependent on the usage of > "-float", which I believe changes the parameter type to be float. This also > makes the fixed parameters float. For the BSpline and Displacement field > transform the origin, spacing, orientation are not stored as floats > resulting in a loss of precision. The problem particularly occurs with the > TransformAdaptors which sets these values. While this error is not > egregious, it is minor flaw which should be addressed. > > The Adaptors should be setting this information with double precision and > not float. > > Brad > > > On Nov 5, 2014, at 11:58 AM, brian avants wrote: > > That's great - very helpful > > I also found ( not sure if you can reproduce ) that if I do: > > MultiplyImages 3 S10.nii.gz 1 S10b.nii.gz > > MultiplyImages 3 KKI2009-11-t1weighted.nii.gz 1 > KKI2009-11-t1weightedb.nii.gz > > and then run > > ./reg_subject_deform.sh S10b.nii.gz KKI2009-11-t1weightedb.nii.gz TEST > > it seems to work ok ... this was originally suggested by phil cook. > > all multiplyimages does, as it suggests, is multiply by a scalar / convert > to floating point type. > > not sure if this is illuminating, yet ... but a little more info. > > > > > brian > > > > On Wed, Nov 5, 2014 at 11:55 AM, Bradley Lowekamp > wrote: > >> Hello, >> >> I narrowed this example down alittle bit, and reduce the size so that is >> can be debugged. Here is the command line I came up with: >> >> cmd="antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ >> $OUTPUT_ROOT , ${OUTPUT_ROOT}deformed.nii.gz ] -r [ $FIXED, $MOVING, 1] -t >> Affine[0.1] -m MI[ $FIXED, $MOVING, 1, 32, Regular, 0.25] -c [100,1e-8,10] >> -f 4 -s 4vox -t SyN[0.2,3,0] -m CC[$FIXED, $MOVING, 1, 2] -c [1x1,1e-9,10] >> -f 4x2 -s 2x1vox " >> >> >> Having two stages in the SyN registration seems to be the critical parts. >> >> Brad >> >> >> On Nov 5, 2014, at 10:07 AM, Bradley Lowekamp >> wrote: >> >> Ahh yes, I see that in your original e-mail... I guess after downloading >> and building ANTs I forgot to go back to the original e-mail. >> >> This looks like a regular ANTs run not a minimal example to illustrate >> the problem. Can you please share what are the requirements to reproduce >> this problem and what you ruled out in the process of narrowing down the >> problem? >> >> I am hoping for something a little more isolated or easier to run than a >> long running registration process. Are all the iteration needed? Do the >> images need to be this big for the problem? I was thinking this was an >> issue with how the meta-data was propagate, computed or manage. Which would >> imply it some what independent of the size of the image. >> >> Thanks, >> Brad >> >> On Nov 5, 2014, at 9:34 AM, brian avants wrote: >> >> just to be clear: it should be called in this way >> >> reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST >> >> i could not find an itk test that covers the 3D case of multiple stages >> ... if someone knows of one, let me know. >> >> >> brian >> >> >> >> On Wed, Nov 5, 2014 at 9:25 AM, Bradley Lowekamp >> wrote: >> >>> Brian, >>> >>> This does not look like a simplified test case to illustrate the >>> problem. Also it didn't work for me: >>> >>> [blowekamp at malawi PhysicalSpaceError]$ ./reg_subject_deform.sh >>> antsRegistration -d 3 --float 1 -u 1 -w [0.005, 0.995] -z 1 -o [ , >>> deformed.nii.gz ] -r [ , , 1] -t Rigid[0.1] -m MI[ , , 1, 32, Regular, >>> 0.25] -c [200x100x50,1e-8,10] -f 6x4x2 -s 4x3x1vox -t Affine[0.1] -m MI[ , >>> , 1, 32, Regular, 0.25] -c [100x100x50x10,1e-8,10] -f 4x4x2x1 -s 4x2x1x0vox >>> -t SyN[0.2,3,0] -m CC[, , 1, 2] -c [40x50x30,1e-9,10] -f 4x2x1 -s 2x1x0vox >>> All_Command_lines_OK >>> Using single precision for computations. >>> bad file name >>> Exception Object caught: >>> >>> itk::ExceptionObject (0x7fcb90f1ca88) >>> Location: "virtual void >>> itk::CenteredTransformInitializer, >>> itk::Image, itk::Image >::InitializeTransform() >>> [TTransform = itk::Euler3DTransform, TFixedImage = itk::Image>> 3>, TMovingImage = itk::Image]" >>> File: >>> /scratch/blowekamp/build/ANTS/ITKv4-install/include/ITK-4.7/itkCenteredTransformInitializer.hxx >>> Line: 42 >>> Description: itk::ERROR: CenteredTransformInitializer(0x7fcb90f1c4b0): >>> Fixed Image has not been set >>> >>> Brad >>> >>> On Nov 4, 2014, at 3:37 PM, brian avants wrote: >>> >>> this example exhibits the problematic behavior (CentOS release 6.3 ) >>> >>> https://copy.com/6imJcj9ZuAGoQVtG >>> >>> reg_subject_deform.sh KKI2009-11-t1weighted.nii.gz S10.nii.gz TEST >>> >>> >>> >>> >>> brian >>> >>> >>> >>> On Tue, Nov 4, 2014 at 9:54 AM, Bradley Lowekamp >> > wrote: >>> >>>> >>>> Was it just the DisplacementFieldTransform being the problem or was it >>>> other filters in general and randomly? >>>> >>>> The proposed new variable should be a static member variable of >>>> ImageToImageFilter, hence the term global. It would be used to set the >>>> value here, instead of a constant [1]. This is similar to the >>>> GlobalDefaultNumberOfThreaders, as it effects the initial value for all new >>>> filters. The complication is that this base class is templated, and this >>>> global need to transcend the templates. A similar things was done with the >>>> ImageSource class by adding a second private parent without templates [2], >>>> [3]. The complexity there with lazy initialization is not needed for this >>>> case, as we just have a simple float. Additionally I have developed a >>>> preference for private namespace local statics for this type of case, as it >>>> produces a cleaner symbol table for shared libraries. >>>> >>>> Clearly for the DisplacementField, the tolerance variables should be >>>> exposed similarly as done in the ImageToImageFilter. And it could pull the >>>> default from the variable from above, however getting the default for a >>>> transform from a filter may not make since. >>>> >>>> >>>> >>>> >>>> [1] >>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>> [2] >>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 >>>> [3] >>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 >>>> >>>> >>>> >>>> On Nov 4, 2014, at 9:28 AM, brian avants wrote: >>>> >>>> so - just to be clear ... same thing needs to be done here: >>>> >>>> >>>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >>>> >>>> and how does Get/SetGlobalDefault differ from >>>> Set/GetCoordinateTolerance Set/GetDirectionTolerance >>>> >>>> which already exists in the image to image filter (but not displacement >>>> field)? >>>> >>>> >>>> brian >>>> >>>> >>>> >>>> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp < >>>> blowekamp at mail.nih.gov> wrote: >>>> >>>>> I agree that would be good. >>>>> >>>>> The other thing which can be done concurrently is add the >>>>> ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer >>>>> for that one? >>>>> >>>>> Brad >>>>> >>>>> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >>>>> >>>>> i guess the next step is to dig up a couple of examples of this >>>>> behavior and post them somewhere. >>>>> >>>>> >>>>> brian >>>>> >>>>> >>>>> >>>>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp < >>>>> blowekamp at mail.nih.gov> wrote: >>>>> >>>>>> That is a question: why is an exact copy not happening? Is is due to >>>>>> runtime errors or accumulation of errors during IO? >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>>> On Nov 4, 2014, at 3:51 AM, >>>>>> wrote: >>>>>> >>>>>> > Hi all, >>>>>> > >>>>>> > Would it be possible to fix this issue by passing the physical >>>>>> space by reference, or by performing an exact copy? >>>>>> > >>>>>> > Regards, Marius >>>>>> > >>>>>> >> -----Original Message----- >>>>>> >> From: Insight-developers [mailto: >>>>>> insight-developers-bounces at itk.org] On >>>>>> >> Behalf Of Matt McCormick >>>>>> >> Sent: maandag 3 november 2014 18:39 >>>>>> >> To: brian avants >>>>>> >> Cc: Insight-developers at itk.org >>>>>> >> Subject: Re: [ITK-dev] image and deformation field physical space >>>>>> check >>>>>> >> >>>>>> >> Hi Brian, >>>>>> >> >>>>>> >> Thanks for discussing this. >>>>>> >> >>>>>> >> I think a combination of fixing the underlying issue that is being >>>>>> brought up by >>>>>> >> the exception, relaxing the tolerance, and improving the >>>>>> documentation is a >>>>>> >> good approach. >>>>>> >> >>>>>> >> 2 cents, >>>>>> >> Matt >>>>>> >> >>>>>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants >>>>>> wrote: >>>>>> >>> This email is motivated by this issue: >>>>>> >>> >>>>>> >>> https://github.com/stnava/ANTs/issues/74 >>>>>> >>> >>>>>> >>> but it is not isolated to ants. Worth a read for additional >>>>>> context. >>>>>> >>> >>>>>> >>> ITK currently enforces a relatively strict check that image and >>>>>> >>> displacement fields "occupy the same physical space." However, >>>>>> for >>>>>> >>> some unclear (to me) reasons, the direction matrices or origins of >>>>>> >>> images can lose precision when passing through ITK pipelines ( >>>>>> >>> especially through resampling or resolution-changing filters ). >>>>>> This >>>>>> >>> results in filters aborting and this can occur at various >>>>>> different >>>>>> >>> places in a complex series of ITK-based operations. >>>>>> >>> >>>>>> >>> My concern with this is that it can lead to a very severe loss of >>>>>> >>> productivity when this somewhat unpredictable error occurs. For >>>>>> instance, >>>>>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>>>>> >>> brainsfit, joint label fusion, etc). The user expects >>>>>> registration or >>>>>> >>> segmentation filters to "work well" especially when the data is >>>>>> of a >>>>>> >>> standard sort. Then, after some oft-substantial execution time, >>>>>> this >>>>>> >>> mysterious error appears: >>>>>> >>> >>>>>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not >>>>>> occupy >>>>>> >>> the same physical space! >>>>>> >>> >>>>>> >>> >>>>>> >>> While I am all for correctness, when the impact on productivity >>>>>> exceeds a >>>>>> >>> certain threshold, I think it is useful to bend the rules a bit. >>>>>> Perhaps >>>>>> >>> one of these would improve the situation: >>>>>> >>> >>>>>> >>> 1) change: >>>>>> >>> >>>>>> >>> >>>>>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>>>>> >>> Transform.hxx >>>>>> >>> >>>>>> >>> and >>>>>> >>> >>>>>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>>>>> >>> >>>>>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>>>>> >>> >>>>>> >>> >>>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>>>> >>> >>>>>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>>>>> >>> 454-L457 >>>>>> >>> >>>>>> >>> >>>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>>>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>>>> >>> >>>>>> >>> and change the documentation too: >>>>>> >>> >>>>>> >>> >>>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>>>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>>>>> >>> >>>>>> >>> 2) Change the exception to a warning. This would at least allow >>>>>> >>> complex pipelines to execute while notifying the user of a >>>>>> possible issue. >>>>>> >>> >>>>>> >>> 3) Document all of the places that the user/developer should >>>>>> call: >>>>>> >>> >>>>>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>>>>> >>> >>>>>> >>> This last solution would require adding Set/GetCoordinate and >>>>>> >>> Direction tolerance to: >>>>>> >>> >>>>>> >>> >>>>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>>>>> >>> >>>>>> >>> as well, for consistency. >>>>>> >>> >>>>>> >>> Anyway, I raise this issue b/c of the many man and computer hours >>>>>> lost >>>>>> >>> by this check. >>>>>> >>> >>>>>> >>> Not once has this check actually helped us, in any measurable way, >>>>>> >>> avoid errors. >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> 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 >>>>>> >>> >>>>>> >> _______________________________________________ >>>>>> >> 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 >>>>>> > _______________________________________________ >>>>>> > 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 >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> 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 >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 blowekamp at mail.nih.gov Wed Nov 5 14:28:53 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Wed, 5 Nov 2014 14:28:53 -0500 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> Message-ID: <2D4A2A84-9637-41E8-8FDE-10D6FA959786@mail.nih.gov> I'll pick up this issue of adding these new methods to better control the tolerances. Brad On Nov 4, 2014, at 9:54 AM, Bradley Lowekamp wrote: > > Was it just the DisplacementFieldTransform being the problem or was it other filters in general and randomly? > > The proposed new variable should be a static member variable of ImageToImageFilter, hence the term global. It would be used to set the value here, instead of a constant [1]. This is similar to the GlobalDefaultNumberOfThreaders, as it effects the initial value for all new filters. The complication is that this base class is templated, and this global need to transcend the templates. A similar things was done with the ImageSource class by adding a second private parent without templates [2], [3]. The complexity there with lazy initialization is not needed for this case, as we just have a simple float. Additionally I have developed a preference for private namespace local statics for this type of case, as it produces a cleaner symbol table for shared libraries. > > Clearly for the DisplacementField, the tolerance variables should be exposed similarly as done in the ImageToImageFilter. And it could pull the default from the variable from above, however getting the default for a transform from a filter may not make since. > > > > > [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 > [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 > [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 > > > On Nov 4, 2014, at 9:28 AM, brian avants wrote: > >> so - just to be clear ... same thing needs to be done here: >> >> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >> >> and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance Set/GetDirectionTolerance >> >> which already exists in the image to image filter (but not displacement field)? >> >> >> >> brian >> >> >> >> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp wrote: >> I agree that would be good. >> >> The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one? >> >> Brad >> >> On Nov 4, 2014, at 9:21 AM, brian avants wrote: >> >>> i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. >>> >>> >>> brian >>> >>> >>> >>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp wrote: >>> That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? >>> >>> Brad >>> >>> >>> On Nov 4, 2014, at 3:51 AM, wrote: >>> >>> > Hi all, >>> > >>> > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? >>> > >>> > Regards, Marius >>> > >>> >> -----Original Message----- >>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On >>> >> Behalf Of Matt McCormick >>> >> Sent: maandag 3 november 2014 18:39 >>> >> To: brian avants >>> >> Cc: Insight-developers at itk.org >>> >> Subject: Re: [ITK-dev] image and deformation field physical space check >>> >> >>> >> Hi Brian, >>> >> >>> >> Thanks for discussing this. >>> >> >>> >> I think a combination of fixing the underlying issue that is being brought up by >>> >> the exception, relaxing the tolerance, and improving the documentation is a >>> >> good approach. >>> >> >>> >> 2 cents, >>> >> Matt >>> >> >>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants wrote: >>> >>> This email is motivated by this issue: >>> >>> >>> >>> https://github.com/stnava/ANTs/issues/74 >>> >>> >>> >>> but it is not isolated to ants. Worth a read for additional context. >>> >>> >>> >>> ITK currently enforces a relatively strict check that image and >>> >>> displacement fields "occupy the same physical space." However, for >>> >>> some unclear (to me) reasons, the direction matrices or origins of >>> >>> images can lose precision when passing through ITK pipelines ( >>> >>> especially through resampling or resolution-changing filters ). This >>> >>> results in filters aborting and this can occur at various different >>> >>> places in a complex series of ITK-based operations. >>> >>> >>> >>> My concern with this is that it can lead to a very severe loss of >>> >>> productivity when this somewhat unpredictable error occurs. For instance, >>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>> >>> brainsfit, joint label fusion, etc). The user expects registration or >>> >>> segmentation filters to "work well" especially when the data is of a >>> >>> standard sort. Then, after some oft-substantial execution time, this >>> >>> mysterious error appears: >>> >>> >>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>> >>> the same physical space! >>> >>> >>> >>> >>> >>> While I am all for correctness, when the impact on productivity exceeds a >>> >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps >>> >>> one of these would improve the situation: >>> >>> >>> >>> 1) change: >>> >>> >>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>> >>> Transform.hxx >>> >>> >>> >>> and >>> >>> >>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>> >>> >>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>> >>> 454-L457 >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>> >>> >>> >>> and change the documentation too: >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>> >>> >>> >>> 2) Change the exception to a warning. This would at least allow >>> >>> complex pipelines to execute while notifying the user of a possible issue. >>> >>> >>> >>> 3) Document all of the places that the user/developer should call: >>> >>> >>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>> >>> >>> >>> This last solution would require adding Set/GetCoordinate and >>> >>> Direction tolerance to: >>> >>> >>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>> >>> >>> >>> as well, for consistency. >>> >>> >>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >>> >>> by this check. >>> >>> >>> >>> Not once has this check actually helped us, in any measurable way, >>> >>> avoid errors. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >>> >>> >> _______________________________________________ >>> >> 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 >>> > _______________________________________________ >>> > 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 >>> >>> >> >> > > _______________________________________________ > 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 > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 ntustison at gmail.com Wed Nov 5 14:35:04 2014 From: ntustison at gmail.com (Nicholas Tustison) Date: Wed, 5 Nov 2014 11:35:04 -0800 Subject: [ITK] [ITK-dev] image and deformation field physical space check In-Reply-To: <2D4A2A84-9637-41E8-8FDE-10D6FA959786@mail.nih.gov> References: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern> <2D4A2A84-9637-41E8-8FDE-10D6FA959786@mail.nih.gov> Message-ID: That?s brilliant, Brad. Thanks. > On Nov 5, 2014, at 11:28 AM, Bradley Lowekamp wrote: > > I'll pick up this issue of adding these new methods to better control the tolerances. > > Brad > On Nov 4, 2014, at 9:54 AM, Bradley Lowekamp > wrote: > >> >> Was it just the DisplacementFieldTransform being the problem or was it other filters in general and randomly? >> >> The proposed new variable should be a static member variable of ImageToImageFilter, hence the term global. It would be used to set the value here, instead of a constant [1]. This is similar to the GlobalDefaultNumberOfThreaders, as it effects the initial value for all new filters. The complication is that this base class is templated, and this global need to transcend the templates. A similar things was done with the ImageSource class by adding a second private parent without templates [2], [3]. The complexity there with lazy initialization is not needed for this case, as we just have a simple float. Additionally I have developed a preference for private namespace local statics for this type of case, as it produces a cleaner symbol table for shared libraries. >> >> Clearly for the DisplacementField, the tolerance variables should be exposed similarly as done in the ImageToImageFilter. And it could pull the default from the variable from above, however getting the default for a transform from a filter may not make since. >> >> >> >> >> [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 >> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageSource.h#L50-L87 >> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/src/itkImageSource.cxx#L27-L46 >> >> >> On Nov 4, 2014, at 9:28 AM, brian avants > wrote: >> >>> so - just to be clear ... same thing needs to be done here: >>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementFieldTransform.h >>> >>> and how does Get/SetGlobalDefault differ from Set/GetCoordinateTolerance Set/GetDirectionTolerance >>> >>> which already exists in the image to image filter (but not displacement field)? >>> >>> >>> >>> brian >>> >>> >>> >>> On Tue, Nov 4, 2014 at 9:26 AM, Bradley Lowekamp > wrote: >>> I agree that would be good. >>> >>> The other thing which can be done concurrently is add the ImageToImageFilter::Get/SetGlobalDefault methods. Any one want to volunteer for that one? >>> >>> Brad >>> >>> On Nov 4, 2014, at 9:21 AM, brian avants > wrote: >>> >>>> i guess the next step is to dig up a couple of examples of this behavior and post them somewhere. >>>> >>>> >>>> brian >>>> >>>> >>>> >>>> On Tue, Nov 4, 2014 at 9:14 AM, Bradley Lowekamp > wrote: >>>> That is a question: why is an exact copy not happening? Is is due to runtime errors or accumulation of errors during IO? >>>> >>>> Brad >>>> >>>> >>>> On Nov 4, 2014, at 3:51 AM, > > wrote: >>>> >>>> > Hi all, >>>> > >>>> > Would it be possible to fix this issue by passing the physical space by reference, or by performing an exact copy? >>>> > >>>> > Regards, Marius >>>> > >>>> >> -----Original Message----- >>>> >> From: Insight-developers [mailto:insight-developers-bounces at itk.org ] On >>>> >> Behalf Of Matt McCormick >>>> >> Sent: maandag 3 november 2014 18:39 >>>> >> To: brian avants >>>> >> Cc: Insight-developers at itk.org >>>> >> Subject: Re: [ITK-dev] image and deformation field physical space check >>>> >> >>>> >> Hi Brian, >>>> >> >>>> >> Thanks for discussing this. >>>> >> >>>> >> I think a combination of fixing the underlying issue that is being brought up by >>>> >> the exception, relaxing the tolerance, and improving the documentation is a >>>> >> good approach. >>>> >> >>>> >> 2 cents, >>>> >> Matt >>>> >> >>>> >> On Mon, Nov 3, 2014 at 11:40 AM, brian avants > wrote: >>>> >>> This email is motivated by this issue: >>>> >>> >>>> >>> https://github.com/stnava/ANTs/issues/74 >>>> >>> >>>> >>> but it is not isolated to ants. Worth a read for additional context. >>>> >>> >>>> >>> ITK currently enforces a relatively strict check that image and >>>> >>> displacement fields "occupy the same physical space." However, for >>>> >>> some unclear (to me) reasons, the direction matrices or origins of >>>> >>> images can lose precision when passing through ITK pipelines ( >>>> >>> especially through resampling or resolution-changing filters ). This >>>> >>> results in filters aborting and this can occur at various different >>>> >>> places in a complex series of ITK-based operations. >>>> >>> >>>> >>> My concern with this is that it can lead to a very severe loss of >>>> >>> productivity when this somewhat unpredictable error occurs. For instance, >>>> >>> a user downloads a toolkit based on ITK ( itk-snap, ants, elastic, >>>> >>> brainsfit, joint label fusion, etc). The user expects registration or >>>> >>> segmentation filters to "work well" especially when the data is of a >>>> >>> standard sort. Then, after some oft-substantial execution time, this >>>> >>> mysterious error appears: >>>> >>> >>>> >>> itk::ERROR: ImageToImageFilter(0x7fb3b2307ac0): Inputs do not occupy >>>> >>> the same physical space! >>>> >>> >>>> >>> >>>> >>> While I am all for correctness, when the impact on productivity exceeds a >>>> >>> certain threshold, I think it is useful to bend the rules a bit. Perhaps >>>> >>> one of these would improve the situation: >>>> >>> >>>> >>> 1) change: >>>> >>> >>>> >>> ITKv4/Modules/Filtering/DisplacementField/include/itkDisplacementField >>>> >>> Transform.hxx >>>> >>> >>>> >>> and >>>> >>> >>>> >>> ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx >>>> >>> >>>> >>> changing direction tolerance and coordinate tolerance to 1.e-4 >>>> >>> >>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L >>>> >>> 454-L457 >>>> >>> >>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>> >>> ore/Common/include/itkImageToImageFilter.hxx#L40-L41 >>>> >>> >>>> >>> and change the documentation too: >>>> >>> >>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/C >>>> >>> ore/Common/include/itkImageToImageFilter.h#L76-L87 >>>> >>> >>>> >>> 2) Change the exception to a warning. This would at least allow >>>> >>> complex pipelines to execute while notifying the user of a possible issue. >>>> >>> >>>> >>> 3) Document all of the places that the user/developer should call: >>>> >>> >>>> >>> Set/GetCoordinateTolerance Set/GetDirectionTolerance . >>>> >>> >>>> >>> This last solution would require adding Set/GetCoordinate and >>>> >>> Direction tolerance to: >>>> >>> >>>> >>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/F >>>> >>> iltering/DisplacementField/include/itkDisplacementFieldTransform.h >>>> >>> >>>> >>> as well, for consistency. >>>> >>> >>>> >>> Anyway, I raise this issue b/c of the many man and computer hours lost >>>> >>> by this check. >>>> >>> >>>> >>> Not once has this check actually helped us, in any measurable way, >>>> >>> avoid errors. >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> 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 >>>> >>> >>>> >> _______________________________________________ >>>> >> 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 >>>> > _______________________________________________ >>>> > 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 >>>> >>>> >>> >>> >> >> _______________________________________________ >> 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 >> _______________________________________________ >> 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://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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 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] [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 _____________________________________ 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 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] [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 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 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] [ITK-users] Processing Time for ICP Message-ID: 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 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] [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 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 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 _____________________________________ 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] [ITK-users] Processing Time for ICP In-Reply-To: References: Message-ID: 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 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 _____________________________________ 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 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] [ITK-users] Processing Time for ICP In-Reply-To: References: Message-ID: It is a Release build with ITK version 4.5.2 On Thu, Nov 6, 2014 at 4:55 PM, Bill Lorensen 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 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 _____________________________________ 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 michkapopoff at gmail.com Thu Nov 6 16:23:38 2014 From: michkapopoff at gmail.com (michkapopoff at gmail.com) Date: Thu, 6 Nov 2014 22:23:38 +0100 Subject: [ITK] Announcement: VTK, ITK and SimpleITK binaries for OS X Message-ID: <1225C0BB-7598-487A-B783-E39D5BFC2890@gmail.com> Hi If you need a fast way to install VTK, ITK and/or SimpleITK on OS X, I have good news for the community. I compiled binaries for OS X 10.8, 10.9 and 10.10, which you can install using homebrew (http://brew.sh). People using my previous binaries for ITK with Python wrappings should use the new imichka-insighttoolkit-wrapitk binaries (the formula name has changed). Here is the list of available packages: imichka-vtk : VTK 6.1.0, C++ and Python wrappings (Python 2.7.8) imichka-insighttoolkit : ITK 4.6.1, C++ only imichka-insighttoolkit-wrapitk : ITK 4.6.1 with Python wrappings (Python 2.7.8) imichka-simpleitk : SimpleITK 0.8.0, Python 2.7.8 (Java, Ruby etc.. were not tested but are provided) Please find the install instructions and more details here: https://github.com/iMichka/homebrew-MacVTKITKPythonBottles Feedback is welcome. If you find any issue please open a ticket on the project?s bug tracker. Michka Popoff -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [ITK-users] 3D Noise Power Spectrum ITK Message-ID: 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] 3D Noise Power Spectrum ITK In-Reply-To: References: Message-ID: 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 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 > _____________________________________ 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] [ITK-users] VectorImage vs image of vectors In-Reply-To: References: 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 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, 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 > void DoSomething() > { > typedef itk::Image< itk::Vector, NDim > ImageType; > ... > } > > int main(int,char *[]) > { > ... > switch(vecLength) > { > case 3: > DoSomething(); > break; > case 11: > DoSomething(); > ? > } > } > > 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" > > 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 , 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smoothingTest.cxx Type: application/octet-stream Size: 2300 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] VectorImage vs image of vectors In-Reply-To: <69392D76-B649-453C-A1E9-3A79CBA63A39@inria.fr> References: <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 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 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, 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 >> void DoSomething() >> { >> typedef itk::Image< itk::Vector, NDim > ImageType; >> ... >> } >> >> int main(int,char *[]) >> { >> ... >> switch(vecLength) >> { >> case 3: >> DoSomething(); >> break; >> case 11: >> DoSomething(); >> ? >> } >> } >> >> 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" >> 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 , 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] VectorImage vs image of vectors In-Reply-To: <707234F5-EAB5-447D-A1C8-476433B3AD11@mail.nih.gov> References: <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 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 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 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, 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 >>> void DoSomething() >>> { >>> typedef itk::Image< itk::Vector, NDim > ImageType; >>> ... >>> } >>> >>> int main(int,char *[]) >>> { >>> ... >>> switch(vecLength) >>> { >>> case 3: >>> DoSomething(); >>> break; >>> case 11: >>> DoSomething(); >>> ? >>> } >>> } >>> >>> 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" >>> 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 , 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/ >> >> >> >> >> >> > > _____________________________________ > 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: -------------- next part -------------- _____________________________________ 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 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] [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. _____________________________________ 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 michael.meuli at gmail.com Tue Nov 11 03:23:15 2014 From: michael.meuli at gmail.com (Michael Meuli) Date: Tue, 11 Nov 2014 09:23:15 +0100 Subject: [ITK] LabelMap Message-ID: Hi all, I have an assert in my program which works fine with most of my images but now failed on one of them. Shouldn't the assert in the following piece of code always be true? typedef itk::Image< unsigned short, 3 > ImageType3D; ImageType3D::Pointer image3Dred = extractchannel(image5D, lysosomechannel); typedef itk::Image< unsigned char, 3 > BinaryImageType3D; typedef itk::BinaryImageToShapeLabelMapFilter BinaryImageToShapeLabelMapFilterType; typedef itk::LabelMapToLabelImageFilter LabelMapToLabelImageFilterType; LabelMapToLabelImageFilterType::Pointer labelMapToLabelImageFilter = LabelMapToLabelImageFilterType::New(); labelMapToLabelImageFilter->SetInput(binaryImageToShapeLabelMapFilter->GetOutput()); typedef itk::LabelImageToStatisticsLabelMapFilter< BinaryImageType3D, ImageType3D > LabelImageToStatisticsLabelMapFilterType; LabelImageToStatisticsLabelMapFilterType::Pointer labelImageToStatisticsLabelMapFilter = LabelImageToStatisticsLabelMapFilterType::New(); labelImageToStatisticsLabelMapFilter->SetFeatureImage(image3Dred); labelImageToStatisticsLabelMapFilter->SetInput(labelMapToLabelImageFilter->GetOutput()); labelImageToStatisticsLabelMapFilter->Update(); assert (binaryImageToShapeLabelMapFilter->GetOutput()->GetNumberOfLabelObjects() == labelImageToStatisticsLabelMapFilter->GetOutput()->GetNumberOfLabelObjects()); Best regards and many thanks Michael Meuli 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] [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. _____________________________________ 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 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] [ITK-users] VectorImage vs image of vectors In-Reply-To: <5CA334E1-1DEA-42AA-B6E3-CC6DB4B5DD65@mail.nih.gov> References: <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: 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 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 > 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 > 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 > 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, 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 >>>> void DoSomething() >>>> { >>>> typedef itk::Image< itk::Vector, NDim > ImageType; >>>> ... >>>> } >>>> >>>> int main(int,char *[]) >>>> { >>>> ... >>>> switch(vecLength) >>>> { >>>> case 3: >>>> DoSomething(); >>>> break; >>>> case 11: >>>> DoSomething(); >>>> ? >>>> } >>>> } >>>> >>>> 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" > >>>> 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 , 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/ >>> >>> >>> >>> >>> >>> >> >> _____________________________________ >> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] VectorImage vs image of vectors In-Reply-To: References: <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: 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 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 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 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 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 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, 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 >>>>> void DoSomething() >>>>> { >>>>> typedef itk::Image< itk::Vector, NDim > ImageType; >>>>> ... >>>>> } >>>>> >>>>> int main(int,char *[]) >>>>> { >>>>> ... >>>>> switch(vecLength) >>>>> { >>>>> case 3: >>>>> DoSomething(); >>>>> break; >>>>> case 11: >>>>> DoSomething(); >>>>> ? >>>>> } >>>>> } >>>>> >>>>> 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" >>>>> 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 , 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/ >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> _____________________________________ >>> 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: -------------- next part -------------- _____________________________________ 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 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] Otsu Filter for object/background separation Message-ID: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: obj-bg.jpg Type: image/jpeg Size: 142924 bytes Desc: not available URL: 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] Otsu Filter for object/background separation In-Reply-To: References: Message-ID: 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 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: 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] [ITK-users] rescaling of volume In-Reply-To: References: Message-ID: Do want to scale it anoint the center of the volume? On Nov 12, 2014 4:18 AM, "Rekha Pyage" 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] rescaling of volume In-Reply-To: References: Message-ID: 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 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" wrote: >> >> Do want to scale it anoint the center of the volume? >> >> On Nov 12, 2014 4:18 AM, "Rekha Pyage" 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 juanprietob at gmail.com Wed Nov 12 16:18:20 2014 From: juanprietob at gmail.com (Juan Carlos Prieto) Date: Wed, 12 Nov 2014 16:18:20 -0500 Subject: [ITK] Stream image to cin Message-ID: Dear all, I was wondering if there is a way to load an image file that was streamed to a c++ program by cin. To be more specific I would like to retrieve an image via cURL and input the content to a c++ program using ITK filters and so on. Is there a way to hack ImageIOFactory or ImageIO to use the input content instead of loading the data from disk? Please let me know if you have any ideas or suggestions. I understand that the simple solution will be to write the file to disk and then execute the program but I would like to try it out this way. Best, Juan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Nov 12 16:27:47 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 12 Nov 2014 16:27:47 -0500 Subject: [ITK] Stream image to cin In-Reply-To: References: Message-ID: Yes you can. Look at this test: Modules/IO/ImageBase/test/itkIOPluginTest it uses itkFileFreeImageIO.cxx On Wed, Nov 12, 2014 at 4:18 PM, Juan Carlos Prieto wrote: > Dear all, > > I was wondering if there is a way to load an image file that was streamed to > a c++ program by cin. > > To be more specific I would like to retrieve an image via cURL and input the > content to a c++ program using ITK filters and so on. > > Is there a way to hack ImageIOFactory or ImageIO to use the input content > instead of loading the data from disk? > > Please let me know if you have any ideas or suggestions. > > I understand that the simple solution will be to write the file to disk and > then execute the program but I would like to try it out this way. > > > Best, > > Juan > > > > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > -- 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] [ITK-users] problem using VTKImageToImageFilter Message-ID: 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: -------------- next part -------------- _____________________________________ 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 13 08:14:56 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 13 Nov 2014 08:14:56 -0500 Subject: [ITK] [ITK-users] problem using VTKImageToImageFilter In-Reply-To: References: Message-ID: 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 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 _____________________________________ 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 08:56:11 2014 From: matimontg at gmail.com (Matias Montroull) Date: Thu, 13 Nov 2014 10:56:11 -0300 Subject: [ITK] [ITK-users] White Background on rotated image Message-ID: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture.JPG Type: image/jpeg Size: 74098 bytes Desc: not available URL: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] White Background on rotated image In-Reply-To: References: 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 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? > > > ? > _____________________________________ > 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: -------------- next part -------------- _____________________________________ 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 09:27:10 2014 From: matimontg at gmail.com (Matias Montroull) Date: Thu, 13 Nov 2014 11:27:10 -0300 Subject: [ITK] [ITK-users] White Background on rotated image In-Reply-To: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 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? > > > ? > _____________________________________ > 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: -------------- next part -------------- _____________________________________ 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 09:30:22 2014 From: matimontg at gmail.com (Matias Montroull) Date: Thu, 13 Nov 2014 11:30:22 -0300 Subject: [ITK] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 > 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 >> 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? >> >> >> ? >> _____________________________________ >> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 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 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 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? >> >> >> ? >> _____________________________________ >> 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: -------------- next part -------------- _____________________________________ 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 12:14:26 2014 From: matimontg at gmail.com (Matias Montroull) Date: Thu, 13 Nov 2014 14:14:26 -0300 Subject: [ITK] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 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 > 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 >>> 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? >>> >>> >>> ? >>> _____________________________________ >>> 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: -------------- next part -------------- _____________________________________ 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 12:16:24 2014 From: matimontg at gmail.com (Matias Montroull) Date: Thu, 13 Nov 2014 14:16:24 -0300 Subject: [ITK] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 > 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 >> 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 >> 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 >>>> 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? >>>> >>>> >>>> ? >>>> _____________________________________ >>>> 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: -------------- next part -------------- _____________________________________ 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 12:18:07 2014 From: matimontg at gmail.com (Matias Montroull) Date: Thu, 13 Nov 2014 14:18:07 -0300 Subject: [ITK] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 > 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 >>> 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 >>> 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 >>>>> 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? >>>>> >>>>> >>>>> ? >>>>> _____________________________________ >>>>> 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: -------------- next part -------------- _____________________________________ 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:34:26 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 13 Nov 2014 12:34:26 -0500 Subject: [ITK] [ITK-users] rescaling of volume In-Reply-To: References: Message-ID: 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 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 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" wrote: >>> >>> Do want to scale it anoint the center of the volume? >>> >>> On Nov 12, 2014 4:18 AM, "Rekha Pyage" 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 _____________________________________ 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] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 > 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 >> 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 >>> 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 >>>> 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 >>>> 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 >>>>> 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 >>>>>> 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? >>>>>> >>>>>> >>>>>> >>>>>> _____________________________________ >>>>>> 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 > _____________________________________ 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] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: Thanks Matt, I'll give it a try On Thu, Nov 13, 2014 at 2:37 PM, Matt McCormick 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 > 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 > > 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 > >> 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 > >>> 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 > >>>> 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 > >>>>> 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 > >>>>>> 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? > >>>>>> > >>>>>> > >>>>>> > >>>>>> _____________________________________ > >>>>>> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] rescaling of volume In-Reply-To: References: 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. _____________________________________ 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 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] [ITK-users] rescaling of volume In-Reply-To: <1415956430247-34901.post@n7.nabble.com> References: <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. _____________________________________ 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 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] [ITK-users] rescaling of volume In-Reply-To: References: 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. _____________________________________ 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 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] [ITK-users] problem using VTKImageToImageFilter In-Reply-To: References: Message-ID: 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 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 > 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 >> 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 >> > 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 > > >> >> 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 >> >>> 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 >> >>>> 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 >> >>>>> 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 > > >> >>>>>> 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? >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _____________________________________ >> >>>>>> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] problem using VTKImageToImageFilter In-Reply-To: References: Message-ID: 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 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 > 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 >> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test Message-ID: 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 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 Date: Fri Oct 24 13:42:02 2014 -0400 BUG: Adding missing parentheses around boolean expression Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 commit 40afd95161727be3274f8094ce19fe45e2c3aa50 Author: Bradley Lowekamp 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: -------------- next part -------------- _______________________________________________ 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 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] [ITK-users] TIFFImageIO refactoring, please test Message-ID: 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 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 Date: Fri Oct 24 13:42:02 2014 -0400 BUG: Adding missing parentheses around boolean expression Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 commit 40afd95161727be3274f8094ce19fe45e2c3aa50 Author: Bradley Lowekamp 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: 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 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 > 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 > Date: Fri Oct 24 13:42:02 2014 -0400 > > BUG: Adding missing parentheses around boolean expression > > Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 > > commit 40afd95161727be3274f8094ce19fe45e2c3aa50 > Author: Bradley Lowekamp > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: 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 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 > 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 > Date: Fri Oct 24 13:42:02 2014 -0400 > > BUG: Adding missing parentheses around boolean expression > > Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 > > commit 40afd95161727be3274f8094ce19fe45e2c3aa50 > Author: Bradley Lowekamp > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 _______________________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: 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 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 > 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 >> 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 >> Date: Fri Oct 24 13:42:02 2014 -0400 >> >> BUG: Adding missing parentheses around boolean expression >> >> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >> >> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >> Author: Bradley Lowekamp >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 _______________________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: 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 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 > 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 >> 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 >> Date: Fri Oct 24 13:42:02 2014 -0400 >> >> BUG: Adding missing parentheses around boolean expression >> >> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >> >> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >> Author: Bradley Lowekamp >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: 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 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 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 >> 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 >>> 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 >>> Date: Fri Oct 24 13:42:02 2014 -0400 >>> >>> BUG: Adding missing parentheses around boolean expression >>> >>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>> >>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>> Author: Bradley Lowekamp >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 _______________________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: 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 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 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 >> 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 >>> 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 >>> Date: Fri Oct 24 13:42:02 2014 -0400 >>> >>> BUG: Adding missing parentheses around boolean expression >>> >>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>> >>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>> Author: Bradley Lowekamp >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>> 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 _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: Wow. The new itk tiff reader sad my tiled images. On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 > 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 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 >>> 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 >>>> 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 >>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>> >>>> BUG: Adding missing parentheses around boolean expression >>>> >>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>> >>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>> Author: Bradley Lowekamp >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 _______________________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: Wow. The new itk tiff reader sad my tiled images. On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 > 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 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 >>> 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 >>>> 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 >>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>> >>>> BUG: Adding missing parentheses around boolean expression >>>> >>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>> >>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>> Author: Bradley Lowekamp >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 >>>> 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 _____________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: Meant to say: Wow. The new itk tiff reader read my tiled images. On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen wrote: > Wow. The new itk tiff reader sad my tiled images. > > On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 >> 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 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 >>>> 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 >>>>> 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 >>>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>>> >>>>> BUG: Adding missing parentheses around boolean expression >>>>> >>>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>>> >>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>>> Author: Bradley Lowekamp >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: Meant to say: Wow. The new itk tiff reader read my tiled images. On Fri, Nov 14, 2014 at 10:45 AM, Bill Lorensen wrote: > Wow. The new itk tiff reader sad my tiled images. > > On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 >> 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 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 >>>> 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 >>>>> 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 >>>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>>> >>>>> BUG: Adding missing parentheses around boolean expression >>>>> >>>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>>> >>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>>> Author: Bradley Lowekamp >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 >>>>> 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 _______________________________________________ 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 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] [ITK-users] White Background on rotated image In-Reply-To: References: <7DE78557-2207-4BD3-86CD-867582315C2B@mail.nih.gov> Message-ID: 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 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 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 > 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 >>> 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 >> > >>> > 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 >>> >>> 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 >>> >>>> 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 >>> >>>>> 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? >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> _____________________________________ >>> >>>>>> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: 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 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 wrote: >> Wow. The new itk tiff reader sad my tiled images. >> >> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 >>> 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 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 >>>>> 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 >>>>>> 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 >>>>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>>>> >>>>>> BUG: Adding missing parentheses around boolean expression >>>>>> >>>>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>>>> >>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>>>> Author: Bradley Lowekamp >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 _______________________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: 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 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 wrote: >> Wow. The new itk tiff reader sad my tiled images. >> >> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 >>> 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 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 >>>>> 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 >>>>>> 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 >>>>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>>>> >>>>>> BUG: Adding missing parentheses around boolean expression >>>>>> >>>>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>>>> >>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>>>> Author: Bradley Lowekamp >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 >>>>>> 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 _____________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: Yes, from the vtk tests. I created them with imagemagik On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp 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 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 wrote: >>> Wow. The new itk tiff reader sad my tiled images. >>> >>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 >>>> 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 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 >>>>>> 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 >>>>>>> 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 >>>>>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>>>>> >>>>>>> BUG: Adding missing parentheses around boolean expression >>>>>>> >>>>>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>>>>> >>>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>>>>> Author: Bradley Lowekamp >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: Message-ID: Yes, from the vtk tests. I created them with imagemagik On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp 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 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 wrote: >>> Wow. The new itk tiff reader sad my tiled images. >>> >>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 >>>> 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 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 >>>>>> 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 >>>>>>> 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 >>>>>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>>>>> >>>>>>> BUG: Adding missing parentheses around boolean expression >>>>>>> >>>>>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>>>>> >>>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>>>>> Author: Bradley Lowekamp >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 >>>>>>> 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 _______________________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: 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 wrote: > Yes, from the vtk tests. I created them with imagemagik > > > On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp > 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 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 wrote: >>>> Wow. The new itk tiff reader sad my tiled images. >>>> >>>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 >>>>> 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 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 >>>>>>> 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 >>>>>>>> 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 >>>>>>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>>>>>> >>>>>>>> BUG: Adding missing parentheses around boolean expression >>>>>>>> >>>>>>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>>>>>> >>>>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>>>>>> Author: Bradley Lowekamp >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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: -------------- next part -------------- _______________________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: 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 wrote: > Yes, from the vtk tests. I created them with imagemagik > > > On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp > 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 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 wrote: >>>> Wow. The new itk tiff reader sad my tiled images. >>>> >>>> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen 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 >>>>> 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 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 >>>>>>> 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 >>>>>>>> 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 >>>>>>>> Date: Fri Oct 24 13:42:02 2014 -0400 >>>>>>>> >>>>>>>> BUG: Adding missing parentheses around boolean expression >>>>>>>> >>>>>>>> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >>>>>>>> >>>>>>>> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >>>>>>>> Author: Bradley Lowekamp >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov> References: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov> Message-ID: I added that compression option to the possibilities On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp 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 wrote: > > Yes, from the vtk tests. I created them with imagemagik > > > On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp > 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 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 > wrote: > > Wow. The new itk tiff reader sad my tiled images. > > On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen > 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 > 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 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 > 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 > 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 > Date: Fri Oct 24 13:42:02 2014 -0400 > > BUG: Adding missing parentheses around boolean expression > > Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 > > commit 40afd95161727be3274f8094ce19fe45e2c3aa50 > Author: Bradley Lowekamp > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 _______________________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov> References: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov> Message-ID: I added that compression option to the possibilities On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp 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 wrote: > > Yes, from the vtk tests. I created them with imagemagik > > > On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp > 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 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 > wrote: > > Wow. The new itk tiff reader sad my tiled images. > > On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen > 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 > 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 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 > 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 > 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 > Date: Fri Oct 24 13:42:02 2014 -0400 > > BUG: Adding missing parentheses around boolean expression > > Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 > > commit 40afd95161727be3274f8094ce19fe45e2c3aa50 > Author: Bradley Lowekamp > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 > 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 _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov> 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 wrote: > I added that compression option to the possibilities > > > On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp > 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 wrote: >> >> Yes, from the vtk tests. I created them with imagemagik >> >> >> On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp >> 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 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 >> wrote: >> >> Wow. The new itk tiff reader sad my tiled images. >> >> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen >> 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 >> 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 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 >> 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 >> 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 >> Date: Fri Oct 24 13:42:02 2014 -0400 >> >> BUG: Adding missing parentheses around boolean expression >> >> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >> >> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >> Author: Bradley Lowekamp >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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: -------------- next part -------------- _______________________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov> 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 wrote: > I added that compression option to the possibilities > > > On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp > 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 wrote: >> >> Yes, from the vtk tests. I created them with imagemagik >> >> >> On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp >> 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 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 >> wrote: >> >> Wow. The new itk tiff reader sad my tiled images. >> >> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen >> 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 >> 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 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 >> 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 >> 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 >> Date: Fri Oct 24 13:42:02 2014 -0400 >> >> BUG: Adding missing parentheses around boolean expression >> >> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >> >> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >> Author: Bradley Lowekamp >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov> Message-ID: 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 wrote: > I added that compression option to the possibilities > > > On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp > 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 wrote: >> >> Yes, from the vtk tests. I created them with imagemagik >> >> >> On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp >> 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 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 >> wrote: >> >> Wow. The new itk tiff reader sad my tiled images. >> >> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen >> 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 >> 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 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 >> 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 >> 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 >> Date: Fri Oct 24 13:42:02 2014 -0400 >> >> BUG: Adding missing parentheses around boolean expression >> >> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >> >> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >> Author: Bradley Lowekamp >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 _____________________________________ 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 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] [ITK-dev] TIFFImageIO refactoring, please test In-Reply-To: References: <31435EB4-3EB1-46CA-9965-0F514D114139@mail.nih.gov> Message-ID: 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 wrote: > I added that compression option to the possibilities > > > On Fri, Nov 14, 2014 at 12:08 PM, Bradley Lowekamp > 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 wrote: >> >> Yes, from the vtk tests. I created them with imagemagik >> >> >> On Fri, Nov 14, 2014 at 11:06 AM, Bradley Lowekamp >> 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 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 >> wrote: >> >> Wow. The new itk tiff reader sad my tiled images. >> >> On Fri, Nov 14, 2014 at 10:25 AM, Bill Lorensen >> 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 >> 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 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 >> 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 >> 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 >> Date: Fri Oct 24 13:42:02 2014 -0400 >> >> BUG: Adding missing parentheses around boolean expression >> >> Change-Id: I669d160ff3ba830f3c33ac87de434db41472eb79 >> >> commit 40afd95161727be3274f8094ce19fe45e2c3aa50 >> Author: Bradley Lowekamp >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 >> 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 _______________________________________________ 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 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] [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 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 bschaffer at superstem.org Mon Nov 17 05:10:38 2014 From: bschaffer at superstem.org (Dr Bernhard Schaffer) Date: Mon, 17 Nov 2014 11:10:38 +0100 Subject: [ITK] ITK and DigitalMicgraph Message-ID: <002801d0024e$be5b3f20$3b11bd60$@superstem.org> Hi all, This is more an announcement than a question. The (spare time) project I've concerned myself with over the last few weeks - which brought me to ITK in a first place - was to create some glue-code between ITK and the scripting language of DigitalMicrograph (http://www.gatan.com/products/tem-analysis/gatan-microscopy-suite-software) I don't know if anybody on this list uses DigitalMicrograph, but it is a fairly wide-spread application software in Electron Microscopy and it features a very simple scripting language. Also, a 'basic' version of the software can be downloaded for free and features all of the scripting language, which makes it a nice playground for image analysis. So my idea was to provide simplified wrapper script commands to ITK functionality similar to what SimpleITK is attempting. So far, only some basic filters have been wrapped, but if there is enough interest in it, I plan on subsequently increasing the wrapped functionality. The plugin can be found on my homepage http://dmscript.tavernmaker.de/ Now for the question: Should this wrapper plugin for the specialized software be announced/linked to anywhere else? Regards, Bernhard PS: I would like to thank T.Uusimaeki - who did a similar wrapper in the past for his own work - for inspiring me to this project and fruitful discussions. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [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 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 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 _____________________________________ 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] [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 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 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 _____________________________________ 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] [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. _____________________________________ 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:21:41 2014 From: jmerkow at gmail.com (jmerkow) Date: Mon, 17 Nov 2014 16:21:41 -0700 (MST) Subject: [ITK] [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. _____________________________________ 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 michael.meuli at gmail.com Tue Nov 18 05:28:32 2014 From: michael.meuli at gmail.com (Michael Meuli) Date: Tue, 18 Nov 2014 11:28:32 +0100 Subject: [ITK] StatisticsLabelMapFilter example Message-ID: Hi all Could somebody point me to some example code using itk::StatisticsLabelMapFilter? Best regards Michael 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] 2D/3D registration Message-ID: 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: 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] [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 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 _____________________________________ 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:03:02 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 18 Nov 2014 09:03:02 -0500 Subject: [ITK] StatisticsLabelMapFilter example In-Reply-To: References: Message-ID: <0D6BEFD1-F80E-464E-B26F-6BF11EA05DCC@mail.nih.gov> Hello, Have you looked at the associated Insight Journal article? http://hdl.handle.net/1926/584 or http://www.insight-journal.org/browse/publication/176 The first template parameter is going to be a itk::LabelMap and the second is expected to be an itk::Image. If you are not already familiar with the LabelMaps, then you likely haven't converted your image to an itk::LabelMap yet. Then you have an itk::Image representing labels, so the itk::LabelImageToStatisticsLabelMapFilter may be a better filter. As it's inputs are itk::Images. Brad On Nov 18, 2014, at 5:28 AM, Michael Meuli wrote: > Hi all > > Could somebody point me to some example code using > itk::StatisticsLabelMapFilter? > > Best regards > Michael > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [ITK-users] 2D/3D registration In-Reply-To: References: Message-ID: 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 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] [ITK-users] 2D/3D registration In-Reply-To: References: 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 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 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 _____________________________________ 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 Tue Nov 18 10:20:25 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 18 Nov 2014 10:20:25 -0500 Subject: [ITK] [ITK-dev] Valgrind defects since October 27 Message-ID: Valgrind has been failing since October 27. Looks like these changes to SliceBySliceImageFilter may have introduced the defects. http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-27 Bill _______________________________________________ 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 blowekamp at mail.nih.gov Tue Nov 18 10:28:31 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 18 Nov 2014 10:28:31 -0500 Subject: [ITK] [ITK-dev] Valgrind defects since October 27 In-Reply-To: References: Message-ID: <7CBFFA5B-EAFE-423C-A6A5-7661E8E895A5@mail.nih.gov> Bill, Thanks for posting this again. Looking at the change the issue seems obvious to me now: https://github.com/Kitware/ITK/blob/master/Modules/Filtering/ImageGrid/test/itkSliceBySliceImageFilterTest.cxx#L160 Looks like the input test image is allocated but never initialized... Brad On Nov 18, 2014, at 10:20 AM, Bill Lorensen wrote: > Valgrind has been failing since October 27. Looks like these changes > to SliceBySliceImageFilter may have introduced the defects. > http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-27 > > Bill > _______________________________________________ > 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 _______________________________________________ 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 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] [ITK-users] 2D/3D registration In-Reply-To: <8F680DDF-47E4-4707-AA58-F30B2A6360DD@gmail.com> References: <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 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 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 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 _____________________________________ 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 Tue Nov 18 11:44:05 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 18 Nov 2014 11:44:05 -0500 Subject: [ITK] StatisticsLabelMapFilter example In-Reply-To: References: Message-ID: This example uses itkLabelStatisticsImageFilter. http://itk.org/Wiki/ITK/Examples/ImageProcessing/ScalarConnectedComponentImageFilter#ScalarConnectedComponentImageFilter.cxx If you have a LabelMap, then StatisticsLabelMapFilter could be used in a similar way. On Tue, Nov 18, 2014 at 5:28 AM, Michael Meuli wrote: > Hi all > > Could somebody point me to some example code using > itk::StatisticsLabelMapFilter? > > Best regards > Michael > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community -- Unpaid intern in BillsBasement at noware dot com 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] [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: > > > 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: -------------- next part -------------- _____________________________________ 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 16:42:41 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 18 Nov 2014 16:42:41 -0500 Subject: [ITK] [ITK-users] SimpleITK Downsampling results in blank image In-Reply-To: References: <1416266410055-34923.post@n7.nabble.com> <0789AC1A-931B-450C-A323-434318BB9253@mail.nih.gov> Message-ID: <37035E93-B7C0-45B9-A231-94281E935335@mail.nih.gov> Hello again, On Nov 18, 2014, at 2:52 PM, Jameson Merkow 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: -------------- next part -------------- _____________________________________ 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 Wed Nov 19 10:57:17 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 19 Nov 2014 10:57:17 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin Message-ID: Matt, This change: http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 is causing the WikiExamples Remote Module to fail doing execution. For example see: http://open.cdash.org/testDetails.php?test=288318310&build=3533969 What should I do? Bill _______________________________________________ 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 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] [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: -------------- next part -------------- _____________________________________ 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 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] [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 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: -------------- next part -------------- _____________________________________ 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 norman-k-williams at uiowa.edu Wed Nov 19 15:45:48 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Wed, 19 Nov 2014 20:45:48 +0000 Subject: [ITK] [ITK-dev] Aloha ITK Developers! Message-ID: This is my last day working for Hans Johnson at the University of Iowa. This e-mail address will shortly become inoperative; if for some reason you wish to contact me, try chaircrusher at gmail dot com. My new job at Leepfrog Technologies will not involve any image processing, so my involvement with the ITK community is mostly ending. I want to thank everyone for the many lessons in software development and obscure C++ programming, and the unique cameraderie of a geographically dispersed development team. ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 ntustison at gmail.com Wed Nov 19 16:40:45 2014 From: ntustison at gmail.com (Nicholas Tustison) Date: Wed, 19 Nov 2014 13:40:45 -0800 Subject: [ITK] [ITK-dev] Aloha ITK Developers! In-Reply-To: References: Message-ID: <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com> Kent, that?s terrible (for us)! Not only am I going to miss all the work that you do but your posts were often so very humorous. Good luck at your new job! Nick > On Nov 19, 2014, at 12:45 PM, Williams, Norman K wrote: > > This is my last day working for Hans Johnson at the University of Iowa. This e-mail address will shortly become inoperative; if for some reason you wish to contact me, try chaircrusher at gmail dot com. > > My new job at Leepfrog Technologies will not involve any image processing, so my involvement with the ITK community is mostly ending. I want to thank everyone for the many lessons in software development and obscure C++ programming, and the unique cameraderie of a geographically dispersed development team. > > > > > 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. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 bill.lorensen at gmail.com Wed Nov 19 16:42:28 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 19 Nov 2014 16:42:28 -0500 Subject: [ITK] [ITK-dev] Aloha ITK Developers! In-Reply-To: <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com> References: <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com> Message-ID: +1 On Wed, Nov 19, 2014 at 4:40 PM, Nicholas Tustison wrote: > Kent, that?s terrible (for us)! Not only am I going to miss all the > work that you do but your posts were often so very humorous. > Good luck at your new job! > > Nick > > > > On Nov 19, 2014, at 12:45 PM, Williams, Norman K > wrote: > > This is my last day working for Hans Johnson at the University of Iowa. > This e-mail address will shortly become inoperative; if for some reason you > wish to contact me, try chaircrusher at gmail dot com. > > My new job at Leepfrog Technologies will not involve any image processing, > so my involvement with the ITK community is mostly ending. I want to thank > everyone for the many lessons in software development and obscure C++ > programming, and the unique cameraderie of a geographically dispersed > development team. > > > > > ________________________________ > 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. > ________________________________ > _______________________________________________ > 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 > > > > _______________________________________________ > 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 _______________________________________________ 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 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] [ITK-users] read imageJ ROI to matlab Message-ID: 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] read imageJ ROI to matlab In-Reply-To: References: Message-ID: Hi, Check this contribution: http://www.mathworks.com/matlabcentral/fileexchange/32479-load---import-imagej-roi-files Cheers, On 19 November 2014 22: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 > > -- *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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] read imageJ ROI to matlab In-Reply-To: References: 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: -------------- next part -------------- _____________________________________ 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 20 00:33:13 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 20 Nov 2014 00:33:13 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin In-Reply-To: References: Message-ID: Hi Bill, Thanks for the note. I'll have to take a look. It may be that if one part of the Wiki Examples is using COMPONENTS, either all or none is required... Thanks, Matt On Wed, Nov 19, 2014 at 10:57 AM, Bill Lorensen wrote: > Matt, > This change: > http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 > is causing the WikiExamples Remote Module to fail doing execution. For > example see: > http://open.cdash.org/testDetails.php?test=288318310&build=3533969 > > What should I do? > > Bill _______________________________________________ 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 matt.mccormick at kitware.com Thu Nov 20 00:35:33 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 20 Nov 2014 00:35:33 -0500 Subject: [ITK] [ITK-dev] Aloha ITK Developers! In-Reply-To: References: <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com> Message-ID: Dear Kent, Best wishes on your new adventure -- you will be missed! Thanks for being an outstanding member of the community. Matt On Wed, Nov 19, 2014 at 4:42 PM, Bill Lorensen wrote: > +1 > > > On Wed, Nov 19, 2014 at 4:40 PM, Nicholas Tustison wrote: >> Kent, that?s terrible (for us)! Not only am I going to miss all the >> work that you do but your posts were often so very humorous. >> Good luck at your new job! >> >> Nick >> >> >> >> On Nov 19, 2014, at 12:45 PM, Williams, Norman K >> wrote: >> >> This is my last day working for Hans Johnson at the University of Iowa. >> This e-mail address will shortly become inoperative; if for some reason you >> wish to contact me, try chaircrusher at gmail dot com. >> >> My new job at Leepfrog Technologies will not involve any image processing, >> so my involvement with the ITK community is mostly ending. I want to thank >> everyone for the many lessons in software development and obscure C++ >> programming, and the unique cameraderie of a geographically dispersed >> development team. >> >> >> >> >> ________________________________ >> 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. >> ________________________________ >> _______________________________________________ >> 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 >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ > 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 _______________________________________________ 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 arnaudgelas at gmail.com Thu Nov 20 02:08:10 2014 From: arnaudgelas at gmail.com (Arnaud Gelas) Date: Thu, 20 Nov 2014 08:08:10 +0100 Subject: [ITK] [ITK-dev] Aloha ITK Developers! In-Reply-To: References: <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com> Message-ID: +1 Bonne chance pour la suite ;) On Wed, Nov 19, 2014 at 10:42 PM, Bill Lorensen wrote: > +1 > > > On Wed, Nov 19, 2014 at 4:40 PM, Nicholas Tustison > wrote: > > Kent, that?s terrible (for us)! Not only am I going to miss all the > > work that you do but your posts were often so very humorous. > > Good luck at your new job! > > > > Nick > > > > > > > > On Nov 19, 2014, at 12:45 PM, Williams, Norman K > > wrote: > > > > This is my last day working for Hans Johnson at the University of Iowa. > > This e-mail address will shortly become inoperative; if for some reason > you > > wish to contact me, try chaircrusher at gmail dot com. > > > > My new job at Leepfrog Technologies will not involve any image > processing, > > so my involvement with the ITK community is mostly ending. I want to > thank > > everyone for the many lessons in software development and obscure C++ > > programming, and the unique cameraderie of a geographically dispersed > > development team. > > > > > > > > > > ________________________________ > > 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. > > ________________________________ > > _______________________________________________ > > 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 > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 bill.lorensen at gmail.com Thu Nov 20 07:36:44 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 20 Nov 2014 07:36:44 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin In-Reply-To: References: Message-ID: Also, my normal ITK build which has several remote modules turned fails to build Linking CXX shared library ../../../../lib/libITKVtkGlue-4.7.dylib ld: library not found for -lvtkCommonCore collect2: ld returned 1 exit status make[2]: *** [lib/libITKVtkGlue-4.7.1.dylib] Error 1 On Thu, Nov 20, 2014 at 12:33 AM, Matt McCormick wrote: > Hi Bill, > > Thanks for the note. > > I'll have to take a look. > > It may be that if one part of the Wiki Examples is using COMPONENTS, > either all or none is required... > > Thanks, > Matt > > On Wed, Nov 19, 2014 at 10:57 AM, Bill Lorensen wrote: >> Matt, >> This change: >> http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 >> is causing the WikiExamples Remote Module to fail doing execution. For >> example see: >> http://open.cdash.org/testDetails.php?test=288318310&build=3533969 >> >> What should I do? >> >> Bill -- 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://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 blowekamp at mail.nih.gov Thu Nov 20 09:39:53 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Thu, 20 Nov 2014 09:39:53 -0500 Subject: [ITK] [ITK-dev] Valgrind: Old issue fixed and new ones pop up Message-ID: <642789B1-D658-48A8-B649-72CA883E57CD@mail.nih.gov> Hello, It looks like some new valgrind issues popped up the same day we fixed the old ones: http://open.cdash.org/viewDynamicAnalysis.php?buildid=3578841 Looks like the is the result of recent B-Spline field changes: https://github.com/InsightSoftwareConsortium/ITK/commit/b8bee55644e1d0e82d0067b01758f3eedff93c2d Add this is also likely the cause of an internal compiler segfault: http://open.cdash.org/viewBuildError.php?buildid=3578654 With clang 2.1.0 (wow, that's old on dashmacmini5): http://open.cdash.org/viewConfigure.php?buildid=3578654 Please let us know if you can fix this issue in a timely manner or need help. Thanks, Brad _______________________________________________ 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 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] [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 _____________________________________ 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 Thu Nov 20 10:40:10 2014 From: ntustison at gmail.com (Nicholas Tustison) Date: Thu, 20 Nov 2014 07:40:10 -0800 Subject: [ITK] [ITK-dev] Valgrind: Old issue fixed and new ones pop up In-Reply-To: <642789B1-D658-48A8-B649-72CA883E57CD@mail.nih.gov> References: <642789B1-D658-48A8-B649-72CA883E57CD@mail.nih.gov> Message-ID: Thanks Brad, I see one obvious problem which I?ll fix this morning (California time). Hopefully that will resolve the B-spline field issues. Nick > On Nov 20, 2014, at 6:39 AM, Bradley Lowekamp wrote: > > Hello, > > It looks like some new valgrind issues popped up the same day we fixed the old ones: > http://open.cdash.org/viewDynamicAnalysis.php?buildid=3578841 > > Looks like the is the result of recent B-Spline field changes: > https://github.com/InsightSoftwareConsortium/ITK/commit/b8bee55644e1d0e82d0067b01758f3eedff93c2d > > Add this is also likely the cause of an internal compiler segfault: > http://open.cdash.org/viewBuildError.php?buildid=3578654 > > With clang 2.1.0 (wow, that's old on dashmacmini5): > http://open.cdash.org/viewConfigure.php?buildid=3578654 > > Please let us know if you can fix this issue in a timely manner or need help. Thanks, > Brad _______________________________________________ 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 bill.lorensen at gmail.com Thu Nov 20 11:07:40 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 20 Nov 2014 11:07:40 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin In-Reply-To: References: Message-ID: Matt, I don't understand the use case for the original patch. If a module is loaded, but not requested it will not be added to the registered factories. What was wrong with the previous version? Where was it failing. I'd like to revert the current one since it breaks the remote wiki examples and also has issues with the vtkglue module. I put a message in my local UseITK.cmake file if(${_module_name}_LOADED AND ${_module_was_requested} EQUAL -1) message(STATUS "================ ${_module_name} is loaded but not requested") endif() and I get: -- ================ ITKIONIFTI is loaded but not requested -- ================ ITKIONRRD is loaded but not requested -- ================ ITKIOGIPL is loaded but not requested -- ================ ITKIOJPEG is loaded but not requested -- ================ ITKIOGDCM is loaded but not requested -- ================ ITKIOBMP is loaded but not requested -- ================ ITKIOLSM is loaded but not requested -- ================ ITKIOPNG is loaded but not requested -- ================ ITKIOTIFF is loaded but not requested -- ================ ITKIOVTK is loaded but not requested -- ================ ITKIOStimulate is loaded but not requested -- ================ ITKIOBioRad is loaded but not requested -- ================ ITKIOMeta is loaded but not requested -- ================ ITKIOTransformMatlab is loaded but not requested -- ================ ITKIOTransformHDF5 is loaded but not requested -- ================ ITKIOTransformInsightLegacy is loaded but not requested Bill On Thu, Nov 20, 2014 at 7:36 AM, Bill Lorensen wrote: > Also, my normal ITK build which has several remote modules turned fails to build > Linking CXX shared library ../../../../lib/libITKVtkGlue-4.7.dylib > ld: library not found for -lvtkCommonCore > collect2: ld returned 1 exit status > make[2]: *** [lib/libITKVtkGlue-4.7.1.dylib] Error 1 > > > > On Thu, Nov 20, 2014 at 12:33 AM, Matt McCormick > wrote: >> Hi Bill, >> >> Thanks for the note. >> >> I'll have to take a look. >> >> It may be that if one part of the Wiki Examples is using COMPONENTS, >> either all or none is required... >> >> Thanks, >> Matt >> >> On Wed, Nov 19, 2014 at 10:57 AM, Bill Lorensen wrote: >>> Matt, >>> This change: >>> http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 >>> is causing the WikiExamples Remote Module to fail doing execution. For >>> example see: >>> http://open.cdash.org/testDetails.php?test=288318310&build=3533969 >>> >>> What should I do? >>> >>> Bill > > > > -- > Unpaid intern in BillsBasement at noware dot com -- 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://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 tyoo at mail.nih.gov Thu Nov 20 15:46:20 2014 From: tyoo at mail.nih.gov (Terry Yoo) Date: Thu, 20 Nov 2014 15:46:20 -0500 Subject: [ITK] [ITK-dev] Aloha ITK Developers! In-Reply-To: References: <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com> Message-ID: Kent: Thank you for your dedicated service to our community. Best of everything in all your future projects. -Terry Terry S. Yoo, PhD Office of High Performance Computing and Communications National Library of Medicine National Institutes of Health tyoo at mail.nih.gov On Nov 20, 2014, at 2:08 AM, Arnaud Gelas wrote: > +1 > Bonne chance pour la suite ;) > > On Wed, Nov 19, 2014 at 10:42 PM, Bill Lorensen wrote: > +1 > > > On Wed, Nov 19, 2014 at 4:40 PM, Nicholas Tustison wrote: > > Kent, that?s terrible (for us)! Not only am I going to miss all the > > work that you do but your posts were often so very humorous. > > Good luck at your new job! > > > > Nick > > > > > > > > On Nov 19, 2014, at 12:45 PM, Williams, Norman K > > wrote: > > > > This is my last day working for Hans Johnson at the University of Iowa. > > This e-mail address will shortly become inoperative; if for some reason you > > wish to contact me, try chaircrusher at gmail dot com. > > > > My new job at Leepfrog Technologies will not involve any image processing, > > so my involvement with the ITK community is mostly ending. I want to thank > > everyone for the many lessons in software development and obscure C++ > > programming, and the unique cameraderie of a geographically dispersed > > development team. > > > > > > > > > > ________________________________ > > 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. > > ________________________________ > > _______________________________________________ > > 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 > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 matt.mccormick at kitware.com Fri Nov 21 00:34:17 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 21 Nov 2014 00:34:17 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin In-Reply-To: References: Message-ID: Hi Bill, That patch is required to prevent link errors with static builds and multiple calls to COMPONENTS -- it should not be reverted. The factory initialization code looks for non-provided symbols in this case: "Multiple calls to find_package(ITK COMPONENTS ...) within a project can result in different IO modules being enabled as ${module}_LOADED. However, the ${module}_LOADED does not match the requested modules enabled with COMPONENTS. Since ITK_LIBRARIES will only contain the requested modules, we must only use these modules to avoid link errors for the factory registration symbols." [1] The ITKVTKGlue error sounds like an unrelated CMake issue. I will see if I can reproduce. Thanks, Matt [1] http://itk.org/gitweb?p=ITK.git;a=commitdiff;h=a0b2c43a2e5c96bdf55b402d1031a03e8b349f21 On Thu, Nov 20, 2014 at 11:07 AM, Bill Lorensen wrote: > Matt, > > I don't understand the use case for the original patch. If a module is > loaded, but not requested it will not be added to the registered > factories. What was wrong with the previous version? Where was it > failing. > > I'd like to revert the current one since it breaks the remote wiki > examples and also has issues with the vtkglue module. > > I put a message in my local UseITK.cmake file > if(${_module_name}_LOADED AND ${_module_was_requested} EQUAL -1) > message(STATUS "================ ${_module_name} is loaded but not > requested") > endif() > > and I get: > > -- ================ ITKIONIFTI is loaded but not requested > -- ================ ITKIONRRD is loaded but not requested > -- ================ ITKIOGIPL is loaded but not requested > -- ================ ITKIOJPEG is loaded but not requested > -- ================ ITKIOGDCM is loaded but not requested > -- ================ ITKIOBMP is loaded but not requested > -- ================ ITKIOLSM is loaded but not requested > -- ================ ITKIOPNG is loaded but not requested > -- ================ ITKIOTIFF is loaded but not requested > -- ================ ITKIOVTK is loaded but not requested > -- ================ ITKIOStimulate is loaded but not requested > -- ================ ITKIOBioRad is loaded but not requested > -- ================ ITKIOMeta is loaded but not requested > -- ================ ITKIOTransformMatlab is loaded but not requested > -- ================ ITKIOTransformHDF5 is loaded but not requested > -- ================ ITKIOTransformInsightLegacy is loaded but not requested > > Bill > > On Thu, Nov 20, 2014 at 7:36 AM, Bill Lorensen wrote: >> Also, my normal ITK build which has several remote modules turned fails to build >> Linking CXX shared library ../../../../lib/libITKVtkGlue-4.7.dylib >> ld: library not found for -lvtkCommonCore >> collect2: ld returned 1 exit status >> make[2]: *** [lib/libITKVtkGlue-4.7.1.dylib] Error 1 >> >> >> >> On Thu, Nov 20, 2014 at 12:33 AM, Matt McCormick >> wrote: >>> Hi Bill, >>> >>> Thanks for the note. >>> >>> I'll have to take a look. >>> >>> It may be that if one part of the Wiki Examples is using COMPONENTS, >>> either all or none is required... >>> >>> Thanks, >>> Matt >>> >>> On Wed, Nov 19, 2014 at 10:57 AM, Bill Lorensen wrote: >>>> Matt, >>>> This change: >>>> http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 >>>> is causing the WikiExamples Remote Module to fail doing execution. For >>>> example see: >>>> http://open.cdash.org/testDetails.php?test=288318310&build=3533969 >>>> >>>> What should I do? >>>> >>>> Bill >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > -- > 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://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 bill.lorensen at gmail.com Fri Nov 21 07:55:04 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 21 Nov 2014 07:55:04 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin In-Reply-To: References: Message-ID: Well, the wiki examples that do i/o no longer run. On Fri, Nov 21, 2014 at 12:34 AM, Matt McCormick wrote: > Hi Bill, > > That patch is required to prevent link errors with static builds and > multiple calls to COMPONENTS -- it should not be reverted. The > factory initialization code looks for non-provided symbols in this > case: > > "Multiple calls to find_package(ITK COMPONENTS ...) within a project > can result in different IO modules being enabled as ${module}_LOADED. > However, the ${module}_LOADED does not match the requested modules > enabled with COMPONENTS. Since ITK_LIBRARIES will only contain the > requested modules, we must only use these modules to avoid link errors > for the factory registration symbols." [1] > > The ITKVTKGlue error sounds like an unrelated CMake issue. > > I will see if I can reproduce. > > Thanks, > Matt > > [1] http://itk.org/gitweb?p=ITK.git;a=commitdiff;h=a0b2c43a2e5c96bdf55b402d1031a03e8b349f21 > > On Thu, Nov 20, 2014 at 11:07 AM, Bill Lorensen wrote: >> Matt, >> >> I don't understand the use case for the original patch. If a module is >> loaded, but not requested it will not be added to the registered >> factories. What was wrong with the previous version? Where was it >> failing. >> >> I'd like to revert the current one since it breaks the remote wiki >> examples and also has issues with the vtkglue module. >> >> I put a message in my local UseITK.cmake file >> if(${_module_name}_LOADED AND ${_module_was_requested} EQUAL -1) >> message(STATUS "================ ${_module_name} is loaded but not >> requested") >> endif() >> >> and I get: >> >> -- ================ ITKIONIFTI is loaded but not requested >> -- ================ ITKIONRRD is loaded but not requested >> -- ================ ITKIOGIPL is loaded but not requested >> -- ================ ITKIOJPEG is loaded but not requested >> -- ================ ITKIOGDCM is loaded but not requested >> -- ================ ITKIOBMP is loaded but not requested >> -- ================ ITKIOLSM is loaded but not requested >> -- ================ ITKIOPNG is loaded but not requested >> -- ================ ITKIOTIFF is loaded but not requested >> -- ================ ITKIOVTK is loaded but not requested >> -- ================ ITKIOStimulate is loaded but not requested >> -- ================ ITKIOBioRad is loaded but not requested >> -- ================ ITKIOMeta is loaded but not requested >> -- ================ ITKIOTransformMatlab is loaded but not requested >> -- ================ ITKIOTransformHDF5 is loaded but not requested >> -- ================ ITKIOTransformInsightLegacy is loaded but not requested >> >> Bill >> >> On Thu, Nov 20, 2014 at 7:36 AM, Bill Lorensen wrote: >>> Also, my normal ITK build which has several remote modules turned fails to build >>> Linking CXX shared library ../../../../lib/libITKVtkGlue-4.7.dylib >>> ld: library not found for -lvtkCommonCore >>> collect2: ld returned 1 exit status >>> make[2]: *** [lib/libITKVtkGlue-4.7.1.dylib] Error 1 >>> >>> >>> >>> On Thu, Nov 20, 2014 at 12:33 AM, Matt McCormick >>> wrote: >>>> Hi Bill, >>>> >>>> Thanks for the note. >>>> >>>> I'll have to take a look. >>>> >>>> It may be that if one part of the Wiki Examples is using COMPONENTS, >>>> either all or none is required... >>>> >>>> Thanks, >>>> Matt >>>> >>>> On Wed, Nov 19, 2014 at 10:57 AM, Bill Lorensen wrote: >>>>> Matt, >>>>> This change: >>>>> http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 >>>>> is causing the WikiExamples Remote Module to fail doing execution. For >>>>> example see: >>>>> http://open.cdash.org/testDetails.php?test=288318310&build=3533969 >>>>> >>>>> What should I do? >>>>> >>>>> Bill >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com -- 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://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 bill.lorensen at gmail.com Fri Nov 21 08:16:23 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 21 Nov 2014 08:16:23 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin In-Reply-To: References: Message-ID: I think I found a workaround on my end. On Fri, Nov 21, 2014 at 7:55 AM, Bill Lorensen wrote: > Well, the wiki examples that do i/o no longer run. > > > On Fri, Nov 21, 2014 at 12:34 AM, Matt McCormick > wrote: >> Hi Bill, >> >> That patch is required to prevent link errors with static builds and >> multiple calls to COMPONENTS -- it should not be reverted. The >> factory initialization code looks for non-provided symbols in this >> case: >> >> "Multiple calls to find_package(ITK COMPONENTS ...) within a project >> can result in different IO modules being enabled as ${module}_LOADED. >> However, the ${module}_LOADED does not match the requested modules >> enabled with COMPONENTS. Since ITK_LIBRARIES will only contain the >> requested modules, we must only use these modules to avoid link errors >> for the factory registration symbols." [1] >> >> The ITKVTKGlue error sounds like an unrelated CMake issue. >> >> I will see if I can reproduce. >> >> Thanks, >> Matt >> >> [1] http://itk.org/gitweb?p=ITK.git;a=commitdiff;h=a0b2c43a2e5c96bdf55b402d1031a03e8b349f21 >> >> On Thu, Nov 20, 2014 at 11:07 AM, Bill Lorensen wrote: >>> Matt, >>> >>> I don't understand the use case for the original patch. If a module is >>> loaded, but not requested it will not be added to the registered >>> factories. What was wrong with the previous version? Where was it >>> failing. >>> >>> I'd like to revert the current one since it breaks the remote wiki >>> examples and also has issues with the vtkglue module. >>> >>> I put a message in my local UseITK.cmake file >>> if(${_module_name}_LOADED AND ${_module_was_requested} EQUAL -1) >>> message(STATUS "================ ${_module_name} is loaded but not >>> requested") >>> endif() >>> >>> and I get: >>> >>> -- ================ ITKIONIFTI is loaded but not requested >>> -- ================ ITKIONRRD is loaded but not requested >>> -- ================ ITKIOGIPL is loaded but not requested >>> -- ================ ITKIOJPEG is loaded but not requested >>> -- ================ ITKIOGDCM is loaded but not requested >>> -- ================ ITKIOBMP is loaded but not requested >>> -- ================ ITKIOLSM is loaded but not requested >>> -- ================ ITKIOPNG is loaded but not requested >>> -- ================ ITKIOTIFF is loaded but not requested >>> -- ================ ITKIOVTK is loaded but not requested >>> -- ================ ITKIOStimulate is loaded but not requested >>> -- ================ ITKIOBioRad is loaded but not requested >>> -- ================ ITKIOMeta is loaded but not requested >>> -- ================ ITKIOTransformMatlab is loaded but not requested >>> -- ================ ITKIOTransformHDF5 is loaded but not requested >>> -- ================ ITKIOTransformInsightLegacy is loaded but not requested >>> >>> Bill >>> >>> On Thu, Nov 20, 2014 at 7:36 AM, Bill Lorensen wrote: >>>> Also, my normal ITK build which has several remote modules turned fails to build >>>> Linking CXX shared library ../../../../lib/libITKVtkGlue-4.7.dylib >>>> ld: library not found for -lvtkCommonCore >>>> collect2: ld returned 1 exit status >>>> make[2]: *** [lib/libITKVtkGlue-4.7.1.dylib] Error 1 >>>> >>>> >>>> >>>> On Thu, Nov 20, 2014 at 12:33 AM, Matt McCormick >>>> wrote: >>>>> Hi Bill, >>>>> >>>>> Thanks for the note. >>>>> >>>>> I'll have to take a look. >>>>> >>>>> It may be that if one part of the Wiki Examples is using COMPONENTS, >>>>> either all or none is required... >>>>> >>>>> Thanks, >>>>> Matt >>>>> >>>>> On Wed, Nov 19, 2014 at 10:57 AM, Bill Lorensen wrote: >>>>>> Matt, >>>>>> This change: >>>>>> http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 >>>>>> is causing the WikiExamples Remote Module to fail doing execution. For >>>>>> example see: >>>>>> http://open.cdash.org/testDetails.php?test=288318310&build=3533969 >>>>>> >>>>>> What should I do? >>>>>> >>>>>> Bill >>>> >>>> >>>> >>>> -- >>>> 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 _______________________________________________ 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 matt.mccormick at kitware.com Fri Nov 21 10:07:12 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 21 Nov 2014 10:07:12 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin In-Reply-To: References: Message-ID: I have been able to reproduce the test failures locally. What is the workaround? On Fri, Nov 21, 2014 at 8:16 AM, Bill Lorensen wrote: > I think I found a workaround on my end. > > > On Fri, Nov 21, 2014 at 7:55 AM, Bill Lorensen wrote: >> Well, the wiki examples that do i/o no longer run. >> >> >> On Fri, Nov 21, 2014 at 12:34 AM, Matt McCormick >> wrote: >>> Hi Bill, >>> >>> That patch is required to prevent link errors with static builds and >>> multiple calls to COMPONENTS -- it should not be reverted. The >>> factory initialization code looks for non-provided symbols in this >>> case: >>> >>> "Multiple calls to find_package(ITK COMPONENTS ...) within a project >>> can result in different IO modules being enabled as ${module}_LOADED. >>> However, the ${module}_LOADED does not match the requested modules >>> enabled with COMPONENTS. Since ITK_LIBRARIES will only contain the >>> requested modules, we must only use these modules to avoid link errors >>> for the factory registration symbols." [1] >>> >>> The ITKVTKGlue error sounds like an unrelated CMake issue. >>> >>> I will see if I can reproduce. >>> >>> Thanks, >>> Matt >>> >>> [1] http://itk.org/gitweb?p=ITK.git;a=commitdiff;h=a0b2c43a2e5c96bdf55b402d1031a03e8b349f21 >>> >>> On Thu, Nov 20, 2014 at 11:07 AM, Bill Lorensen wrote: >>>> Matt, >>>> >>>> I don't understand the use case for the original patch. If a module is >>>> loaded, but not requested it will not be added to the registered >>>> factories. What was wrong with the previous version? Where was it >>>> failing. >>>> >>>> I'd like to revert the current one since it breaks the remote wiki >>>> examples and also has issues with the vtkglue module. >>>> >>>> I put a message in my local UseITK.cmake file >>>> if(${_module_name}_LOADED AND ${_module_was_requested} EQUAL -1) >>>> message(STATUS "================ ${_module_name} is loaded but not >>>> requested") >>>> endif() >>>> >>>> and I get: >>>> >>>> -- ================ ITKIONIFTI is loaded but not requested >>>> -- ================ ITKIONRRD is loaded but not requested >>>> -- ================ ITKIOGIPL is loaded but not requested >>>> -- ================ ITKIOJPEG is loaded but not requested >>>> -- ================ ITKIOGDCM is loaded but not requested >>>> -- ================ ITKIOBMP is loaded but not requested >>>> -- ================ ITKIOLSM is loaded but not requested >>>> -- ================ ITKIOPNG is loaded but not requested >>>> -- ================ ITKIOTIFF is loaded but not requested >>>> -- ================ ITKIOVTK is loaded but not requested >>>> -- ================ ITKIOStimulate is loaded but not requested >>>> -- ================ ITKIOBioRad is loaded but not requested >>>> -- ================ ITKIOMeta is loaded but not requested >>>> -- ================ ITKIOTransformMatlab is loaded but not requested >>>> -- ================ ITKIOTransformHDF5 is loaded but not requested >>>> -- ================ ITKIOTransformInsightLegacy is loaded but not requested >>>> >>>> Bill >>>> >>>> On Thu, Nov 20, 2014 at 7:36 AM, Bill Lorensen wrote: >>>>> Also, my normal ITK build which has several remote modules turned fails to build >>>>> Linking CXX shared library ../../../../lib/libITKVtkGlue-4.7.dylib >>>>> ld: library not found for -lvtkCommonCore >>>>> collect2: ld returned 1 exit status >>>>> make[2]: *** [lib/libITKVtkGlue-4.7.1.dylib] Error 1 >>>>> >>>>> >>>>> >>>>> On Thu, Nov 20, 2014 at 12:33 AM, Matt McCormick >>>>> wrote: >>>>>> Hi Bill, >>>>>> >>>>>> Thanks for the note. >>>>>> >>>>>> I'll have to take a look. >>>>>> >>>>>> It may be that if one part of the Wiki Examples is using COMPONENTS, >>>>>> either all or none is required... >>>>>> >>>>>> Thanks, >>>>>> Matt >>>>>> >>>>>> On Wed, Nov 19, 2014 at 10:57 AM, Bill Lorensen wrote: >>>>>>> Matt, >>>>>>> This change: >>>>>>> http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 >>>>>>> is causing the WikiExamples Remote Module to fail doing execution. For >>>>>>> example see: >>>>>>> http://open.cdash.org/testDetails.php?test=288318310&build=3533969 >>>>>>> >>>>>>> What should I do? >>>>>>> >>>>>>> Bill >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 _______________________________________________ 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 bill.lorensen at gmail.com Fri Nov 21 10:12:12 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 21 Nov 2014 10:12:12 -0500 Subject: [ITK] [ITK-dev] Problems with WikiExamples Remote Module after recent checkin In-Reply-To: References: Message-ID: I needed to change the way I configured if building as a remote module. I needed to explicitly include ITKConfig.cmake before including the ITKUse.cmake. This simulates a find_package (ITK). I have checked in the changes to the wikiExamples repo. I'll be updated the remote module for ITK soon. Bill On Fri, Nov 21, 2014 at 10:07 AM, Matt McCormick wrote: > I have been able to reproduce the test failures locally. > > What is the workaround? > > On Fri, Nov 21, 2014 at 8:16 AM, Bill Lorensen wrote: >> I think I found a workaround on my end. >> >> >> On Fri, Nov 21, 2014 at 7:55 AM, Bill Lorensen wrote: >>> Well, the wiki examples that do i/o no longer run. >>> >>> >>> On Fri, Nov 21, 2014 at 12:34 AM, Matt McCormick >>> wrote: >>>> Hi Bill, >>>> >>>> That patch is required to prevent link errors with static builds and >>>> multiple calls to COMPONENTS -- it should not be reverted. The >>>> factory initialization code looks for non-provided symbols in this >>>> case: >>>> >>>> "Multiple calls to find_package(ITK COMPONENTS ...) within a project >>>> can result in different IO modules being enabled as ${module}_LOADED. >>>> However, the ${module}_LOADED does not match the requested modules >>>> enabled with COMPONENTS. Since ITK_LIBRARIES will only contain the >>>> requested modules, we must only use these modules to avoid link errors >>>> for the factory registration symbols." [1] >>>> >>>> The ITKVTKGlue error sounds like an unrelated CMake issue. >>>> >>>> I will see if I can reproduce. >>>> >>>> Thanks, >>>> Matt >>>> >>>> [1] http://itk.org/gitweb?p=ITK.git;a=commitdiff;h=a0b2c43a2e5c96bdf55b402d1031a03e8b349f21 >>>> >>>> On Thu, Nov 20, 2014 at 11:07 AM, Bill Lorensen wrote: >>>>> Matt, >>>>> >>>>> I don't understand the use case for the original patch. If a module is >>>>> loaded, but not requested it will not be added to the registered >>>>> factories. What was wrong with the previous version? Where was it >>>>> failing. >>>>> >>>>> I'd like to revert the current one since it breaks the remote wiki >>>>> examples and also has issues with the vtkglue module. >>>>> >>>>> I put a message in my local UseITK.cmake file >>>>> if(${_module_name}_LOADED AND ${_module_was_requested} EQUAL -1) >>>>> message(STATUS "================ ${_module_name} is loaded but not >>>>> requested") >>>>> endif() >>>>> >>>>> and I get: >>>>> >>>>> -- ================ ITKIONIFTI is loaded but not requested >>>>> -- ================ ITKIONRRD is loaded but not requested >>>>> -- ================ ITKIOGIPL is loaded but not requested >>>>> -- ================ ITKIOJPEG is loaded but not requested >>>>> -- ================ ITKIOGDCM is loaded but not requested >>>>> -- ================ ITKIOBMP is loaded but not requested >>>>> -- ================ ITKIOLSM is loaded but not requested >>>>> -- ================ ITKIOPNG is loaded but not requested >>>>> -- ================ ITKIOTIFF is loaded but not requested >>>>> -- ================ ITKIOVTK is loaded but not requested >>>>> -- ================ ITKIOStimulate is loaded but not requested >>>>> -- ================ ITKIOBioRad is loaded but not requested >>>>> -- ================ ITKIOMeta is loaded but not requested >>>>> -- ================ ITKIOTransformMatlab is loaded but not requested >>>>> -- ================ ITKIOTransformHDF5 is loaded but not requested >>>>> -- ================ ITKIOTransformInsightLegacy is loaded but not requested >>>>> >>>>> Bill >>>>> >>>>> On Thu, Nov 20, 2014 at 7:36 AM, Bill Lorensen wrote: >>>>>> Also, my normal ITK build which has several remote modules turned fails to build >>>>>> Linking CXX shared library ../../../../lib/libITKVtkGlue-4.7.dylib >>>>>> ld: library not found for -lvtkCommonCore >>>>>> collect2: ld returned 1 exit status >>>>>> make[2]: *** [lib/libITKVtkGlue-4.7.1.dylib] Error 1 >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Nov 20, 2014 at 12:33 AM, Matt McCormick >>>>>> wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> Thanks for the note. >>>>>>> >>>>>>> I'll have to take a look. >>>>>>> >>>>>>> It may be that if one part of the Wiki Examples is using COMPONENTS, >>>>>>> either all or none is required... >>>>>>> >>>>>>> Thanks, >>>>>>> Matt >>>>>>> >>>>>>> On Wed, Nov 19, 2014 at 10:57 AM, Bill Lorensen wrote: >>>>>>>> Matt, >>>>>>>> This change: >>>>>>>> http://open.cdash.org/viewChanges.php?project=Insight&date=2014-10-18 >>>>>>>> is causing the WikiExamples Remote Module to fail doing execution. For >>>>>>>> example see: >>>>>>>> http://open.cdash.org/testDetails.php?test=288318310&build=3533969 >>>>>>>> >>>>>>>> What should I do? >>>>>>>> >>>>>>>> Bill >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 _______________________________________________ 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 arjun89 at cmu.edu Fri Nov 21 13:18:41 2014 From: arjun89 at cmu.edu (Arjun S Kumar) Date: Fri, 21 Nov 2014 13:18:41 -0500 Subject: [ITK] [ITK Community] Speeding up Cross Correlation Message-ID: Hi all, I am trying to cross correlate two images such that the output image displays the similarity of the first image and the second image as a function of the translation of the second image. Currently, I'm using the itk::FFTNormalizedCorrelationImageFilter class. However, only a small portion, close to the center, of the output image is relevant for me. For example, for two images of sizes 500x500, the output image is about 1000x1000. However, I only need a 50x50 portion of the output image, centered at the center of the output image. So my question is, can I use this fact to perform the cross correlation faster? I tried using the SetRequiredNumberOfOverlappingPixels method to discard regions outside the 50x50 portion of the image but this didn't have a discernible effect on the speed of the operation. Shouldn't setting the required number of overlapping pixels to a high number decrease the time needed by reducing the domain of the output image? Is there a different way to manually set the size of the output image so that the computation is made faster? Can I change the requested region of the output image, just as we can do for input images? Are there other ITK classes that are more suited for this purpose. Does anybody recommend using neighborhood iterators? The problem I see with this is using a 500x500 neighborhood, which is too high isn't it? Please let me know. Thanks, Arjun From matt.mccormick at kitware.com Fri Nov 21 13:56:06 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 21 Nov 2014 13:56:06 -0500 Subject: [ITK] [ITK Community] Speeding up Cross Correlation In-Reply-To: References: Message-ID: Hi Arjun, Since computing an FFT requires all of an image, you cannot speed up this algorithm even if only part of the output is required. Some other options: ConvolutionImageFilter [1] A cross correlation metric [2]. Hope this helps, Matt [1] http://www.itk.org/Doxygen/html/classitk_1_1ConvolutionImageFilter.html [2] http://www.itk.org/Doxygen/html/classitk_1_1CorrelationImageToImageMetricv4.html On Fri, Nov 21, 2014 at 1:18 PM, Arjun S Kumar wrote: > Hi all, > > I am trying to cross correlate two images such that the output image displays the similarity of the first image and the second image as a function of the translation of the second image. > > Currently, I'm using the itk::FFTNormalizedCorrelationImageFilter class. However, only a small portion, close to the center, of the output image is relevant for me. For example, for two images of sizes 500x500, the output image is about 1000x1000. However, I only need a 50x50 portion of the output image, centered at the center of the output image. > > So my question is, can I use this fact to perform the cross correlation faster? I tried using the SetRequiredNumberOfOverlappingPixels method to discard regions outside the 50x50 portion of the image but this didn't have a discernible effect on the speed of the operation. Shouldn't setting the required number of overlapping pixels to a high number decrease the time needed by reducing the domain of the output image? > > Is there a different way to manually set the size of the output image so that the computation is made faster? Can I change the requested region of the output image, just as we can do for input images? > > Are there other ITK classes that are more suited for this purpose. Does anybody recommend using neighborhood iterators? The problem I see with this is using a 500x500 neighborhood, which is too high isn't it? > > Please let me know. > > Thanks, > > Arjun > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community From blowekamp at mail.nih.gov Fri Nov 21 14:10:07 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Fri, 21 Nov 2014 14:10:07 -0500 Subject: [ITK] [ITK Community] Speeding up Cross Correlation In-Reply-To: References: Message-ID: <93CBBCE2-2865-441A-8D9C-0B09B834FFFE@mail.nih.gov> Hello, FFT's only operate on the whole image in the frequency domain, so the the cost to compute can not be changed as you ask. You should be able to crop the large image though to reduce the computation. However, there is an alternative. I think you have a case to try the non-FFT version the NormalizedCorrelationImageFilter[1]. This filter operates in the spacial domain and appears to support updating an arbitrary area [2]. So you should be able to use an ExtractImageFilter or manually set the ROI to update and only update the needed area. As you suspect this is still a really large neighborhood to do in the spacial domain the order of the operation is 500x500x50x50 = 6.25e8, where if the FFT operation is O(n log n), with n = 1000x1000 then the operation is on the order of 6e6. So it's likely the spacial domain algorithm will still be slower. This is an interesting case. I hope you report your conclusion. Brad [1] http://www.itk.org/Doxygen/html/classitk_1_1NormalizedCorrelationImageFilter.html [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/Convolution/include/itkNormalizedCorrelationImageFilter.hxx#L47-L90 On Nov 21, 2014, at 1:18 PM, Arjun S Kumar wrote: > Hi all, > > I am trying to cross correlate two images such that the output image displays the similarity of the first image and the second image as a function of the translation of the second image. > > Currently, I'm using the itk::FFTNormalizedCorrelationImageFilter class. However, only a small portion, close to the center, of the output image is relevant for me. For example, for two images of sizes 500x500, the output image is about 1000x1000. However, I only need a 50x50 portion of the output image, centered at the center of the output image. > > So my question is, can I use this fact to perform the cross correlation faster? I tried using the SetRequiredNumberOfOverlappingPixels method to discard regions outside the 50x50 portion of the image but this didn't have a discernible effect on the speed of the operation. Shouldn't setting the required number of overlapping pixels to a high number decrease the time needed by reducing the domain of the output image? > > Is there a different way to manually set the size of the output image so that the computation is made faster? Can I change the requested region of the output image, just as we can do for input images? > > Are there other ITK classes that are more suited for this purpose. Does anybody recommend using neighborhood iterators? The problem I see with this is using a 500x500 neighborhood, which is too high isn't it? > > Please let me know. > > Thanks, > > Arjun > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community 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] [ITK-users] Texture features/descriptors for 3D objects Message-ID: 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Encapsulate a ITK function into a DLL to be used with C# Message-ID: 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 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 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Encapsulate a ITK function into a DLL to be used with C# In-Reply-To: References: Message-ID: Hello Have you looked into SimpleITK's C Sharp bindings? > On Nov 22, 2014, at 7:31 AM, Matias Montroull 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 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 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 _____________________________________ 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] [ITK-users] Encapsulate a ITK function into a DLL to be used with C# In-Reply-To: References: Message-ID: 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 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 > 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 > 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 > _____________________________________ 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] [ITK-users] Texture features/descriptors for 3D objects In-Reply-To: References: Message-ID: 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 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 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] [ITK-users] Texture features/descriptors for 3D objects In-Reply-To: References: Message-ID: 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_1HistogramToRunLengthFeaturesFilter.html http://www.itk.org/Doxygen/html/classitk_1_1StochasticFractalDimensionImageFilter.html Nick > On Nov 22, 2014, at 9:32 AM, Matt McCormick 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 > 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: -------------- next part -------------- _____________________________________ 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 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] [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 svd(VNLMatrix); Yet, it runs fine when I use this line instead: vnl_svd 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 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 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. _____________________________________ 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 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] [ITK-users] Encapsulate a ITK function into a DLL to be used with C# In-Reply-To: References: Message-ID: 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" 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 > 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 > 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-dev] Problem reading a big nifti volume. Message-ID: 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: -------------- next part -------------- _______________________________________________ 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 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] [ITK-users] Problem reading a big nifti volume. Message-ID: 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Problem reading a big nifti volume. In-Reply-To: References: 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Problem reading a big nifti volume. In-Reply-To: <54725C6B.7020001@auckland.ac.nz> References: <54725C6B.7020001@auckland.ac.nz> Message-ID: Hi Jerome, Yes, I correctly specified the pixel type to unsigned char. On Sun, Nov 23, 2014 at 5:15 PM, Jerome Plumat 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 > > 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://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: -------------- next part -------------- _____________________________________ 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 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] [ITK-dev] [ITK-users] Problem reading a big nifti volume. In-Reply-To: <54725C6B.7020001@auckland.ac.nz> References: <54725C6B.7020001@auckland.ac.nz> Message-ID: Hi Jerome, Yes, I correctly specified the pixel type to unsigned char. On Sun, Nov 23, 2014 at 5:15 PM, Jerome Plumat 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 > > 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://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: -------------- next part -------------- _______________________________________________ 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 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] [ITK-users] Problem reading a big nifti volume. In-Reply-To: References: Message-ID: 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Problem reading a big nifti volume. In-Reply-To: References: Message-ID: 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 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: -------------- next part -------------- _____________________________________ 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 Mon Nov 24 08:47:47 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Mon, 24 Nov 2014 08:47:47 -0500 Subject: [ITK] [ITK-dev] Redesigning the way examples are added Message-ID: Matt, It looks like you started some awesome work to get more examples into the doxygen. This is really a great idea and I think it will benefit many people using ITK. I have an alternative approach to suggest that may be more maintainable and flexible in the long run. Perhaps the itk_module macro could be extended with an additional named argument. Something like "EXAMPLE_REGEX_LIST". This would enable module them selfs to control the examples listed, and may paves way to include examples in addition to test is external/internal modules. I don't think this should be too hard to do. What do you think? Brad _______________________________________________ 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 blowekamp at mail.nih.gov Mon Nov 24 08:58:21 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Mon, 24 Nov 2014 08:58:21 -0500 Subject: [ITK] [ITK-dev] Override keyword requirements: New transform compilation errors. Message-ID: <71E0EE41-524B-49C6-84A6-61E3AA8B10C4@mail.nih.gov> Community Developers, Recently a number of builds that are running C++11 have been producing errors when the override moniker is not used on derived method. This is difficult for many contributors to ensure because this is new to C++11 and those who are not compiling for that version of C++ are oblivious to this potential error. Is it worth the effort to enforce this usage? Or should we try to see if it can only be a warning? If we want to enforce it's usage then we will _need_ a cdash at home build with this flag, so that we can check the gerrit builds. But I don't think that we have additional cdash at home resources to additional builds. Hans, There are some new compilation errors on the dashboard, related to overriding the Transform::GetNumberOfParameteres: http://open.cdash.org/viewBuildError.php?buildid=3585002 Please let us know if you need some help addressing these in a timely fashion. Thanks, Brad _______________________________________________ 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 hans-johnson at uiowa.edu Mon Nov 24 09:09:03 2014 From: hans-johnson at uiowa.edu (Johnson, Hans J) Date: Mon, 24 Nov 2014 14:09:03 +0000 Subject: [ITK] [ITK-dev] Override keyword requirements: New transform compilation errors. In-Reply-To: <71E0EE41-524B-49C6-84A6-61E3AA8B10C4@mail.nih.gov> References: <71E0EE41-524B-49C6-84A6-61E3AA8B10C4@mail.nih.gov> Message-ID: Brad, I think it was fixed last night. I submitted a patch, and Matt reviewed and merged it. http://review.source.kitware.com/#/c/18135/ Hans -----Original Message----- From: Bradley Lowekamp Date: Monday, November 24, 2014 at 7:58 AM To: ITK Cc: Hans Johnson , Matthew McCormick Subject: Override keyword requirements: New transform compilation errors. Community Developers, Recently a number of builds that are running C++11 have been producing errors when the override moniker is not used on derived method. This is difficult for many contributors to ensure because this is new to C++11 and those who are not compiling for that version of C++ are oblivious to this potential error. Is it worth the effort to enforce this usage? Or should we try to see if it can only be a warning? If we want to enforce it's usage then we will _need_ a cdash at home build with this flag, so that we can check the gerrit builds. But I don't think that we have additional cdash at home resources to additional builds. Hans, There are some new compilation errors on the dashboard, related to overriding the Transform::GetNumberOfParameteres: http://open.cdash.org/viewBuildError.php?buildid=3585002 Please let us know if you need some help addressing these in a timely fashion. Thanks, Brad ________________________________ 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. ________________________________ _______________________________________________ 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 blowekamp at mail.nih.gov Mon Nov 24 09:26:51 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Mon, 24 Nov 2014 09:26:51 -0500 Subject: [ITK] [ITK-dev] Override keyword requirements: New transform compilation errors. In-Reply-To: References: <71E0EE41-524B-49C6-84A6-61E3AA8B10C4@mail.nih.gov> Message-ID: Hans, Great, thanks for being so prompt an sneaking that patch in. Brad On Nov 24, 2014, at 9:09 AM, Johnson, Hans J wrote: > Brad, > > I think it was fixed last night. I submitted a patch, and Matt reviewed > and merged it. > > http://review.source.kitware.com/#/c/18135/ > > > Hans > > > > > -----Original Message----- > From: Bradley Lowekamp > Date: Monday, November 24, 2014 at 7:58 AM > To: ITK > Cc: Hans Johnson , Matthew McCormick > > Subject: Override keyword requirements: New transform compilation errors. > > Community Developers, > > Recently a number of builds that are running C++11 have been producing > errors when the override moniker is not used on derived method. This is > difficult for many contributors to ensure because this is new to C++11 and > those who are not compiling for that version of C++ are oblivious to this > potential error. > > Is it worth the effort to enforce this usage? Or should we try to see if > it can only be a warning? > > If we want to enforce it's usage then we will _need_ a cdash at home build > with this flag, so that we can check the gerrit builds. But I don't think > that we have additional cdash at home resources to additional builds. > > > Hans, > > There are some new compilation errors on the dashboard, related to > overriding the Transform::GetNumberOfParameteres: > http://open.cdash.org/viewBuildError.php?buildid=3585002 > > Please let us know if you need some help addressing these in a timely > fashion. > > Thanks, > Brad > > > > ________________________________ > 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. > ________________________________ _______________________________________________ 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 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] [ITK-users] Problem reading a big nifti volume. In-Reply-To: References: 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 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-dev] [ITK-users] Problem reading a big nifti volume. In-Reply-To: References: 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 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: -------------- next part -------------- _______________________________________________ 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 matt.mccormick at kitware.com Mon Nov 24 13:20:19 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 24 Nov 2014 13:20:19 -0500 Subject: [ITK] [ITK-dev] Redesigning the way examples are added In-Reply-To: References: Message-ID: Hi Brad, Yes, I think that is a great idea. It would probably be a list of explicit names and globs for ease of implementation, but I'll see what can be done. Thanks, Matt On Mon, Nov 24, 2014 at 8:47 AM, Bradley Lowekamp wrote: > Matt, > > It looks like you started some awesome work to get more examples into the doxygen. This is really a great idea and I think it will benefit many people using ITK. I have an alternative approach to suggest that may be more maintainable and flexible in the long run. > > Perhaps the itk_module macro could be extended with an additional named argument. Something like "EXAMPLE_REGEX_LIST". This would enable module them selfs to control the examples listed, and may paves way to include examples in addition to test is external/internal modules. I don't think this should be too hard to do. What do you think? > > Brad > > > _______________________________________________ > 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 _______________________________________________ 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 matt.mccormick at kitware.com Mon Nov 24 13:38:32 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 24 Nov 2014 13:38:32 -0500 Subject: [ITK] [ITK-dev] Override keyword requirements: New transform compilation errors. In-Reply-To: References: <71E0EE41-524B-49C6-84A6-61E3AA8B10C4@mail.nih.gov> Message-ID: Brad, It is a good point that we should a C++11 build for the change sets. We are updating the testing infrastructure, and we will make sure we have at least one compiler building with C++11. Thanks, Matt On Mon, Nov 24, 2014 at 9:26 AM, Bradley Lowekamp wrote: > Hans, > > Great, thanks for being so prompt an sneaking that patch in. > > Brad > > On Nov 24, 2014, at 9:09 AM, Johnson, Hans J wrote: > >> Brad, >> >> I think it was fixed last night. I submitted a patch, and Matt reviewed >> and merged it. >> >> http://review.source.kitware.com/#/c/18135/ >> >> >> Hans >> >> >> >> >> -----Original Message----- >> From: Bradley Lowekamp >> Date: Monday, November 24, 2014 at 7:58 AM >> To: ITK >> Cc: Hans Johnson , Matthew McCormick >> >> Subject: Override keyword requirements: New transform compilation errors. >> >> Community Developers, >> >> Recently a number of builds that are running C++11 have been producing >> errors when the override moniker is not used on derived method. This is >> difficult for many contributors to ensure because this is new to C++11 and >> those who are not compiling for that version of C++ are oblivious to this >> potential error. >> >> Is it worth the effort to enforce this usage? Or should we try to see if >> it can only be a warning? >> >> If we want to enforce it's usage then we will _need_ a cdash at home build >> with this flag, so that we can check the gerrit builds. But I don't think >> that we have additional cdash at home resources to additional builds. >> >> >> Hans, >> >> There are some new compilation errors on the dashboard, related to >> overriding the Transform::GetNumberOfParameteres: >> http://open.cdash.org/viewBuildError.php?buildid=3585002 >> >> Please let us know if you need some help addressing these in a timely >> fashion. >> >> Thanks, >> Brad >> >> >> >> ________________________________ >> 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. >> ________________________________ > > _______________________________________________ > 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 _______________________________________________ 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 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] [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 > 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: -------------- next part -------------- _____________________________________ 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 Mon Nov 24 16:23:18 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 24 Nov 2014 16:23:18 -0500 Subject: [ITK] ITK 4.7 Release Candidates Approach Message-ID: Hi, The ITK 4.7 release candidates are scheduled to start week. Please have reviewed, green build patches merged by the end of the week. Thanks, Matt From matt.mccormick at kitware.com Mon Nov 24 16:26:10 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 24 Nov 2014 16:26:10 -0500 Subject: [ITK] ITK Software Guide Printing Message-ID: Hi, We are scheduled to have the ITK Software Guide sent to the printers next week so the physical books will be available for the 4.7 release. Please have any changes reviewed in Gerrit over the next week. Thanks, Matt From michkapopoff at gmail.com Mon Nov 24 16:32:31 2014 From: michkapopoff at gmail.com (michkapopoff at gmail.com) Date: Mon, 24 Nov 2014 22:32:31 +0100 Subject: [ITK] ITK Software Guide Printing In-Reply-To: References: Message-ID: <523190F9-B674-42F6-B8F8-5C0D09473993@gmail.com> Cool :) I see that we have still some errors on the software guide dashboard: warning: Line length too long for LaTeX printing Will Christopher Mullins have time to work on this before printing, or do you need some help to fix the remaining warnings ? Michka > On 24 Nov 2014, at 22:26, Matt McCormick wrote: > > Hi, > > We are scheduled to have the ITK Software Guide sent to the printers > next week so the physical books will be available for the 4.7 release. > Please have any changes reviewed in Gerrit over the next week. > > Thanks, > Matt > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [ITK-users] Encapsulate a ITK function into a DLL to be used with C# In-Reply-To: References: Message-ID: Thank you all for your answers, I'll give it a try! On Sun, Nov 23, 2014 at 4:09 AM, Dan Mueller 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" 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 >> 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 >> 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Get RescaleIntercept Message-ID: 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Get RescaleIntercept In-Reply-To: References: Message-ID: 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 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 > _____________________________________ 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] Otsu Filter for object/background separation In-Reply-To: References: Message-ID: 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 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 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 michkapopoff at gmail.com Tue Nov 25 04:58:05 2014 From: michkapopoff at gmail.com (michkapopoff at gmail.com) Date: Tue, 25 Nov 2014 10:58:05 +0100 Subject: [ITK] InterpolateImageFunction wrapping errors Message-ID: <46DA010C-5272-4E65-8E79-7CF392CA1225@gmail.com> Hi One of the cdash machines (Linux-x86_64-gcc4.8-WrapITK) is reporting errors like: itkInterpolateImageFunction.i:598: Warning 401: Nothing known about base class 'itk::ImageFunction< itk::Image< itk::RGBAPixel< unsigned short >,2u >,itk::RGBAPixel< double >,double >'. Ignored. These errors appeared as soon as I added wrapping for this function. The other cdash machines are green and I can not reproduce this locally. I would need some help to fix this before ITK 4.7 RC1, so that we have a (mostly) green dashboard. https://issues.itk.org/jira/browse/ITK-3333 Michka -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Tue Nov 25 08:06:44 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 25 Nov 2014 08:06:44 -0500 Subject: [ITK] ITK Software Guide Printing In-Reply-To: <523190F9-B674-42F6-B8F8-5C0D09473993@gmail.com> References: <523190F9-B674-42F6-B8F8-5C0D09473993@gmail.com> Message-ID: I think we could use some help with any warnings, especially for Book 1. Thank you! On Mon, Nov 24, 2014 at 4:32 PM, wrote: > Cool :) > > I see that we have still some errors on the software guide dashboard: > warning: Line length too long for LaTeX printing > > Will Christopher Mullins have time to work on this before printing, or do > you need some help > to fix the remaining warnings ? > > Michka > > On 24 Nov 2014, at 22:26, Matt McCormick wrote: > > Hi, > > We are scheduled to have the ITK Software Guide sent to the printers > next week so the physical books will be available for the 4.7 release. > Please have any changes reviewed in Gerrit over the next week. > > Thanks, > Matt > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > > From christopher.mullins at kitware.com Tue Nov 25 08:11:04 2014 From: christopher.mullins at kitware.com (Christopher Mullins) Date: Tue, 25 Nov 2014 08:11:04 -0500 Subject: [ITK] ITK Software Guide Printing In-Reply-To: References: <523190F9-B674-42F6-B8F8-5C0D09473993@gmail.com> Message-ID: Yes, I can also take a look. Thought we took care of all the line length warnings, but maybe I put a few back in. On Nov 25, 2014 8:06 AM, "Matt McCormick" wrote: > I think we could use some help with any warnings, especially for Book > 1. Thank you! > > On Mon, Nov 24, 2014 at 4:32 PM, wrote: > > Cool :) > > > > I see that we have still some errors on the software guide dashboard: > > warning: Line length too long for LaTeX printing > > > > Will Christopher Mullins have time to work on this before printing, or do > > you need some help > > to fix the remaining warnings ? > > > > Michka > > > > On 24 Nov 2014, at 22:26, Matt McCormick > wrote: > > > > Hi, > > > > We are scheduled to have the ITK Software Guide sent to the printers > > next week so the physical books will be available for the 4.7 release. > > Please have any changes reviewed in Gerrit over the next week. > > > > Thanks, > > Matt > > _______________________________________________ > > Community mailing list > > Community at itk.org > > http://public.kitware.com/mailman/listinfo/community > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Tue Nov 25 08:44:39 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 25 Nov 2014 08:44:39 -0500 Subject: [ITK] InterpolateImageFunction wrapping errors In-Reply-To: <46DA010C-5272-4E65-8E79-7CF392CA1225@gmail.com> References: <46DA010C-5272-4E65-8E79-7CF392CA1225@gmail.com> Message-ID: Hello Michka, I think that systems turns on just about every thing in it's configuration [1]. To reproduce it try adding: ITK_WRAP_rgba_unsigned_char:BOOL=ON ITK_WRAP_rgba_unsigned_short:BOOL=ON Brad [1] http://open.cdash.org/viewNotes.php?buildid=3586596 On Nov 25, 2014, at 4:58 AM, michkapopoff at gmail.com wrote: > Hi > > One of the cdash machines (Linux-x86_64-gcc4.8-WrapITK) is reporting errors like: > itkInterpolateImageFunction.i:598: Warning 401: Nothing known about base class 'itk::ImageFunction< itk::Image< itk::RGBAPixel< unsigned short >,2u >,itk::RGBAPixel< double >,double >'. Ignored. > > These errors appeared as soon as I added wrapping for this function. The other cdash machines are green and I can not reproduce this locally. I would need some help to fix this before ITK 4.7 RC1, so that we have a (mostly) green dashboard. > > https://issues.itk.org/jira/browse/ITK-3333 > > > Michka > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Tue Nov 25 09:17:22 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 25 Nov 2014 09:17:22 -0500 Subject: [ITK] [ITK-dev] FDFImageIO Pull request Message-ID: <821CBBE2-3D5D-4526-B8BD-A5AE3049C921@mail.nih.gov> Hello, To address compilation errors with FDFImageIO I have a pull request. https://github.com/InsightSoftwareConsortium/itkFDFImageIO/pull/1 Reviews are appreciated. This module does not appear to have been working for a while. Is there continued support and usage from the community for this module? Thanks, Brad _______________________________________________ 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 michkapopoff at gmail.com Tue Nov 25 09:22:38 2014 From: michkapopoff at gmail.com (michkapopoff at gmail.com) Date: Tue, 25 Nov 2014 15:22:38 +0100 Subject: [ITK] InterpolateImageFunction wrapping errors In-Reply-To: References: <46DA010C-5272-4E65-8E79-7CF392CA1225@gmail.com> Message-ID: Oops my bad, this was obvious. I just need to add the right lines for unsigned short RGB/RGBA, this should be an easy fix. Thanks Bradley Michka > On 25 Nov 2014, at 14:44, Bradley Lowekamp wrote: > > Hello Michka, > > I think that systems turns on just about every thing in it's configuration [1]. To reproduce it try adding: > > ITK_WRAP_rgba_unsigned_char:BOOL=ON > ITK_WRAP_rgba_unsigned_short:BOOL=ON > Brad > > > [1] http://open.cdash.org/viewNotes.php?buildid=3586596 > > On Nov 25, 2014, at 4:58 AM, michkapopoff at gmail.com wrote: > >> Hi >> >> One of the cdash machines (Linux-x86_64-gcc4.8-WrapITK) is reporting errors like: >> itkInterpolateImageFunction.i:598: Warning 401: Nothing known about base class 'itk::ImageFunction< itk::Image< itk::RGBAPixel< unsigned short >,2u >,itk::RGBAPixel< double >,double >'. Ignored. >> >> These errors appeared as soon as I added wrapping for this function. The other cdash machines are green and I can not reproduce this locally. I would need some help to fix this before ITK 4.7 RC1, so that we have a (mostly) green dashboard. >> >> https://issues.itk.org/jira/browse/ITK-3333 >> >> >> Michka >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans-johnson at uiowa.edu Tue Nov 25 09:55:49 2014 From: hans-johnson at uiowa.edu (Johnson, Hans J) Date: Tue, 25 Nov 2014 14:55:49 +0000 Subject: [ITK] [ITK-dev] ITK Software Guide Printing In-Reply-To: References: <523190F9-B674-42F6-B8F8-5C0D09473993@gmail.com> Message-ID: <3549BA92-5B59-4300-A0B4-7CD41E696A2D@uiowa.edu> I build the software guide last night. If we are targeting a 4.7 synchronization, then we need to update to a more recent codebase. A new gerri-patch pushed UpdateITKToNear4.7. Hans On Nov 25, 2014, at 7:06 AM, Matt McCormick > wrote: I think we could use some help with any warnings, especially for Book 1. Thank you! On Mon, Nov 24, 2014 at 4:32 PM, > wrote: Cool :) I see that we have still some errors on the software guide dashboard: warning: Line length too long for LaTeX printing Will Christopher Mullins have time to work on this before printing, or do you need some help to fix the remaining warnings ? Michka On 24 Nov 2014, at 22:26, Matt McCormick > wrote: Hi, We are scheduled to have the ITK Software Guide sent to the printers next week so the physical books will be available for the 4.7 release. Please have any changes reviewed in Gerrit over the next week. Thanks, Matt _______________________________________________ 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://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 ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 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] [ITK-dev] [ITK-users] Problem reading a big nifti volume. In-Reply-To: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> References: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> Message-ID: 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 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 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ 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 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] [ITK-users] Problem reading a big nifti volume. In-Reply-To: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> References: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> Message-ID: 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 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 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Compiling ITK with GPU ON In-Reply-To: <1416946491553778.030297.ptmail03@ptmail03> References: <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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Compiling ITK with GPU ON In-Reply-To: <033801d00902$5f3afbb0$1db0f310$@ac.kr> References: <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 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 > > 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Compiling ITK with GPU ON In-Reply-To: <1416957299141961.09157.ptmail03@ptmail03> References: <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 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 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: -------------- next part -------------- _____________________________________ 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 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] [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 ImageType; typedef itk::DiscreteGaussianImageFilter 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. _____________________________________ 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 fedorov at bwh.harvard.edu Tue Nov 25 18:21:57 2014 From: fedorov at bwh.harvard.edu (Andriy Fedorov) Date: Tue, 25 Nov 2014 18:21:57 -0500 Subject: [ITK] [ITK-dev] ITK Software Guide Printing Message-ID: Can someone share the link to the software guide repository? I would be very interested to take a look. On Tue, Nov 25, 2014 at 3:14 PM, wrote: > Send Community mailing list submissions to > community at itk.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://public.kitware.com/mailman/listinfo/community > or, via email, send a message with subject or body 'help' to > community-request at itk.org > > You can reach the person managing the list at > community-owner at itk.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Community digest..." > > > Today's Topics: > > 1. Re: [ITK-dev] ITK Software Guide Printing (Johnson, Hans J) > 2. Re: [ITK-dev] [ITK-users] Problem reading a big nifti volume. > (Fotis Drakopoulos) > 3. Re: [ITK-users] Problem reading a big nifti volume. > (Fotis Drakopoulos) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Nov 2014 14:55:49 +0000 > From: "Johnson, Hans J" > To: Matt McCormick > Cc: ITK , Christopher Mullins > > Subject: Re: [ITK] [ITK-dev] ITK Software Guide Printing > Message-ID: <3549BA92-5B59-4300-A0B4-7CD41E696A2D at uiowa.edu> > Content-Type: text/plain; charset="us-ascii" > > I build the software guide last night. If we are targeting a 4.7 > synchronization, then we need to update to a more recent codebase. > > A new gerri-patch pushed UpdateITKToNear4.7. > > Hans > > On Nov 25, 2014, at 7:06 AM, Matt McCormick > wrote: > > I think we could use some help with any warnings, especially for Book > 1. Thank you! > > On Mon, Nov 24, 2014 at 4:32 PM, michkapopoff at gmail.com>> wrote: > Cool :) > > I see that we have still some errors on the software guide dashboard: > warning: Line length too long for LaTeX printing > > Will Christopher Mullins have time to work on this before printing, or do > you need some help > to fix the remaining warnings ? > > Michka > > On 24 Nov 2014, at 22:26, Matt McCormick > wrote: > > Hi, > > We are scheduled to have the ITK Software Guide sent to the printers > next week so the physical books will be available for the 4.7 release. > Please have any changes reviewed in Gerrit over the next week. > > Thanks, > Matt > _______________________________________________ > 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://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 > > > > ________________________________ > 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. > ________________________________ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://public.kitware.com/pipermail/community/attachments/20141125/bfdacfd2/attachment-0001.html > > > -------------- next part -------------- > _______________________________________________ > 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 > > ------------------------------ > > Message: 2 > Date: Tue, 25 Nov 2014 15:14:38 -0500 > From: Fotis Drakopoulos > To: Bradley Lowekamp > Cc: "insight-users at itk.org" , > "insight-developers at itk.org" > Subject: Re: [ITK] [ITK-dev] [ITK-users] Problem reading a big nifti > volume. > Message-ID: > < > CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > > 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 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/community/attachments/20141125/6480b0fc/attachment.html > > > -------------- next part -------------- > _______________________________________________ > 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 > > ------------------------------ > > Message: 3 > Date: Tue, 25 Nov 2014 15:14:38 -0500 > From: Fotis Drakopoulos > To: Bradley Lowekamp > Cc: "insight-users at itk.org" , > "insight-developers at itk.org" > Subject: Re: [ITK] [ITK-users] Problem reading a big nifti volume. > Message-ID: > < > CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > > 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 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/community/attachments/20141125/6480b0fc/attachment-0001.html > > > -------------- next part -------------- > _____________________________________ > 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 > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > > > ------------------------------ > > End of Community Digest, Vol 14, Issue 72 > ***************************************** > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [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(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 (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. _____________________________________ 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 Tue Nov 25 20:28:31 2014 From: ntustison at gmail.com (Nicholas Tustison) Date: Tue, 25 Nov 2014 17:28:31 -0800 Subject: [ITK] [ITK-dev] FDFImageIO Pull request In-Reply-To: <821CBBE2-3D5D-4526-B8BD-A5AE3049C921@mail.nih.gov> References: <821CBBE2-3D5D-4526-B8BD-A5AE3049C921@mail.nih.gov> Message-ID: <025B8F34-0769-4625-AC4B-5F1B7C3B5806@gmail.com> Hi Brad, I use it for a single collaborator who acquires images in this FDF format. I apologize but I don?t understand the errors that you?re seeing. Kent and I updated the code from a contributor who had posted it back in the early 2000s. I didn?t think there was anything particularly complex about the code. Nick > On Nov 25, 2014, at 6:17 AM, Bradley Lowekamp wrote: > > Hello, > > To address compilation errors with FDFImageIO I have a pull request. > > https://github.com/InsightSoftwareConsortium/itkFDFImageIO/pull/1 > > Reviews are appreciated. > > This module does not appear to have been working for a while. Is there continued support and usage from the community for this module? > > Thanks, > Brad _______________________________________________ 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 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] [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,class itk::GPUImage,3>,class itk::DemonsRegistrationFilter,class itk::GPUImage,class itk::GPUImage,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,classitk::GPUImage,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 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] [ITK-users] [ITK-dev] Problem reading a big nifti volume. In-Reply-To: References: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> Message-ID: 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 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 > 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 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 > _____________________________________ 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 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] [ITK-dev] [ITK-users] Problem reading a big nifti volume. In-Reply-To: References: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> Message-ID: 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 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 > 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 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 > _______________________________________________ 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 matt.mccormick at kitware.com Tue Nov 25 22:49:38 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 25 Nov 2014 22:49:38 -0500 Subject: [ITK] [ITK-dev] ITK Software Guide Printing In-Reply-To: References: Message-ID: Hi Andriy, Here is the repository: http://itk.org/ITKSoftwareGuide.git More info can be found in the README: http://itk.org/gitweb?p=ITKSoftwareGuide.git;a=blob;f=README.md;h=eadf34576971b36c6f1c64c9f9590d7194fa4463;hb=HEAD Thanks for your interest, Matt On Tue, Nov 25, 2014 at 6:21 PM, Andriy Fedorov wrote: > > > Can someone share the link to the software guide repository? I would be very > interested to take a look. > > > > On Tue, Nov 25, 2014 at 3:14 PM, wrote: >> >> Send Community mailing list submissions to >> community at itk.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://public.kitware.com/mailman/listinfo/community >> or, via email, send a message with subject or body 'help' to >> community-request at itk.org >> >> You can reach the person managing the list at >> community-owner at itk.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Community digest..." >> >> >> Today's Topics: >> >> 1. Re: [ITK-dev] ITK Software Guide Printing (Johnson, Hans J) >> 2. Re: [ITK-dev] [ITK-users] Problem reading a big nifti volume. >> (Fotis Drakopoulos) >> 3. Re: [ITK-users] Problem reading a big nifti volume. >> (Fotis Drakopoulos) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 25 Nov 2014 14:55:49 +0000 >> From: "Johnson, Hans J" >> To: Matt McCormick >> Cc: ITK , Christopher Mullins >> >> Subject: Re: [ITK] [ITK-dev] ITK Software Guide Printing >> Message-ID: <3549BA92-5B59-4300-A0B4-7CD41E696A2D at uiowa.edu> >> Content-Type: text/plain; charset="us-ascii" >> >> I build the software guide last night. If we are targeting a 4.7 >> synchronization, then we need to update to a more recent codebase. >> >> A new gerri-patch pushed UpdateITKToNear4.7. >> >> Hans >> >> On Nov 25, 2014, at 7:06 AM, Matt McCormick >> > wrote: >> >> I think we could use some help with any warnings, especially for Book >> 1. Thank you! >> >> On Mon, Nov 24, 2014 at 4:32 PM, >> > wrote: >> Cool :) >> >> I see that we have still some errors on the software guide dashboard: >> warning: Line length too long for LaTeX printing >> >> Will Christopher Mullins have time to work on this before printing, or do >> you need some help >> to fix the remaining warnings ? >> >> Michka >> >> On 24 Nov 2014, at 22:26, Matt McCormick >> > wrote: >> >> Hi, >> >> We are scheduled to have the ITK Software Guide sent to the printers >> next week so the physical books will be available for the 4.7 release. >> Please have any changes reviewed in Gerrit over the next week. >> >> Thanks, >> Matt >> _______________________________________________ >> 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://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 >> >> >> >> ________________________________ >> 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. >> ________________________________ >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> -------------- next part -------------- >> _______________________________________________ >> 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 >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 25 Nov 2014 15:14:38 -0500 >> From: Fotis Drakopoulos >> To: Bradley Lowekamp >> Cc: "insight-users at itk.org" , >> "insight-developers at itk.org" >> Subject: Re: [ITK] [ITK-dev] [ITK-users] Problem reading a big nifti >> volume. >> Message-ID: >> >> >> Content-Type: text/plain; charset="utf-8" >> >> 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 >> >> 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 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 >> > >> > >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> -------------- next part -------------- >> _______________________________________________ >> 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 >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 25 Nov 2014 15:14:38 -0500 >> From: Fotis Drakopoulos >> To: Bradley Lowekamp >> Cc: "insight-users at itk.org" , >> "insight-developers at itk.org" >> Subject: Re: [ITK] [ITK-users] Problem reading a big nifti volume. >> Message-ID: >> >> >> Content-Type: text/plain; charset="utf-8" >> >> 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 >> >> 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 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 >> > >> > >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> -------------- next part -------------- >> _____________________________________ >> 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 >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community >> >> >> ------------------------------ >> >> End of Community Digest, Vol 14, Issue 72 >> ***************************************** >> >> >> The information in this e-mail is intended only for the person to whom it >> is >> addressed. If you believe this e-mail was sent to you in error and the >> e-mail >> contains patient information, please contact the Partners Compliance >> HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you in >> error >> but does not contain patient information, please contact the sender and >> properly >> dispose of the e-mail. >> > > > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > 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] [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: 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 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,class itk::GPUImage itk::Vector,3>,class itk::DemonsRegistrationFilter itk::GPUImage,class itk::GPUImage,class > itk::GPUImage,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,classitk::GPUImage,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 _____________________________________ 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] [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 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 itk::GPUImage,class itk::GPUImage,class > itk::GPUImage,3>,class > itk::DemonsRegistrationFilter itk::GPUImage,class itk::GPUImage,class > itk::GPUImage,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,classitk::GPUImage itk::Vector,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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: itkGPUDemonsRegistrationFilterTest.cxx URL: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] [ITK-dev] Problem reading a big nifti volume. In-Reply-To: References: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> Message-ID: Hi, I signed up for the ITK community on midas. Thanks, Fotis Drakopoulos On Tue, Nov 25, 2014 at 10:44 PM, Matt McCormick 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 > 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 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-dev] [ITK-users] Problem reading a big nifti volume. In-Reply-To: References: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> Message-ID: Hi, I signed up for the ITK community on midas. Thanks, Fotis Drakopoulos On Tue, Nov 25, 2014 at 10:44 PM, Matt McCormick 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 > 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 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: -------------- next part -------------- _______________________________________________ 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 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] [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. _____________________________________ 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 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] [ITK-users] Get RescaleIntercept In-Reply-To: References: Message-ID: Thanks Matt, that worked! On Mon, Nov 24, 2014 at 10:47 PM, Matt McCormick 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 > 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: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] [ITK-dev] Problem reading a big nifti volume. In-Reply-To: References: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> Message-ID: Thanks! Added. On Wed, Nov 26, 2014 at 9:21 AM, Fotis Drakopoulos 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 > 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 >> 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 >> > >> > 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 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 >> > _____________________________________ 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 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] [ITK-dev] [ITK-users] Problem reading a big nifti volume. In-Reply-To: References: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov> Message-ID: Thanks! Added. On Wed, Nov 26, 2014 at 9:21 AM, Fotis Drakopoulos 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 > 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 >> 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 >> > >> > 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 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 >> > _______________________________________________ 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 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] [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: 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 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 _____________________________________ 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] Otsu Filter for object/background separation In-Reply-To: References: Message-ID: 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 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 > 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 > 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: 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] [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 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 itk::GPUImage,class itk::GPUImage,class > itk::GPUImage,3>,class > itk::DemonsRegistrationFilter itk::GPUImage,class itk::GPUImage,class > itk::GPUImage,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,classitk::GPUImage itk::Vector,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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: itkGPUDemonsRegistrationFilterTest.cxx URL: -------------- next part -------------- _____________________________________ 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 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] [ITK-users] Future of WrapITK Message-ID: 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 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] [ITK-users] Future of WrapITK In-Reply-To: References: 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 (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 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: From c.metz at quantib.com Thu Nov 27 13:58:14 2014 From: c.metz at quantib.com (Coert Metz) Date: Thu, 27 Nov 2014 19:58:14 +0100 Subject: [ITK] SimpleITK get reference to voxel data pointer in Python Message-ID: Hi all, I would like to get access to the voxel data pointer of a SimpleITK image from Python. I see there is a method GetBufferAsInt16 which would suffice but it does not seem to wrapped in Python. Is there a way to still access this voxel data pointer? Regards, -- Coert Metz, PhD Research & Development Engineer | Quantib B.V. c.metz at quantib.com | +31 650 68 60 28 -- This message may contain confidential or privileged information. If you are not the addressee, please notify the sender and delete it from your files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xerneas999 at gmail.com Thu Nov 27 14:38:25 2014 From: xerneas999 at gmail.com (Charlotte Xerneas) Date: Thu, 27 Nov 2014 11:38:25 -0800 Subject: [ITK] Problem linking file 'ITKAlgorithms.lib' when using the 2D active shape model ITK Message-ID: Hi, I'm pretty new to this forum, as well as to ITK. I hope you can helping me out to make an existing ITK VC project work. I downloaded the source code from http://www.insight-journal.org/browse/publication/812. I used cmake and then tried to compile it in Visual Studio 2010. But I got the error LINK : fatal error LNK1104: cannot open file 'ITKAlgorithms.lib'. These are the options I used in CMake configure: CMAKE_BACKWARDS_COMPATIBILITY 2.4 CMAKE_CONFIGURATION_TYPES: Debug;Release;MinSizeRel;RelWithDebInfo CMAKE_INSTALL_PREFIX C:/Program Files (x86)/2dasm EXECUTABLE_OUTPUT_PATH: E:/ITK/Create2DActiveShapeModel/dev10/excecutable ITK_DIR: E:/ITK/ITK4.6-dev10 LIBRARY_OUTPUT_PATH: E:/ITK/Create2DActiveShapeModel/dev10/liboutput After I generated using CMake, both the executable_output_path and library_output_path are empty. For you convenience, this is the cmake file I used: PROJECT( 2dasm ) CMAKE_MINIMUM_REQUIRED(VERSION 2.4) if(COMMAND cmake_policy) cmake_policy(SET CMP0003 NEW) endif(COMMAND cmake_policy) FIND_PACKAGE ( ITK ) IF ( ITK_FOUND ) INCLUDE( ${USE_ITK_FILE} ) ENDIF( ITK_FOUND ) INCLUDE_DIRECTORIES(${imfilter_SOURCE_DIR}) ADD_EXECUTABLE( 2dasm 2dasm.cxx ) TARGET_LINK_LIBRARIES ( 2dasm ITKAlgorithms ITKBasicFilters ITKCommon ITKIO ITKNumerics ITKSpatialObject ${VTK_LIBRARIES}) Please help me identify what have I done wrong. Many thanks, Charlotte -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Thu Nov 27 22:15:05 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 27 Nov 2014 22:15:05 -0500 Subject: [ITK] SimpleITK get reference to voxel data pointer in Python In-Reply-To: References: Message-ID: Hi Coert, There is a GetArrayFromImage function that can get a NumPy array from a SimpleITK image. Then possibly use the numpy ctypes support [1]. It depends on what you want to do... HTH, Matt [1] http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.ctypes.html On Thu, Nov 27, 2014 at 1:58 PM, Coert Metz wrote: > Hi all, > > I would like to get access to the voxel data pointer of a SimpleITK image > from Python. I see there is a method GetBufferAsInt16 which would suffice > but it does not seem to wrapped in Python. Is there a way to still access > this voxel data pointer? > > Regards, > -- > Coert Metz, PhD > Research & Development Engineer | Quantib B.V. > c.metz at quantib.com | +31 650 68 60 28 > > This message may contain confidential or privileged information. If you are > not the addressee, please notify the sender and delete it from your files. > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > From matt.mccormick at kitware.com Thu Nov 27 22:17:12 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 27 Nov 2014 22:17:12 -0500 Subject: [ITK] Problem linking file 'ITKAlgorithms.lib' when using the 2D active shape model ITK In-Reply-To: References: Message-ID: Hi Charlotte, Welcome to ITK! The explicit list of ITK libraries (which have changed names in ITKv4 versus ITKv3) can be fixed by using ${ITK_LIBRARIES}. So, On Thu, Nov 27, 2014 at 2:38 PM, Charlotte Xerneas wrote: > Hi, > > I'm pretty new to this forum, as well as to ITK. I hope you can helping me > out to make an existing ITK VC project work. I downloaded the source code > from > http://www.insight-journal.org/browse/publication/812. > > I used cmake and then tried to compile it in Visual Studio 2010. But I got > the error > > LINK : fatal error LNK1104: cannot open file 'ITKAlgorithms.lib'. > > > These are the options I used in CMake configure: > > CMAKE_BACKWARDS_COMPATIBILITY 2.4 > > CMAKE_CONFIGURATION_TYPES: Debug;Release;MinSizeRel;RelWithDebInfo > CMAKE_INSTALL_PREFIX C:/Program Files (x86)/2dasm > EXECUTABLE_OUTPUT_PATH: E:/ITK/Create2DActiveShapeModel/dev10/excecutable > ITK_DIR:?E:/ITK/ITK4.6-dev10 > LIBRARY_OUTPUT_PATH: E:/ITK/Create2DActiveShapeModel/dev10/liboutput > > After I generated using CMake, both the executable_output_path and > library_output_path are empty. > > For you convenience, this is the cmake file I used: > PROJECT( 2dasm ) > > CMAKE_MINIMUM_REQUIRED(VERSION 2.4) > if(COMMAND cmake_policy) > cmake_policy(SET CMP0003 NEW) > endif(COMMAND cmake_policy) > > FIND_PACKAGE ( ITK ) > IF ( ITK_FOUND ) > INCLUDE( ${USE_ITK_FILE} ) > ENDIF( ITK_FOUND ) > > > INCLUDE_DIRECTORIES(${imfilter_SOURCE_DIR}) > > ADD_EXECUTABLE( 2dasm 2dasm.cxx ) > > TARGET_LINK_LIBRARIES ( > 2dasm > ITKAlgorithms > ITKBasicFilters > ITKCommon > ITKIO > ITKNumerics > ITKSpatialObject > ${VTK_LIBRARIES}) > > > Please help me identify what have I done wrong. > > Many thanks, > Charlotte > > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > From matt.mccormick at kitware.com Thu Nov 27 22:17:55 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 27 Nov 2014 22:17:55 -0500 Subject: [ITK] Problem linking file 'ITKAlgorithms.lib' when using the 2D active shape model ITK In-Reply-To: References: Message-ID: Hi Charlotte, Welcome to ITK! The explicit list of ITK libraries (which have changed names in ITKv4 versus ITKv3) can be fixed by using ${ITK_LIBRARIES}. So, TARGET_LINK_LIBRARIES ( 2dasm ${ITK_LIBRARIES} ${VTK_LIBRARIES}) Hope this helps, Matt On Thu, Nov 27, 2014 at 10:17 PM, Matt McCormick wrote: > Hi Charlotte, > > Welcome to ITK! > > The explicit list of ITK libraries (which have changed names in ITKv4 > versus ITKv3) can be fixed by using ${ITK_LIBRARIES}. So, > > > > On Thu, Nov 27, 2014 at 2:38 PM, Charlotte Xerneas wrote: >> Hi, >> >> I'm pretty new to this forum, as well as to ITK. I hope you can helping me >> out to make an existing ITK VC project work. I downloaded the source code >> from >> http://www.insight-journal.org/browse/publication/812. >> >> I used cmake and then tried to compile it in Visual Studio 2010. But I got >> the error >> >> LINK : fatal error LNK1104: cannot open file 'ITKAlgorithms.lib'. >> >> >> These are the options I used in CMake configure: >> >> CMAKE_BACKWARDS_COMPATIBILITY 2.4 >> >> CMAKE_CONFIGURATION_TYPES: Debug;Release;MinSizeRel;RelWithDebInfo >> CMAKE_INSTALL_PREFIX C:/Program Files (x86)/2dasm >> EXECUTABLE_OUTPUT_PATH: E:/ITK/Create2DActiveShapeModel/dev10/excecutable >> ITK_DIR:?E:/ITK/ITK4.6-dev10 >> LIBRARY_OUTPUT_PATH: E:/ITK/Create2DActiveShapeModel/dev10/liboutput >> >> After I generated using CMake, both the executable_output_path and >> library_output_path are empty. >> >> For you convenience, this is the cmake file I used: >> PROJECT( 2dasm ) >> >> CMAKE_MINIMUM_REQUIRED(VERSION 2.4) >> if(COMMAND cmake_policy) >> cmake_policy(SET CMP0003 NEW) >> endif(COMMAND cmake_policy) >> >> FIND_PACKAGE ( ITK ) >> IF ( ITK_FOUND ) >> INCLUDE( ${USE_ITK_FILE} ) >> ENDIF( ITK_FOUND ) >> >> >> INCLUDE_DIRECTORIES(${imfilter_SOURCE_DIR}) >> >> ADD_EXECUTABLE( 2dasm 2dasm.cxx ) >> >> TARGET_LINK_LIBRARIES ( >> 2dasm >> ITKAlgorithms >> ITKBasicFilters >> ITKCommon >> ITKIO >> ITKNumerics >> ITKSpatialObject >> ${VTK_LIBRARIES}) >> >> >> Please help me identify what have I done wrong. >> >> Many thanks, >> Charlotte >> >> _______________________________________________ >> Community mailing list >> Community at itk.org >> http://public.kitware.com/mailman/listinfo/community >> From xerneas999 at gmail.com Thu Nov 27 22:28:25 2014 From: xerneas999 at gmail.com (Charlotte Xerneas) Date: Thu, 27 Nov 2014 19:28:25 -0800 Subject: [ITK] Problem linking file 'ITKAlgorithms.lib' when using the 2D active shape model ITK In-Reply-To: References: Message-ID: Thanks that worked! On Thu, Nov 27, 2014 at 7:17 PM, Matt McCormick wrote: > Hi Charlotte, > > Welcome to ITK! > > The explicit list of ITK libraries (which have changed names in ITKv4 > versus ITKv3) can be fixed by using ${ITK_LIBRARIES}. So, > > TARGET_LINK_LIBRARIES ( > 2dasm > ${ITK_LIBRARIES} > ${VTK_LIBRARIES}) > > Hope this helps, > Matt > > On Thu, Nov 27, 2014 at 10:17 PM, Matt McCormick > wrote: > > Hi Charlotte, > > > > Welcome to ITK! > > > > The explicit list of ITK libraries (which have changed names in ITKv4 > > versus ITKv3) can be fixed by using ${ITK_LIBRARIES}. So, > > > > > > > > On Thu, Nov 27, 2014 at 2:38 PM, Charlotte Xerneas > wrote: > >> Hi, > >> > >> I'm pretty new to this forum, as well as to ITK. I hope you can helping > me > >> out to make an existing ITK VC project work. I downloaded the source > code > >> from > >> http://www.insight-journal.org/browse/publication/812. > >> > >> I used cmake and then tried to compile it in Visual Studio 2010. But I > got > >> the error > >> > >> LINK : fatal error LNK1104: cannot open file 'ITKAlgorithms.lib'. > >> > >> > >> These are the options I used in CMake configure: > >> > >> CMAKE_BACKWARDS_COMPATIBILITY 2.4 > >> > >> CMAKE_CONFIGURATION_TYPES: Debug;Release;MinSizeRel;RelWithDebInfo > >> CMAKE_INSTALL_PREFIX C:/Program Files (x86)/2dasm > >> EXECUTABLE_OUTPUT_PATH: > E:/ITK/Create2DActiveShapeModel/dev10/excecutable > >> ITK_DIR: E:/ITK/ITK4.6-dev10 > >> LIBRARY_OUTPUT_PATH: E:/ITK/Create2DActiveShapeModel/dev10/liboutput > >> > >> After I generated using CMake, both the executable_output_path and > >> library_output_path are empty. > >> > >> For you convenience, this is the cmake file I used: > >> PROJECT( 2dasm ) > >> > >> CMAKE_MINIMUM_REQUIRED(VERSION 2.4) > >> if(COMMAND cmake_policy) > >> cmake_policy(SET CMP0003 NEW) > >> endif(COMMAND cmake_policy) > >> > >> FIND_PACKAGE ( ITK ) > >> IF ( ITK_FOUND ) > >> INCLUDE( ${USE_ITK_FILE} ) > >> ENDIF( ITK_FOUND ) > >> > >> > >> INCLUDE_DIRECTORIES(${imfilter_SOURCE_DIR}) > >> > >> ADD_EXECUTABLE( 2dasm 2dasm.cxx ) > >> > >> TARGET_LINK_LIBRARIES ( > >> 2dasm > >> ITKAlgorithms > >> ITKBasicFilters > >> ITKCommon > >> ITKIO > >> ITKNumerics > >> ITKSpatialObject > >> ${VTK_LIBRARIES}) > >> > >> > >> Please help me identify what have I done wrong. > >> > >> Many thanks, > >> Charlotte > >> > >> _______________________________________________ > >> Community mailing list > >> Community at itk.org > >> http://public.kitware.com/mailman/listinfo/community > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.metz at quantib.com Fri Nov 28 03:35:57 2014 From: c.metz at quantib.com (Coert Metz) Date: Fri, 28 Nov 2014 09:35:57 +0100 Subject: [ITK] SimpleITK get reference to voxel data pointer in Python In-Reply-To: References: Message-ID: Hi Matt, Thanks, this is exactly what I need. I want to pass the pointer to a DLL with C-API. Coert On Fri, Nov 28, 2014 at 4:15 AM, Matt McCormick wrote: > Hi Coert, > > There is a GetArrayFromImage function that can get a NumPy array from > a SimpleITK image. Then possibly use the numpy ctypes support [1]. It > depends on what you want to do... > > HTH, > Matt > > [1] > http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.ctypes.html > > On Thu, Nov 27, 2014 at 1:58 PM, Coert Metz wrote: > > Hi all, > > > > I would like to get access to the voxel data pointer of a SimpleITK image > > from Python. I see there is a method GetBufferAsInt16 which would suffice > > but it does not seem to wrapped in Python. Is there a way to still access > > this voxel data pointer? > > > > Regards, > > -- > > Coert Metz, PhD > > Research & Development Engineer | Quantib B.V. > > c.metz at quantib.com | +31 650 68 60 28 > > > > This message may contain confidential or privileged information. If you > are > > not the addressee, please notify the sender and delete it from your > files. > > _______________________________________________ > > Community mailing list > > Community at itk.org > > http://public.kitware.com/mailman/listinfo/community > > > -- Coert Metz, PhD Research & Development Engineer | Quantib B.V. c.metz at quantib.com | +31 650 68 60 28 -- This message may contain confidential or privileged information. If you are not the addressee, please notify the sender and delete it from your files. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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] [ITK-users] Future of WrapITK In-Reply-To: <189A597A-010D-4BEC-8A76-29A5046E32DD@gmail.com> References: , <189A597A-010D-4BEC-8A76-29A5046E32DD@gmail.com> Message-ID: 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 > 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: From zeinsalah at gmail.com Wed Nov 12 06:08:06 2014 From: zeinsalah at gmail.com (Zein Salah) Date: Wed, 12 Nov 2014 11:08:06 -0000 Subject: [ITK] Otsu Filter for object/background separation Message-ID: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: obj-bg.jpg Type: image/jpeg Size: 239545 bytes Desc: not available URL: