# Advice on grid formats
**URL:** https://discourse.vtk.org/t/advice-on-grid-formats/5343
**Category:** Support
**Created:** [March 8, 2021, 6:01pm UTC](https://discourse.vtk.org/t/advice-on-grid-formats/5343 "2021-03-08T18:01:06Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Luke\_Dalessandro](https://discourse.vtk.org/u/Luke_Dalessandro)
#### Post date: [March 8, 2021, 6:01pm UTC](https://discourse.vtk.org/t/advice-on-grid-formats/5343/1 "2021-03-08T18:01:06Z")
Hi all.
For the last couple of years I have been using the `vtkUnstructuredGrid` file format as an output format for my solver infrastructure–-basically it’s storing N-dimensional `[point]→(f0,f1,...)` scalar data corresponding to a custom compressed solution (via `grid->GetPointData()->AddArray()` calls).
I now have a need to output the underlying uncompressed grid, which is a standard uniform grid. From what I can tell it directly matches the regular topology and geometry provided by an N-dimensional `vtkImageData` grid (or possibly `vtkStructuredPoints`, details are a little hard to come by for this subclass).
Is either `vtkImageData` or `vtkStructuredPoints` an appropriate choice for a `[point]→(f0,f1,...)` type of dense dataset, such that it will basically fit into an existing Paraview analysis methodology based around `vtkUnstructuredGrid`? I don’t see any corresponding `XMLWriter` functionality so I suspect it’s not.
I don’t mind continuing to use unstructured grids as an output format but skipping the explicit point and coordinate data output for the regular case would save me a bunch of memory.
Any advice is appreciated.
Thanks,
Luke
---
### Author:  [@Luke\_Dalessandro](https://discourse.vtk.org/u/Luke_Dalessandro)
#### Post date: [March 8, 2021, 6:15pm UTC](https://discourse.vtk.org/t/advice-on-grid-formats/5343/2 "2021-03-08T18:15:37Z")
Oh, I just ran into `vtkXMLImageDataWriter`… don’t know how I missed that earlier. Maybe this `vtkImageData` is exactly what I want even though I’m not dealing with image data specifically.
---
### Author:  [@will.schroeder](https://discourse.vtk.org/u/will.schroeder)
#### Post date: [March 8, 2021, 6:16pm UTC](https://discourse.vtk.org/t/advice-on-grid-formats/5343/3 "2021-03-08T18:16:20Z")
It sounds like it’s a fit based on what I understand. If you have a workflow around vtkUnstructuredGrids, if you change dataset type to vtkImageData then you may have to find equivalent filters, or perform data conversion, to process the data. One thing good about vtkImageData is that many specialized algorithms and rendering techniques exist which are often much faster than the vtkUnstructuredGrid equivalents.
vtkStructuredPoints and vtkImageData are pretty much the same thing except the way the origin and extent are handled. Typically vtkImageData is used.
The classes vtkXMLImageDataWriter / vtkXMLImageDataReader are available for writing / reading data.
---
### Author:  [@Luke\_Dalessandro](https://discourse.vtk.org/u/Luke_Dalessandro)
#### Post date: [March 8, 2021, 6:22pm UTC](https://discourse.vtk.org/t/advice-on-grid-formats/5343/4 "2021-03-08T18:22:04Z")
Okay, I’ll give that a shot and see if the poor souls (i.e., grad students) that actually have to analyze results have any problem synthesizing the physical or logical coordinate data.
Thank you,
Luke
---
### Author:  [@Luke\_Dalessandro](https://discourse.vtk.org/u/Luke_Dalessandro)
#### Post date: [March 9, 2021, 12:54am UTC](https://discourse.vtk.org/t/advice-on-grid-formats/5343/5 "2021-03-09T00:54:18Z")
Is the image origin a logical thing or a physical thing? If I have an (e.g.,) 1D physical domain that’s (-1, 1), should I be setting Origin for that? Or is that information unavailable in the vtkImageData model (or something I get via inheritance, that I just don’t see right now)?
---
### Author:  [@will.schroeder](https://discourse.vtk.org/u/will.schroeder)
#### Post date: [March 9, 2021, 12:52pm UTC](https://discourse.vtk.org/t/advice-on-grid-formats/5343/6 "2021-03-09T12:52:31Z")
Look at the documentation in vtkImageData.h. It can be tricky - I have to remind myself often of the concepts. What follows is off the cuff so there may be some bad advice here but hopefully it will get you going 🙂
SetOrigin() specifies the position of the logical index (i=0,j=0,k=0). Since the actual image extents do not need to contain index (0,0,0), the physical origin position can be outside of the actual volume.
Typically beginners find that using extents starting at (0,0,0) with the origin specified in 3D space using SetOrigin() (as well as specifying voxel spacing with SetSpacing()) is less confusing. Since there is a relationship with the dimensions of the 3D image with the extent, an image can be specified with: SetDimensions(iDim,jDim,kDim); SetOrigin(xO,yO,zO); SetSpacing(vx,vy,vz). Then use AllocateScalars() to allocate memory for the data values associated with the image.
Finally, the concept of image or volume dimensions can be very confusing. This follows since VTK has the notion of both point data and cell data, and that cells are interpolation fields across regions of space. For example, in VTK a 3D image consisting of a single voxel is of dimensions (2x2x2) since eight points define a voxel. Of course, if your perspective is one of “cells” then a single voxel volume is of dimensions (1x1x1). Many people are more comfortable describing an image/volume in terms of “number of pixels” or “number of voxels” so it’s important to be careful of terminology. (And a related issue is the physical origin and “size” of a volume specified using _cell_ dimensions - there is 1/2 voxel shifting required etc.) All these are simple concepts but can drive you crazy if not thought through carefully.
---
### Author:  [@Luke\_Dalessandro](https://discourse.vtk.org/u/Luke_Dalessandro)
#### Post date: [March 9, 2021, 3:07pm UTC](https://discourse.vtk.org/t/advice-on-grid-formats/5343/7 "2021-03-09T15:07:47Z")
Thanks Will.
I was just trying to understand the call to SetOrigin, as its argument is named `ijk` which we would normally use for discrete logical indexing, rather than `x` or `xyz` which would be a floating-point physical index.
It sounds like I’m using it correctly though, in that `SetOrigin(-M_PI,-M_PI,0)` should imply that logical index `0,0,0` would correspond with the physical location `-M_PI,-M_PI,0`.