[Insight-developers] ImageIO::ReadBufferAsASCII and WriteBufferAsASCII do not handle signed and unsigned chars correctly

[Bradley Lowekamp]

Hello,

I discovered the following bug the other week:

http://www.itk.org/Bug/view.php?id=10124


Caused by the following code:

void WriteBuffer(std::ostream& os, const TComponent *buffer, ImageIOBase::SizeType num)
{
  const TComponent *ptr = buffer;
  for (ImageIOBase::SizeType i=0; i < num; i++)
    {
    if ( !(i%6) && i ) os << "\n";
    os << *ptr++ << " ";
    }
}
}

The solution is to use the numeric trait "PrintType" for the reading and writing here. The reason I believe that this bug has not been found earlier is that this writing and reading is symmetric. What I mean is that you can write a file with ASCII chars and then read it back and it will be correct in ITK. But the file would actually be binary chars.

Should this bug be fixed with my proposed solution?

I suppose if backwards compatibility of the files is an issue ( one could always use an older version if ITK to convert to binary or another file type), we would have to some how specialize the ReadBuffer<> method. Then if the LEGACY is defined we would need to scan a certain amount of the input, and then try to guess if the input was legacy binary chars or correct ascii. But  of course you can always have a binary file which looks like an ascii file, so then perhaps the size of the file could be used. But then again the file could have some kind of data at the end of the file. So this would likely be some ugly hack which tries to preserve the behavior but will likely cause more issues, and maintenance problems.

Brad


========================================================
Bradley Lowekamp  
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100217/712aa58b/attachment.htm>