…ically The itkVTIImageIOReadWriteTestVHFColorZLib test registration has failed since @dzenanz's commit c283dfd because it references DATA{Input/VHFColorZLib.vti} but no .cid content-link pointer was ever committed -- the ParaView-produced VHFColorZLib.vti fixture exceeds the 100 KB direct-commit cap, and uploading through ExternalData is blocked on the content-link-upload.itk.org migration (storacha -> Pinata), tracked at InsightSoftwareConsortium#4340 InsightSoftwareConsortium/cmake-w3-externaldata-upload#3 Disable the failing registration (leave it commented with a TODO that points at both issues) and replace its coverage with a synthetic equivalent that does not need the upload pipeline. generate_vti_fixtures.py produces a new fixture VTI_vector3_f32_zlib_appended.{vti,mhd,raw}: a 4x4x2 Vector<float,3> image encoded as ZLib-compressed appended-raw with a UInt64 block-size header, with <PointData Vectors="vectors"> so the reader dispatches to IOPixelEnum::VECTOR rather than RGB. This mirrors the shape of ParaView's VHFColorZLib output (3-component Float32, vtkZLibDataCompressor, appended-raw, UInt64 header) that the original test exercised. itkVTIImageIOGeneratedFixturesTest gets a matching vector3_f32_zlib_appended case that reads the new fixture with VTIImageIO and pixel-compares to its MetaIO oracle (tolerance 1e-6 relative). Because the fixture is produced by a Python-stdlib writer (xml/struct/base64/zlib), this closes the same format-boundary code path as the disabled test without ITK participating in the data generation. ctest -R VTI now reports 9/9 passing on this branch. When the ExternalData upload tool is operational again, un-comment the VHFColorZLib registration and publish Input/VHFColorZLib.vti.cid alongside it; the synthetic case remains useful as cross-impl validation either way.

Update for new APIs #3

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions