Repository navigation
Incorrect visualization of vtkLongArray cell scalars when using vtk.js local rendering #900
Description
Activity
Thanks for the report! I'm hoping to maybe look at it sometime next week.
Reacted by user27182Looking 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.
- changed the title
[-]Incorrect visualization of `vtkLongArray` cell scalars[/-][+]Incorrect visualization of `vtkLongArray` cell scalars when using vtk.js local rendering[/+]on Jul 23, 2026 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.pyto restore the old (wrong) behavior... will wait to see if there's a proper fix here first.Reacted by Sebastien Jourdain (Kitware)I've integrated your validation example here and also added a
--wasmoption 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.14release.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
vtkszfiles specifically:
https://6a63a555a69438104215e4c0--pyvista-doctest-images.netlify.appCompared to ~30 with
trame-vtk==2.11.13:
https://6a5ee09cddccd2039dccb7f3--pyvista-doctest-images.netlify.appReacted by Sebastien Jourdain (Kitware)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-buildfor building docs, thentox run -e docs-testfor 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'.Reacted by user27182That 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/30126676041EDIT: 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
Reacted by Sebastien Jourdain (Kitware)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.appYes 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_noiseWhich 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 separatetrame-vtkissue, 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
generateddir. 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
Describe the bug
Using
trame-vtkwithvtkLongArraycell scalars results in incorrect visualization of the data. UsingvtkTypeInt64Arrayinstead 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_numpyandnumpy_to_vtkare 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
vtkLongArraypreviously working in 9.6.2 with a NumPy round-trip, which breaks with vtk 9.7.This issue with
vtkLongArrayis only visible when usingtrame-vtk. The correct output is observed in all cases when usingvtkoutside of a trame app.vtkLongArrayvtkLongArray --numpy-roundtripvtkTypeInt64ArrayvtkTypeInt64Array --numpy-roundtripTo Reproduce
Download the script dtype_bug.py. Create a new env and install deps:
Run the script with the args listed in the table above to generate the outputs, along with a port, e.g.
Platform:
Device:
OS:
Browsers Affected: