Incorrect visualization of vtkLongArray cell scalars when using vtk.js local rendering

Describe the bug

Using trame-vtk with vtkLongArray cell scalars results in incorrect visualization of the data. Using vtkTypeInt64Array instead produces the correct result.

In VTK 9.6.2, the conversion between NumPy and VTK array dtypes was incorrect, resulting in long being converted to int64. This was fixed in VTK 9.7.0 with https://gitlab.kitware.com/vtk/vtk/-/merge_requests/13430.

Consequently, downstream users like PyVista which use vtk_to_numpy and numpy_to_vtk are now seeing this bug surface in VTK 9.7, since the numpy conversion would previously "mask" the bug by changing the dtype from long (broken) to int64 (working), whereas now the NumPy conversion is correct and we go from long (broken) back to long (still broken). See pyvista/pyvista#8810 (comment)

I created a matrix using the reproducer below to show how the different arrays and how the use of a NumPy round-trip conversion affects the output. The table shows the apparent regression with vtkLongArray previously working in 9.6.2 with a NumPy round-trip, which breaks with vtk 9.7.

This issue with vtkLongArray is only visible when using trame-vtk. The correct output is observed in all cases when using vtk outside of a trame app.

Args	vtk-9.6.2	vtk-9.7.0rc2
`vtkLongArray`
`vtkLongArray --numpy-roundtrip`
`vtkTypeInt64Array`
`vtkTypeInt64Array --numpy-roundtrip`

To Reproduce

Download the script dtype_bug.py. Create a new env and install deps:

pip install trame trame-vuetify trame-vtk vtk

Run the script with the args listed in the table above to generate the outputs, along with a port, e.g.

python ./dtype_bug.py vtkLongArray --port 1234
python ./dtype_bug.py vtkLongArray --numpy-roundtrip --port 1234
python ./dtype_bug.py vtkTypeInt64Array --port 1234
python ./dtype_bug.py vtkTypeInt64Array --numpy-roundtrip --port 1234

Platform:

Device:

Desktop
Mobile

OS:

Browsers Affected:

Thanks for the report! I'm hoping to maybe look at it sometime next week.

Looking at the sample code, this use case is with local rendering using vtk.js.
Ideally, I would like to start enabling vtk-wasm for local rendering which should solve most if not all issue related to vtk.js limitation.

But in this case it is more of a Web limitation in the TypedArray... I'm not sure what would be the path forward on that specific issue.

I see, that makes sense. If needed, downstream users could probably monkey-patch the new mappings from numpy array types to VTK array types inside of numpy_support.py to restore the old (wrong) behavior... will wait to see if there's a proper fix here first.

I've integrated your validation example here and also added a --wasm option to test also the wasm rendering output.

Since there is no perfect solution (due to JS lacking Int64), I performed a data conversion to Int32 server side within the trame-vtk==2.11.14 release.

I let you test and see what you think and if it is ok to close this issue or not?

BTW, the rendering of the colors/light is weird between the various array types...

Thanks, I pushed version updates to pyvista/pyvista#8819 to test trame-vtk==2.11.14. The cell scalars issue seems to be fixed, but there are many new errors with some images producing blank result, e.g.

See the image regression report here, there are now ~300 errors reported with vtksz files specifically:
https://6a63a555a69438104215e4c0--pyvista-doctest-images.netlify.app

Compared to ~30 with trame-vtk==2.11.13:
https://6a5ee09cddccd2039dccb7f3--pyvista-doctest-images.netlify.app

Ok looking into it.

Any easy way for me to test those locally? I have an idea of the cause of the problem, but I want to validate it before triggering yet another release.

not really easy because it requires the full docs build and patching the tox config to install the deps you want... but typically use tox run -e docs-build for building docs, then tox run -e docs-test for testing afterwards. You can usually use --override testenv.deps+= to add additional deps but I just tried and it doesn't work for installing from a git commit.

So it seems you need to add the install in tox config commands_pre, e.g.

commands_pre =
    uv pip install "git+https://github.com/Kitware/trame-vtk.git@094ee32ff306005f744b5d5d0f3f114a30a7038e"

If you give me specific commits to install from whatever packages you want to test I can push them to pyvista/pyvista#8819 directly and let our CI test it out

Takes about 30 minutes to run too... not ideal for iterative debugging. The alternative is to try to create a minimal reproducer, but I tried doing something like this (based on the observation that this example was one of the blank images):

from pyvista import examples
import pyvista as pv
mesh = examples.download_bunny()
out = mesh.partition(4, as_composite=True)
pl = pv.Plotter()
pl.add_mesh(out)
pl.export_html('test.html')

But it didn't work, the output html wasn't blank, so does not reproduce....

Ok thanks, I'll create a branch to test/validate then. Thanks again for your guidance.

I tried to clone pyvista and setup a venv to run it, but I always get a ModuleNotFoundError: No module named 'tox_uv'.

That would be the one to test Kitware/trame-vtk#123

Thanks I pushed 000de9c, tracking build status here
https://github.com/pyvista/pyvista/actions/runs/30126676041

EDIT: And it's tracking the branch directly, so if you make any more pushes we can just retry the job to pull in the updates

new generated report looks the same :(, images still blank
From this action: https://github.com/pyvista/pyvista/actions/runs/30128641958
This is the report link https://6a63dc7040f03b07ab45e0d1--pyvista-doctest-images.netlify.app

Yes I noticed... We/I really need to get to the bottom of it. I need to figure out how to properly build the website locally on my mac to really.

BTW, Do you know how to find the live page of a broken example? I was trying to get to the dragon, but I can't seem to find it.

Like the page below
https://6a63dcaf4fb70d49edbddbdb--pyvista-dev.netlify.app/examples/01-filter/image_fft_perlin_noise

Which seems to work...

Hum, I'm wondering if it is a timing issue in the validation when the screenshot get captured as I could not find an issue from the deployed website.

It could be a test issue, the code for taking the screenshot with playwright lives in pytest-pyvista. The fact that the docs look good, and that when I try generating the html locally it also looks good, reminds of this comment on a separate trame-vtk issue, where it was also specific to the test env pyvista/pyvista#8360 (comment).

And the test-specific context gave me a hint to create this small reproducer. The tests will fail because there are no baseline images (cache is empty), but ignore that, and look at the contents of the generated dir. You should see the blank image for the vtksz screenshot.

# Create environment
git clone https://github.com/pyvista/pyvista.git
cd pyvista

uv venv
source .venv/bin/activate

uv pip install -e . --group test playwright
uv pip install --extra-index-url https://wheels.vtk.org vtk --pre --upgrade
uv pip install trame-vtk 2.11.14
playwright install chromium

# Create image directories for storing images and running test
DEBUG_DIR="../debug"
mkdir -p "$DEBUG_DIR"

DEBUG_DIR="$(realpath "$DEBUG_DIR")"
DOC_IMAGES_DIR="$DEBUG_DIR/images"
GENERATED_DIR="$DEBUG_DIR/generated"
IMAGE_CACHE_DIR="$DEBUG_DIR/cache"

mkdir -p \
    "$DOC_IMAGES_DIR" \
    "$GENERATED_DIR" \
    "$IMAGE_CACHE_DIR"

# Generate a `.png` and `.vtksz` of the plot
python - <<EOF
from pyvista import examples
import pyvista as pv

mesh = examples.download_bunny()
out = mesh.partition(4, as_composite=True)

pl = pv.Plotter(off_screen=True)
pl.add_mesh(out)
pl.trame.export_vtksz("$DOC_IMAGES_DIR/test.vtksz")
pl.show(auto_close=False)
pl.screenshot("$DOC_IMAGES_DIR/test.png")
pl.close()
EOF

# Run test to take a screenshot of the vtksz file and compare it to baseline
pytest \
    --doc_mode \
    --include_vtksz \
    --generated_image_dir "$GENERATED_DIR" \
    --doc_images_dir "$DOC_IMAGES_DIR" \
    --image_cache_dir "$IMAGE_CACHE_DIR"

Resolved by Kitware/trame-vtk#123

Navigation Menu

Repository navigation

Incorrect visualization of `vtkLongArray` cell scalars when using vtk.js local rendering #900

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Incorrect visualization of vtkLongArray cell scalars when using vtk.js local rendering #900

Description

Activity

jourdain commented on Jul 23, 2026

jourdain commented on Jul 23, 2026

user27182 commented on Jul 23, 2026

jourdain commented on Jul 24, 2026

user27182 commented on Jul 24, 2026

jourdain commented on Jul 24, 2026

jourdain commented on Jul 24, 2026

user27182 commented on Jul 24, 2026

user27182 commented on Jul 24, 2026

jourdain commented on Jul 24, 2026

jourdain commented on Jul 24, 2026

user27182 commented on Jul 24, 2026

user27182 commented on Jul 24, 2026

jourdain commented on Jul 24, 2026

jourdain commented on Jul 24, 2026

user27182 commented on Jul 25, 2026

user27182 commented on Jul 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Incorrect visualization of `vtkLongArray` cell scalars when using vtk.js local rendering #900