Skip to content

add_mesh per-face coloring#984

Open
sp-droid wants to merge 2 commits into
fastplotlib:mainfrom
sp-droid:main
Open

add_mesh per-face coloring#984
sp-droid wants to merge 2 commits into
fastplotlib:mainfrom
sp-droid:main

Conversation

@sp-droid
Copy link
Copy Markdown

  • When not uniform, the class will expect colors to be as large as either the positions (per-vertex coloring with intermediate interpolation) or the indices (per-face coloring).

I didn't go further with creating a new parameter because this was much simpler.

When not uniform, the class will expect colors to be as large as either the positions (per-vertex coloring with intermediate interpolation) or the indices (per-face coloring)
@sp-droid
Copy link
Copy Markdown
Author

sp-droid commented Feb 6, 2026

I also suggest adding a comment to specify that the colors must be in linear RGB mode, NOT sRGB which is what we get from popular colormap sources such as the ones in matplotlib. I was pulling my hairs today trying to figure out why the same thing on matplotlib and fastplotlib was different.

@sp-droid
Copy link
Copy Markdown
Author

@kushalkolar Could we take a look into this? I've been using it for a few months without issue.

@kushalkolar
Copy link
Copy Markdown
Member

I also suggest adding a comment to specify that the colors must be in linear RGB mode, NOT sRGB which is what we get from popular colormap sources such as the ones in matplotlib. I was pulling my hairs today trying to figure out why the same thing on matplotlib and fastplotlib was different.

pygfx uses sRGB by default, can you play with pygfx.Color("name").to_physical() and pygfx.Color.from_physical() to see what's happening?

@sp-droid
Copy link
Copy Markdown
Author

I also suggest adding a comment to specify that the colors must be in linear RGB mode, NOT sRGB which is what we get from popular colormap sources such as the ones in matplotlib. I was pulling my hairs today trying to figure out why the same thing on matplotlib and fastplotlib was different.

pygfx uses sRGB by default, can you play with pygfx.Color("name").to_physical() and pygfx.Color.from_physical() to see what's happening?

this is what i do. I set

self._mesh = self._figure[0, 0].add_mesh(
          self._mesh_vertices,
          self._mesh_indices,
          colors=self._random_colors,
          mode="basic"
      )

once. Then change that colors attribute with self._mesh.colors = any color array. It could be that i'm unknowingly bypassing the "to_physical" method, which explains why i have to convert to linear space myself

@kushalkolar
Copy link
Copy Markdown
Member

With pygfx.Color("teal").to_physical():

image

Without to_physical():

image

Are you expecting the former?

@sp-droid
Copy link
Copy Markdown
Author

Sorry busy week. I'm not sure which one to be honest but yes it's the same conflict i have as it looks on pygfx docs:
image

Let me put it this way, add_mesh and add_image have different behaviors with respect to coloring. When im passing colors to the mesh, if I do not convert my own colors from sRGB to linear, it gets washed down. This does not happen with UI elements, or with the image plot. In fact I built the same thing for a mesh and an image plot, and noticed instantly that the fix I used for the mesh was making the image colors look bad, it eats sRGB colors. I'm having the exact same result on image vs mesh with this correction.

I suggest for now, as I wrote in the PR, that we just warn people that it needs colors in linear colorspace. Otherwise change the pygfx color transform that it's applying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants