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-dev] image and deformation field physical space check
Message-ID: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>

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! <https://github.com/stnava/ANTs/issues/31>

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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141103/2428d7bc/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
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 <stnava at gmail.com> wrote:
> 
> This email is motivated by this issue:
> 
> https://github.com/stnava/ANTs/issues/74 <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! <https://github.com/stnava/ANTs/issues/31>
> 
> 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/Filtering/DisplacementField/include/itkDisplacementFieldTransform.hxx#L454-L457>
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Core/Common/include/itkImageToImageFilter.hxx#L40-L41 <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 <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 <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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141103/a3839dff/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <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 <ntustison at gmail.com> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141103/fac3ba6d/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com>
 <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov>
Message-ID: <CABWzF4VN0Yjp2CmQw7YCD3ZzFnurX+LNguK6zMhZ0C186QJ0aA@mail.gmail.com>

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 <blowekamp at mail.nih.gov>
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 <ntustison at gmail.com>
> 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 <stnava at gmail.com> 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! <https://github.com/stnava/ANTs/issues/31>
>
> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141103/5eb86582/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <CABWzF4VN0Yjp2CmQw7YCD3ZzFnurX+LNguK6zMhZ0C186QJ0aA@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com>
 <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov>
 <CABWzF4VN0Yjp2CmQw7YCD3ZzFnurX+LNguK6zMhZ0C186QJ0aA@mail.gmail.com>
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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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 <ntustison at gmail.com> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141103/8e940e91/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <3FD91A2E-D5FF-4330-A198-913440E36561@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <9ED9F811-C2D9-4E12-A102-C57BA770948F@gmail.com>
 <29EB464B-89F7-4830-BC49-5F22BB52C516@mail.nih.gov>
 <CABWzF4VN0Yjp2CmQw7YCD3ZzFnurX+LNguK6zMhZ0C186QJ0aA@mail.gmail.com>
 <3FD91A2E-D5FF-4330-A198-913440E36561@mail.nih.gov>
Message-ID: <CAO+ouverz2pW98aFZ4WpPuAsjJN_KEPpT2YjGfXwcyPh8pZU3Q@mail.gmail.com>

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 <blowekamp at mail.nih.gov>
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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov>
> 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 <ntustison at gmail.com>
>> 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 <stnava at gmail.com> 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! <https://github.com/stnava/ANTs/issues/31>
>>
>> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141103/3aab6a55/attachment-0001.html>

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-dev] image and deformation field physical space check
In-Reply-To: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
Message-ID: <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>

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 <stnava at gmail.com> 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
>

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-dev] image and deformation field physical space check
In-Reply-To: <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
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 <stnava at gmail.com> 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

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-dev] image and deformation field physical space check
In-Reply-To: <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
Message-ID: <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>

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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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 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-dev] image and deformation field physical space check
In-Reply-To: <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
Message-ID: <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>

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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141104/a02a4e78/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
Message-ID: <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>

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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141104/328db9e9/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
Message-ID: <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>

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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl>
>> 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 <stnava at gmail.com>
>> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141104/494f5265/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
Message-ID: <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>


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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141104/d9437229/attachment-0001.html>

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-dev] image and deformation field physical space check
In-Reply-To: <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
Message-ID: <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>

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 <blowekamp at mail.nih.gov>
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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl>
>>> 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 <stnava at gmail.com>
>>> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141104/e31e88b8/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
 <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>
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::Euler3DTransform<float>, itk::Image<float, 3>, itk::Image<float, 3> >::InitializeTransform() [TTransform = itk::Euler3DTransform<float>, TFixedImage = itk::Image<float, 3>, TMovingImage = itk::Image<float, 3>]" 
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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/94025235/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
 <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>
 <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov>
Message-ID: <CABWzF4UQ81mohxA1dWfCUaS4gr35LppSMoU3yB5Bu6CotAHqPA@mail.gmail.com>

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 <blowekamp at mail.nih.gov>
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::Euler3DTransform<float>,
> itk::Image<float, 3>, itk::Image<float, 3> >::InitializeTransform()
> [TTransform = itk::Euler3DTransform<float>, TFixedImage = itk::Image<float,
> 3>, TMovingImage = itk::Image<float, 3>]"
> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov>
> 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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl>
>>>> 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 <stnava at gmail.com>
>>>> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/a1b45094/attachment.html>

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-dev] image and deformation field physical space check
In-Reply-To: <CABWzF4UQ81mohxA1dWfCUaS4gr35LppSMoU3yB5Bu6CotAHqPA@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
 <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>
 <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov>
 <CABWzF4UQ81mohxA1dWfCUaS4gr35LppSMoU3yB5Bu6CotAHqPA@mail.gmail.com>
Message-ID: <A81228F1-D507-4403-8296-7875BC974048@mail.nih.gov>

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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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::Euler3DTransform<float>, itk::Image<float, 3>, itk::Image<float, 3> >::InitializeTransform() [TTransform = itk::Euler3DTransform<float>, TFixedImage = itk::Image<float, 3>, TMovingImage = itk::Image<float, 3>]" 
> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/8e0e0a8a/attachment-0001.html>

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-dev] [ITK] image and deformation field physical space check
In-Reply-To: <A81228F1-D507-4403-8296-7875BC974048@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
 <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>
 <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov>
 <CABWzF4UQ81mohxA1dWfCUaS4gr35LppSMoU3yB5Bu6CotAHqPA@mail.gmail.com>
 <A81228F1-D507-4403-8296-7875BC974048@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 <blowekamp at mail.nih.gov> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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::Euler3DTransform<float>, itk::Image<float, 3>, itk::Image<float, 3> >::InitializeTransform() [TTransform = itk::Euler3DTransform<float>, TFixedImage = itk::Image<float, 3>, TMovingImage = itk::Image<float, 3>]" 
>> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/22135737/attachment.html>

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-dev] [ITK] image and deformation field physical space check
In-Reply-To: <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
 <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>
 <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov>
 <CABWzF4UQ81mohxA1dWfCUaS4gr35LppSMoU3yB5Bu6CotAHqPA@mail.gmail.com>
 <A81228F1-D507-4403-8296-7875BC974048@mail.nih.gov>
 <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov>
Message-ID: <CABWzF4W9zV1zGbqu2YXj5=Nww6P9h6c_s-0MLh8PBLXiyJLgdw@mail.gmail.com>

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 <blowekamp at mail.nih.gov>
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 <blowekamp at mail.nih.gov>
> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov>
> 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::Euler3DTransform<float>,
>> itk::Image<float, 3>, itk::Image<float, 3> >::InitializeTransform()
>> [TTransform = itk::Euler3DTransform<float>, TFixedImage = itk::Image<float,
>> 3>, TMovingImage = itk::Image<float, 3>]"
>> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov>
>> 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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl>
>>>>> 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 <stnava at gmail.com>
>>>>> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/13ad0acc/attachment.html>

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-dev] [ITK] image and deformation field physical space check
In-Reply-To: <CABWzF4W9zV1zGbqu2YXj5=Nww6P9h6c_s-0MLh8PBLXiyJLgdw@mail.gmail.com>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
 <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>
 <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov>
 <CABWzF4UQ81mohxA1dWfCUaS4gr35LppSMoU3yB5Bu6CotAHqPA@mail.gmail.com>
 <A81228F1-D507-4403-8296-7875BC974048@mail.nih.gov>
 <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov>
 <CABWzF4W9zV1zGbqu2YXj5=Nww6P9h6c_s-0MLh8PBLXiyJLgdw@mail.gmail.com>
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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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 <blowekamp at mail.nih.gov> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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::Euler3DTransform<float>, itk::Image<float, 3>, itk::Image<float, 3> >::InitializeTransform() [TTransform = itk::Euler3DTransform<float>, TFixedImage = itk::Image<float, 3>, TMovingImage = itk::Image<float, 3>]" 
>>> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov> 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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/2e47f7de/attachment-0001.html>

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-dev] [ITK] image and deformation field physical space check
In-Reply-To: <552F6BE4-DA37-4C73-89BC-947169CFEE6F@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
 <CABWzF4Vr86ojUz72dJ13q+s1RzVzzBSQxU8TpmN67qw95Qp6UA@mail.gmail.com>
 <7EF014DE-EDD5-4D1A-8753-13406BF8BBDD@mail.nih.gov>
 <CABWzF4UQ81mohxA1dWfCUaS4gr35LppSMoU3yB5Bu6CotAHqPA@mail.gmail.com>
 <A81228F1-D507-4403-8296-7875BC974048@mail.nih.gov>
 <72195E96-E431-4094-941F-0D21FFB71B20@mail.nih.gov>
 <CABWzF4W9zV1zGbqu2YXj5=Nww6P9h6c_s-0MLh8PBLXiyJLgdw@mail.gmail.com>
 <552F6BE4-DA37-4C73-89BC-947169CFEE6F@mail.nih.gov>
Message-ID: <CABWzF4UJCDQbP4WY8NBDmADY2OV_rqzk-rQHJ=sdojvH6Urrvg@mail.gmail.com>

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 <blowekamp at mail.nih.gov>
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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov>
> 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 <blowekamp at mail.nih.gov>
>> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov>
>> 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::Euler3DTransform<float>,
>>> itk::Image<float, 3>, itk::Image<float, 3> >::InitializeTransform()
>>> [TTransform = itk::Euler3DTransform<float>, TFixedImage = itk::Image<float,
>>> 3>, TMovingImage = itk::Image<float, 3>]"
>>> 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 <stnava at gmail.com> 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 <blowekamp at mail.nih.gov
>>> > 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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl>
>>>>>> 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 <stnava at gmail.com>
>>>>>> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/1a68ae4d/attachment.html>

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-dev] [ITK] image and deformation field physical space check
In-Reply-To: <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
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 <blowekamp at mail.nih.gov> 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 <stnava at gmail.com> 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 <stnava at gmail.com> 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, <M.Staring at lumc.nl> <M.Staring at lumc.nl> 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 <stnava at gmail.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/d064b78e/attachment.html>

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-dev] [ITK] image and deformation field physical space check
In-Reply-To: <2D4A2A84-9637-41E8-8FDE-10D6FA959786@mail.nih.gov>
References: <CABWzF4VOq38c_uca42dsc9d9vuBc3m5CmKDWPvA7-uPS-ASiJA@mail.gmail.com>
 <CALzTN-RBW=Q5TaONL03mDQebH8v-yknLSU6wBv-wkNtPsHWUGw@mail.gmail.com>
 <24D8AA23EC0DCB4498C35EC60401E76137F6AC09@MAIL-MB3.lumcnet.prod.intern>
 <E371E36D-06CF-4B40-ABF6-2CA20234BC53@mail.nih.gov>
 <CABWzF4UGJTkcNQFE7H0jP475zjyBG6aWg_6XzETktfCocLQcHg@mail.gmail.com>
 <A094D3FF-6184-4FF6-9481-0B2F0A15368B@mail.nih.gov>
 <CABWzF4V2KLw_t3eYf8niBnR=Gc5Ap6to=GENvwjUY0bf=7yTEA@mail.gmail.com>
 <AAC4E04A-18E4-4996-93CF-77D47168DA88@mail.nih.gov>
 <2D4A2A84-9637-41E8-8FDE-10D6FA959786@mail.nih.gov>
Message-ID: <AA08F2A4-7420-4103-AB0B-F054DBB3C593@gmail.com>

That?s brilliant, Brad.  Thanks.


> On Nov 5, 2014, at 11:28 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> 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 <blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>> 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 <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 <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 <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 <stnava at gmail.com <mailto:stnava at gmail.com>> 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 <mailto: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 <stnava at gmail.com <mailto:stnava at gmail.com>> 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 <mailto: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, <M.Staring at lumc.nl <mailto:M.Staring at lumc.nl>> <M.Staring at lumc.nl <mailto:M.Staring at lumc.nl>> 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 <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 <mailto: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 <stnava at gmail.com <mailto:stnava at gmail.com>> wrote:
>>>> >>> This email is motivated by this issue:
>>>> >>>
>>>> >>> https://github.com/stnava/ANTs/issues/74 <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 <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 <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 <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 <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 <http://www.kitware.com/>
>>>> >>>
>>>> >>> Visit other Kitware open-source projects at
>>>> >>> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>>>> >>>
>>>> >>> Kitware offers ITK Training Courses, for more information visit:
>>>> >>> http://kitware.com/products/protraining.php <http://kitware.com/products/protraining.php>
>>>> >>>
>>>> >>> Please keep messages on-topic and check the ITK FAQ at:
>>>> >>> http://www.itk.org/Wiki/ITK_FAQ <http://www.itk.org/Wiki/ITK_FAQ>
>>>> >>>
>>>> >>> Follow this link to subscribe/unsubscribe:
>>>> >>> http://public.kitware.com/mailman/listinfo/insight-developers <http://public.kitware.com/mailman/listinfo/insight-developers>
>>>> >>>
>>>> >> _______________________________________________
>>>> >> Powered by www.kitware.com <http://www.kitware.com/>
>>>> >>
>>>> >> Visit other Kitware open-source projects at
>>>> >> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>>>> >>
>>>> >> Kitware offers ITK Training Courses, for more information visit:
>>>> >> http://kitware.com/products/protraining.php <http://kitware.com/products/protraining.php>
>>>> >>
>>>> >> Please keep messages on-topic and check the ITK FAQ at:
>>>> >> http://www.itk.org/Wiki/ITK_FAQ <http://www.itk.org/Wiki/ITK_FAQ>
>>>> >>
>>>> >> Follow this link to subscribe/unsubscribe:
>>>> >> http://public.kitware.com/mailman/listinfo/insight-developers <http://public.kitware.com/mailman/listinfo/insight-developers>
>>>> > _______________________________________________
>>>> > Powered by www.kitware.com <http://www.kitware.com/>
>>>> >
>>>> > Visit other Kitware open-source projects at
>>>> > http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>>>> >
>>>> > Kitware offers ITK Training Courses, for more information visit:
>>>> > http://kitware.com/products/protraining.php <http://kitware.com/products/protraining.php>
>>>> >
>>>> > Please keep messages on-topic and check the ITK FAQ at:
>>>> > http://www.itk.org/Wiki/ITK_FAQ <http://www.itk.org/Wiki/ITK_FAQ>
>>>> >
>>>> > Follow this link to subscribe/unsubscribe:
>>>> > http://public.kitware.com/mailman/listinfo/insight-developers <http://public.kitware.com/mailman/listinfo/insight-developers>
>>>> 
>>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> Powered by www.kitware.com <http://www.kitware.com/>
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>> 
>> Please keep messages on-topic and check 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141105/ae0cc085/attachment-0001.html>

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

Greetings,

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

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

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

Thanks,
Brad

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

Brad,

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

BTW I do not mean tiled pyramid tiff images.

Bill

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



-- 
Unpaid intern in BillsBasement at noware dot com

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

Bill,

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

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

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

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

Brad

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


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

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


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

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

I'll keep you posted.

Bill

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



-- 
Unpaid intern in BillsBasement at noware dot com

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

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

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



-- 
Unpaid intern in BillsBasement at noware dot com

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

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


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



-- 
Unpaid intern in BillsBasement at noware dot com

From 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-dev] TIFFImageIO refactoring, please test
In-Reply-To: <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
References: <CAAB4D33-062C-469A-8AB2-2E57C80523BD@mail.nih.gov>
 <CADZJ4hP4vu7f4AwpAxESH1i5Pe6Hn3hguiCf56ONJJH98nOtsQ@mail.gmail.com>
 <A23A2085-9D92-4F62-92A6-7782921C8D82@mail.nih.gov>
 <CADZJ4hNNVyrs4f+tvA8UjOzgH4vxHh3pNnOYMpvpLL=XsCCiuA@mail.gmail.com>
 <CADZJ4hPmpm-DjpdA85r7mDuAbNF3=2nTVq2CCeV4gu5GkJXaJA@mail.gmail.com>
 <CADZJ4hMLvuYhoj5pOLHYYGYyyVxLN_uZKV8geEz3c4jNBGkYGA@mail.gmail.com>
Message-ID: <C64961EA-03EE-4E61-90C4-0C2F3E33B33E@mail.nih.gov>

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

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

Brad


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

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


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

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


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



-- 
Unpaid intern in BillsBasement at noware dot com

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

Bill,

Your images have an odd compression:

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

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

How is VTK handling this odd compression?

Brad 

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

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

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

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

I added that compression option to the possibilities


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



-- 
Unpaid intern in BillsBasement at noware dot com

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

Bill,

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

int TIFFIsCODECConfigured(uint16 scheme);

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

Updating ITK...

Brad


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

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

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

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

Bill,

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


Brad


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

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

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


From 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-dev] Valgrind defects since October 27
Message-ID: <CADZJ4hPG2YxtfQGnLG8sWTY=_=+-2RA9Td6dPVBOZb1HK25mVA@mail.gmail.com>

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

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-dev] Valgrind defects since October 27
In-Reply-To: <CADZJ4hPG2YxtfQGnLG8sWTY=_=+-2RA9Td6dPVBOZb1HK25mVA@mail.gmail.com>
References: <CADZJ4hPG2YxtfQGnLG8sWTY=_=+-2RA9Td6dPVBOZb1HK25mVA@mail.gmail.com>
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 <bill.lorensen at gmail.com> 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


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-dev] Problems with WikiExamples Remote Module after recent
	checkin
Message-ID: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>

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

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-dev] Aloha ITK Developers!
Message-ID: <D0925E71.CB1E%norman-k-williams@uiowa.edu>

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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141119/b99f076d/attachment.html>

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-dev] Aloha ITK Developers!
In-Reply-To: <D0925E71.CB1E%norman-k-williams@uiowa.edu>
References: <D0925E71.CB1E%norman-k-williams@uiowa.edu>
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 <norman-k-williams at uiowa.edu> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141119/31182f0a/attachment-0001.html>

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-dev] Aloha ITK Developers!
In-Reply-To: <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com>
References: <D0925E71.CB1E%norman-k-williams@uiowa.edu>
 <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com>
Message-ID: <CADZJ4hMe7bE-0wt_YBRXfQwWLaPNKtZaoKzPK_qHCt8fHYsNFA@mail.gmail.com>

+1


On Wed, Nov 19, 2014 at 4:40 PM, Nicholas Tustison <ntustison at gmail.com> 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
> <norman-k-williams at uiowa.edu> 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

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-dev] Problems with WikiExamples Remote Module after recent
	checkin
In-Reply-To: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
References: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
Message-ID: <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>

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 <bill.lorensen at gmail.com> 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

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-dev] Aloha ITK Developers!
In-Reply-To: <CADZJ4hMe7bE-0wt_YBRXfQwWLaPNKtZaoKzPK_qHCt8fHYsNFA@mail.gmail.com>
References: <D0925E71.CB1E%norman-k-williams@uiowa.edu>
 <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com>
 <CADZJ4hMe7bE-0wt_YBRXfQwWLaPNKtZaoKzPK_qHCt8fHYsNFA@mail.gmail.com>
Message-ID: <CALzTN-SKQyC55shhqt22yf1U=st8XXLT_xZ7j=+W6A2xHoQN=w@mail.gmail.com>

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 <bill.lorensen at gmail.com> wrote:
> +1
>
>
> On Wed, Nov 19, 2014 at 4:40 PM, Nicholas Tustison <ntustison at gmail.com> 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
>> <norman-k-williams at uiowa.edu> 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 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-dev] Aloha ITK Developers!
In-Reply-To: <CADZJ4hMe7bE-0wt_YBRXfQwWLaPNKtZaoKzPK_qHCt8fHYsNFA@mail.gmail.com>
References: <D0925E71.CB1E%norman-k-williams@uiowa.edu>
 <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com>
 <CADZJ4hMe7bE-0wt_YBRXfQwWLaPNKtZaoKzPK_qHCt8fHYsNFA@mail.gmail.com>
Message-ID: <CAK3qF+9W-NPBp1LhFtKNcRQSLks+q-7uKCRCtPYuY0EU=0=cPA@mail.gmail.com>

+1
Bonne chance pour la suite ;)

On Wed, Nov 19, 2014 at 10:42 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> +1
>
>
> On Wed, Nov 19, 2014 at 4:40 PM, Nicholas Tustison <ntustison at gmail.com>
> 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
> > <norman-k-williams at uiowa.edu> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141120/eb221e0a/attachment.html>

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-dev] Problems with WikiExamples Remote Module after recent
	checkin
In-Reply-To: <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>
References: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
 <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>
Message-ID: <CADZJ4hPdzNLZnEFyXfvMBepj-qQOZsazMCcJ-ofKUO83N9iDNA@mail.gmail.com>

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
<matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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

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-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

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-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: <BEF1507A-AFBE-4566-8CB9-94CBD8F5A684@gmail.com>

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 <blowekamp at mail.nih.gov> 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


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-dev] Problems with WikiExamples Remote Module after recent
	checkin
In-Reply-To: <CADZJ4hPdzNLZnEFyXfvMBepj-qQOZsazMCcJ-ofKUO83N9iDNA@mail.gmail.com>
References: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
 <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>
 <CADZJ4hPdzNLZnEFyXfvMBepj-qQOZsazMCcJ-ofKUO83N9iDNA@mail.gmail.com>
Message-ID: <CADZJ4hMZrCbEsNUB09qWqTx53LfyKU_PQ86HAK1jaepssMzu_Q@mail.gmail.com>

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 <bill.lorensen at gmail.com> 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
> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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

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-dev] Aloha ITK Developers!
In-Reply-To: <CAK3qF+9W-NPBp1LhFtKNcRQSLks+q-7uKCRCtPYuY0EU=0=cPA@mail.gmail.com>
References: <D0925E71.CB1E%norman-k-williams@uiowa.edu>
 <8BE02438-9659-4E1F-8EDB-42A01E4587FF@gmail.com>
 <CADZJ4hMe7bE-0wt_YBRXfQwWLaPNKtZaoKzPK_qHCt8fHYsNFA@mail.gmail.com>
 <CAK3qF+9W-NPBp1LhFtKNcRQSLks+q-7uKCRCtPYuY0EU=0=cPA@mail.gmail.com>
Message-ID: <FF4F38E8-4A6B-4243-A720-53E7580D2E3B@mail.nih.gov>


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 <arnaudgelas at gmail.com> wrote:

> +1
> Bonne chance pour la suite ;)
> 
> On Wed, Nov 19, 2014 at 10:42 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> +1
> 
> 
> On Wed, Nov 19, 2014 at 4:40 PM, Nicholas Tustison <ntustison at gmail.com> 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
> > <norman-k-williams at uiowa.edu> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141120/2b65c724/attachment.html>

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-dev] Problems with WikiExamples Remote Module after recent
	checkin
In-Reply-To: <CADZJ4hMZrCbEsNUB09qWqTx53LfyKU_PQ86HAK1jaepssMzu_Q@mail.gmail.com>
References: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
 <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>
 <CADZJ4hPdzNLZnEFyXfvMBepj-qQOZsazMCcJ-ofKUO83N9iDNA@mail.gmail.com>
 <CADZJ4hMZrCbEsNUB09qWqTx53LfyKU_PQ86HAK1jaepssMzu_Q@mail.gmail.com>
Message-ID: <CALzTN-Sc4u7Xn_PtDgEY3K6D1QaUdzxUN9c_Qjrw35eyRB2OZg@mail.gmail.com>

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 <bill.lorensen at gmail.com> 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 <bill.lorensen at gmail.com> 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
>> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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

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-dev] Problems with WikiExamples Remote Module after recent
	checkin
In-Reply-To: <CALzTN-Sc4u7Xn_PtDgEY3K6D1QaUdzxUN9c_Qjrw35eyRB2OZg@mail.gmail.com>
References: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
 <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>
 <CADZJ4hPdzNLZnEFyXfvMBepj-qQOZsazMCcJ-ofKUO83N9iDNA@mail.gmail.com>
 <CADZJ4hMZrCbEsNUB09qWqTx53LfyKU_PQ86HAK1jaepssMzu_Q@mail.gmail.com>
 <CALzTN-Sc4u7Xn_PtDgEY3K6D1QaUdzxUN9c_Qjrw35eyRB2OZg@mail.gmail.com>
Message-ID: <CADZJ4hPWw0Q77Htz9uWQ3V_po0d0oWRZ1eGrBF2miO6NcpkxJA@mail.gmail.com>

Well, the wiki examples that do i/o no longer run.


On Fri, Nov 21, 2014 at 12:34 AM, Matt McCormick
<matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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 <bill.lorensen at gmail.com> 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
>>> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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

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-dev] Problems with WikiExamples Remote Module after recent
	checkin
In-Reply-To: <CADZJ4hPWw0Q77Htz9uWQ3V_po0d0oWRZ1eGrBF2miO6NcpkxJA@mail.gmail.com>
References: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
 <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>
 <CADZJ4hPdzNLZnEFyXfvMBepj-qQOZsazMCcJ-ofKUO83N9iDNA@mail.gmail.com>
 <CADZJ4hMZrCbEsNUB09qWqTx53LfyKU_PQ86HAK1jaepssMzu_Q@mail.gmail.com>
 <CALzTN-Sc4u7Xn_PtDgEY3K6D1QaUdzxUN9c_Qjrw35eyRB2OZg@mail.gmail.com>
 <CADZJ4hPWw0Q77Htz9uWQ3V_po0d0oWRZ1eGrBF2miO6NcpkxJA@mail.gmail.com>
Message-ID: <CADZJ4hNAt8Z-NJ4mJ49x6OSo64KJWP9kQLgyMsjFYcnGh5YbNQ@mail.gmail.com>

I think I found a workaround on my end.


On Fri, Nov 21, 2014 at 7:55 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Well, the wiki examples that do i/o no longer run.
>
>
> On Fri, Nov 21, 2014 at 12:34 AM, Matt McCormick
> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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 <bill.lorensen at gmail.com> 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
>>>> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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

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-dev] Problems with WikiExamples Remote Module after recent
	checkin
In-Reply-To: <CADZJ4hNAt8Z-NJ4mJ49x6OSo64KJWP9kQLgyMsjFYcnGh5YbNQ@mail.gmail.com>
References: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
 <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>
 <CADZJ4hPdzNLZnEFyXfvMBepj-qQOZsazMCcJ-ofKUO83N9iDNA@mail.gmail.com>
 <CADZJ4hMZrCbEsNUB09qWqTx53LfyKU_PQ86HAK1jaepssMzu_Q@mail.gmail.com>
 <CALzTN-Sc4u7Xn_PtDgEY3K6D1QaUdzxUN9c_Qjrw35eyRB2OZg@mail.gmail.com>
 <CADZJ4hPWw0Q77Htz9uWQ3V_po0d0oWRZ1eGrBF2miO6NcpkxJA@mail.gmail.com>
 <CADZJ4hNAt8Z-NJ4mJ49x6OSo64KJWP9kQLgyMsjFYcnGh5YbNQ@mail.gmail.com>
Message-ID: <CALzTN-QySt-UO0==ndPhVrgwkMK-eb0520RFCxJZ8Zq=vnUAfg@mail.gmail.com>

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 <bill.lorensen at gmail.com> wrote:
> I think I found a workaround on my end.
>
>
> On Fri, Nov 21, 2014 at 7:55 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Well, the wiki examples that do i/o no longer run.
>>
>>
>> On Fri, Nov 21, 2014 at 12:34 AM, Matt McCormick
>> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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 <bill.lorensen at gmail.com> 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
>>>>> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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

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-dev] Problems with WikiExamples Remote Module after recent
	checkin
In-Reply-To: <CALzTN-QySt-UO0==ndPhVrgwkMK-eb0520RFCxJZ8Zq=vnUAfg@mail.gmail.com>
References: <CADZJ4hNS4vu70g1Ub0uKAzFxhmWnwhOWn1g_4mfCF+GPMjcrgw@mail.gmail.com>
 <CALzTN-RtSif+FkT9df_rFf2P68XCfCRmZ2tAQSQH-0PchApkiQ@mail.gmail.com>
 <CADZJ4hPdzNLZnEFyXfvMBepj-qQOZsazMCcJ-ofKUO83N9iDNA@mail.gmail.com>
 <CADZJ4hMZrCbEsNUB09qWqTx53LfyKU_PQ86HAK1jaepssMzu_Q@mail.gmail.com>
 <CALzTN-Sc4u7Xn_PtDgEY3K6D1QaUdzxUN9c_Qjrw35eyRB2OZg@mail.gmail.com>
 <CADZJ4hPWw0Q77Htz9uWQ3V_po0d0oWRZ1eGrBF2miO6NcpkxJA@mail.gmail.com>
 <CADZJ4hNAt8Z-NJ4mJ49x6OSo64KJWP9kQLgyMsjFYcnGh5YbNQ@mail.gmail.com>
 <CALzTN-QySt-UO0==ndPhVrgwkMK-eb0520RFCxJZ8Zq=vnUAfg@mail.gmail.com>
Message-ID: <CADZJ4hN8pyn_qbdUgFtEHwwP58LxtQpCtCUOgOzv9CyTbve_7A@mail.gmail.com>

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
<matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> wrote:
>> I think I found a workaround on my end.
>>
>>
>> On Fri, Nov 21, 2014 at 7:55 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>> Well, the wiki examples that do i/o no longer run.
>>>
>>>
>>> On Fri, Nov 21, 2014 at 12:34 AM, Matt McCormick
>>> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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 <bill.lorensen at gmail.com> 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
>>>>>> <matt.mccormick at kitware.com> 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 <bill.lorensen at gmail.com> 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

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-dev] Problem reading a big nifti volume.
Message-ID: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>

Hi all,

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

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

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

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

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

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

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

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

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

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

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

Hi  Jerome,

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

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

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

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-dev] Redesigning the way examples are added
Message-ID: <CD435A29-5259-4273-97A3-0EB6E2F64158@mail.nih.gov>

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

 

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-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

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-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: <D098979E.219AB%hans.j.johnson@gmail.com>

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 <blowekamp at mail.nih.gov>
Date: Monday, November 24, 2014 at 7:58 AM
To: ITK <insight-developers at itk.org>
Cc: Hans Johnson <hans.j.johnson at gmail.com>, Matthew McCormick
<matt at mmmccormick.com>
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.
________________________________

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-dev] Override keyword requirements: New transform
	compilation errors.
In-Reply-To: <D098979E.219AB%hans.j.johnson@gmail.com>
References: <71E0EE41-524B-49C6-84A6-61E3AA8B10C4@mail.nih.gov>
 <D098979E.219AB%hans.j.johnson@gmail.com>
Message-ID: <E6F06570-F522-4251-AB51-D5C27E222325@mail.nih.gov>

Hans,

Great, thanks for being so prompt an sneaking that patch in.

Brad

On Nov 24, 2014, at 9:09 AM, Johnson, Hans J <hans-johnson at uiowa.edu> 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 <blowekamp at mail.nih.gov>
> Date: Monday, November 24, 2014 at 7:58 AM
> To: ITK <insight-developers at itk.org>
> Cc: Hans Johnson <hans.j.johnson at gmail.com>, Matthew McCormick
> <matt at mmmccormick.com>
> 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.
> ________________________________


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-dev] [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
Message-ID: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>

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

Got data?

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

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

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

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-dev] Redesigning the way examples are added
In-Reply-To: <CD435A29-5259-4273-97A3-0EB6E2F64158@mail.nih.gov>
References: <CD435A29-5259-4273-97A3-0EB6E2F64158@mail.nih.gov>
Message-ID: <CALzTN-RGc3mKNDonrjs-+YuvoiF6ELURN+dRzOr+z5ie-VSE2w@mail.gmail.com>

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
<blowekamp at mail.nih.gov> 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

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-dev] Override keyword requirements: New transform
 compilation errors.
In-Reply-To: <E6F06570-F522-4251-AB51-D5C27E222325@mail.nih.gov>
References: <71E0EE41-524B-49C6-84A6-61E3AA8B10C4@mail.nih.gov>
 <D098979E.219AB%hans.j.johnson@gmail.com>
 <E6F06570-F522-4251-AB51-D5C27E222325@mail.nih.gov>
Message-ID: <CALzTN-RtfBUf4U0=1sNc9m2BxWEXOQScXS=K3bpqNBEWMtOX3Q@mail.gmail.com>

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
<blowekamp at mail.nih.gov> 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 <hans-johnson at uiowa.edu> 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 <blowekamp at mail.nih.gov>
>> Date: Monday, November 24, 2014 at 7:58 AM
>> To: ITK <insight-developers at itk.org>
>> Cc: Hans Johnson <hans.j.johnson at gmail.com>, Matthew McCormick
>> <matt at mmmccormick.com>
>> 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 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-dev] ITK 4.7 Release Candidates Approach
Message-ID: <CALzTN-TrMsxTZZ+DEB+ev+uzy7hutpqv8Q5QKwOLE9VwcKok8w@mail.gmail.com>

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-dev] ITK Software Guide Printing
Message-ID: <CALzTN-SNsjPyq0FAEyNtJc6goTXncVDi9ph_zQ5ZxeDW12fu1Q@mail.gmail.com>

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-dev] [ITK] ITK Software Guide Printing
In-Reply-To: <CALzTN-SNsjPyq0FAEyNtJc6goTXncVDi9ph_zQ5ZxeDW12fu1Q@mail.gmail.com>
References: <CALzTN-SNsjPyq0FAEyNtJc6goTXncVDi9ph_zQ5ZxeDW12fu1Q@mail.gmail.com>
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 <matt.mccormick at kitware.com> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20141124/4705613d/attachment.html>

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-dev] [ITK] ITK Software Guide Printing
In-Reply-To: <523190F9-B674-42F6-B8F8-5C0D09473993@gmail.com>
References: <CALzTN-SNsjPyq0FAEyNtJc6goTXncVDi9ph_zQ5ZxeDW12fu1Q@mail.gmail.com>
 <523190F9-B674-42F6-B8F8-5C0D09473993@gmail.com>
Message-ID: <CALzTN-Tr3ZdgSEkEzOJ3qtzi9tcVmEDwHXaV69q5cKHH0fBKng@mail.gmail.com>

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 <matt.mccormick at kitware.com> 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 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-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

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-dev] [ITK] ITK Software Guide Printing
In-Reply-To: <CALzTN-Tr3ZdgSEkEzOJ3qtzi9tcVmEDwHXaV69q5cKHH0fBKng@mail.gmail.com>
References: <CALzTN-SNsjPyq0FAEyNtJc6goTXncVDi9ph_zQ5ZxeDW12fu1Q@mail.gmail.com>
 <523190F9-B674-42F6-B8F8-5C0D09473993@gmail.com>
 <CALzTN-Tr3ZdgSEkEzOJ3qtzi9tcVmEDwHXaV69q5cKHH0fBKng@mail.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 <matt.mccormick at kitware.com<mailto:matt.mccormick at kitware.com>> 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<mailto: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 <matt.mccormick at kitware.com<mailto:matt.mccormick at kitware.com>> 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<mailto:Community at itk.org>
http://public.kitware.com/mailman/listinfo/community


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

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

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

Please keep messages on-topic and check 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/insight-developers/attachments/20141125/bfdacfd2/attachment.html>

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-dev] [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
Message-ID: <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>

Hi all,

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

Best,
Fotis Drakopoulos


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

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

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-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 <blowekamp at mail.nih.gov> 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


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-dev] [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
 <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>
Message-ID: <CALzTN-RPtGjgVY=NPgQOE0tVj5hvP9EQRWFkwdJzBvo64_vyKA@mail.gmail.com>

Hi Fotis,

Thanks for helping to improve large nifti file support.

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

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

Thanks,
Matt

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

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

From 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-dev] [ITK-users] Problem reading a big nifti volume.
In-Reply-To: <CALzTN-RPtGjgVY=NPgQOE0tVj5hvP9EQRWFkwdJzBvo64_vyKA@mail.gmail.com>
References: <CAG6AjROMWzAEWptqC3XmamwqDmwPc88d2YDup84tkDg20ZJdxw@mail.gmail.com>
 <BD80F91C3E2E394894ED4780703D7F9E826D4E43@uxcn10-tdc06.UoA.auckland.ac.nz>
 <790CBE9F-0722-4C59-9B6B-2FB619068CB9@mail.nih.gov>
 <CAG6AjRNaVdcxH1ScfVx-k3dXx8i2obffjvtLRvvLqPG1xnCSaA@mail.gmail.com>
 <CALzTN-RPtGjgVY=NPgQOE0tVj5hvP9EQRWFkwdJzBvo64_vyKA@mail.gmail.com>
Message-ID: <CAG6AjRP9KTRsNgOgDifr33MKvQN7SuuR-XR1r3pWcnwSW_6rcw@mail.gmail.com>

Hi,
I signed up for the ITK community on midas.

Thanks,
Fotis Drakopoulos

On Tue, Nov 25, 2014 at 10:44 PM, Matt McCormick <matt.mccormick at kitware.com
> wrote:

> Hi Fotis,
>
> Thanks for helping to improve large nifti file support.
>
> The file can be uploaded on midas3.kitware.com.  Sign up for the ITK
> community [1], let the list know the name of your account, and myself
> or one of the other administrators will add upload priviledges to the
> account.
>
> The file could then be added to ITK/Public/ITK/Modules/IO/NIFTI/test/Input.
>
> Thanks,
> Matt
>
> [1] http://midas3.kitware.com/midas/community/12
>
> On Tue, Nov 25, 2014 at 3:14 PM, Fotis Drakopoulos <fdrakopo at gmail.com>
> wrote:
> > Hi all,
> >
> > I created a test nifti image that reproduces the problem I mentioned
> before.
> > How can I share this image with the ITK community?
> >
> > Best,
> > Fotis Drakopoulos
> >
> >
> > On Mon, Nov 24, 2014 at 10:13 AM, Bradley Lowekamp <
> blowekamp at mail.nih.gov>
> > wrote:
> >>
> >> Shareable test data greatly helps determine the cause and fix these
> types
> >> of issues.
> >>
> >> Got data?
> >>
> >> Brad
> >> On Nov 23, 2014, at 5:40 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
> >>
> >> This is reminiscent of the previous problem with big TIFF images, now
> >> fixed.
> >>
> >> Gib
> >> ________________________________
> >> From: Insight-users [insight-users-bounces at itk.org] on behalf of Fotis
> >> Drakopoulos [fdrakopo at gmail.com]
> >> Sent: Monday, 24 November 2014 10:51 a.m.
> >> To: insight-users at itk.org; insight-developers at itk.org
> >> Subject: [ITK-users] Problem reading a big nifti volume.
> >>
> >> Hi all,
> >>
> >> For the last couple of days I have been trying reading
> (unsuccessfully)  a
> >> big nifti volume labeled image from my disk.
> >>
> >> The pixel type is unsigned char and the rest specs of the image are:
> >> Size : [1001, 1001, 8345]  (in voxels)
> >> Spacing : [0.012, 0.012, 0.012]  (in mm)
> >> Origin : [0, 0, 0]
> >> Direction :
> >> 1 0 0
> >> 0 1 0
> >> 0 0 1
> >>
> >> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea
> >> how it looks like. Indeed the object in the volume looks as it was
> expected.
> >> So far no problems. The specs of the image on Slicer are the same as
> above
> >> (except the direction which has flipped signs for the first two diagonal
> >> entries, as we know ).
> >>
> >> Then I tried to load the image in the memory using the
> >> itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After
> loading
> >> the image I noticed that there are pixels with zero values instead of
> >> non-zero by comparing the same indexes with the loaded image on Slicer.
> >>
> >> Then I decided to write the loaded image on the disk using the
> >> itk::ImageFileWriter.
> >>
> >> After opening the (written from ITK) image on Slicer I checked the
> specks
> >> and were the same with the original image as above. However I noticed
> that a
> >> big portion of the image is completely empty (black)!
> >>
> >> My workstation has enough memory to load the image (768 GB 1600MHz
> DDR3L)
> >> and is using Red Hat Enterprise Linux Server 6.5.
> >> The size of the original nifti volume is :
> >>
> >> 25.7 MB (.nii.gz)
> >> 8.36 GB (.nii)
> >>
> >> Has anybody experienced similar difficulties trying to load so big
> volume
> >> data?
> >>
> >> Best,
> >> Fotis Drakopoulos
> >> CRTC
> >>
> >> _____________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Kitware offers ITK Training Courses, for more information visit:
> >> http://www.kitware.com/products/protraining.php
> >>
> >> Please keep messages on-topic and check the ITK FAQ at:
> >> http://www.itk.org/Wiki/ITK_FAQ
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://public.kitware.com/mailman/listinfo/insight-users
> >>
> >>
> >> ________________________________
> >>
> >> Spam
> >> Not spam
> >> Forget previous vote
> >
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Kitware offers ITK Training Courses, for more information visit:
> > http://kitware.com/products/protraining.php
> >
> > Please keep messages on-topic and check the ITK FAQ at:
> > http://www.itk.org/Wiki/ITK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/insight-developers
> >
>
>
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
>
> Teach CanIt if this mail (ID 03Nk3J6v4) is spam:
> Spam:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=s
> Not spam:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=n
> Forget vote:
> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=f
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20141126/e4896ead/attachment.html>

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

Thanks! Added.

On Wed, Nov 26, 2014 at 9:21 AM, Fotis Drakopoulos <fdrakopo at gmail.com> wrote:
> Hi,
> I signed up for the ITK community on midas.
>
> Thanks,
> Fotis Drakopoulos
>
> On Tue, Nov 25, 2014 at 10:44 PM, Matt McCormick
> <matt.mccormick at kitware.com> wrote:
>>
>> Hi Fotis,
>>
>> Thanks for helping to improve large nifti file support.
>>
>> The file can be uploaded on midas3.kitware.com.  Sign up for the ITK
>> community [1], let the list know the name of your account, and myself
>> or one of the other administrators will add upload priviledges to the
>> account.
>>
>> The file could then be added to
>> ITK/Public/ITK/Modules/IO/NIFTI/test/Input.
>>
>> Thanks,
>> Matt
>>
>> [1] http://midas3.kitware.com/midas/community/12
>>
>> On Tue, Nov 25, 2014 at 3:14 PM, Fotis Drakopoulos <fdrakopo at gmail.com>
>> wrote:
>> > Hi all,
>> >
>> > I created a test nifti image that reproduces the problem I mentioned
>> > before.
>> > How can I share this image with the ITK community?
>> >
>> > Best,
>> > Fotis Drakopoulos
>> >
>> >
>> > On Mon, Nov 24, 2014 at 10:13 AM, Bradley Lowekamp
>> > <blowekamp at mail.nih.gov>
>> > wrote:
>> >>
>> >> Shareable test data greatly helps determine the cause and fix these
>> >> types
>> >> of issues.
>> >>
>> >> Got data?
>> >>
>> >> Brad
>> >> On Nov 23, 2014, at 5:40 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
>> >>
>> >> This is reminiscent of the previous problem with big TIFF images, now
>> >> fixed.
>> >>
>> >> Gib
>> >> ________________________________
>> >> From: Insight-users [insight-users-bounces at itk.org] on behalf of Fotis
>> >> Drakopoulos [fdrakopo at gmail.com]
>> >> Sent: Monday, 24 November 2014 10:51 a.m.
>> >> To: insight-users at itk.org; insight-developers at itk.org
>> >> Subject: [ITK-users] Problem reading a big nifti volume.
>> >>
>> >> Hi all,
>> >>
>> >> For the last couple of days I have been trying reading (unsuccessfully)
>> >> a
>> >> big nifti volume labeled image from my disk.
>> >>
>> >> The pixel type is unsigned char and the rest specs of the image are:
>> >> Size : [1001, 1001, 8345]  (in voxels)
>> >> Spacing : [0.012, 0.012, 0.012]  (in mm)
>> >> Origin : [0, 0, 0]
>> >> Direction :
>> >> 1 0 0
>> >> 0 1 0
>> >> 0 0 1
>> >>
>> >> First I loaded the volume on Slicer-4.4.0 (64 bit-linux) to get an idea
>> >> how it looks like. Indeed the object in the volume looks as it was
>> >> expected.
>> >> So far no problems. The specs of the image on Slicer are the same as
>> >> above
>> >> (except the direction which has flipped signs for the first two
>> >> diagonal
>> >> entries, as we know ).
>> >>
>> >> Then I tried to load the image in the memory using the
>> >> itk::ImageFileReader  from ITK4.6.0 (64 bit-linux) version. After
>> >> loading
>> >> the image I noticed that there are pixels with zero values instead of
>> >> non-zero by comparing the same indexes with the loaded image on Slicer.
>> >>
>> >> Then I decided to write the loaded image on the disk using the
>> >> itk::ImageFileWriter.
>> >>
>> >> After opening the (written from ITK) image on Slicer I checked the
>> >> specks
>> >> and were the same with the original image as above. However I noticed
>> >> that a
>> >> big portion of the image is completely empty (black)!
>> >>
>> >> My workstation has enough memory to load the image (768 GB 1600MHz
>> >> DDR3L)
>> >> and is using Red Hat Enterprise Linux Server 6.5.
>> >> The size of the original nifti volume is :
>> >>
>> >> 25.7 MB (.nii.gz)
>> >> 8.36 GB (.nii)
>> >>
>> >> Has anybody experienced similar difficulties trying to load so big
>> >> volume
>> >> data?
>> >>
>> >> Best,
>> >> Fotis Drakopoulos
>> >> CRTC
>> >>
>> >> _____________________________________
>> >> Powered by www.kitware.com
>> >>
>> >> Visit other Kitware open-source projects at
>> >> http://www.kitware.com/opensource/opensource.html
>> >>
>> >> Kitware offers ITK Training Courses, for more information visit:
>> >> http://www.kitware.com/products/protraining.php
>> >>
>> >> Please keep messages on-topic and check the ITK FAQ at:
>> >> http://www.itk.org/Wiki/ITK_FAQ
>> >>
>> >> Follow this link to subscribe/unsubscribe:
>> >> http://public.kitware.com/mailman/listinfo/insight-users
>> >>
>> >>
>> >> ________________________________
>> >>
>> >> Spam
>> >> Not spam
>> >> Forget previous vote
>> >
>> >
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Kitware offers ITK Training Courses, for more information visit:
>> > http://kitware.com/products/protraining.php
>> >
>> > Please keep messages on-topic and check the ITK FAQ at:
>> > http://www.itk.org/Wiki/ITK_FAQ
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/insight-developers
>> >
>>
>>
>> --
>> BEGIN-ANTISPAM-VOTING-LINKS
>> ------------------------------------------------------
>>
>> Teach CanIt if this mail (ID 03Nk3J6v4) is spam:
>> Spam:
>> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=s
>> Not spam:
>> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=n
>> Forget vote:
>> https://www.spamtrap.odu.edu/canit/b.php?i=03Nk3J6v4&m=9e79d1b816aa&t=20141125&c=f
>> ------------------------------------------------------
>> END-ANTISPAM-VOTING-LINKS
>>
>