[Insight-developers] help requested with itkBrains2MaskTest

[Karthik Krishnan]

Kent,

The Brains2MaskIO is not parsing the headers correctly while reading the 
Brains2Mask file. The mask file is written out correctly. But the 
ReadHeader assumes that the fields between IPL_HEADER_BEGIN and 
IPL_HEADER_END contains fields delimited by spaces. That needn't always 
be the case cause several dashboards run the tests from paths with 
spaces between them.

The failing tests really have nothing to do with the platform. They'll 
fail on any plaform if the Brains2Mask filename being read contained 
spaces. The Keys end up getting offset and garbled.

Thanks
regards
karthik


Kent Williams wrote:

> As you have no doubt noticed, the itkBrains2MaskTest is currently 
> failing on the following platforms:
>
> Cygwin-gcc33 (sometimes)
> Visual studio  7.1,7.0 (sometimes), 6.0
>
> I have Visual Studio .NET on my home machine, and built up ITK last 
> night, and it passes the test. What's worse, apparently some builds 
> don't fail the test even though other builds with the same compiler do 
> fail the test!
>
> The changes I made that precipitated the failures were correcting a 
> problem with the header written out to brains2 mask files. The header 
> comprises a bunch of name/value pairs written out, bracketed by 
> begin/end symbols, followed by the binary data that defines an octree 
> representation of the mask volume.
>
> I don't have access to any of the compilers that are currently 
> failing. I suspect the problem comes down to whether the ifstream 
> reading though the header gobbles the last newline in the textual 
> header portion of the file.  In itkBrains2MaskImageIO.cxx, at line 151 
> (in the itk::Brains2MaskImageIO::Read method) there's this clause:
>
> //Need to gobble up the end of line character here and move one more 
> byte.
> //Except for Borland where the operator>> has already gobbled the 
> endline char
> #if !defined(__BORLANDC__)
>  local_InputStream.ignore();
> #endif
>
> I suspect that the failing platforms are also reading the newline 
> character unexpectedly at the end of the header -- the code is too 
> simple for many other explanations.
>
> If you have regular builds on one of the failing platforms, would you 
> please try adding that platform to the #if clause above, to see if it 
> fixes the test? If there's no consistency, I'll rewrite the header 
> reader to step through the header a character at a time, and make sure 
> it's gobbling the '\n' character properly.  Incidentally, the files 
> are read and written with the ios::binary flag set... so in theory, 
> the end of line in the header is always represented with a single '\n'.
>
> I've been programming for a living since 1984, and I suspect I've 
> spent at least a couple of months during that time dealing with bugs 
> that happen because there's no universal agreement on what comprises a 
> newline!
>
> Thanks in advance!
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>