[Insight-users] NaN Pixel Values

[Michael Halle]

Daniel Mace wrote:
> Robert,
> 
> Even if ITK would allow it (it may internally, but I think you would 
> have issues with writing and reading it), it probably would not be a 
> good idea to do it.  Providing memory isn't an issue, the more practical 
> solution would be to create an identically sized mask image with 0's and 
> 1's denoting your criteria.  
> It's probably more computationally 
> efficient to check the state of the mask image and maintain two 
> iterators than it is to check if your image value is NaN (even faster if 
> you cast your original image and masked image into a VectorImage and use 
> a single VectorImageIterator to walk through the values (this is if you 
> need to do further processing on the image)).  You can then write the 
> masked image out as a separate file, or use ScalarToArrayCastImageFilter 
> to construct it as a vector image and write it out.

If there isn't ubiquitous support for NaNs in a future ITK, I think 
there are at least a few compromise steps that would be extremely handy. 
  These aren't exactly what Robert wants (actually setting values to be 
NaN) but they are related.

*) A standard way to produce the mask+image you just described from an 
existing image that has NaNs (and vice versa).  That allows a couple of 
things:
     -) support for existing data sets that use NaNs
     -) Robert's application:  he can use (0.0/0.0) to create a NaN and 
use it in an image because it's convenient for him, then turn that 
information into a mask because it's convenient for ITK.

*) A standard way to tell ITK that an image may have NaNs, and a way to 
know ask if an image does actually have NaNs.  Using NaNs can introduce 
some extra tests or computational expense to filters, costs that can be 
avoided in the  more common case where NaNs don't exist.  If there was a 
way to warn ITK that an image might have NaNs, then those extra tests 
could be turned off most of the time.

To avoid further computation costs, histograms could use this 
"MayHaveNaNs" flag to enable an extra method, "DoesHaveNaNs". 
DoesHaveNaNs says that a particular image does, in fact, have NaNs. 
NaN-aware processing elements can use that information to choose between 
fast paths or careful paths.  If an image that "MayHaveNaNs" in fact 
(not DoesHaveNaNs), then the fast path can be used.  A filter that 
doesn't deal with NaNs can also check this flag or method and bail out 
accordingly.

I think these additions strike a balance between making all of ITK 
NaN-aware (probably impossible at this point) and allowing specific 
parts to choose to be NaN-aware in a standard way.

Following TEEM/AIR's lead, it might make sense for the flags to consider 
Inf as well.

--Mike



> 
> Cheers,
> Dan
> 
> 
> 
> Robert Jason Harris wrote:
>>
>> Hello all,
>>
>> I used ITK for a project this past summer, and I have since been 
>> reviewing what I have done.  It occurred to me that it might be useful 
>> to enter NaN values into some pixels of an image after it had been 
>> processed by a filtering algorithm that I wrote.  Is this defined in 
>> ITK, or will ITK break?  I have been looking for the use of NaN in 
>> ITK, and I've found hints but nothing definite.  I'm thinking of 
>> something like the following:
>>
>> ...
>> // process image and come up with criterion based
>> // on pixel values to determine which to set to NaN and
>> // which to keep at their current value
>>
>> if ( pixel value < some value)
>>  image_iterator.SetPixel(NaN)
>> else
>> //do nothing.
>>
>>
>>
>> Thanks for any help you can provide!
>>
>> Robert Harris
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users