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

Berk Geveci berk.geveci at kitware.com
Wed Jun 11 08:57:18 EDT 2008


Hi Levent,

Compare the attached vti file to the one you wrote. I wrote this using
VTK and I can read into ParaView without a problem. I opened both with
a hex editor and I can definitely see a difference at the beginning of
the appended section.

-berk

On Tue, Jun 10, 2008 at 3:17 PM, Server Levent Yilmaz
<leventyilmaz at gmail.com> wrote:
> 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 --------------
A non-text attachment was scrubbed...
Name: test.vti
Type: application/octet-stream
Size: 1089 bytes
Desc: not available
URL: <http://www.paraview.org/pipermail/paraview/attachments/20080611/e2bbb33b/attachment.obj>


More information about the ParaView mailing list