Uploaded patch set 1.

Patch Set 1:

A few specific comments:

• Many of the lines not covered are exceptions or special conditions that seem hard to be met without a deeper insight. So unfortunately even if the topic gets merged, some files will have many lines that are not exercised. If anybody happens to have some suggestions on this, I would be happy to add further test code to address the remaining lines in another topic.

• I still need to upload the new baselines generated. Namely, those that correspond to the tests having the AutoMinMax flag to false. However, I realize that for the filters that I've tested this condition either breaks the test or produces a black image.

For example, the itkMomentsThredholsImagefilterTestNoAutoMinMax breaks at 60% of the progress because the itkMomentsThresholdCalculator.hxx:94 calls the GetMeasurement with the threshold being -1 (int), while the definition at itk::Histogram::GetMeasurement expects it to be of type InstanceIdentifier, which turns to be unsigned long in this case. Hence, the type casting results in a out of range vector exception. Am I missing something? Is this a bug?

For the cases where I get a black I image, I fear that the result is not correct. Hence, I'm wondering if the flag should ever be set to false. If yes, which parameter am I missing to get meaningful results?

• I still need to correct the MD5 hash comparison in CMakeLists.txt for the new baselines generated.
• There are many tests that break during execution. An example is

• The
• itkBinaryThresholdSpatialFunctionTest.cxx
• does not test any class in the Thresholding module, but:

\Core\Common\include\itkBinaryThresholdSpatialFunction.h \Segmentation\SignedDistanceFunction\include\itkSphereSignedDistanceFunction.h \Core\Common\include\itkFloodFilledSpatialFunctionConditionalConstIterator.h Should the test be moved elsewhere? Or else, should the filter itself be moved to the Thresholding folder?

• I did not use the number of histograms or autominmax parameters in the masked versions. Let me know if it would be highly desirable to test them as well.

• For the itkIntermodesThresholdImageFilterTest.cxx, I'd dare to say that the calculator maximum number of iterations is not being effectively set/used. When debugging the test, it becomes apparent that the exception is caught not due to an arbitrary value of 200 that I set, but due to the default value of 10000 being exceeded. Looks like the cause is that instead of using the filter's m_IntermodesCalculator, it's the Superclass' m_Calculator instance that is used when performing the computations. Thus, it does not seem fair to me that the property has no effect on the filter. Is this a bug? Am I missing something?

Patch Set 1: Verified-1

Build Failed: CDash filtered results: https://open.cdash.org/index.php?&project=Insight&filtercount=3&field1=buildname/string&compare1=63&value1=22134-1&field2=buildstarttime/date&compare2=83&value2=2015-03-01&field3=buildstarttime/date&compare3=84&value3=2029-01-01

Patch Set 1:

Looks like there is a lot to look at here. I won't be able to help much for a couple of weeks. Looks like a good start, but we need to sort out those questions you've raised

Patch Set 1:

Thanks Richard.

I'll try to fix the errors having to do with the tests having an incorrect number of parameters.

As for the concerns I raised, I'll wait for your thoughts.

Patch Set 1:

Also, a short note: all error messages are sent to std::cout, instead of std::cerr. I realized that std::cerr may not be set in the build sites when I found that it was not set locally for my git bash. Hence, at times relevant error messages are not printed and may lead to confusion when debugging.

It has happened a few times to me with the remote sites.

If you think we should redirect error messages to std::cerr, let me know so that I change it for the files in this topic.

Uploaded patch set 2.

Patch Set 2: Verified-1

Build Failed: CDash filtered results: https://open.cdash.org/index.php?&project=Insight&filtercount=3&field1=buildname/string&compare1=63&value1=22134-2&field2=buildstarttime/date&compare2=83&value2=2015-03-01&field3=buildstarttime/date&compare3=84&value3=2029-01-01

Uploaded patch set 3.

Patch Set 3: Verified-1

Build Failed: CDash filtered results: https://open.cdash.org/index.php?&project=Insight&filtercount=3&field1=buildname/string&compare1=63&value1=22134-3&field2=buildstarttime/date&compare2=83&value2=2015-03-01&field3=buildstarttime/date&compare3=84&value3=2029-01-01

Uploaded patch set 4.

Patch Set 4: Verified-1

Build Failed: CDash filtered results: https://open.cdash.org/index.php?&project=Insight&filtercount=3&field1=buildname/string&compare1=63&value1=22134-4&field2=buildstarttime/date&compare2=83&value2=2015-03-01&field3=buildstarttime/date&compare3=84&value3=2029-01-01

Patch Set 4:

Now it's good to go to fix the AutoMinMax issues. Apart from the need to fix the expected value for the threshold regression tests, I still get black images in such cases.

Uploaded patch set 5: Patch Set 4 was rebased.

Patch Set 5: Verified-1

Build Failed: CDash filtered results: https://open.cdash.org/index.php?&project=Insight&filtercount=3&field1=buildname/string&compare1=63&value1=22134-5&field2=buildstarttime/date&compare2=83&value2=2015-03-01&field3=buildstarttime/date&compare3=84&value3=2029-01-01

Uploaded patch set 6.

Patch Set 6: Verified-1

Build Failed: CDash filtered results: https://open.cdash.org/index.php?&project=Insight&filtercount=3&field1=buildname/string&compare1=63&value1=22134-6&field2=buildstarttime/date&compare2=83&value2=2015-03-01&field3=buildstarttime/date&compare3=84&value3=2029-01-01

Uploaded patch set 7.

Patch Set 7:

Patch set 7 fixes the breaking (producing SEGFAULTS) tests.

Talking to Richard to try to fix the black image output issues.

Will likely update the thread soon.

Patch Set 7: Verified-1

Build Failed: CDash filtered results: https://open.cdash.org/index.php?&project=Insight&filtercount=3&field1=buildname/string&compare1=63&value1=22134-7&field2=buildstarttime/date&compare2=83&value2=2015-03-01&field3=buildstarttime/date&compare3=84&value3=2029-01-01

Patch Set 7:

Hi Everyone, Thanks for the efforts so far. Here's what I think is going on with the AutoMinimumMaximum settings.

When setting up a histogram it is necessary to specify a range of values that are going to be put into it so that the bins can be created. When the "auto" flag is off in the max and min settings appear to be derived from the max and min of the pixel type: ImageToHistogramFilter, lines 209 and 217. This makes sense if the image dynamic range is a substantial proportion of the pixel type.

If the pixel range is used (auto=off) for, say, unsigned short types, while the input dynamic range is actually unsigned char, then we end up with all the data in a tiny number of bins, not providing a useful approximation of the distribution, and probably leading to crazy threshold estimates (like all black).

I think that if the auto flag is off for larger pixel types we should have some way of explicitly setting the min/max used by the histogram generator, but it looks as though this is missing. It would be useful to be able to set the range explicitly if the data had some outliers and some robust estimation of range was necessary, or the range was already known and we want to optimize things by avoiding recalculation.

Thus, I think our problem here is that we don't have a way of setting the range when we turn auto calculation off. There is no reason to expect sensible results if the auto flag is off and no alternative estimate of range is provided.

The default is to have auto on for non char pixel types.