[Paraview] windows build can not read appended image (VTI) data

[Berk Geveci]

Hi Levent,

> Thanks for the reply Berk,

You are welcome. I am sorry this is so painful.

>> I followed the reader in the debugger. It looks like the header of the
>> u block is corrupt. The length of the array does not look right.
>
> Can you be a bit more specific? What is the length you read, what is it that
> you expect (in what binary format you expect the number 128)? Well, the
> thing is I highly doubt that the data itself is corrupt, because it does
> work on some systems. I might be wrong. Please read on.

I debugged on Mac OS X. I put a breakpoint right before the error occurs:

//----------------------------------------------------------------------------
int vtkXMLStructuredDataReader::ReadArrayForCells(vtkXMLDataElement* da,
                                                  vtkAbstractArray* outArray)
{
  int* pieceExtent = this->PieceExtents + this->Piece*6;
  int* pieceCellDimensions = this->PieceCellDimensions + this->Piece*3;
  vtkIdType* pieceCellIncrements = this->PieceCellIncrements + this->Piece*3;
>>>>> if(!this->ReadSubExtent(pieceExtent, pieceCellDimensions,
                          pieceCellIncrements, this->UpdateExtent,
                          this->CellDimensions, this->CellIncrements,
                          this->SubExtent, this->SubCellDimensions,
                          da, outArray))
    {
    vtkErrorMacro("Error reading extent "
                  << this->SubExtent[0] << " " << this->SubExtent[1] << " "
                  << this->SubExtent[2] << " " << this->SubExtent[3] << " "
                  << this->SubExtent[4] << " " << this->SubExtent[5]
                  << " from piece " << this->Piece);
    return 0;
    }
  return 1;
}

I follow the code until it starts reading the array:

//----------------------------------------------------------------------------
vtkXMLDataParser::OffsetType
vtkXMLDataParser::ReadUncompressedData(unsigned char* data,
                                       OffsetType startWord,
                                       OffsetType numWords,
                                       int wordSize)
{
  // First read the length of the data.
  HeaderType rsize;
  const unsigned long len = sizeof(HeaderType);
  unsigned char* p = reinterpret_cast<unsigned char*>(&rsize);
  if(this->DataStream->Read(p, len) < len) { return 0; }
  this->PerformByteSwap(&rsize, 1, len);

At this point rsize is 2147483648. Note that len here is 4 bytes. It
looks like the reader is expecting a 4 byte block that is the size of
the block but somehow is getting junk. I cannot tell you much more
beyond that because I am not very familiar with the internals of the
file format.

> Based on this pattern, it seems to me quite unlikely that my data file is
> corrupt. Just in case here is how I encode the raw binary (although it is
> the simplest to use format, it is not a fully documented one and I had to
> ask for help here in the mail group and iterate a number of times to get it
> "right"):
>
> [ header ]
> <AppendedData encoding="raw"> _
> [Number of elements in the array, in 4 byte BIG ENDIAN integer]
> [BinaryData with precision and endianness as specified in the header]
> [ .. more of the same for each record..]
> </AppendedData>
>
> (note: there are no line breaks or any other extra space after `_' in the
> actual file)
>
> To discover (for it was undocumented) that a 4 byte number of elements
> should precede each record and should be a BIG ENDIAN integer regardless of
> the endianness of rest of the binary data was quite a thrill (to say the
> least!). Although there is still room in some mysterious way that I might be
> wrong with this discovery; this is what works in Linux 64bit builds for any
> file and all builds for small data (<128 elements). Can someone please
> enlighten the situation? What is it with this data format?

I'll forward this to the develop of the readers. We'll see what he says.

-berk