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

[Server Levent Yilmaz]

Thanks for the reply Berk,

On Mon, Jun 9, 2008 at 9:35 PM, Berk Geveci <berk.geveci at kitware.com> wrote:

> 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.

First off, I did some more checks with whatever build I have access to. It
turns out it is not just the Win32 build:

system / PV version / can load file 8x4x4.vti?
Linux (ubuntu hardy) x86_64 / 3.3.0 / yes
Linux (ubuntu hardy) x86_64 / 3.2.1 / yes
MacOSX x86_32 / 3.2.1 / yes
Linux (ubuntu gutsy) x86_32 / 3.2.1 / no
Windows XP x86_32 / 3.2.1 / no

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?


thanks,
Levent

-- 
Server Levent Yilmaz
Mechanical Engineering
University of Pittsburgh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20080610/7c72979d/attachment-0001.htm>