Replies: 1 comment 4 replies
-
|
The behavior is "experimental." To be completely transparent, I don't believe the math is accurate either way. Anyway, I think it's better to keep view dependent color and base color separate for now (e.g., it can be useful to desaturate spherical harmonics in isolation). If you want to constrain them, use channel expressions from a |
Beta Was this translation helpful? Give feedback.
-
|
agreed on keeping f_dc and f_rest separate, but it seems keeping f_dc around is useful for regenerating Cd at later steps in a network might be useful... as a data point: o3-mini thinks HSV adjustments directly on the coefficients is wrong ("because the SH expansion is a linear projection of a spatial function, and nonlinear color operations (like hue rotation) do not translate simply into linear operations on the coefficients"), instead should be done as a postprocess after the color is determined based in the complete set of SH coefficients. But it would be possible to generate new coefficients based on a complete set of color corrected outputs (via sampling the new color sphere) detailed reasoning here: |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for sharing this. Yeah, the UX isn't quite ironed out yet. Ideally, we could fetch the rasterized splats directly in Copernicus, but this isn't yet possible. The cc @rubendhz what do you think? I remember us discussing including |
Beta Was this translation helpful? Give feedback.
-
|
If I understood correctly, the main question here is whether we should always keep the original/unmodified color attribute alongside the "main" one (that might have been modified, including with potentially incorrect operations). Also, I see this question as independent from whether we use Inria's naming convention or Houdini's, or stored in SH (
^ This is literally this operation When a splat model is rotated, there's no point in keeping the original SHs around, only the rotated ones. Ideally we think of color adjustments the same way, if an operator has done something to color (assuming operation is correct), original value becomes irrelevant. If user really wants to keep original color value (prior to the operation), it'd be on their plate to duplicate/rename the original attribute. I often do this to compare results or other purposes. My preference is not to duplicate color values, and only have |
Beta Was this translation helpful? Give feedback.
-
Sounds good--thanks for your input! |
Beta Was this translation helpful? Give feedback.
-
From my understanding we have 2 components to the SH data in the original INRIA style 3dgs data - f_dc_ (direct SH component, 0-order, ie base colour) and then f_rest_ (higher order SH coefficients, view dependent color data). When loading the data, f_dc is transformed into Cd, f_rest ends up in the sh_coefficients array.
Subsequent operations on the SH data seem to only operate on the view dependent part, ignoring the direct component. An example would be 'gaussian splat attribute adjust' - if you do an hsv adjust, it only modifies f_rest, but ignores f_dc (or color).
Is this behavior intentional?
Beta Was this translation helpful? Give feedback.
All reactions