

Those set the voxel size and origin point of the grid. The Data Spacing and Data Origin we’ll just leave alone. The Data Bye Order needs to be changed from its default of LittleEndian. Most machines, such as Intel, are little endian now a days. Since my data is stored as 16-bit integers, keep the Data Scalar Type set to short. The default properties panel looks like this:Īnd for my specific data set, I’ll want to change to these values (with the changes boxed in red.)Ī bit of discussion of what the properties are is in order. You’ll want to pick the binary one.Īfter this, you’ll need to set the properties correctly before hitting apply. When loading the file in Paraview, you’ll be faced with a choice of three different raw readers. For raw/brick files, you’ll have to use the ‘. If you want a comma separated file to be loaded, you’ll need to use ‘.

Paraview specifically uses the filename’s extension to determine which reader or choice of readers to use when opening a file. This won’t work out if the filenames aren’t zero padded. Since the names of each of these files happen to be zero padded, this will naturally pack the data in order. In Bash, the globbing operator ( *) will return its results in alphabetical order. This is sometimes known as a brick.Ĭat 000001a8d1611e71_vol_0_* | gunzip - > tooth.raw So first we need to uncompress and collect all of the files into a single large block. Paraview has a nice file reader for raw blocks of voxel data. So now it’s time to create a file that we can bring into Paraview more easily. Which gives this: Looks Like a Medical Image to Me Getting this into Paraview Julia> imshow(plane) # View the data as an image Julia> read!(open("junk"), plane) # Loading the plane into the matrix Julia> plane = zeros(Int16, 512, 512) # Making a 16-bit per plane matrix

I picked a middle frame to visualize and using Julia: julia> using ImageView # This is a registered package you'll need to add A clean answer was gotten with sqrt(52488/2), which was 512. If I guessed that the data set was a sequence of Int32’s, then sqrt(524288/4) would still yield unclean numbers.

Starting off with the assumption that the data is square and that each voxel was a byte, I took the square root of 524288 to see if that yielded a clean number. I had a conversation with my dentist about the data and she had remembered something about the data being stored as image planes. The file is `524288` bytes big and running `file` yields that this is an unknown format at least to that program. So `cat 000001a8d1611e71_vol_0_001 | gunzip – > junk` will cat the file to stdout, pipe the stream through gunzip, and then write the contents to a file called junk. Typing `file 000001a8d1611e71_vol_0_001` at the bash prompt tells me that these are gzipped files of some sort. If you have a similar data set, you’ll have to substitute the names.
Paraview file format code#
I actually have a couple of data sets from my dentist, so I know that the data directory’s code (`000001a8d1611e71`) changes for every scan. The files are numerically ordered and named from `000001a8d1611e71_vol_0_001` to `000001a8d1611e71_vol_0_607` with a couple of extra similarly named support files of some sort, one being an XML file, and I’m unsure about the other. Poking around the CD, there’s a directory called `000001a8d1611e71_vol_0` containing a sequence of 608 files around 100-350KB big. This post is going to go through some of the process I used to discover how the data was organized as well as give a brief introduction to using Raw files in Paraview. Since I don’t have Windows, this left me with the fun task of trying to reverse engineer the data so I can visualize it.
Paraview file format windows#
The X-ray equipment my dentist uses can export the data to a CD with an installer for some sort of Windows based viewing tool. Of course, the question I’m going to ask after they take the 3D X-ray of my jaw is, “can I have a copy of the data?” It’s a common thing I ask. So, I’m in the process of getting an implant for a new tooth.
