Skip to content

BUG: Add VTKPolyDataMeshIO FIELD data support (forward-port of #4859)#6188

Draft
hjmjohnson wants to merge 1 commit intoInsightSoftwareConsortium:mainfrom
hjmjohnson:vtk-field-main
Draft

BUG: Add VTKPolyDataMeshIO FIELD data support (forward-port of #4859)#6188
hjmjohnson wants to merge 1 commit intoInsightSoftwareConsortium:mainfrom
hjmjohnson:vtk-field-main

Conversation

@hjmjohnson
Copy link
Copy Markdown
Member

Forward-port of #4859 from release-5.4 to main, with the bug that made itkMeshFileReadWriteTestField fail now fixed.

What this adds

Reading of VTK legacy FIELD data entries inside POINT_DATA / CELL_DATA sections of .vtk PolyData files. When a FIELD FieldData N block is present and the first array's tuple count matches the point/cell count, the data is read as a VariableLengthVector pixel. Additional arrays in the same field are silently skipped.

The gourd.vtk test fixture exercises the path via the new itkMeshFileReadWriteTestField test.

The bug that made #4859's test fail

The original PR added FIELD detection only in ReadMeshInformation — it set m_PointPixelType=VARIABLELENGTHVECTOR and m_NumberOfPointPixelComponents but didn't teach Read{Point,Cell}DataBufferAs{ASCII,BINARY} how to parse the FIELD layout. Those helpers only knew to skip SCALARS+LOOKUP_TABLE or bare VECTORS/NORMALS/TENSORS headers. For a FIELD section the file has an extra array-header line:

POINT_DATA <numPoints>
FIELD FieldData <numArrays>
<arrayName> <numComponents> <numTuples> <dataType>   ← this line was treated as data
<value1> <value2> ...

That extra line was never consumed, so ReadComponentsAsASCII (or the inputFile.read block in the binary path) started parsing the array header as the first values — producing garbage and tripping itkMeshFileReadWriteTestField.

The fix adds a find("FIELD") branch alongside the existing SCALARS branch in all four buffer readers, consuming the array-header line before falling through to the value read.

Closes #4859.

@hjmjohnson hjmjohnson mentioned this pull request May 2, 2026
@github-actions github-actions Bot added type:Bug Inconsistencies or issues which will cause an incorrect result under some or all circumstances type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots area:IO Issues affecting the IO module labels May 2, 2026
@hjmjohnson
Copy link
Copy Markdown
Member Author

@greptileai review this draft before I make it official

@greptile-apps

This comment was marked as resolved.

Comment thread Modules/IO/MeshVTK/src/itkVTKPolyDataMeshIO.cxx Outdated
Add reading of VTK legacy FIELD data entries in both POINT_DATA
and CELL_DATA sections.  When FIELD data is present and the number
of tuples matches the point/cell count, the data is read as a
VariableLengthVector pixel type.

`ReadMeshInformation` detects the `FIELD FieldData N` keyword and
parses the first array's header (`<name> <numComponents> <numTuples>
<dataType>`) to set the IO metadata.  The matching
`Read{Point,Cell}DataBufferAs{ASCII,BINARY}` helpers now also consume
that array-header line after the `FIELD` keyword so the actual data
block lines up; without that step `itkMeshFileReadWriteTestField`
fails because the reader treats the array header as data.

Only the first field-data array per section is used; additional
arrays are silently skipped.  Add a test with a `gourd.vtk` file
that exercises the FIELD data path.

Forward-port of InsightSoftwareConsortium#4859 from `release-5.4` to `main`.

Co-Authored-By: Matt McCormick <matt@mmmccormick.com>
Co-Authored-By: Hans Johnson <hans-johnson@uiowa.edu>
@hjmjohnson hjmjohnson requested a review from thewtex May 2, 2026 18:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:IO Issues affecting the IO module type:Bug Inconsistencies or issues which will cause an incorrect result under some or all circumstances type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants