BUG: Add VTKPolyDataMeshIO FIELD data support (forward-port of #4859)#6188
Open
hjmjohnson wants to merge 1 commit intoInsightSoftwareConsortium:mainfrom
Open
BUG: Add VTKPolyDataMeshIO FIELD data support (forward-port of #4859)#6188hjmjohnson wants to merge 1 commit intoInsightSoftwareConsortium:mainfrom
hjmjohnson wants to merge 1 commit intoInsightSoftwareConsortium:mainfrom
Conversation
Closed
github-actions
Bot
added
type:Bug
Member
Author
|
@greptileai review this draft before I make it official |
This comment was marked as resolved.
This comment was marked as resolved.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
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>
3 tasks
Member
|
@hjmjohnson thanks! Have you verified that the result can be read by a VTK-based reader, e.g. Slicer? |
Member
Author
|
@thewtex Both files successfully read by slicer. They appear identical on first view. |
Member
Author
|
@thewtex Please merge if you approve this PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Forward-port of #4859 from
release-5.4tomain, with the bug that madeitkMeshFileReadWriteTestFieldfail now fixed.What this adds
Reading of VTK legacy
FIELDdata entries insidePOINT_DATA/CELL_DATAsections of.vtkPolyData files. When aFIELD FieldData Nblock is present and the first array's tuple count matches the point/cell count, the data is read as aVariableLengthVectorpixel. Additional arrays in the same field are silently skipped.The
gourd.vtktest fixture exercises the path via the newitkMeshFileReadWriteTestFieldtest.The bug that made #4859's test fail
The original PR added
FIELDdetection only inReadMeshInformation— it setm_PointPixelType=VARIABLELENGTHVECTORandm_NumberOfPointPixelComponentsbut didn't teachRead{Point,Cell}DataBufferAs{ASCII,BINARY}how to parse the FIELD layout. Those helpers only knew to skipSCALARS+LOOKUP_TABLEor bareVECTORS/NORMALS/TENSORSheaders. For a FIELD section the file has an extra array-header line:That extra line was never consumed, so
ReadComponentsAsASCII(or theinputFile.readblock in the binary path) started parsing the array header as the first values — producing garbage and trippingitkMeshFileReadWriteTestField.The fix adds a
find("FIELD")branch alongside the existingSCALARSbranch in all four buffer readers, consuming the array-header line before falling through to the value read.Closes #4859.